The keyboards in question have n-key rollover, this seems to be
implemented by sending every single key id every time the keyboard is
polled, this includes several keys that does not exist physically for
example 0x31. This may be a bit excessive but not broken. If I press
a-key and '-key in rapid succession, I get the following events
(omitting all other 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  - 43 is up
VALUE 1 CODE 43 HID 0x32  - 43 is down
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31  - 43 is up
VALUE 1 CODE 43 HID 0x32  - 43 is down
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31  - 43 is up
VALUE 1 CODE 43 HID 0x32  - 43 is down
Output: '

So even though the keyboard is behaving a bit weird the problem is in
the kernel as it will interpret 0x31 and 0x32 as the same key.

I don't have access to the keyboard at the moment, I will send the
descriptor later today.


On Wed, Sep 10, 2014 at 12:09 PM, David Herrmann [off-list ref] wrote:

Hi

(CC Dmitry for AT details)

On Wed, Sep 10, 2014 at 10:26 AM, Jiri Kosina [off-list ref] wrote:

quoted

On Tue, 9 Sep 2014, Fredrik Hallenberg wrote:

quoted

Hi, time for a bump on this one.

On Sun, Aug 10, 2014 at 11:56 AM, Fredrik Hallenberg
[off-list ref] wrote:

quoted

Here is my attempt on a fix for bug 70181, please review it. It is
tested on my nordic Corsair K70, if this solution is deemed acceptable
I can ask some people with other problematic keyboards to test it.

Signed-off-by: Fredrik Hallenberg <redacted>
---
 drivers/hid/hid-input.c | 14 ++++++++++++++
 include/linux/hid.h     |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 2619f7f..56429c0 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c

@@ -1085,6 +1085,20 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
                return;
        }

+       /*
+        * Some keyboards will report both HID keys 0x31 (\ and |) and
+        * 0x32 (Non-US # and ~) which are both mapped to
+        * KEY_BACKSLASH. This will cause spurious events causing

Hmm, makes me wonder if this mapping in hid_keyboard[] is even correct.
The footnote in HUT 1.12 specifies very different mappings for different
national keyboards.

This is the key that's moved on European layouts due to the different
shape of the 'Enter' key. HID defines two different usage types, key
0x31 and 0x32. It doesn't make sense for a keyboard to enable both, so
this really sounds like a broken hid description to me.

We currently map both those keys to KEY_BACKSLASH, which means
regardless whether it's the European or standard layout, the same
keycodes are generated. So mapping 0x31 and 0x32 to the same key
sounds fine (or at least consistent).

@Fredrik: can you send us your HID descriptor from the broken deivce?
(cat /sys/kernel/debug/hid/<device>/desc).

I wonder why you get key-repeat events, though. I mean, the keyboard
has to send both 0x31 and 0x32 events for you to get those repeat
events. But it really doesn't make sense to me for a keyboard to
report both keys, and furthermore your report sounded like you only
pressed a single key, right?

Thanks
David