Comment # 1 on bug 1093389 from Oliver Neukum

Quoting the analysis:

It contains both Input fields (reports from the keyboard) and Output fields
(control messages sent to the keyboard), and they are jumbled together, which
is nothing unusual. The input fields are also pretty standard: The first byte
has bits for modifier keys (left and right shift/ctrl/alt/meta), followed by a
constant zero byte, followed by 6 bytes for up to 6 simultanously pressed keys.
As you can see from the report examples, this is also exactly what the keyboard
sends.

The last extra byte has a range of -128 to 127 (so 71 is -15), and is described
as "Generic Desktop" with a usage index of 0x168. This index is not assigned in
the publicly available HID Usage Table (HUT) version 1.12, so I don't know what
it means. It must be some kind of analog range (keyboard tilt? pressure? some
other sensor?). It's also not particularly important what it is, it would be
just get ignored by the HID translation layer.

The output message is also standard: One byte, of which 3 bits control the
keyboard LEDs (num lock, caps lock, scroll lock), and 5 bits are unused.

However, the switch to Usage Page (Keyboard) in the next input field from Usage
Page (LED) in the output field occurs in the middle of the block, and
apparently that confuses the kernel HID descriptor parser, so that it
interprets this input field also as "LEDs", which makes no sense at all, and
prevents it from translating the keys as it should.

That's a bug: Either in the kernel HID descriptor parser, or in the HID
descriptor. In the first case, it should be fixed, in the last case, the
descriptor should get a quirk in the kernel so it can be fixed. In any way,
report it as a bug to the kernel maintainers.