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. > - 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. > - 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 -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
