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: <ZdeHi/WTNXEBevAX@duo.ucw.cz>
Date: Thu, 22 Feb 2024 18:42:35 +0100
From: Pavel Machek <pavel@....cz>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Gregor Riepl <onitake@...il.com>,
	Werner Sembach <wse@...edocomputers.com>,
	Lee Jones <lee@...nel.org>, jikos@...nel.org,
	linux-kernel@...r.kernel.org, Jelle van der Waa <jelle@...aa.nl>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.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: Future handling of complex RGB devices on Linux v2

Hi!

> > To be honest, I think the kernel shouldn't include too much high-level complexity. If there is a desire to implement a generic display device on top of the RGB device, this should be a configurable service running in user space. The kernel should provide an interface to expose this emulated display as a "real" display to applications - unless this can also be done entirely in user space in a generic way.
> 
> We really need to stop seeing per key addressable RGB keyboards as displays:
> 
> 1. Some "pixels" are non square
> 2. Not all "pixels" have the same width-height ratio

They are quite close to square usually.

> 3. Not all rows have the same amount of pixels

True for cellphone displays, too. Rounded corners.

> 4. There are holes in the rows like between the enter key and then numpad

True for cellphone displays, too. Hole for camera.

> 5. Some "pixels" have multiple LEDs beneath them. These might be addressable
>    per LEDs are the sub-pixels ? What about a 2 key wide backspace key vs
>    the 1 key wide + another key (some non US layouts) in place of the backspace?
>    This will be "2 pixels" in some layout and 1 pixel with maybe / maybe-not
>    2 subpixels where the sub-pixels may/may not be individually addressable ?

Treat those "sub pixels" as pixels. They will be in same matrix as the rest.

> For all these reasons the display analogy really is a bit fit for these keyboards
> we tried to come up with a universal coordinate system for these at the beginning
> of the thread and we failed ...

I'd suggest trying harder this time :-).

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