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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZarYSkzISyS+wuYR@duo.ucw.cz>
Date: Fri, 19 Jan 2024 21:15:06 +0100
From: Pavel Machek <pavel@....cz>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Werner Sembach <wse@...edocomputers.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>, jikos@...nel.org,
	Jelle van der Waa <jelle@...aa.nl>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Lee Jones <lee@...nel.org>, linux-kernel@...r.kernel.org,
	"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?

Hi!

> >> 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.
> 
> Ok, so based on the discussion so far and Pavel's feedback lets try to
> design a custom userspace API for this. I do not believe that auxdisplay
> is a good fit because:

Ok, so lets call this a "display". These days, framebuffers and drm
handles displays. My proposal is to use similar API as other displays.

> So my proposal would be an ioctl interface (ioctl only no r/w)
> using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
> 
> For per key controllable rgb LEDs we need to discuss a coordinate
> system. I propose using a fixed size of 16 rows of 64 keys,
> so 64x16 in standard WxH notation.
> 
> And then storing RGB in separate bytes, so userspace will then
> always send a buffer of 192 bytes per line (64x3) x 14 rows
> = 3072 bytes. With the kernel driver ignoring parts of
> the buffer where there are no actual keys.

That's really really weird interface. If you are doing RGB888 64x14,
lets make it a ... display? :-).

ioctl always sending 3072 bytes is really a hack.

Small displays exist and are quite common, surely we'd handle this as
a display:
https://pajenicko.cz/displeje/graficky-oled-displej-0-66-64x48-i2c-bily-wemos-d1-mini
It is 64x48.

And then there's this:
https://pajenicko.cz/displeje/maticovy-8x8-led-displej-s-radicem-max7219
and this:
https://pajenicko.cz/displeje/maticovy-8x32-led-displej-s-radicem-max7219

One of them is 8x8.

Surely those should be displays, too?

And yes, we'd probably want some extra ioctls on top, for example to
map from input device to this and back, and maybe for various effects,
too. And yes, I realize that display with holes in it and with some
pixels bigger than others is weird, but it still looks like a display
to me. (And phones have high-res displays with rounded corners and
holes in them, so... we'll need to deal with weird displays anyway).

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)