From: Jani Nikula <jani.nikula@linux.intel.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Pavel Machek <pavel@ucw.cz>
Cc: Lee Jones <lee@kernel.org>,
linux-kernel@vger.kernel.org,
Werner Sembach <wse@tuxedocomputers.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linux-input@vger.kernel.org, ojeda@kernel.org,
linux-leds@vger.kernel.org
Subject: Re: Implement per-key keyboard backlight as auxdisplay?
Date: Mon, 23 Oct 2023 14:40:18 +0300 [thread overview]
Message-ID: <87sf61bm8t.fsf@intel.com> (raw)
In-Reply-To: <CANiq72mfP+dOLFR352O0UNVF8m8yTi_VmOY1zzQdTBjPWCRowg@mail.gmail.com>
On Mon, 16 Oct 2023, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek <pavel@ucw.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
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Pavel Machek <pavel@ucw.cz>
Cc: Lee Jones <lee@kernel.org>,
linux-kernel@vger.kernel.org,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Werner Sembach <wse@tuxedocomputers.com>,
linux-input@vger.kernel.org, ojeda@kernel.org,
linux-leds@vger.kernel.org
Subject: Re: Implement per-key keyboard backlight as auxdisplay?
Date: Mon, 23 Oct 2023 14:40:18 +0300 [thread overview]
Message-ID: <87sf61bm8t.fsf@intel.com> (raw)
In-Reply-To: <CANiq72mfP+dOLFR352O0UNVF8m8yTi_VmOY1zzQdTBjPWCRowg@mail.gmail.com>
On Mon, 16 Oct 2023, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek <pavel@ucw.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
next prev parent reply other threads:[~2023-10-23 11:40 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 19:00 [PATCH] leds: rgb: Implement per-key keyboard backlight for several TUXEDO devices Werner Sembach
2023-10-11 19:21 ` Werner Sembach
2023-10-12 8:58 ` Pavel Machek
2023-10-12 10:02 ` Werner Sembach
2023-10-12 14:05 ` Pavel Machek
2023-10-12 16:35 ` Werner Sembach
2023-10-13 12:19 ` Pavel Machek
2023-10-13 14:38 ` Werner Sembach
2023-10-13 14:54 ` Implement per-key keyboard backlight as auxdisplay? Werner Sembach
2023-10-13 14:54 ` Werner Sembach
2023-10-13 19:56 ` Pavel Machek
2023-10-13 19:56 ` Pavel Machek
2023-10-13 20:03 ` Pavel Machek
2023-10-13 20:03 ` Pavel Machek
2023-10-16 10:57 ` Miguel Ojeda
2023-10-16 10:57 ` Miguel Ojeda
2023-10-23 11:40 ` Jani Nikula [this message]
2023-10-23 11:40 ` Jani Nikula
2023-10-23 11:44 ` Miguel Ojeda
2023-10-23 11:44 ` Miguel Ojeda
2023-11-20 20:53 ` Pavel Machek
2023-11-20 20:53 ` Pavel Machek
2023-11-20 20:52 ` Pavel Machek
2023-11-20 20:52 ` Pavel Machek
2023-11-21 11:33 ` Werner Sembach
2023-11-21 11:33 ` Werner Sembach
2023-11-21 12:20 ` Hans de Goede
2023-11-21 12:20 ` Hans de Goede
2023-11-21 13:29 ` Werner Sembach
2023-11-21 13:29 ` Werner Sembach
2023-11-22 18:34 ` Hans de Goede
2023-11-22 18:34 ` Hans de Goede
2023-11-27 10:59 ` Werner Sembach
2023-11-27 10:59 ` Werner Sembach
2023-12-29 19:13 ` Werner Sembach
2024-01-17 15:26 ` Hans de Goede
2024-01-17 15:26 ` Hans de Goede
2024-01-17 16:50 ` Userspace API for per key backlight for non HID (no hidraw) keyboards Hans de Goede
2024-01-17 16:50 ` Hans de Goede
2024-01-17 19:03 ` Armin Wolf
2024-01-17 19:03 ` Armin Wolf
2024-01-18 0:58 ` Werner Sembach
2024-01-18 0:58 ` Werner Sembach
2024-01-18 17:45 ` Implement per-key keyboard backlight as auxdisplay? Pavel Machek
2024-01-18 17:45 ` Pavel Machek
2024-01-18 22:32 ` Werner Sembach
2024-01-18 22:32 ` Werner Sembach
2024-01-19 8:44 ` Hans de Goede
2024-01-19 8:44 ` Hans de Goede
2024-01-19 10:51 ` Jani Nikula
2024-01-19 10:51 ` Jani Nikula
2024-01-19 16:06 ` Werner Sembach
2024-01-19 16:06 ` Werner Sembach
2024-01-19 18:33 ` Dmitry Torokhov
2024-01-19 18:33 ` Dmitry Torokhov
2024-01-19 22:14 ` Pavel Machek
2024-01-19 22:14 ` Pavel Machek
2024-01-23 16:51 ` Werner Sembach
2024-01-23 16:51 ` Werner Sembach
2024-01-19 15:19 ` Werner Sembach
2024-01-19 16:04 ` Werner Sembach
2024-01-19 16:04 ` Werner Sembach
2024-01-29 13:24 ` Hans de Goede
2024-01-29 13:24 ` Hans de Goede
2024-01-30 11:12 ` Werner Sembach
2024-01-30 11:12 ` Werner Sembach
2024-01-30 17:10 ` Hans de Goede
2024-01-30 17:10 ` Hans de Goede
2024-01-30 18:01 ` Werner Sembach
2024-01-30 18:09 ` Werner Sembach
2024-01-30 18:09 ` Werner Sembach
2024-01-30 18:35 ` Hans de Goede
2024-01-30 18:35 ` Hans de Goede
2024-01-30 19:08 ` Werner Sembach
2024-01-30 19:08 ` Werner Sembach
2024-01-30 19:46 ` Hans de Goede
2024-01-30 19:46 ` Hans de Goede
2024-01-31 11:41 ` Future handling of complex RGB devices on Linux Werner Sembach
2024-01-31 11:41 ` Werner Sembach
2024-01-31 15:52 ` Roderick Colenbrander
2024-01-31 15:52 ` Roderick Colenbrander
2024-02-21 11:12 ` Future handling of complex RGB devices on Linux v2 Werner Sembach
2024-02-21 22:17 ` Pavel Machek
2024-02-22 9:04 ` Pekka Paalanen
2024-02-22 17:38 ` Pavel Machek
2024-02-23 8:53 ` Pekka Paalanen
2024-07-23 20:40 ` Keybaords with arrays of RGB LEDs was " Pavel Machek
2024-02-23 9:21 ` Thomas Zimmermann
2024-02-22 10:46 ` Hans de Goede
2024-02-22 11:38 ` Gregor Riepl
2024-02-22 12:39 ` Hans de Goede
2024-02-22 13:14 ` Future handling of complex RGB devices on Linux v3 Werner Sembach
2024-03-18 11:11 ` Hans de Goede
2024-03-19 15:18 ` Werner Sembach
2024-03-25 14:18 ` Hans de Goede
2024-03-25 17:01 ` Werner Sembach
2024-03-20 11:16 ` Werner Sembach
2024-03-20 11:33 ` Werner Sembach
2024-03-20 18:45 ` Werner Sembach
2024-03-25 14:25 ` In kernel virtual HID devices (was Future handling of complex RGB devices on Linux v3) Hans de Goede
2024-03-25 15:56 ` Benjamin Tissoires
2024-03-25 16:48 ` Werner Sembach
2024-03-25 18:30 ` Hans de Goede
2024-03-26 7:57 ` Werner Sembach
2024-03-26 15:39 ` Benjamin Tissoires
2024-03-26 16:57 ` Werner Sembach
2024-03-27 11:03 ` Benjamin Tissoires
2024-03-28 23:52 ` Werner Sembach
2024-03-27 11:01 ` Hans de Goede
2024-07-24 17:36 ` Pavel Machek
2024-07-24 21:05 ` Werner Sembach
2024-07-24 21:08 ` Werner Sembach
2024-03-25 18:38 ` Miguel Ojeda
2024-04-09 13:33 ` Andy Shevchenko
2024-02-22 17:42 ` Future handling of complex RGB devices on Linux v2 Pavel Machek
2024-02-22 17:52 ` Pavel Machek
2024-02-22 17:23 ` Pavel Machek
2024-02-23 8:33 ` Werner Sembach
2024-01-19 20:15 ` Implement per-key keyboard backlight as auxdisplay? Pavel Machek
2024-01-19 20:15 ` Pavel Machek
2024-01-19 20:22 ` Werner Sembach
2024-01-19 20:22 ` Werner Sembach
2024-01-19 20:32 ` Pavel Machek
2024-01-19 20:32 ` Pavel Machek
2024-01-29 13:24 ` Hans de Goede
2024-01-29 13:24 ` Hans de Goede
2023-10-12 13:00 ` [PATCH] leds: rgb: Implement per-key keyboard backlight for several TUXEDO devices kernel test robot
2023-10-16 11:21 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sf61bm8t.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=lee@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=pavel@ucw.cz \
--cc=wse@tuxedocomputers.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.