Bug 93641 - external numpad gets unresponsive when it's simultaneously used with another keyboard
Summary: external numpad gets unresponsive when it's simultaneously used with another ...
Status: RESOLVED NOTOURBUG
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-08 14:01 UTC by Kamil Páral
Modified: 2016-01-22 02:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
system journal (6.82 KB, text/plain)
2016-01-08 14:03 UTC, Kamil Páral
Details
evemu record - no extra events (16.74 KB, text/plain)
2016-01-08 14:05 UTC, Kamil Páral
Details
evemu record - extra numlock events (25.63 KB, text/plain)
2016-01-08 14:06 UTC, Kamil Páral
Details
evemu record - extra number events (20.16 KB, text/plain)
2016-01-08 14:07 UTC, Kamil Páral
Details
hid-recorder output (6.31 KB, text/plain)
2016-01-21 21:17 UTC, Kamil Páral
Details

Description Kamil Páral 2016-01-08 14:01:09 UTC
Hello,

I have purchased an external numpad (A4Tech TK-5). When I use it with my desktop machine, I can reliably reproduce input issues described here. However, not all machines exhibit those issues (more on that later).

The problem is, that the numpad works (produces key events) only when I don't use it with my standard keyboard at the very same time. If I wait a short while (~1 second) when switching between these two devices (i.e. I wait 1 second between stopping typing on the standard keyboard and starting typing on the numpad, and vice versa), everything is OK. But when I start typing on both simultaneously, the numpad gets dead/unresponsive, and no longers send *any* events (no numbers, numlock switching doesn't work - the LED does not change state) until I disconnect it and reconnect it again.

I can reproduce this every single time on my desktop machine, but only when using my rear motherboard usb ports. When I use external front panel usb ports, I can't reproduce it. So it seems to be somehow related to a certain usb chipset? (If it is a race condition, maybe it has much higher probability to occur on a certain usb chipset). On the very same machine when using Windows 10, I can't reproduce the issue on any of those ports, it works flawlessly, so I support this is a software issue, not a hardware one.

I also saw similar issues with my Thinkpad X220, but I can't reproduce them consistently there or on will, it happens randomly and rarely. On ThinkPad T450s, I could not reproduce the issue at all. So this seems to be very much affected by hardware.

When the numpad gets dead, there is no message about it in the dmesg/system journal, even if I wait for a while. xev shows no events, even when I press buttons. libinput-debug-events shows no events, even when I press buttons. (Before it gets dead, both xev and libinput-debug-events of course show proper numpad key presses).

libinput-list-devices says:
Device:           KEYBOARD
Kernel:           /dev/input/event18
Group:            4
Seat:             seat0, default
Capabilities:     keyboard 
Tap-to-click:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a

Device:           KEYBOARD
Kernel:           /dev/input/event19
Group:            4
Seat:             seat0, default
Capabilities:     keyboard pointer 
Tap-to-click:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    disabled
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a

I'm not sure why it shows two devices (for my standard keyboard it also shows 2 devices), when debugging this I used event18 as the input device.

When using evemu-record, I noticed that sometimes events just stop coming from the numpad once it gets dead, but very often I see an endless stream of very fast scrolling events, like this:

E: 4.378433 0001 0045 0002      # EV_KEY / KEY_NUMLOCK          2
E: 4.378433 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 4.411421 0001 0045 0002      # EV_KEY / KEY_NUMLOCK          2
E: 4.411421 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 4.444406 0001 0045 0002      # EV_KEY / KEY_NUMLOCK          2
E: 4.444406 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 4.477405 0001 0045 0002      # EV_KEY / KEY_NUMLOCK          2
E: 4.477405 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 4.510417 0001 0045 0002      # EV_KEY / KEY_NUMLOCK          2
E: 4.510417 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 4.543443 0001 0045 0002      # EV_KEY / KEY_NUMLOCK          2
E: 4.543443 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms


or like this:

E: 3.800587 0001 004d 0002      # EV_KEY / KEY_KP6              2
E: 3.800587 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 3.833587 0001 004d 0002      # EV_KEY / KEY_KP6              2
E: 3.833587 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 3.866576 0001 004d 0002      # EV_KEY / KEY_KP6              2
E: 3.866576 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 3.899576 0001 004d 0002      # EV_KEY / KEY_KP6              2
E: 3.899576 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 3.932576 0001 004d 0002      # EV_KEY / KEY_KP6              2
E: 3.932576 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms
E: 3.965584 0001 004d 0002      # EV_KEY / KEY_KP6              2
E: 3.965584 0000 0000 0001      # ------------ SYN_REPORT (1) ---------- +33ms

