[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVvHYAsM1p8O7J8r@duo.ucw.cz>
Date: Mon, 20 Nov 2023 21:53:52 +0100
From: Pavel Machek <pavel@....cz>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, jikos@...nel.org
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
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 2023-10-23 13:44:46, Miguel Ojeda wrote:
> On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> >
> > 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.
>
> Yeah, sounds quite reasonable too, in fact it may make more sense
> there given the LEDs are associated per-key rather than being an
> uniform matrix in a rectangle if I understand correctly. If the input
> subsystem wants to take it, that would be great.
Unfortunately we are getting no input from input subsystem. Question
seems to be more of "is auxdisplay willing to take it if it is done
properly"?
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists