Hi! > We have an upcoming device that has a per-key keyboard backlight, but does > the control completely via a wmi/acpi interface. So no usable hidraw here > for a potential userspace driver implementation ... > > So a quick summary for the ideas floating in this thread so far: > > 1. Expand leds interface allowing arbitrary modes with semi arbitrary > optional attributes: > - Con: > > - Violates the simplicity paradigm of the leds interface (e.g. with > this one leds entry controls possible multiple leds) Let's not do this. > 2. Implement per-key keyboards as auxdisplay > > - Pro: > > - Already has a concept for led positions > > - Is conceptually closer to "multiple leds forming a singular entity" > > - Con: > > - No preexisting UPower support > > - No concept for special hardware lightning modes > > - No support for arbitrary led outlines yet (e.g. ISO style enter-key) Please do this one. > 3. Implement in input subsystem > > - Pro: > > - Preexisting concept for keys and key purpose > > - Con: > > - Not in scope for subsystem > > - No other preexisting light infrastructure Or negotiate with input people to do this. > 4. Implement a simple leds driver only supporting a small subset of the > capabilities and make it disable-able for a userspace driver to take over No. Kernel should abstract this away. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
