<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Hi Hans, <div class="moz-cite-prefix">Am 30.01.24 um 18:10 schrieb Hans de Goede: </div> <blockquote type="cite" cite="mid:952409e1-2f0e-4d7a-a7a9-3b78f2eafec7@redhat.com"> <pre class="moz-quote-pre" wrap="">Hi Werner, On 1/30/24 12:12, Werner Sembach wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hi Hans, Am 29.01.24 um 14:24 schrieb Hans de Goede: </pre> </blockquote> </blockquote> <snip> <blockquote type="cite" cite="mid:952409e1-2f0e-4d7a-a7a9-3b78f2eafec7@redhat.com"> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I think that are mostly external keyboards, so in theory a possible cut could also between built-in and external devices. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> IMHO it would be better to limit /dev/rgbledstring use to only cases where direct userspace control is not possible and thus have the cut be based on whether direct userspace control (e.g. /dev/hidraw access) is possible or not.</pre> </blockquote> Ack <snip> <blockquote type="cite" cite="mid:952409e1-2f0e-4d7a-a7a9-3b78f2eafec7@redhat.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">So also no basic driver? Or still the concept from before with a basic 1 zone only driver via leds subsystem to have something working, but it is unregistered by userspace, if open rgb wants to take over for fine granular support? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Ah good point, no I think that a basic driver just for kbd backlight brightness support which works with the standard desktop environment controls for this makes sense. Combined with some mechanism for e.g. openrgb to fully take over control as discussed. It is probably a good idea to file a separate issue with the openrgb project to discuss the takeover API.</pre> </blockquote> I think the OpenRGB maintainers are pretty flexible at that point, after all it's similar to enable commands a lot of rgb devices need anyway. I would include it in a full api proposal. On this note: Any particular reason you suggested an ioctl interface instead of a sysfs one? (Open question as, for example, I have no idea what performance implications both have) <snip> <blockquote type="cite" cite="mid:952409e1-2f0e-4d7a-a7a9-3b78f2eafec7@redhat.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I opened an issue regarding this: <a class="moz-txt-link-freetext" href="https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916">https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916</a> </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Great, thank you.</pre> </blockquote> First replies are in. <blockquote type="cite" cite="mid:952409e1-2f0e-4d7a-a7a9-3b78f2eafec7@redhat.com"> <pre class="moz-quote-pre" wrap="">Regards, Hans</pre> </blockquote> Kind regards, Werner </body> </html>