Re: Implement per-key keyboard backlight as auxdisplay?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hans & the others,

[snip]
I also stumbled across a new Problem:

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:

    - Pro:

        - Still offers all default attributes for use with UPower

        - Fairly simple to implement from the preexisting codebase

        - Could be implemented for all (to me) known internal keyboard backlights

    - Con:

        - Violates the simplicity paradigm of the leds interface (e.g. with this one leds entry controls possible multiple leds)

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 lighting modes

        - No support for arbitrary led outlines yet (e.g. ISO style enter-key)

3. Implement in input subsystem

    - Pro:

        - Preexisting concept for keys and key purpose

    - Con:

        - Not in scope for subsystem

        - No other preexisting light infrastructure

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

    - Pro:

        - Most simple to implement basic support

        - In scope for led subsystem simplicity paradigm

    - Con:

        - Not all built in keyboard backlights can be implemented in a userspace only driver

Kind Regards,

Werner

Just a gentle bump and request for comments again. 4. would be better then nothing but it is not a universal future proof solution so I'm hesitant to put work into it even though it would be the simplest driver. I still tend towards 1. as the leds interface already got expanded once with the multicolor stuff.

The only other way I see would be to implement a platform driver with no standardized api or implement a complete new api/subsystem from the ground up.

Kind Regards,

Werner





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux