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

Plover only handling 6 keys for NKRO keyboard #644

Closed
GuiltyDolphin opened this issue Nov 15, 2016 · 25 comments
Closed

Plover only handling 6 keys for NKRO keyboard #644

GuiltyDolphin opened this issue Nov 15, 2016 · 25 comments

Comments

@GuiltyDolphin
Copy link

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

  1. Buy this keyboard.
  2. Run Plover
  3. Try and type with more than 6 keys at once.

Expected Results

  1. More than 6 keys register.

Actual Results

  1. Only 6 keys register.

Version

Plover version 3.1.0

Installed via: GitHub

Notes

Configuration

OS: Linux Mint 17 (Cinnamon)

@TheaMorin
Copy link
Member

Can you test on Windows as well?

@TheaMorin
Copy link
Member

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/

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 15, 2016

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

@TheaMorin
Copy link
Member

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.

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 16, 2016

@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

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 16, 2016

@morinted I've done a bit more digging and it looks like 840d1a4 breaks it (build on previous commit works fine, build on that commit doesn't work with NKRO).

PR containing the commit: #558

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 16, 2016

@morinted I've narrowed it down a bit more and it looks like in run, the display is only passing 6 keypress events (via next_event).

840d1a4#diff-0d9bf39a2fd48c448c2073e8f39cf871R194

@benoit-pierre
Copy link
Member

What's the output when you press one of those combos that don't work with Plover while running: xinput test-xi2 --root?

@GuiltyDolphin
Copy link
Author

@benoit-pierre It appears to only recognize the first 6 keys:

USB Keyboard                                id=14   [slave  keyboard (3)]
    Reporting 1 classes:
        Class originated from: 14. Type: XIKeyClass
        Keycodes supported: 248

EVENT type 13 (RawKeyPress)
    device: 14 (14)
    detail: 47
    valuators:

EVENT type 13 (RawKeyPress)
    device: 14 (14)
    detail: 38
    valuators:

EVENT type 13 (RawKeyPress)
    device: 14 (14)
    detail: 39
    valuators:

EVENT type 13 (RawKeyPress)
    device: 14 (14)
    detail: 40
    valuators:

EVENT type 13 (RawKeyPress)
    device: 14 (14)
    detail: 41
    valuators:

EVENT type 13 (RawKeyPress)
    device: 14 (14)
    detail: 44
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 14 (14)
    detail: 47
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 14 (14)
    detail: 38
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 14 (14)
    detail: 39
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 14 (14)
    detail: 40
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 14 (14)
    detail: 41
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 14 (14)
    detail: 44
    valuators:

I've also tried xev which seems to work fine.

@benoit-pierre
Copy link
Member

Can you upload the full output? Also what does xinput list report?

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 17, 2016

@benoit-pierre That is the full output from xinput (bar the key press and release for ^C to exit). If I press the home row keys (SKWR RBGS) then Plover will fairly consistently show the SKWR RS keys being pressed (other combos vary).

Output from xinput list (ID has changed as it has since been replugged):

⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
⎜   ↳ USB Keyboard                              id=14   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Video Bus                                   id=7    [slave  keyboard (3)]
    ↳ Power Button                                id=8    [slave  keyboard (3)]
    ↳ Sleep Button                                id=9    [slave  keyboard (3)]
    ↳ HD WebCam                                   id=10   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=11   [slave  keyboard (3)]
    ↳ Acer WMI hotkeys                            id=13   [slave  keyboard (3)]
    ↳ USB Keyboard                                id=15   [slave  keyboard (3)]

@benoit-pierre
Copy link
Member

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 xinput test-xi2, and the monitoring is done on all devices (and so work if a new keyboard is plugged), so I guess it's a bug in Xinput? You'll have to open a bug there: https://bugs.freedesktop.org/

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 17, 2016

@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

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 29, 2016

@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:

