Status of bugreport to Cherry GmbH

[skraus-dev]

Description
As mentioned in issue #22, there is a firmware bug that produces bogus keyevents once LED data was set and the device is handed back to the kernel driver.

The bug was reported to Cherry GmbH (22.04.2023) and acknowledged (27.04.2023). It's being handed to the development division.
However, the support agent told me that it's unlikely to be fixed, because I am the first and only person reporting this bug :(

I simply wanted to open this ticket so all users are aware of it and can track possible responses / fixes from Cherry.

Additional context

• OS: This issue only occurs on Linux systems
• Architecture: [e.g. x64, ARM, ...]
• Keyboard (known so far):
  • G80-3000N TKL RGB
  • MX 10.0N RGB

[hjudt]

I have also reported this to Cherry two or three weeks ago, received a similar response but not that it won't be fixed. I haven't asked again though, maybe I should do so soon.

[hjudt]

Also note that the bug survives a restart; If you change some LED in windows, then reboot into Linux, the issue will be there. Connecting and disconnecting solves it.

[skraus-dev]

Cherry provided a BETA Firmware via E-Mail that fixes the issue on "G80-3000N TKL RGB".

• Typing is possible in regular speed after setting LEDs, no excessive KEY 250 events are produced
• FN Keys (Volume up/down/mute) still work

Very happy with that :)

[felfert]

Do you have a Ticket-ID or some other reference that I can refer to if I might contact them?

[skraus-dev]

Yup, here you go: Serviceanfrage-Nr. Che20230422-71160

[felfert]

FYI current state here:

• Contacted Cherry support
• Got a firmware from Cherry too, but update-utility does not recognize keyboard, so ticket still in progress.

[hjudt]

Same here for my MX 10.0N RGB. It says "USB HID device not found" or similar. I hope this is not because I am still using Win7, but the other utilities work in Win7 so I guess it is just the utility not recognizing my keyboard. Waiting for an updated utility.

[felfert]

I hope this is not because I am still using Win7

It's not. Happens on Win10 here.
Did you try my solution described here?

[hjudt]

I guessed so. No I haven't tried that solution. TBH, I'd prefer if Cherry fixed the firmware if it is a firmware issue.

[hjudt]

Cherry was very fast (a few hours) to send me the correct version of the update package, which applied firmware 1.0.5 to my keyboard. Previously, they sent me the wrong updater for the EU/Chinese variant, which did not recognize my keyboard. With this, now the issue is fixed, and special keys work. I have only tested the official Cherry utility software this time for changing LED settings, but I think this doesn't matter.

[felfert]

Huh? The special keys not working were not the problem of the firmware. Instead, those were caused by the OLD cherryrgb_cli unloading the kernel driver before setting RGB colors and then forgetting to load it again afterwards?!

It was only after the fix of the above problem, that we discovered those bogus events that lead to strage effects like slow response etc.

Regarding Cherry support. I got exactly the same: The sent me the correct updater and it appears to work (not to cause problems)

However:
Running my driver in debug mode, i still see superfluous incoming interrupt packets after sending RGB commands. It just so happens, that those are different than the ones before and happen to be filtered out by the regular kernel driver. With my driver (which did not filter those new packets), I got mouse movements on each keypress - quite funny - well now my driver filtersd those too.

[hjudt]

I see. Well, I cannot tell of any other problems except the unknown key event spam that slows things down and makes the keyboard misbehave, and those are fixed for me. To be honest, I have not had any need to use the cherryrgb_cli utility because I simply configured it once using the Cherry windows utility and do not intend to change it. I have also removed the windows utility from autoruns, so I somehow worked around it anyway. But it is nice that those problems have been fixed at least. Maybe I'll try cherryrgb_cli to find out how to make the keys glow in a nice yellow color...