-
Notifications
You must be signed in to change notification settings - Fork 282
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
Plover only handling 6 keys for NKRO keyboard #644
Comments
Can you test on Windows as well? |
I'd also appreciate if you could confirm that NKRO works on something like the browser test page here: http://www.gigahype.com/nkey-rollover-test-page/ |
@morinted Unfortunately I cannot test on Windows as I do not have access to a Windows machine. From testing on that site (and others, including local software) the NKRO works fine. I only experience the issue in Plover. |
This is a long shot, for sure, but there have been many changes in how we handle the keyboard in Linux in the past year. Would you be able to try 2.5.8 and see if the issue existed back then, too? Thanks for the feedback that the website works. |
@morinted Okay, it appears to work with version 2.5.8. Also, I was having a look around and found this reference to a similar issue in the past: #60 (comment) Edit: It also works on v3.0.0 |
@morinted I've narrowed it down a bit more and it looks like in |
What's the output when you press one of those combos that don't work with Plover while running: |
@benoit-pierre It appears to only recognize the first 6 keys:
I've also tried |
Can you upload the full output? Also what does |
@benoit-pierre That is the full output from Output from
|
What I was trying to determine is if the keyboard driver does some ugly things like creating new devices dynamically to work around the core HID limitations of 6 keys + modifiers. Anyway, I've checked the source code for |
@benoit-pierre Okay, thanks for looking into this. I've opened a bug over on the bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=98762 |
@benoit-pierre Thanks to Peter Hutterer's help it looks like this isn't an issue with xinput, and he did have the following comment:
Are we listening to the slave devices directly? Do we handle the XIDeviceChangedEvent events? |
I'm confused, reading the comments on the Freedesktop bug report, it looks like |
@benoit-pierre The keyboard exposes two devices, but I was only listening to one before. The output works with no devices specified, and if devices
Could we not just explicitly ignore events from the XTEST keyboard? |
No, it's not that simple, we also need to suppress the right devices. Anyway, if device 11 sends keyboard events too, then it is a bug in Xinput! No? It's a pointer device! Does it change class dynamically? Is that what happen? Please give me the full output of running |
Output from
Output from
Output from
Output from
|
Ah, right! If you add support for SlavePointers it works! 😄 Seems like an odd way to implement the NKRO though. Is this an acceptible solution? I can make a PR if you wish. |
Yeah, it's not pretty... Does it work with this patch: diff --git i/plover/oslayer/xkeyboardcontrol.py w/plover/oslayer/xkeyboardcontrol.py
index 3f61cce..b898862 100644
--- i/plover/oslayer/xkeyboardcontrol.py
+++ w/plover/oslayer/xkeyboardcontrol.py
@@ -172,6 +172,9 @@ class KeyboardCapture(threading.Thread):
# Find all keyboard devices.
keyboard_devices = []
for devinfo in self.display.xinput_query_device(xinput.AllDevices).devices:
+ if devinfo.use == xinput.MasterPointer:
+ keyboard_devices.append(devinfo.deviceid)
+ continue
# Only keep slave keyboard devices.
if devinfo.use != xinput.SlaveKeyboard:
continue ? |
@benoit-pierre I was thinking more along the lines of updating It doesn't appear to work with that patch (though it does with my earlier suggestion). |
Which I'm trying to avoid so we don't end up with a boatload of pointer devices added to the list we need to suppress (and the amount of requests we need to make when enabling/disabling output). |
But then again the list is already pretty long with the slave keyboards... |
Does the pointer device have a diff --git i/plover/oslayer/xkeyboardcontrol.py w/plover/oslayer/xkeyboardcontrol.py
index 3f61cce..d48e3b7 100644
--- i/plover/oslayer/xkeyboardcontrol.py
+++ w/plover/oslayer/xkeyboardcontrol.py
@@ -173,7 +173,7 @@ class KeyboardCapture(threading.Thread):
keyboard_devices = []
for devinfo in self.display.xinput_query_device(xinput.AllDevices).devices:
# Only keep slave keyboard devices.
- if devinfo.use != xinput.SlaveKeyboard:
+ if devinfo.use not in (xinput.SlaveKeyboard, xinput.SlavePointer):
continue
# Ignore XTest keyboard device.
if 'Virtual core XTEST keyboard' == devinfo.name:
@@ -181,6 +181,12 @@ class KeyboardCapture(threading.Thread):
# Ignore disabled devices.
if not devinfo.enabled:
continue
+ for c in devinfo.classes:
+ if c.type == xinput.KeyClass:
+ print('%s [%u]: %u keycode(s)' % (devinfo.name, devinfo.deviceid, len(c.keycodes)))
+ break
+ else:
+ continue
keyboard_devices.append(devinfo.deviceid)
if XINPUT_DEVICE_ID == xinput.AllDevices:
self.devices = keyboard_devices ? |
@benoit-pierre It looks like it! It also looks like 9/12 devices make it into the print, including both the USB keyboard devices. |
Classification: Bug
Reproducibility: Always
Summary
I'm using a VicTop mechanical keyboard with NKRO on Linux Mint (17). The NKRO features works fine on pretty much everything except Plover. Plover will only register 6 keys at a time which makes it a pain to type!
Steps to Reproduce
Expected Results
Actual Results
Version
Plover version 3.1.0
Installed via: GitHub
Notes
Configuration
OS: Linux Mint 17 (Cinnamon)
The text was updated successfully, but these errors were encountered: