Hi, On 1/30/24 20:08, Werner Sembach wrote: > Hi, > > Am 30.01.24 um 19:35 schrieb Hans de Goede: >> Hi, >> >> On 1/30/24 19:09, Werner Sembach wrote: >>> Hi Hans, >>> >>> resend because Thunderbird htmlified the mail :/ >> I use thunderbird too. If you right click on the server name >> and then go to "Settings" -> "Composition & Addressing" >> and then uncheck "Compose messages in HTML format" >> I think that should do the trick. > Can't set this globally or other people will complain that my replies delete > company logos in signatures xD. But usually the auto detection of Thunderbird > works. >> >>> Am 30.01.24 um 18:10 schrieb Hans de Goede: >>>> Hi Werner, >>>> >>>> On 1/30/24 12:12, Werner Sembach wrote: >>>>> Hi Hans, >>>>> >>>>> Am 29.01.24 um 14:24 schrieb Hans de Goede: >>> <snip> >>>>> I think that are mostly external keyboards, so in theory a possible cut >>>>> could also between built-in and external devices. >>>> 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. >>> Ack >>> >>> <snip> >>> >>>>> 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? >>>> 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. >>> 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. >> Ack. >> >>> 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) >> sysfs APIs typically have a one file per setting approach, >> so for effects with speed and multiple-color settings you >> would need a whole bunch of different files and then you >> would either need to immediately apply every setting, >> needing multiple writes to the hw for a single effect >> update, or have some sort of "commit" sysfs attribute. >> >> With ioctls you can simply provide all the settings >> in one call, which is why I suggested using ioctls. > > Ack > > If the static mode update is fast enough to have userspace controlled > animations, OpenRGB is calling that direct mode. Is it feasible to send 30 or > more ioctls per second for such an direct mode? Or should this spawn a > special purpose sysfs file that is kept open by userspace to continuously > update the keyboard?
ioctls are quite fast and another advantage of ioctls is you open the /dev/rgbledstring# device only once and then re-use the fd for as many ioctls as you want. Regards, Hans