But nothing gets printed on the screen, and the numpad is unresponsive. So my suspicion is that either libinput or something lower in the stack gets stuck and repeats the last event over and over and over again, and therefore the numpad stops responding/producing key presses.

Attaching logs.


libinput-1.1.4-1.fc23.x86_64
xorg-x11-drv-libinput-0.16.0-1.fc23.x86_64
xorg-x11-server-Xorg-1.18.0-2.fc23.x86_64
Comment 1 Kamil Páral 2016-01-08 14:02:22 UTC
Oh, and I'm not actually using Wayland (this place just seemed like the proper upstream place to report libreport bugs, regardless of Wayland/X11 usage).
Comment 2 Kamil Páral 2016-01-08 14:03:05 UTC
Created attachment 120897 [details]
system journal

System journal after connecting the keypad (nothing gets printed out when it gets unresponsive).
Comment 3 Kamil Páral 2016-01-08 14:05:09 UTC
Created attachment 120898 [details]
evemu record - no extra events

evemu record of the numpad (event18) when simultaneously typing on a keyboard and the numpad. The numpad stops producing numbers in the text editor, and no new events are printed out in evemu record (the last event in the log is the last number correctly printed out, then it died).
Comment 4 Kamil Páral 2016-01-08 14:06:09 UTC
Created attachment 120899 [details]
evemu record - extra numlock events

Another evemu record, but this time after numpad gets unresponsive, the evemu log contains an infinite stream of numlock events.
Comment 5 Kamil Páral 2016-01-08 14:07:17 UTC
Created attachment 120900 [details]
evemu record - extra number events

Another evemu record, but this time after numpad gets unresponsive, the evemu log contains an infinite stream of KEY_KP6 events (I assume that was the last button pressed before it died).
Comment 6 Peter Hutterer 2016-01-13 05:54:42 UTC
value 2 for key events is the kernel's autorepeat code. which we ignore, because we do software repeat in X. This is a kernel issue, though I don't know what could cause this. Benjamin?

Please attach a hid recording here, this may help identify some issues. See https://bentiss.github.io/hid-replay-docs/
Comment 7 Kamil Páral 2016-01-21 21:17:52 UTC
Created attachment 121195 [details]
hid-recorder output

Here it is, but I'm afraid it won't show much. This is the output where I pressed some buttons quickly on keypad (no issues), and then combined it with mashing buttons on my keyboard (and the keypad got stuck). But even though evemu-record shows a neverending stream of these events
E: 2.243998 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +33ms
E: 2.276997 0001 004c 0002	# EV_KEY / KEY_KP5              2
E: 2.276997 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +33ms
E: 2.309997 0001 004c 0002	# EV_KEY / KEY_KP5              2
the hid-recorder output has shown no such thing, it simply stopped printing anything.
Comment 8 Kamil Páral 2016-01-21 21:26:25 UTC
I have to add that I've seen several times today the keypad to get stuck (print the neverending stream of value 2 events, or stop sending any signals) just by pressing its buttons alone, not combined with the keyboard. So this error can be reproduced with just the keypad, but it's just not that likely. When I use my keyboard simultaneously, it makes reproducing this almost instant.

One further thing, I'm not sure if this is related, but it seems weird to me, that if I listen to just the keypad using evemu-record, and I press NumLock on keyboard (different device, not listening to that), it prints these events:
E: 3.352170 0011 0000 0000	# EV_LED / LED_NUML             0
E: 3.352170 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +2641ms
E: 4.520290 0011 0000 0001	# EV_LED / LED_NUML             1
E: 4.520290 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +1168ms
However, if I press NumLock on they keypad itself, it generates no events. Maybe unrelated, maybe even expected. Just mentioning.
Comment 9 Peter Hutterer 2016-01-22 02:09:58 UTC
ok, this is a hardware or kernel bug then. as said above, value 2 for key events is a software-generated key repeat event so looks like the kernel never sees the key up event either. since you said the device works under windows, I'd say it's a kernel issue.

Benjamin, any ideas based on the hid recording?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.