keyboardio
Keypresses are wrong over RDP
Hi When pressing {, } or | (fn+ u, i, -) the order of the events seems to be either inconsistent or just plain wrong. On connections via RDP this makes some keypresses output the wrong key. Pressing { might yield [ sometimes. } => ] and | => .
Attaching 'xev' logs of fn+- (fn and dash).
On physical machines - the mapping is always OK. Using VMWare PCoIP mapping is OK Using Physical -> RDP mapping is BAD Using Physical -> VMWare PCoIP -> RDP mapping is BAD
You can see that most keypress events are "|" but some are on ""
I've also seen the ordering of key-release \ come both after and before key-release Lshift
What can I do ?? keyboardlogs.txt
I think this is the same issue we've seen before with Remote Desktop, where USB HID reports are transmitted at a lower rate, and get squashed, dropping information. If the modifier keycodes are processed after the printable ones (because they have higher numbers, perhaps), that would probably explain the observed behaviour, because sometimes the two reports for Key_LeftCurlyBrace straddle a report interval boundary, and sometimes they don't.
If I'm right, I would call that a bug in Remote Desktop. The only way I can think of to work around that is to introduce a configurable delay so that Kaleidoscope won't send a subsequent report until the defined interval has passed. We tried something like that a while back, but it causes other problems…
Anything I can do ? RDP wise or config/firmware wise? I work via RDP all day and this is driving me insane. I am OK with testing/flashing new fw/modifications to see how it changes behavior
I wrote a PR for KeyboardioHID (https://github.com/keyboardio/KeyboardioHID/pull/30) a while ago meant to address this issue. It's probably out of date enough that it needs rebasing before it could work. It will be a couple of weeks before I can do anything more about it, but you can feel free to give it a try in the meantime.
Another (maybe obvious) data point:
If I press shift + fn + u then I see in xev that the L-shift release event is not triggered, and the key printed is always {
This became worse and worse over time at my company with varying latencies over RDP. It turns out that there's a setting to resolve modifier keys on the local machine; so the bug in RDP is no longer relevant for me..
Can you describe how to change the setting? It would be very useful to other people who are having this problem.
Doing a bit more reading, this issue apparently afflicts some folks with regular keyboards too, though what we're doing clearly exacerbates the issue.
I've found some additional resources. I'm reopening this issue to at least be able to track this problem.
One -possible- solution described by a random internet user: To change the setting:Open Remote Desktop Client.Do not connect to a remote host, yet.Click button Options.Open tab Local Resources.Choose option "On this computer" in drop-down list Apply Windows key combinations.(from https://superuser.com/questions/219461/shift-and-control-keys-out-of-sync-with-normal-keys-over-rdp) Other resources I've found, just for reference: https://superuser.com/questions/1011701/windows-10-remote-desktop-alt-tab-winm-problems?rq=1
TL;DR: Synergy could be breaking it if you have that set up as a soft kvm. https://support.citrix.com/article/CTX110281 TL;DR: Citrix agrees with superuser post https://www.jigsolving.com/jigsovling/shift-key-not-seem-work-full-screen-mode-remote-desktop-sometimes TL;DR: Same proposed solution https://support.microsoft.com/en-us/help/2847932/language-switch-fails-in-a-rd-session-and-shortcut-menu-is-not-display TL;DR: There was a hotfix for Windows 7. https://answers.microsoft.com/en-us/windows/forum/all/remote-desktop-synchronization-of-modifier-keys/ab070367-83d8-450c-946d-f9af0c7d063b TL;DR: Someone else complaining about this issue on a regular keyboard
Unfortunately I'm regularly hitting this issue when using RDP. I've tried the Local Resources setting but it breaks other key combinations so I don't think it's a solution for me. I've also upgraded to Windows 10 20H2 and it's still an issue.
Would my next step be to try a delay as suggested in keyboardio/KeyboardioHID#30? I've read through those comments but I'm not really sure where to start, so any pointers would be gratefully received.
