Bug 70181 - Duplicated key sequence on fast pressing the # and any other key
Summary: Duplicated key sequence on fast pressing the # and any other key
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: IA-64 Linux
: P1 low
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-06 19:17 UTC by Lars H
Modified: 2016-09-09 08:02 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.11.0-15
Tree: Mainline
Regression: No


Attachments

Description Lars H 2014-02-06 19:17:37 UTC
Kernel Version: 3.11.0-15
Distribution: Debian based, Arch, ...
Hardware Environment: Keyboard QPAD MK-85
Software Environment: X, terminal
Problem Description: I got a QPAD MK85 and a really strange behaviour in several tested linux distrubitions, it's not only in graphical environments.

Steps to reproduce: 
It happens only if I press the '#' key and then fast pressing another key. For example the key sequence '#' and 'd' will produce #d# instead of #d. I tried a bunch of layouts with the same behaviour. On windows the keyboard works, so I can exclude a malfunction. It is also tested with a non-mechanical keyboards where I don't have this strange issue.

Unfortunately I haven't a great idea to log this events, so I used a event capture. If there is a better logging for keyboard events please let me know.

20:09:15.868559: EV_MSC MSC_SCAN 458802
20:09:15.868559: EV_KEY KEY_BACKSLASH (0x2b) pressed
20:09:15.868559: EV_SYN code=0 value=0
#20:09:15.920556: EV_MSC MSC_SCAN 458759
20:09:15.920556: EV_KEY KEY_D (0x20) pressed
20:09:15.920556: EV_MSC MSC_SCAN 458801
20:09:15.920556: EV_KEY KEY_BACKSLASH (0x2b) released
20:09:15.920556: EV_MSC MSC_SCAN 458802
20:09:15.920556: EV_KEY KEY_BACKSLASH (0x2b) pressed
20:09:15.920556: EV_SYN code=0 value=0
d#20:09:15.944558: EV_MSC MSC_SCAN 458801
20:09:15.944558: EV_KEY KEY_BACKSLASH (0x2b) released
20:09:15.944558: EV_SYN code=0 value=0
20:09:15.996558: EV_MSC MSC_SCAN 458759
20:09:15.996558: EV_KEY KEY_D (0x20) released
Comment 1 Fredrik Hallenberg 2014-08-08 16:15:44 UTC
My Corsair K70 keyboard have the same problem, possibly all keyboards with n-key rollover are affected. I am using Linux 3.16.0.

I believe the root cause of this is that the keyboard reports all keys
including both HID keys 0x31 and 0x32 which are both mapped to
KEY_BACKSLASH in hid-input.c. I am using a nordic keyboard meaning
KEY_BACKSLASH is labeled "apostrophe" and that HID key 0x32 is
reported. A US keyboard has a backslash key which should report 0x31.

I have added some traces before the input_event call at the end of
hidinput_report_event. When pressing A key and then apostrophe,
something like this is seen (omitting all inactive keys):

VALUE 1 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31
VALUE 0 CODE 43 HID 0x32
Output: a

VALUE 1 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31
VALUE 1 CODE 43 HID 0x32
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31
VALUE 1 CODE 43 HID 0x32
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31
VALUE 1 CODE 43 HID 0x32
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31
VALUE 0 CODE 43 HID 0x32

So the fact that 0x31 is inactive will cause bad release events on key
43 to be sent.

I have made a simple patch that tracks which of the two variants is
active and ignores the other one. It works but I don't have much
knowledge on HID input so before posting it would like to know if
someone has input on how to do a cleaner fix. I am happy to help with
testing or implementation if I am able.
Comment 2 Christopher Head 2014-10-20 04:15:33 UTC
I have encountered the same problem on the Das Keyboard 4, whose N-key rollover mode uses a Data Var Abs 1-bit×104-key bit field to represent all the keys, from 0 to 103. As Fredrik did, I also found the hid_keyboard mapping array in hid-input.c which maps both 49 and 50 to KEY_BACKSLASH, so that whenever a new report arrives, since it’s a bit field, it has current values for both keys, with 49 representing the actual backslash and 50 being unused. So, pressing backslash results in a press followed immediately by a release.

The net result is the following problems:
(1) Because backslash is believed released immediately after it’s pressed, repeat never happens with backslash as it does with other keys.
(2) Any software (e.g. a game) that relies on held-vs-unheld to be meaningful will fail with backslash because it is reported as instantly released.
(3) As Lars found, upon pressing a second key, a second HID report is generated, resulting in the kernel again noticing that backslash is still held down, interpreting that information as a fresh keypress (erroneously believing the key have previously been released), and issues another backslash—after which it instantly reports it as released again, since the very next bit in the report is zero.