The second cause would be that plover is doing something incorrect with the keyboard events. Whenever the other event node gets active an XIDeviceChangedEvent is sent to notify the client. It may be that this is confusing plover? Or plover is listening to the slave devices directly? I don't know.

Are we listening to the slave devices directly? Do we handle the XIDeviceChangedEvent events?

@benoit-pierre
Copy link
Member

I'm confused, reading the comments on the Freedesktop bug report, it looks like xinput test-xi2 does actually work? And I mean this exact command, not without specifying a device number; can you confirm? Because when not specifying said device number, the code will use the special AllDevices or AllMasterDevices parameter to listen to all devices, which will also automatically pick up new devices (if you plug a new keyboard while the command is running, or if you're keyboard does funny things to implement NKRO). Plover itself does not use AllDevices/AllMasterDevices because it needs to ignore the fake XTEST keyboard, and does not listen to other Xinput events (like XIDeviceChangedEvent, or XIHierarchyChangedEvent). So it does not work if you dynamically plug a new keyboard while Plover is running, that's a known issue.

@GuiltyDolphin
Copy link
Author

@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 11 and 12 (from the list below) are specified in separate instances then all the keys can be accounted for (though only through RawKeyPresses and RawKeyReleases).

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=15	[slave  pointer  (2)]
⎜   ↳ USB Keyboard                            	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ HD WebCam                               	id=10	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=14	[slave  keyboard (3)]
    ↳ Acer WMI hotkeys                        	id=16	[slave  keyboard (3)]
    ↳ USB Keyboard                            	id=12	[slave  keyboard (3)]

Could we not just explicitly ignore events from the XTEST keyboard?

@benoit-pierre
Copy link
Member

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 xinput test-xi2 and pressing 6+ keys.

@GuiltyDolphin
Copy link
Author

Output from xinput list:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=15	[slave  pointer  (2)]
⎜   ↳ USB Keyboard                            	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ HD WebCam                               	id=10	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=14	[slave  keyboard (3)]
    ↳ Acer WMI hotkeys                        	id=16	[slave  keyboard (3)]
    ↳ USB Keyboard                            	id=11	[slave  keyboard (3)]

Output from xinput test-xi2 --root:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=15	[slave  pointer  (2)]
⎜   ↳ USB Keyboard                            	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ HD WebCam                               	id=10	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=14	[slave  keyboard (3)]
    ↳ Acer WMI hotkeys                        	id=16	[slave  keyboard (3)]
    ↳ USB Keyboard                            	id=11	[slave  keyboard (3)]
EVENT type 13 (RawKeyPress)
    device: 2 (12)
    detail: 45
    valuators:

EVENT type 2 (KeyPress)
    device: 12 (12)
    detail: 45
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 13 (RawKeyPress)
    device: 2 (12)
    detail: 46
    valuators:

EVENT type 2 (KeyPress)
    device: 12 (12)
    detail: 46
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 1 (DeviceChanged)
    device: 3 (11)
    reason: SlaveSwitch
	Reporting 1 classes:
		Class originated from: 11. Type: XIKeyClass
		Keycodes supported: 248

EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 47
    valuators:

EVENT type 2 (KeyPress)
    device: 11 (11)
    detail: 47
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 38
    valuators:

EVENT type 2 (KeyPress)
    device: 11 (11)
    detail: 38
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 39
    valuators:

EVENT type 2 (KeyPress)
    device: 11 (11)
    detail: 39
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 40
    valuators:

EVENT type 2 (KeyPress)
    device: 11 (11)
    detail: 40
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 41
    valuators:

EVENT type 2 (KeyPress)
    device: 11 (11)
    detail: 41
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 44
    valuators:

EVENT type 2 (KeyPress)
    device: 11 (11)
    detail: 44
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 2 (12)
    detail: 45
    valuators:

EVENT type 3 (KeyRelease)
    device: 12 (12)
    detail: 45
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 2 (12)
    detail: 46
    valuators:

