Hi
Am 22.02.24 um 18:38 schrieb Pavel Machek:
Hi!
so after more feedback from the OpenRGB maintainers I came up with an even
more generic proposal:
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
evaluate-set-command ioctl taking:
{
enum command /* one of supported_commands */
union data
{
char raw[3072],
{
<input struct for command 0>
},
Yeah, so ... this is not a interface. This is a backdoor to pass
arbitrary data. That's not going to fly.
For keyboards, we don't need complete new interface; we reasonable
extensions over existing display APIs -- keyboards are clearly 2D.
I suppose they could be seen as *a* display, but if you are referring
to DRM KMS UAPI, then no, I don't see that fitting at all:
So -- we already have very similar displays in
drivers/auxdisplay. drivers/auxdisplay/cfag12864b.c is 128x64 display,
1-bit display for example.
Auxdisplay can be anything for everyone. It appears to be the rest that
didn't clearly fit elsewhere. The core interface seems to be a custom
char device. The fbdev code in cfag12864b is not representative.
- the "pixel grid" is not orthogonal, it's not a rectangle, and it
might not be a grid at all
It is quite close to orthogonal. I'd suggest simply pretending it is
orthogonal grid with some pixels missing :-). We already have
cellphone displays with rounded corners and holes in them, so I
suspect handling of missing pixels will be neccessary anyway.
- Timings and video modes? DRM KMS has always been somewhat awkward for
display devices that do not have an inherent scanout cycle and timings
totally depend on the amount of pixels updated at a time
(FB_DAMAGE_CLIPS), e.g. USB displays (not USB-C DP alt mode).
They do work, but they are very different from the usual hardware
involved with KMS, require special consideration in userspace, and
they still are actual displays while what we're talking about here
are not.
As you say, there are other displays with similar problems.
- KMS has no concept of programmed autonomous animations, and likely
never will. They are not useful with actual displays.
Yep. We need some kind of extension here, and this is likely be quite
vendor-specific, as animations will differ between vendors. I guess
"please play pattern xyzzy with parametrs 3 and 5" might be enough for this.
The litmus test for DRM and fbdev is something like "would the user run
the console, desktop, or any other meaningful output in this display".
That is also what userspace (e.g., X, Wayland, gfx terminals) expects: a
display to show the user's main output. Keyboard LEDs don't fit here.
Best regards
Thomas
- Userspace will try to light up KMS outputs automatically and extend
the traditional desktop there. This was already a problem for
head-mounted displays (HMD) where it made no sense. That was worked
around with an in-kernel list of HMDs and some KMS property
quirking.
This will need fixing for cfag12864b.c, no? Perhaps userspace should
simply ignore anything smaller than 240x160 or something...
Modern KMS UAPI very much aims to be a generic UAPI that abstracts
display devices. It already breaks down a little for things like USB
displays and virtual machines (e.g. qemu, vmware, especially with
remote viewers), which I find unfortunate. With HMDs the genericity
breaks down in other ways, but I'd claim HMDs are a better fit still
than full-featured VM virtual displays (cursor plane hijacking). With
non-displays like keyboards the genericity would be completely lost, as
they won't work at all the same way as displays. You cannot even show
proper images there, only coarse light patterns *IF* you actually know
the pixel layout. But the pixel layout is(?) hardware-specific which is
the opposite of generic.
While you could dress keyboard lights etc. up with DRM KMS UAPI, the
userspace would have to be written from scratch for them, and you
somehow need to make existing KMS userspace to never touch those
devices. What's the point of using DRM KMS UAPI in the first place,
then?
Well, at least we have good UAPI to work with. Other options were 100
files in /sys/class/leds, pretending it is a linear array of leds,
just passing raw data around, and pretending it is grid of RGB888
data.
Anyway, there are devices such as these: (8x8 LED display).
https://www.laskakit.cz/8x8-led-matice-s-max7219-3mm-cervena/
We should think about what interface we want for these, and then I
believe we should make RGB keyboards use something similar.
Best regards,
Pavel
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
