On Tue, 2023-05-30 at 13:05 +0200, Werner Sembach wrote:
The old three KEY_KBDILLUM* keycodes don't reflect the currentCan you please point to the user-space patches (or issues filed) that
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>
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