UHK-60: fix mouse high-res scrolling for Linux #1216
Conversation
benedekkupper
force-pushed
the
high-res-scrolling-linux-fix
branch
from
f5e73bb to
fd78074
Compare
|
On Linux, scrolling in vscode was already smooth, but not in Chrome. This PR also makes scrolling smooth in Chrome. On Windows 11, however, scrolling was smooth in Chrome, but now it's choppy. This must be fixed. on macOS, scrolling is unchanged. |
benedekkupper
force-pushed
the
high-res-scrolling-linux-fix
branch
from
ffc6c63 to
d9f9020
Compare
|
Please check the new build |
|
Now, the choppiness persists on Windows, and the smoothness is gone on Linux-Chrome. So, the current state is a step backward compared to your earlier commit, and it reflects master. macOS is unchanged. |
benedekkupper
force-pushed
the
high-res-scrolling-linux-fix
branch
from
d9f9020 to
cdc289b
Compare
|
@benedekkupper Should I test this again? |
|
No, I just rebased so I could flash it with agent, but I observe the same behavior. I failed the disassembly to solder the debug connection, so I’m kind of blocked on UHK-60 for the time being. |
This reverts commit a427453.
The Linux kernel sends 0 length SetReport request for the high-res multiplier feature, when the report descriptor doesn't use report IDs. Define an ID, which also must be used for the input report.
It wasn't implemented properly, but since nobody noticed, better to indicate to the host that it's not available.
benedekkupper
force-pushed
the
high-res-scrolling-linux-fix
branch
from
cdc289b to
042d338
Compare
|
With the debugging infrastructure set up, I was able to trace the remaining issue in this PR, and now it should work just as it does on UHK80. @mondalaci @rightaditya please try this out. |
|
That bug - #1261 - is present on uhk80 too. (Unless this pr fixes it.) |
|
@benedekkupper What's the rationale for fixing MCUXpresso SDK USB descriptors if the UHK 60 firmware will be ported to c2usb anyway? |
|
It's an interim fix, since it was in progress anyway I thought I will clear this up, as getting to c2usb on kinetis might take a longer time. For the suspend issue, I cannot reproduce myself, because both my Linux systems (old Thinkpad laptop, RPi 400) don't have working suspend mode. |
|
I can reproduce it with my home laptop. Works fine with the other one though. Both linuxes. |
|
I.e., I can provide logs. I will be away from friday for a week though. |
@benedekkupper I'm out of town at the moment but can give it a go over the weekend. |
@benedekkupper Thanks for reporting it! I considered it but didn't really want to interact with LKML, especially since I wasn't 100% confident about what was going on. Glad to see the issue officially documented... hopefully something will come of it. |
Please double-check this, as high-res scrolling now works consistently across OSes for me. |
|
If this branch in its current state still produces the scrolling problem after a suspend-wakeup cycle, a brute-force way to solve #1261 is to do a USB soft disconnect-reconnect after wake. We can already identify when the keyboard is plugged into a Linux host (mouse scroll multiplier set, no MSOS descriptor fetched), and limit this functionality to it. |
|
I gave this branch a quick test with UHK80 first, not realizing that this PR tires to fix only the uhk60 variant of the bug. It makes cursor shoot at roughly 200x its normal speed. As for UHK60, mouse speed after a clean boot is fine. After suspending the host, the leds go out at first, then briefly flash twice, then the board reboots. |
4 participants
There is a Linux bug that I reported, the kernel incorrectly calculates the size of the set report payload when there is no report ID, ending up with a 0 length payload. This is what @rightaditya worked around with by accepting set report with no data. The reason no such workaround is necessary on UHK80 is because there we use report IDs. I changed the UHK60 implementation to have a report ID, so Linux sends correct payloads, and we can eliminate the guessing logic.