Cherry USB controller problems visible in Linux and macOS

[Daniel Beardsmore]

I've confirmed ilcavero's reported fault that the G80-3000 controller exhibits bad HID reports that are readily apparent within Linux. I don't know the age of his, but mine was bought brand new in 2012, and it was made in 2012.

Specifically, when a key is blocked and (in my case, anyway) the valid keys have been held momentarily, a false HID report of 0x0101010101010101 is emitted. The leading byte is the modifier field, and 0x01 is LCtrl. Windows appears to discards this report as nonsense, while Linux and macOS will accept it. In Linux, where keyboard shortcuts in graphical software typically use ctrl, the blocked key will cause the previous keystroke to register as a keyboard shortcut.

To reproduce in Linux:

Open up a text editor where ctrl+A is Select All (e.g. Gedit)
Press and hold Q
Press and hold A (with Q still held)
Press and hold P (with Q and A still held)

With NKRO, "p" should appear. With 2KRO, "p" should not appear and "a" should continue to autorepeat. With a G80-3000, Select All is invoked, as the modifier field from the spurious report is applied back over the previous keystroke: even though you've already seen "a" auto-repeated, the LCtrl from the spurious report causes the "a" to reprocessed as ctrl+a. This is strange enough in itself.

I'm interested to know if any other Cherry models with USB (e.g. G81-3000 or G83-3000 or even the STRAIT or INITIAL) share this defect.

Windows seems to drop the spurious report at a low level, an in Windows, holding a key and then holding control does not convert the key I'm holding into a shortcut: it simply cuts off the autorepeat of that key.

[Lustique]

I just wanted to reply that I don't experience this issue when I read the title again and noticed that not only am I using a G81 at the moment, it's also PS/2…

To add something of value: With a G84-4100LCMDE-2 I get Qs, then As, and then Ps (tested using Mousepad).

[ilcavero]

I did reproduce this on 2 different G80-3000s over USB, one of them just bought off amazon. An easy way to reproduce is to open a terminal and pressing and holding right shift, c and e, this should trigger a ctrl+c that breaks the line and gives you a new command prompt.

[Daniel Beardsmore]

Just a test, I connected my G80-3000 into a USB to PS/2 adapter and then into a Blue Cube PS/2 to USB adapter, and the fault went away. I also tried some standard Dell keyboards on the same laptop (mostly to see if they still worked following reassembly) and they worked fine.

If I remember, I do have a G84 series keyboard that should be USB that I can test with one day.

[Rimrul]

I've tested this with 2 2012 G80-3000 and a 2013 G81-3000 and they all show this issue.

[Daniel Beardsmore]

Ah, good, thank you. I was going to mention it on the wiki page for the G80-3000 but I thought it would be better to check first if other models are affected, as the controller code is likely to be the same.

[Daniel]

I wasn't able to reproduce this on my G80-3000 neither. I'm using a USB to PS2 converter though.
Once I attach it via USB the problem is reproducible. My G80-3000 has a date code of 39Y (2012).

[Daniel Beardsmore]

Hm ... I am not sure which page to write this up on. Suggestions?

[Daniel]

I'd suggest the G80-3000 page. And additionally a sentence on the G81 page linking/referencing to the paragraph on the G80-3000 page.

[hasu]

G80-3600(U37, 2008?) has similar issue, it has no ghost due to diodes and can register upto 6 keys without problem but the report in question appears when 7th key is depressed.

usbhid-dump output:

Code: Select all

003:051:000:STREAM             1514073950.977190
 00 00 1E 1F 20 21 22 00

003:051:000:STREAM             1514073951.273167
 00 00 1E 1F 20 21 22 23

003:051:000:STREAM             1514073951.753133
 01 01 01 01 01 01 01 01

[Daniel Beardsmore]

According to the wiki, "The [G80-3000] USB controller identifies itself as a "G83 (RS 6000) Keyboard", so the G83-3000 presumably has the same bug. The G80-3600 looks the same as a G80-3000 though, so I guess the USB firmware in G80 keyboards can be configured for 6KRO.

