Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Second HOGP connection does not fire events #663

Open
Slion opened this issue Feb 18, 2025 · 7 comments
Open

Second HOGP connection does not fire events #663

Slion opened this issue Feb 18, 2025 · 7 comments

Comments

@Slion
Copy link

Slion commented Feb 18, 2025

Pico 2 W SDK 2.1.0-develop

Two devices are paired with the board. One Logitech LIFT Mouse and one Lenovo ThinkPad TrackPoint Keyboard II.

The board boots then starts scanning for known devices. We activate the keyboard which reconnects fine. Then we move the mouse which fails to reconnect properly. Though encryption is resumed, GATTSERVICE_SUBEVENT_HID_SERVICE_CONNECTED is never fired for the second device, nor did we get any error message. Looking at the HCI traffic though I'm guessing the mouse is connected too but events don't fire as they should.

If we connect the mouse first the keyboard won't connect as second device. So it's not device specific.

ble-2x-fail.zip

@Slion Slion changed the title Second HOGP connection does not fire event Second HOGP connection does not fire events Feb 18, 2025
@mringwal
Copy link
Member

mringwal commented Feb 19, 2025 via email

@Slion
Copy link
Author

Slion commented Feb 19, 2025

MAX_NR_HIDS_CLIENTS is set to 8 and hids_client_connect returns ERROR_CODE_SUCCESS. The remote device thinks it is connected, solid LED, the HCI logs activity when moving the mouse tells me the reports are received but no HIDS events are coming through for some reason. Feels like a state management issue in btstack.

@Slion
Copy link
Author

Slion commented Feb 19, 2025

In the log HCI LE Set Scan Params is called with Scan Interval = 0x0002, which is outside the allowed range and the Controller returns an error.
I've updated the gap_set_scan_params function to validate the params, but you still need to check the return status.
That's why scan with whitelist hasn't worked for you - the 'use whitelist' was never active.

Thanks, I've changed the scan interval to 4 then. The specs mention 1.28s that's why I used 2. That does not help connecting to a second device though.

@Slion
Copy link
Author

Slion commented Feb 20, 2025

Same issue when using gap_connect_with_whitelist instead of an actual scan. This one shows logs of two Logitech Lift mouse. One for the left hand and one for the right hand. So very similar devices. When the second device connects encryption resumes, I call hids_client_connect and then nothing. I don't get any events anymore. Though the second device thinks it is connected, showing a solid LED and it looks like btstack even gets the reports but don't route them to the client.

ble-2x-lift-fail.zip

@Slion
Copy link
Author

Slion commented Feb 20, 2025

For the first successful device we get the following after the controller reads the Device Name:
279 10.882000 controller host HCI_EVT 13 Rcvd LE Meta (LE Connection Update Complete)
Then the Pico does:
280 10.916000 RaspberryPi_b7:73:ff (HID Proxy) d5:04:3a:2d:0c:43 () ATT 18 Sent Find By Type Value Request, Primary Service, Handles: 0x0001..0xffff
Then Pico goes on to read the Report descriptor from the controller.

For the second device after:
821 30.316000 controller host HCI_EVT 13 Rcvd LE Meta (LE Connection Update Complete)
Then Pico just falls silent instead of following the same protocol as for the first device.
From this point on you only get the mouse report being sent by the controller.
The Pico has established the connection like I thought but failed to fetch the Report descriptor like it did for the first device.
It really looks like an issue with the state of the HID client.

@Slion
Copy link
Author

Slion commented Feb 20, 2025

If I enable ENABLE_TESTING_SUPPORT I get the following for the first device:

Query Services:
HID Service: start handle 0x001F, end handle 0x0035


Query Characteristics of service 0:
HID Characteristic HID_INFORMATION:  
    Attribute Handle 0x0020, Properties 0x02, Handle 0x0021, UUID 0x2A4A, service 0
HID Characteristic BOOT_MOUSE_INPUT_REPORT:  
    Attribute Handle 0x0022, Properties 0x12, Handle 0x0023, UUID 0x2A33, service 0, report index 0x00
