linux-kernel - Re: Implement per-key keyboard backlight as auxdisplay?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sf61bm8t.fsf@intel.com>
Date:   Mon, 23 Oct 2023 14:40:18 +0300
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Pavel Machek <pavel@....cz>
Cc:     Lee Jones <lee@...nel.org>, linux-kernel@...r.kernel.org,
        Werner Sembach <wse@...edocomputers.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        linux-input@...r.kernel.org, ojeda@...nel.org,
        linux-leds@...r.kernel.org
Subject: Re: Implement per-key keyboard backlight as auxdisplay?

On Mon, 16 Oct 2023, Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:
> On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek <pavel@....cz> wrote:
>>
>> So... a bit of rationale. The keyboard does not really fit into the
>> LED subsystem; LEDs are expected to be independent ("hdd led") and not
>> a matrix of them.
>
> Makes sense.
>
>> We do see various strange displays these days -- they commonly have
>> rounded corners and holes in them. I'm not sure how that's currently
>> supported, but I believe it is reasonable to view keyboard as a
>> display with slightly weird placing of pixels.
>>
>> Plus, I'd really like to play tetris on one of those :-).
>>
>> So, would presenting them as auxdisplay be acceptable? Or are there
>> better options?
>
> It sounds like a fair use case -- auxdisplay are typically simple
> character-based or small graphical displays, e.g. 128x64, that may not
> be a "main" / usual screen as typically understood, but the concept is
> a bit fuzzy and we are a bit of a catch-all.
>
> And "keyboard backlight display with a pixel/color per-key" does not
> sound like a "main" screen, and having some cute effects displayed
> there are the kind of thing that one could do in the usual small
> graphical ones too. :)
>
> But if somebody prefers to create new categories (or subcategories
> within auxdisplay) to hold these, that could be nice too (in the
> latter case, I would perhaps suggest reorganizing all of the existing
> ones while at it).

One could also reasonably make the argument that controlling the
individual keyboard key backlights should be part of the input
subsystem. It's not a display per se. (Unless you actually have small
displays on the keycaps, and I think that's a thing too.)

There's force feedback, there could be light feedback? There's also
drivers/input/input-leds.c for the keycaps that have leds, like caps
lock, num lock, etc.

Anyway, just throwing ideas around, no strong opinions, really.


BR,
Jani.


-- 
Jani Nikula, Intel