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

Keypresses are wrong over RDP #87

Open
DavidVentura opened this issue Jul 8, 2019 · 8 comments
Open

Keypresses are wrong over RDP #87

DavidVentura opened this issue Jul 8, 2019 · 8 comments

Comments

@DavidVentura
Copy link

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

@gedankenexperimenter
Copy link
Contributor

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…

@DavidVentura
Copy link
Author

DavidVentura commented Jul 8, 2019

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

@gedankenexperimenter
Copy link
Contributor

I wrote a PR for KeyboardioHID (keyboardio/KeyboardioHID#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.

@DavidVentura
Copy link
Author

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 {

@DavidVentura
Copy link
Author

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..

@gedankenexperimenter
Copy link
Contributor

Can you describe how to change the setting? It would be very useful to other people who are having this problem.

@obra
Copy link
Member

obra commented Jun 25, 2020

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

@obra obra reopened this Jun 25, 2020
@sparkleblue
Copy link

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.

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

4 participants