Bug 70181

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.

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.

(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

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.

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.

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.

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.

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

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?

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

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.

As discussed in the thread above the hwdb-solution is no good as it will break US-keyboards.

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

I can confirm that the linux-input patch fixes the North American Das 4.

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.

Oh... please mention this as a reply to the mail above, I don't think David Herrmann checks this bugzilla.

OK, sent.

Fixed by 6ce901eb61 and 8e7b34103 in hid.git#for-3.20/upstream.