Editing Cherry G80-3000 (section)

==Possible controller bug==
G80-3000, [[Cherry G80-3600|G80-3600]] (a G80-3000 with 6KRO) and [[Cherry G81-3000|G81-3000]] keyboards exhibit a potential bug with the controller under USB operation. Whenever a keystroke is blocked, a USB report is issued containing 0x0101010101010101. [[Microsoft Windows]] discards this report, while Linux and [[macOS]] will attempt to obey it. The first byte holds the modifier keys, and bit 1 is left control; Linux is confirmed to retrospectively apply the apparent control keystroke to the most recently-pressed key. For example, holding Q, then holding A at the same time, reaches the rollover limit of a G30-3000; when P is then struck with the first two keys held, that keystroke is blocked, causing 0x010101010101010101 to be emitted, which applies left control to the most recently-pressed key (A), causing the system to see Ctrl+A.<ref name="DT-bug" />

The USB HID specification indicates (in Appendix C) that instances of keys being blocked must be reported to the OS, but the wording of the specification is hard to understand and no example is given.<ref name="USB-HID" /> Specifically, the standard specifies:

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

Based on the problems displayed, there is a suggestion that only the six non-modifier key position fields should be set to 0x01, giving 0x000001010101010101. Affected Cherry controllers also put 0x01 into the modifier field (first byte) and into the second byte, which is reserved and expected to contain 0x00. Setting those first two bytes to 0x01 prevents the aforementioned operating systems from correctly interpreting the report, but it remains unproven as to where the fault actually lies: it may be that Linux and macOS are misinterpreting a valid report. Cherry have yet to comment.<ref name="DT-bug" />