[Bug]: uni_bt_stop_scanning prevents already-paired Xbox One controller from connecting

[elipsitz]

What happened?

If I set uni_bt_stop_scanning_unsafe(false) and uni_bt_allow_incoming_connections(true) in platform_on_init_complete, I intend to prevent new, unpaired gamepads from connecting, but allow connections from already-paired ones.

This works exactly as expected for a Joycon (BT classic), but doesn't work for an Xbox One controller (v5 firmware, BLE). The Xbox one controller won't connect (even though the key is saved) until I then go and call uni_bt_start_scanning_safe(true) later. Then it connects fine.

See logs showing that the gamepad is saved in Bluetooth LE keys. Note that there are no log messages about the Xbox controller being discovered or anything, even when I turn on the device.

Bluepad32 Version

Other

Bluepad32 version custom

4.2.0 (6efa7123fe8badf5a40ad1205743a80b31c00ea4) (not listed above)

Bluepad32 Platform

Pico SDK

Platform version

Pico SDK 2.1.1

Controller

Xbox One 1914 using firmware 5.9.2709.0

Microcontroller

Pico W

Microcontroller board

Pico W

OS

macOS

Relevant log output

[09:15:49.502] Bluepad32 (C) 2016-2025 Ricardo Quesada and contributors.
[09:15:49.507] Version: v4.2.0
[09:15:49.509] BTstack: Copyright (C) 2017 BlueKitchen GmbH.
[09:15:49.513] Version: v1.6.2
[09:15:49.514] Platform: 
[09:15:49.517] bluetooth: init()
[09:15:49.518] Max connected gamepads: 4
[09:15:49.521] BR/EDR support: enabled
[09:15:49.524] BLE support: enabled
[09:15:49.525] Device ID SDP service record size: 64
[09:15:49.528] Gap security level: 2
[09:15:49.530] Periodic Inquiry: max=5, min=4, len=3
[09:15:49.879] Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879
[09:15:50.096] cyw43 loaded ok, mac 28:cd:c1:0a:19:36
[09:15:50.100] BT FW download, version = CYW4343A2_001.003.016.0065.0000_Generic_SDIO_37MHz_wlbga_BU_RPI_dl_signed
[09:15:50.409] No TLV for bp.bt.allowlist, returning default value '(null)'
[09:15:50.415] Bluetooth Allowlist: Disabled
[09:15:50.568] HCI not ready, cannot send packet, will again try later. Current state idx=0
[09:15:50.676] HCI not ready, cannot send packet, will again try later. Current state idx=1
[09:15:50.683] bluetooth: on_init_complete()
[09:15:50.686] Bluetooth BR/EDR keys:
[09:15:50.687] Bluetooth LE keys:
[09:15:50.690] 14:CB:65:FD:72:2B - type 0
[09:15:50.693] .
[09:15:50.693] my_platform_on_oob_event: Bluetooth enabled: 0
[09:15:50.697] properties:
[09:15:50.698] bp.bt.allow_en = false
[09:15:50.699] No TLV for bp.bt.allowlist, returning default value '(null)'
[09:15:50.705] bp.bt.allowlist = <empty>
[09:15:50.707] bp.ble.enabled = true
[09:15:50.709] bp.gap.inq_len = 3
[09:15:50.712] bp.gap.level = 2
[09:15:50.713] bp.gap.max_len = 5
[09:15:50.714] bp.gap.min_len = 4
[09:15:50.716] bp.mouse.scale = 1.000000
[09:15:50.718] No TLV for bp.version, returning default value '4.2.0'
[09:15:50.724] bp.version = '4.2.0'
[09:15:50.725] bp.virt_dev_en = false

Relevant sketch

static void platform_on_init_complete(void) {
    logi("bluetooth: on_init_complete()\n");

    uni_bt_list_keys_unsafe();

    uni_bt_stop_scanning_unsafe();
    uni_bt_allow_incoming_connections(true);

    uni_property_dump_all();
}

[jfedor2]

That's just how Bluetooth LE works. The peripheral advertises, the central scans and initiates the connection. You can't connect without scanning.

[elipsitz]

Sure -- I think the behavior that the library exposes is a bit counterintuitive then. If uni_bt_allow_incoming_connections(true) is supposed to allow connections from known devices (but not new ones), it should still scan for BLE devices (if that's required), and just not connect to any devices that it discovers that it doesn't already know.