Special keys no longer work after running cli

[mpldr]

It seems the keys are "removed" from the keyboards firmware as no key events are sent at all.

After factory reset:

# libinput debug-events
 event2   DEVICE_REMOVED          CHERRY CHERRY Keyboard            seat0 default group4  cap:k
-event4   DEVICE_REMOVED          CHERRY CHERRY Keyboard            seat0 default group4  cap:k
-event6   DEVICE_REMOVED          CHERRY CHERRY Keyboard Mouse      seat0 default group4  cap:p
-event6   DEVICE_ADDED            CHERRY CHERRY Keyboard Mouse      seat0 default group7  cap:p left scroll-nat scroll-button
-event4   DEVICE_ADDED            CHERRY CHERRY Keyboard            seat0 default group7  cap:kp scroll-nat
-event2   DEVICE_ADDED            CHERRY CHERRY Keyboard            seat0 default group7  cap:k
-event4   KEYBOARD_KEY            +12.178s	KEY_VOLUMEDOWN (114) pressed
 event4   KEYBOARD_KEY            +12.356s	KEY_VOLUMEDOWN (114) released
 event4   KEYBOARD_KEY            +13.150s	KEY_MUTE (113) pressed
 event4   KEYBOARD_KEY            +13.311s	KEY_MUTE (113) released
 event4   KEYBOARD_KEY            +13.756s	KEY_MUTE (113) pressed
 event4   KEYBOARD_KEY            +13.895s	KEY_MUTE (113) released
 event4   KEYBOARD_KEY            +14.446s	KEY_VOLUMEUP (115) pressed
 event4   KEYBOARD_KEY            +14.609s	KEY_VOLUMEUP (115) released
 event4   KEYBOARD_KEY            +15.167s	KEY_CALC (140) pressed
 event4   KEYBOARD_KEY            +15.329s	KEY_CALC (140) released
 event4   KEYBOARD_KEY            +19.792s	KEY_PLAYPAUSE (164) pressed
 event4   KEYBOARD_KEY            +19.936s	KEY_PLAYPAUSE (164) released
 event4   KEYBOARD_KEY            +20.253s	KEY_PLAYPAUSE (164) pressed
 event4   KEYBOARD_KEY            +20.418s	KEY_PLAYPAUSE (164) released

after running cherryrgb_cli --product-id 223 --brightness full animation wave slow 500475

# libinput debug-events
-event2   DEVICE_REMOVED          CHERRY CHERRY Keyboard            seat0 default group4  cap:k
-event4   DEVICE_ADDED            CHERRY CHERRY Keyboard            seat0 default group7  cap:k
-event6   DEVICE_ADDED            CHERRY CHERRY Keyboard Mouse      seat0 default group7  cap:p left scroll-nat scroll-button
-event2   DEVICE_ADDED            CHERRY CHERRY Keyboard            seat0 default group7  cap:k

Used Keyboard: Cherry MX 10.0n RGB

[skraus-dev]

Thanks for the report.

#17 - this might be responsible for overwriting the special keys on keyboard init.
Needs further investigation and research on what these commands actually trigger/set.

[mpldr]

Happy to help with debugging, not much of a rustacean though, so I probably can't help with providing code :)

[luv4bytes]

Could be worth a try to comment out the state fetching and try to set the LEDs without this. This would tell us if it's really the state fetching that "removes" the keys.

[mpldr]

No change when removing the state fetching.

[luv4bytes]

You could try commenting out individual payloads in the function that sets the animation as a next step. I mean it's got to be somewhere. If that doesn't give us the result we want, I'm pretty much clueless.

[felfert]

Confirmed.
I just noticed this issue and since I have the same keyboard (I thought see below),
I tried it out immediately. I still use the old version 0.2.1 (with my PR applied) so it's not something of the
newer changes that have been committed since. Here, the four special keys above the Numeric block
(Vol-, Mute, Vol+, Calc) are not working. I just never noticed, because I never used these before.
To be shure, I tested all other keys as well and they do work.

What is strange though:
Where is this key (KEY_PLAYPAUSE) on your keyboard? My keyboard does not have that. So there might be subtle
differences between keyboard models named "MX 10.0N" Also: What layout does your keyboard have? (Mine is
german.)

Also: A simple unplug/plug of the keyboard brings back those 4 keys to life. No special factory reset necessary.

Cheers
-Fritz

[mpldr]

Mine is also german. KEY_PLAYPAUSE is sent by Fn+F11 and indeed, replugging brings them back. Though that's hardly an optimal solution.

[felfert]

Found it and fixed it here 😃

The reason is:
The kernel_driver gets detached before claiming the device, but never gets attached again, after the program is finished.

In fact, instead of implicit calling detach_kernel_driver(), libusb1 provides a function that handles everything automatically for us. the rusb signature is:

.set_auto_detach_kernel_driver(boolean)

Expect a PR soon ...

Cheers
-Fritz