-
Notifications
You must be signed in to change notification settings - Fork 0
Conversation
6598fbe
to
424fb1e
Compare
@mondalaci please test all outstanding USB issues with this branch: mouse stuck, wakeup, text macros garbled |
I get the following, and it keeps crashing in every second:
Can you reproduce it? |
I need more information on how exactly you have performed the programming. For me the right half is working, but I'm using simple west flash command. Sidenote: The "factory default" config is producing false key presses (at least a month or so before, when I pressed the keys, the right characters were sent, now they have been mixed/shifted around). |
Thanks for revealing UltimateHackingKeyboard/firmware#967! We'll fix it, and then the factory keymap's scancodes will be as expected. In the meantime, you can use Agent to save the user configuration, which fixes the scancodes on your UHK 80, although I think you only use it for development. All things considered, this PR is a huge step forward. The good:
The bad:
|
I forgot to tell that I did a |
ce602b2
to
297f5c4
Compare
@benedekkupper Please let me know when I can re-test this issue. The mentioned "BLE pairing doesn't work anymore" issue may not be an actual issue and may be due to UltimateHackingKeyboard/firmware#1022. The mouse pointer issue, however, is an actual issue that must be fixed. |
297f5c4
to
b8e4aa5
Compare
@mondalaci please go ahead and give this a try. Further development:
|
I checked out the repo using the usual steps in the README, but right after cloning it, I switched to this PR. The "Build UHK 80 right firmware" task failed:
Even from the command line, the build failed:
|
b8e4aa5
to
e8ed467
Compare
I added some changes to address this, please check again. |
The build succeeded and after flashing it, my UHK kept crashing:
Then I ran
|
This is not happening on my side, so if you can share more details about your setup that would be great. I pushed a commit that should help print where the assert() is coming from. |
|
cf9100d
to
0d546de
Compare
Thanks for the log, this helped me pinpoint and fix the issue. Care to take another shot at it? :) |
Crashing has been fixed, and the good and bad mentioned in #353 (comment) is unchanged. According to Android, the UHK is connected after pairing, but the UHK displays Disconnected, and UHK key presses don't affect my phone. This persists: Upon wake up, if I move the mouse pointer with any right module, such as the trackpoint module, the mouse pointer moves very quickly. If I stop moving the trackpoint, the mouse keeps moving in the last direction until I press a key or trigger a mouse action with a mouse key (on the mouse layer). I can only fix this behavior by resetting the right keyboard half. |
@benedekkupper Is there any reason why you can't test the persisting issues? I'm asking because testing them is time-consuming. It would be much better if you could test them and only let me know when they're resolved. |
The reason I ask you to test is because I don't experience the issues that you report (anymore), there was a problem with the BLE report sending similar to what you saw, that I fixed. I myself don't have any modules to test mouse movement with, so if you have a suggestion how to simulate it, then I can check it. I have tried the BLE connection with Windows and Android, both are fine for me now.
Is this something that affects both BLE and USB, or only BLE? |
@kareltucek I can't use this branch with BLE. Please test BLE. I'm asking because I suspect a higher-level firmware issue is the culprit, not c2usb. @benedekkupper We'll ship you modules. |
I can connect to Android phone, and input works, except cursor movement tears very much and the phone as a whole becomes laggy. When trying to connect from a linux laptop, UHK disconnects:
The first three attempts are from laptop, the last one is from the phone. I am not sure why security fails with error 9 from laptop, but upon receiving the security_changed with level 1, we are indeed disconnecting - both because of security level 1, and because of receiving an error. Is that what you asked about? Otherwise, please clarify your question. |
21ce474
to
42f2cbc
Compare
Actually the most recent nRF Connect VSCode extension is able to do the whole build flow for me. Two things to pay attention to when setting up the build configuration:
Since I have no leads on what's wrong (I got the modules, but the cursor movement seems fine for me on Android, behaves just like a normal mouse cursor), instead I started to trim down on which BT features are active for which board. For that I needed to also modify the source code with precompiler switches, and more targeted cmake configuration (though this is not complete work, device/src/CMakeLists.txt should have no GLOBs in the final solution). For some reason the disabling of the USB interface during BLE HID operation was removed, I restored it. There's a lot of new things going on with the BT connection management since I last saw it, probably coming from the OOB pairing implementation? |
Current bt code naively assumes that whenever a BLE connection is unidentified, it is a BLE HID connection. This is not always the case. If a dongle bonding gets removed/corrupted on right half side, then dongle is identified as a BLE HID connection. When this happens, we want to recover the dongle via Agent, but disabling USB HID instantly disconnects Agent on dongle connection, which makes it impossible to recover such a dongle. (Less importantly, the same goes for establishing a new BLE HID connection - we want to register it in host connections, but that is not easily possible since (again) when the BLE HID connection is established, Agent gets cut off.) I am not at all clear on why we would want to disable USB HID when BLE HID gets connected. Maybe the
Yes. They mostly deal with following:
(Up until OOB pairing implementation, new settings were done by rebooting the board.) (Definitely feel free to refactor / fix them. I know my bt code is not a very good one.) |
Now, I can connect via BLE to my phone. The pointer drifting issue persists. Here's how to reproduce it:
|
@kareltucek can you instruct me on how to test this scenario of dongle connection corrupted, and manually reestablishing paired state with it? |
This reverts commit d833820.
also update battery level on BLE
motivation: my debugger cannot open and track symlink source files The new solution is to move all code (except main.c) into "uhk" and "uhk-shared" libraries, whose top cmake file is at the root of the codebase.
cbcbbac
to
08d28d9
Compare
I think I fixed the dongle LED problem (I also moved the LED voltage fix to this branch), please check it. |
Repeating #347, which itself was a combination of #319, #331 and #346