-
Notifications
You must be signed in to change notification settings - Fork 17
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
Numlock key is double-registering and therefore not working #74
Comments
Current contents of the raw-keymap section of config.ini:
|
Here the corresponding debug log bits for barrier on the server side would be useful, at least for now (I should probably add a provision for more information to the waynergy logging to prevent necessitating this). Thank you for reporting these issues, by the way; it is extremely useful to get data points for configurations I don't really use myself. |
I can't figure out how to get useful debug output from Barrier when I hit keys on the keyboard. I can get it to show me when the mouse (and thus its focus) leaves and enters each connected screen, or grabs the clipboard etc, but not show output on each keystroke the way waynergy does. Do you know how I can get you the information you're asking for? Right now the debug output on the Barrier side when I hit the numlock key is, effectively, |
I think I got it:
It does not seem to double-register the button-press on the Mac. |
This will log things at the synergy protocol level, which would normally be overkill but given recent issues like #74 it would actually be quite useful.
The mouse bits are commented out for now, as this is strictly for #74 debugging at the moment, but just in case I'll leave them for easy reactivation later.
|
Here's what I got when I hit numlock:
|
Issue #74 showcases the need to allow for improperly-duplicated keys to be dropped. id maps will already take precedence, but we need to ensure that anything else is ignored.
For some reason Barrier is duplicating the button, while sending with a key id of 0, which probably shouldn't be happening. In any case, a workaround. In new latest master, keys should now be dropped by mapping to
This is a simpler variant of what I'd posted earlier, which makes things slightly less confusing. |
That fixed it! |
Keyboard shortcut processing will prevent certain keys from registering with waynergy-mapper, and, in the case of #74, triggers quite undesirable behavior when the keys differ wildly from the server. Using the keyboard shortcut inhibition protocol, this should hopefully eliminate this and make keymap generation much smoother.
Host: Mac OS with Barrier
Client: Arch Linux with KDE backend
Here is the debug output from waynergy when I hit the numlock key a single time on the host machine's USB keyboard:
I'm not sure why this is double-registering or what to do about it. Currently, as you might expect, the numlock key effectively does nothing and I cannot activate it.
The text was updated successfully, but these errors were encountered: