linux-kernel - Re: [PATCH] input: Add new keyboard backlight control keys to match modern notebooks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dba63a7b-6e5d-6145-5eea-0c2da3dc9445@redhat.com>
Date:   Wed, 31 May 2023 15:52:35 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Werner Sembach <wse@...edocomputers.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Bastien Nocera <hadess@...ess.net>
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: Add new keyboard backlight control keys to match
 modern notebooks

Hi Werner,

Thank you for your patch.

On 5/30/23 13:05, Werner Sembach wrote:
> 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@...edocomputers.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