fix pairing with Linux hosts #1108
Conversation
|
@mondalaci @mhantsch please test these potential fixes in this order and give feedback: https://github.com/UltimateHackingKeyboard/firmware/actions/runs/13069715914/artifacts/2515801778 |
|
@mondalaci 12.3.2 did not resolve this; I tried it last night. Instead, when I try to initiate a pairing request, the right half reboots. I'll try the newer builds soon. I'm not near the UHK80 right now. |
|
See this video: https://photos.app.goo.gl/LmmP42BY8fz2Z35x7 taken with UHK fw 12.3.2. As soon as I click the UHK 80 entry in the bluetooth panel, the spinner appears while the host is trying to connect. At the same time, the UHK reboots, and the spinner stops again and reverts to "Not set up". Pop_OS! 22.04 on Framework 13 laptop. I have zero issues with all my other Bluetooth devices (mice, ErgoTravel keyboard running ZMK, BT speakers, headsets etc.). They all connect, pair and work fine. |
|
Thanks for sharing! Waiting for your findings regarding the new firmware builds. |
|
Neither of the two builds shows any visible change in behaviour. First, I see two entries for UHK80. We've discussed this before - one is the correct one for the HID connection from the right half, but I also see a second one also called "UHK 80". I know if I click the wrong one it immediately goes back to "Not set up" after only a split second. So I can rule that one out. When I click the other one (the correct one), the spinner occurs for a little longer. Sometimes for a very brief moment, the UHK displays the pairing code screen, but often it doesn't get to that or it's too short to be able to notice. Then the right half restarts: the displays goes blank for about 1 second and then it comes back up with the main screen showing the keymap and connection name, and the indicators start lighting up. All the builds I have tried behave the same. Further noticed: after flashing the firmware through Agent, agent reports correct firmware versions, and the flashing log shows that the flash was correctly finished for both halves, but the left half behaves weirdly. It starts blinking the backlight at intervals as if it were rebooting every few seconds, some of the light comes on in incorrect colours, and generally, the left half is not working. This may go away if I disconnect the spiral cable. Flashing the firmware a second time fixed this. Generally, sometimes the keyboard misbehaves with the two halves seemingly not communicating correctly with each other. If I disconnect the spiral cable, it may start working again. If I then connect the spiral cable again, the problem might come back, or it often starts working again. I know this is being addressed by karel in another issue; just wanted you to know that a) these problems are in these bluetooth test builds too, and b) they make testing really difficult because after flashing a new build, first I have to work through lots of other unrelated bugs until I can be sure that the keyboard actually works now (to a meaningful extend) and I can start the actual test that I intend to execute (e.g. start testing the bluetooth host connection). |
|
At least for our testing it would be useful if you could rename those multiple "UHK 80" connections so that it is obvious which one is the HID connection from the right half, and what the other one is. I know you intend to send correct advertisement parameters so that only the correct connection is shown, but until that works correctly can you help out a bit by giving the "other" connection a different name, e.g. "UHK 80 internal" or something like that? |
|
@benedekkupper Would you look into this again? We can take small steps per PR. For one, it'd be very helpful to expose only a single BLE device instead of two: #999 (comment) |
|
The names cannot be different, but next week I do want to look into removing the NUS advertisement info altogether from the right side, as this might be the root cause of #990 as well - but this change requires rework on the dongle side as well (and has a potential to break the left-right BLE pairing too), so not trivial to carry out. |
|
I have physically isolated the left and right halves, and as it turns out, the extra "UHK 80" belongs to the left half, so it must be the NUS server of the left half that connects to the NUS client of the right half.
If I'm not mistaken, the NUS server should not be scannable and it should be a directed connectable (ADV_DIRECT_IND) instead, but @benedekkupper probably knows better than me. |
|
By the looks of it, #1110 may be related. |
Closes #999