Hi Hans, thank you so much for taking the time to read through the questions and get back to me! Den ons 4 dec. 2024 kl 18:31 skrev Hans de Goede <hdegoede@xxxxxxxxxx>: > > So I think it is best to just emulate what the laptops where > the cycling is directly done by the embedded-control do. > > That is: > > 1. Add LED_BRIGHT_HW_CHANGED to the flags of the led_classdev > for the "xxx:kbd_backlight" led class device you expose > > 2. Filter out kbd-backlight-cycle keypresses and on such > a keypress: > > 2.1 Determine new brightness level > 2.2 Apply new brightness level > 2.3 Call: > > led_classdev_notify_brightness_hw_changed(&kbd_backlight_led_classdev, new_brightness_level); > This is actually exactly what I have already implemented with the one exception: I am executing exactly the same kind of logic you mentioned (via schedule_work()) but I have NOT filtered out the keypress; instead, it is just scheduling this logic to run in a workqueue and then going ahead and passing along the keypress as well, just in case anyone wanted to trigger any other kind of event from this hotkey. I have actually submitted a patch to the keyboard hwdb which was merged in to systemd that maps this particular key to "unknown" with the idea that someone who has this model would also likely have this platform driver module loaded, so by default the kernel-space action to actually change the brightness level would be executed (the "EC-like" behavior as you mentioned that they could not change), but the user would also have the option of remapping the key and triggering additional actions on top of this if they wanted. Does that sound appropriate or is it better to just filter out the keypress entirely once the above actions are scheduled/executed? Also as an aside, I have had a few users who have mentioned that if they have compiled and loaded i8042 as a module (which is then marked as "used by" samsung_galaxybook due to the i8042 filter), if they execute a modprobe -r then it also removes i8042 and their keyboard stops working. Is this known/expected behavior and/or is there anything that can be done in this driver itself to try and help prevent this from happening? Otherwise I guess a "fix" for this would be if users compile their kernel with CONFIG_SERIO_I8042=y then they would not have this problem? Thank you again! Best regards, Joshua > [...]