I'm curious whether this strange bug has survived into the MX Board 2.0 (Cherry G80-3800) and MX Board 3.0 (Cherry G80-3850), i.e. do they still use the same firmware, or was new firmware written?

[Rimrul]

I think we have a G83-6000 at work. I might get around to testing that in January.

[Daniel Beardsmore]

I look forward to it. I have one, but it's PS/2 only.

[Daniel Beardsmore]

I almost wrote up this bug, but I went to see just what key 0x01 would be if it did work, and I found this:

https://gist.github.com/MightyPork/6da2 ... 55fdc73db2

Specifically:

Code: Select all

/**
 * Scan codes - last N slots in the HID report (usually 6).
 * 0x00 if no key pressed.
 * 
 * If more than N keys are pressed, the HID reports 
 * KEY_ERR_OVF in all slots to indicate this condition.
 */

#​define KEY_NONE 0x00 // No key pressed
#​define KEY_ERR_OVF 0x01 //  Keyboard Error Roll Over - used for all slots if too many keys are pressed ("Phantom key")
// 0x02 //  Keyboard POST Fail
// 0x03 //  Keyboard Error Undefined

So this raises the question, what does "used for all slots" mean? You could argue that it means either:

0x0000010101010101 — no modifiers, reserve byte preserved, blocking occurred
0x0101010101010101 — entire report replaced with 0x01s

The former would put Cherry at fault for misreporting a blocked key; the latter would put Linux and macOS at fault for misunderstanding a valid report.

According to Device Class Definition for Human Interface Devices (HID) Version 1.11, Appendix C:

The keyboard must report a phantom state indexing Usage(ErrorRollOver) in all array fields whenever the number of keys pressed exceeds the Report Count. The limit is six non-modifier keys when using the keyboard descriptor in Appendix B. Additionally, a keyboard may report the phantom condition when an invalid or unrecognizable combination of keys is pressed.

Unfortunately the standard is written in double Dutch. Certainly, the existence of this strange report is intentional. However, someone has clearly misunderstood the standard (why on earth can't standards just give a clear example?)

[ilcavero]

Wow congrats on finding that info, and during xmas break no less! I think the solution is to plug other usb keyboards and see how they behave, either 0x0000010101010101 or 0x0101010101010101
I'm on holidays now but will definitively test that after new years, if anybody else can test it wireshark+usbcap on windows is probably the easiest way to examine the raw usb protocol

[ilcavero]

I tried with an apple wired usb keyboard on my linux machine and the result was that after leaving pressed 3 keys I got what you suspected was the correct pattern 0x00000101...

Code: Select all

ffff9200abf58600 249338681 C Ii:006:01 0 8 = 00001400 00000000
ffff9200abf58600 249338738 S Ii:006:01 -115 8 <
qffff9200abf58600 249666801 C Ii:006:01 0 8 = 0000141d 00000000
ffff9200abf58600 249666861 S Ii:006:01 -115 8 <
zzffff9200abf58600 250066794 C Ii:006:01 0 8 = 00000101 01010100   <-- HERE
ffff9200abf58600 250066819 S Ii:006:01 -115 8 <
zzzzzzzzzzzzzzzzffff9200abf58600 250882792 C Ii:006:01 0 8 = 0000141d 00000000
ffff9200abf58600 250882819 S Ii:006:01 -115 8 <

I haven't heard back from cherry support, initially they said it had been forwarded to a developer.

[Daniel Beardsmore]

Curiously, yours has 00 at the end instead of 01.

[Rimrul]

I think we have a G83-6000 at work. I might get around to testing that in January.

Yeah, that keyboard turned out to be a PS/2 only G83-6105. Sorry.

[Daniel Beardsmore]

Well, at least we're getting closer to understanding what's gone wrong! It's really a matter now for someone here who actually knows the USB standard, someone like hasu. The standard to me seems pointlessly obtuse.

[Daniel Beardsmore]

I haven't heard back from cherry support, initially they said it had been forwarded to a developer.

No word from Cherry so far, I gather?

[ilcavero]

I got word from Cherry, basically they screwed up but would not accept it, take any responsibility or apologize. The keyboard is not even a valid implementation of the boot keyboard protocol. Quite a disappointment of a company. Don't buy cherry keyboards unless they have NKR.

[kbdfr]

I got word from Cherry, basically they screwed up but would not accept it, take any responsibility or apologize. […]

Not sure how to interpret your post. Did they write they screwed up but would not etc.?
Or did you just insert your rant in between?

I'm not discussing the "screwed up" argument, by the way (I'm just a Windows user with no further clue),
but I do appreciate clear statements.

