Re: [PATCH] input: Add new keyboard backlight control keys to match modern notebooks
From: Hans de Goede <hidden>
Date: 2023-05-31 14:04:19
Also in:
lkml
Hi Werner, Thank you for your patch. On 5/30/23 13:05, Werner Sembach wrote:
quoted hunk ↗ jump to hunk
The old three KEY_KBDILLUM* keycodes don't reflect the current situation modern notebooks anymore. Especially the ones with RGB keyboards. e.g. - Clevo NL50NU has a toggle, an up, a down and a color-cycle key - TongFang PH4ARX1 doesn't have a toggle key, but one that cycles through off, half-brightness, and full-brightness. Also, on some devices these keys are already implemented in firmware. It would still be nice if there is a way to let userspace know when one of these keys is pressed to display the OSD, but don't advice it to actually do anything. This is the intended purpose of the KEY_KBDILLUMCHANGE define. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> --- include/uapi/linux/input-event-codes.h | 4 ++++ 1 file changed, 4 insertions(+)diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 022a520e31fc2..05287bf9a77f7 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h@@ -803,6 +803,10 @@ #define BTN_TRIGGER_HAPPY39 0x2e6 #define BTN_TRIGGER_HAPPY40 0x2e7 +#define KEY_KBDILLUMCYCLE 0x2e8
I do not really see what the difference is between this and the existing KEY_KBDILLUMTOGGLE, userspace can already choice whether it toggles to a number of states or just toggles on/off. So IMHO this one should be dropped.
+#define KEY_KBDILLUMCOLORCYCLE 0x2e9
This one is fine.
+#define KEY_KBDILLUMCHANGE 0x2ea
Keyboard backlight support should be exported to userspace as a LED class device, see e.g. : drivers/platform/x86/thinkpad_acpi.c : tpacpi_led_kbdlight drivers/platform/x86/dell/dell-laptop.c : kbd_led And the LED class device sysfs API already has a mechanism for signalling kbd-brightness changes triggered by the hw itself (e.g. by the embedded controller) to userspace. See the use of the LED_BRIGHT_HW_CHANGED flag and the calling of led_classdev_notify_brightness_hw_changed() in the 2 above drivers. So strong NACK for adding KEY_KBDILLUMCHANGE, this is duplicate with the led_classdev_notify_brightness_hw_changed() functionality which is already supported by userspace. E.g. GNOME will show an OSD notification similar to the sound volume change OSD when changing the keyboard brightness through EC handled hotkeys on ThinkPads and various Dell models. TL;DR: to me only KEY_KBDILLUMCOLORCYCLE makes sense, assuming that this needs to be handled by userspace, if this is handled in the EC then this too should simply call led_classdev_notify_brightness_hw_changed() Regards, Hans
+ /* We avoid low common keys in module aliases so they don't get huge. */ #define KEY_MIN_INTERESTING KEY_MUTE #define KEY_MAX 0x2ff