I suspect Lars’s and Fredrik’s keyboards probably don’t suffer from problems 1 and 2 because, assuming the HID layer scans the bits from left to right, it would see key 50 after key 49 and, since their keyboards use 50 for their actual key and leave 49 unused, report the proper held state in the end—merely interpreting each report as a release followed by a press, as opposed to mine, which interprets each report as a press followed by a release.
Comment 3 Fredrik Hallenberg 2014-10-20 06:41:41 UTC
(In reply to Christopher Head from comment #2)

> I suspect Lars’s and Fredrik’s keyboards probably don’t suffer from problems
> 1 and 2 because, assuming the HID layer scans the bits from left to right,
> it would see key 50 after key 49 and, since their keyboards use 50 for their
> actual key and leave 49 unused, report the proper held state in the
> end—merely interpreting each report as a release followed by a press, as
> opposed to mine, which interprets each report as a press followed by a
> release.

Right, this explains the different issues reported by non-US and US keyboard owners.

Note that there has been some discussion and a proposed patch on the linux-input list:

http://article.gmane.org/gmane.linux.kernel.input/38144
Comment 4 Christopher Head 2014-10-22 05:05:54 UTC
The patch in that message (the extra check in hid-core.c) looks like a reasonable idea, should be harmless in all cases AFAICT, and fixes this for the North American Das 4.
Comment 5 Alexandre Cavaco 2014-10-23 14:08:04 UTC
Hello,


I have the same problem in my keyboard, which is the Ozone Strike Pro mechanical keyboard, portuguese (PT) layout.

In my case, it affects the dead tilde ('~') and dead circumflex ('^') keys, (keycode 43 using showkey in the console).


In Portuguese there are a many words which include the substring "ão".
Because of this bug, most of the times I write words like "não" the output is "nãõ".
It becomes very annoying having to frequently replace the last 'õ' for 'o'.


My kernel version is 3.1.0-37-generic.

If someone needs my lsusb output please let me know.
Comment 6 Fredrik Hallenberg 2014-10-24 08:38:17 UTC
The patch in the link in comment 3 should work regardless o(In reply to Alexandre Cavaco from comment #5)
> I have the same problem in my keyboard, which is the Ozone Strike Pro
> mechanical keyboard, portuguese (PT) layout.

The patch in the link in comment 3 should work regardless of language and keyboard type, feel free to test it.
Comment 7 Alexandre Cavaco 2014-10-24 11:51:15 UTC
Thanks Fredrik, I can confirm the patch works perfectly.

I think this should be accepted as a fix, as most people can't recompile it's own kernel (can't or don't know how to).

BTW, I meant 3.13.0-37-generic (Ubuntu 14.04) in comment 5.
Comment 8 Fredrik Hallenberg 2014-10-24 13:31:25 UTC
(In reply to Alexandre Cavaco from comment #7)
> Thanks Fredrik, I can confirm the patch works perfectly.
> 
> I think this should be accepted as a fix, as most people can't recompile
> it's own kernel (can't or don't know how to).

David Herrmann is working on a proper patch, a fix will be included in the kernel sooner or later.
Comment 9 rh 2014-12-17 23:32:39 UTC
I can confirm that this patch works for my *Corsair Raptor K30 (German)* keyboard which also had the "repeating BACKSLASH key issue".

How can I assist to get this patch in the kernel as soon as possible?
Comment 10 Fredrik Hallenberg 2014-12-18 10:49:07 UTC
(In reply to r from comment #9)
> I can confirm that this patch works for my *Corsair Raptor K30 (German)*
> keyboard which also had the "repeating BACKSLASH key issue".
> 
> How can I assist to get this patch in the kernel as soon as possible?

You could report this on the linux-input list, preferably as a comment to the thread mentioned above so it gets pinged.
Comment 11 rh 2014-12-20 19:01:01 UTC
I have posted on the mailing list that the hwdb method works for me, so the kernel patch is not needed:

# entry in hwdb.d keyboards
# don't forget to rebuild and apply hwdb
keyboard:usb:v1B1Cp1B0A*
 KEYBOARD_KEY_70031=reserved

See also http://blog.dev001.net/post/105617477155/using-a-corsair-raptor-k30-keyboard-with-linux

So, shall this bug be closed here?

What are the next steps? I don't think it's a kernel issue anymore but rather a potential entry for hwdb. I guess this would have to be suggested to freedesktop.org?

I'd really like to save other users from having this issue.
Comment 12 Fredrik Hallenberg 2014-12-20 19:45:34 UTC
As discussed in the thread above the hwdb-solution is no good as it will break US-keyboards.
Comment 13 Fredrik Hallenberg 2014-12-29 16:16:01 UTC
There is a now a proper patch posted on linux-input, feel free to test it:

http://article.gmane.org/gmane.linux.kernel.input/40058
Comment 14 Christopher Head 2014-12-29 20:10:12 UTC
I can confirm that the linux-input patch fixes the North American Das 4.
Comment 15 Christopher Head 2014-12-30 18:55:25 UTC
I spoke too soon. This fixes NKRO mode but breaks 6KRO mode (which uses the common DATA ARRAY ABS report field for regular keys): the last typed key repeats forever even after being released.
Comment 16 Fredrik Hallenberg 2014-12-30 20:40:03 UTC
Oh... please mention this as a reply to the mail above, I don't think David Herrmann checks this bugzilla.
Comment 17 Christopher Head 2014-12-31 00:57:49 UTC
OK, sent.
Comment 18 Jiri Kosina 2015-01-08 17:09:52 UTC
Fixed by 6ce901eb61 and 8e7b34103 in hid.git#for-3.20/upstream.

Note You need to log in before you can comment on or make changes to this bug.