Spoiler:

signed: kbdfr, the grumpy chocolate bar

[ilcavero]

I got word from Cherry, basically they screwed up but would not accept it, take any responsibility or apologize. […]

Not sure how to interpret your post. Did they write they screwed up but would not etc.?
Or did you just insert your rant in between?

I'm not discussing the "screwed up" argument, by the way (I'm just a Windows user with no further clue),
but I do appreciate clear statements.

Spoiler:

signed: kbdfr, the grumpy chocolate bar

Yes I inserted my rant, I remembered this thread and just want to give a quick update because this whole affair was a big waste of time, I got a few emails a month or two ago where they basically argued that the spec does not specifically state that what they did is wrong so they are not at fault and that linux drivers should be fixed (conveniently they didn't say anything about OSX), but from actually reading thoroughly the HID spec and from being a developer myself I know that they screwed up. I had a few back and forth with them trying to at least get them to appreciate the free QA work we did on this thread and the only thing I got from them was to say that they will keep this in mind in the future. In any case for a keyboard that costs around 100€ this is unacceptable treatment of paying customers.

[hkwb2148]

Hello. What is the status of this?
Did they fix it by now? I'm interested in G80-3000, but I'd be using a keyboard over USB and with various operating systems.

[Findecanor]

This type of report should be valid according to spec... except that the spec is ambiguous on what data should be in the modifier byte.

As it said in the first post, Windows did not have a problem with this type of report.
Linux's USB HID stack did not handle this type of report correctly earlier, but this bug is supposed to have been fixed in later versions of the Linux kernel. (Just don't ask me about version numbers ...)

Many keyboards don't send ErrorRollOver reports, just to avoid problems with faulty host USB HID implementations. When they detect more than six non-modifier keys at once, they either block input or shift keys in FIFO order when the seventh key is pressed.

[hasu]

This problem is still there on Linux 5.4.0(Ubuntu 20.04.1).

I didn't read HID spec thoroughly but I'd say Cherry controller is faulty rather than Linux HID stack.

From natural interpretation of Appendix C of HID spec, keyboard should send 'valid' modifers in the first byte(modifer bitmap) of its report even in case of 'phamtom state'. I beleive that ErrorRollOver usage(0x01) should not be set in the first byte and we should put real modifier keys state or 0x00 if it is not possible. I still agree with you in terms of the spec's ambiguousness, though.

Related excerpts from Appendix C: Keyboard Implementation:

The keyboard must report a phantom state indexing Usage(ErrorRollOver) in
all array fields whenever the number of keys pressed exceeds the Report
Count. The limit is six non-modifier keys when using the keyboard descriptor
in Appendix B. Additionally, a keyboard may report the phantom condition
when an invalid or unrecognizable combination of keys is pressed.

from Comment in the example:

Phantom state.
[Four] Array keys
pressed. Modifiers
still reported.

Note This example uses a 4-byte report so that the phantom condition can be
more easily demonstrated. Most keyboards should have 8 or more bytes in their
reports.

https://usb.org/sites/default/files/hid1_11.pdf
wiki/Cherry_G80-3000#Possible_controller_bug