Messages in this thread | | | Date | Thu, 18 Jan 2024 18:45:36 +0100 | From | Pavel Machek <> | Subject | Re: Implement per-key keyboard backlight as auxdisplay? |
| |
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. [unhandled content-type:application/pgp-signature] | |