On Tue, 2023-05-30 at 13:05 +0200, 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@xxxxxxxxxxxxxxxxxxx> Can you please point to the user-space patches (or issues filed) that would integrate the support for those keycodes, and make the key presses do something? Has anyone tested that those keycodes are fit for purpose when mixed with other brightness changes that don't happen through key presses? > --- > 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 > +#define KEY_KBDILLUMCOLORCYCLE 0x2e9 > +#define KEY_KBDILLUMCHANGE 0x2ea > + > /* We avoid low common keys in module aliases so they don't get > huge. */ > #define KEY_MIN_INTERESTING KEY_MUTE > #define KEY_MAX 0x2ff
