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.
signature.asc
Description: PGP signature