EVENT type 3 (KeyRelease)
    device: 12 (12)
    detail: 46
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 1 (DeviceChanged)
    device: 3 (11)
    reason: SlaveSwitch
	Reporting 1 classes:
		Class originated from: 11. Type: XIKeyClass
		Keycodes supported: 248

EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 47
    valuators:

EVENT type 3 (KeyRelease)
    device: 11 (11)
    detail: 47
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 38
    valuators:

EVENT type 3 (KeyRelease)
    device: 11 (11)
    detail: 38
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 39
    valuators:

EVENT type 3 (KeyRelease)
    device: 11 (11)
    detail: 39
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 40
    valuators:

EVENT type 3 (KeyRelease)
    device: 11 (11)
    detail: 40
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 41
    valuators:

EVENT type 3 (KeyRelease)
    device: 11 (11)
    detail: 41
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b
EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 44
    valuators:

EVENT type 3 (KeyRelease)
    device: 11 (11)
    detail: 44
    flags:
    root: 432.46/308.09
    event: 432.46/308.09
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9d event 0x9d child 0x160245b

Output from xinput test-xi2 --root 11:

USB Keyboard                            	id=11	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 11. Type: XIKeyClass
		Keycodes supported: 248

EVENT type 13 (RawKeyPress)
    device: 11 (11)
    detail: 47
    valuators:

EVENT type 13 (RawKeyPress)
    device: 11 (11)
    detail: 38
    valuators:

EVENT type 13 (RawKeyPress)
    device: 11 (11)
    detail: 39
    valuators:

EVENT type 13 (RawKeyPress)
    device: 11 (11)
    detail: 40
    valuators:

EVENT type 13 (RawKeyPress)
    device: 11 (11)
    detail: 41
    valuators:

EVENT type 13 (RawKeyPress)
    device: 11 (11)
    detail: 44
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 11 (11)
    detail: 47
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 11 (11)
    detail: 38
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 11 (11)
    detail: 39
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 11 (11)
    detail: 40
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 11 (11)
    detail: 41
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 11 (11)
    detail: 44
    valuators:

Output from xinput test-xi2 --root 12:

USB Keyboard                            	id=12	[slave  pointer  (2)]
	Reporting 6 classes:
		Class originated from: 12. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button 0" "Button Unknown" "Button Unknown" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 12. Type: XIKeyClass
		Keycodes supported: 248
		Class originated from: 12. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 1 units/m
		  Mode: relative
		Class originated from: 12. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 1 units/m
		  Mode: relative
		Class originated from: 12. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Horiz Wheel
		  Range: -1.000000 - -1.000000
		  Resolution: 1 units/m
		  Mode: relative
		Class originated from: 12. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 2 (horizontal)
		  increment: 1.000000
		  flags: 0x0

EVENT type 13 (RawKeyPress)
    device: 12 (12)
    detail: 46
    valuators:

EVENT type 13 (RawKeyPress)
    device: 12 (12)
    detail: 45
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 12 (12)
    detail: 45
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 12 (12)
    detail: 46
    valuators:

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 29, 2016

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.

@benoit-pierre
Copy link
Member

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

?

@GuiltyDolphin
Copy link
Author

GuiltyDolphin commented Nov 29, 2016

@benoit-pierre I was thinking more along the lines of updating if devinfo.use != xinput.SlaveKeyboard to be if devinfo.use != xinput.SlaveKeyboard and devinfo.use != xinput.SlavePointer (or if devinfo.use not in [xinput.SlaveKeyboard, xinput.SlavePointer]).

It doesn't appear to work with that patch (though it does with my earlier suggestion).

@benoit-pierre
Copy link
Member

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

@benoit-pierre
Copy link
Member

But then again the list is already pretty long with the slave keyboards...

@benoit-pierre
Copy link
Member

Does the pointer device have a KeyClass in its list of classes? Does it get picked up with this patch:

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

?

@GuiltyDolphin
Copy link
Author

@benoit-pierre It looks like it! It also looks like 9/12 devices make it into the print, including both the USB keyboard devices.

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

3 participants