HID Characteristic REPORT_MAP:  
    Attribute Handle 0x0025, Properties 0x02, Handle 0x0026, UUID 0x2A4B, service 0
HID Characteristic REPORT:  
    Attribute Handle 0x0027, Properties 0x12, Handle 0x0028, UUID 0x2A4D, service 0, report index 0x01
HID Characteristic REPORT:  
    Attribute Handle 0x002B, Properties 0x12, Handle 0x002C, UUID 0x2A4D, service 0, report index 0x02
HID Characteristic REPORT:  
    Attribute Handle 0x002F, Properties 0x0E, Handle 0x0030, UUID 0x2A4D, service 0, report index 0x03
HID Characteristic HID_CONTROL_POINT:  
    Attribute Handle 0x0032, Properties 0x04, Handle 0x0033, UUID 0x2A4C, service 0
HID Characteristic PROTOCOL_MODE:  
    Attribute Handle 0x0034, Properties 0x06, Handle 0x0035, UUID 0x2A4E, service 0


Read REPORT_MAP (Handle 0x0026) HID Descriptor of service 0:
05 01 09 02 A1 01 85 02 09 01 A1 00 95 10 75 01 15 00 25 01 05 09 
19 01 29 10 81 02 05 01 16 01 F8 26 FF 07 75 0C 95 02 09 30 09 31 
81 06 15 81 25 7F 75 08 95 01 09 38 81 06 95 01 05 0C 0A 38 02 81 
06 C0 C0 06 43 FF 0A 02 02 A1 01 85 11 75 08 95 13 15 00 26 FF 00 
09 02 81 00 09 02 91 00 C0 

Discover REPORT_MAP (Handle 0x0026) Characteristic Descriptors of service 0:

Query Report Characteristic Descriptors [1, 0, 0x0028]:
    Report Client Characteristic Configuration Descriptor: Handle 0x0029, UUID 0x2902
    Report Characteristic Report Reference Characteristic Descriptor:  Handle 0x002A, UUID 0x2908
    Update report ID and type [2, 1] of report index 0x01, service index 0x00

Query Report Characteristic Descriptors [2, 0, 0x002C]:
    Report Client Characteristic Configuration Descriptor: Handle 0x002D, UUID 0x2902
    Report Characteristic Report Reference Characteristic Descriptor:  Handle 0x002E, UUID 0x2908
    Update report ID and type [17, 1] of report index 0x02, service index 0x00

Query Report Characteristic Descriptors [3, 0, 0x0030]:
    Report Characteristic Report Reference Characteristic Descriptor:  Handle 0x0031, UUID 0x2908
    Update report ID and type [17, 2] of report index 0x03, service index 0x00

Register for Notifications: 
    Notification enable [1, 0, 0x0028]:
    Notification enable [2, 0, 0x002C]:

For the second device all I get is:

Query Services:

@Slion
Copy link
Author

Slion commented Feb 20, 2025

My issue was that my config was setting MAX_NR_GATT_CLIENTS to 1 when you need at least one of those per HID connection. Then I'm guessing I will also need one extra per connection if I want to connect to the battery service too.

It would be nice to have some error logs when running into such issues to save developers time. So in gatt_client_provide_context_for_handle it could look like:

    gatt_client = btstack_memory_gatt_client_get();
    if (gatt_client == NULL){
        *out_gatt_client = NULL;
        log_error("No enough GATT clients, see MAX_NR_GATT_CLIENTS");
        return ERROR_CODE_MEMORY_CAPACITY_EXCEEDED;
    } 

We could even have some compile time warnings or errors like:

#if MAX_NR_HIDS_CLIENTS>MAX_NR_GATT_CLIENTS
#warning "BLE: You need at least one GATT client per HID client"
#endif

Also consider having hids_run_for_client return an error code and propagate the unused att_status from gatt_client_discover_primary_services_by_uuid16 up all the way to hids_client_connect return value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants