On Oct 01 2024, Werner Sembach wrote: > (sorry resend because thunderbird made it a html mail) > > Hi, > > Am 30.09.24 um 19:06 schrieb Benjamin Tissoires: > > On Sep 30 2024, Werner Sembach wrote: > > > [...] > > > Thinking about it, maybe it's not to bad that it only changes once udev is > > > ready, like this udev could decide if leds should be used or if it should > > > directly be passed to OpenRGB for example, giving at least some consistency > > > only changing once: i.e. firmware -> OpenRGB setting and not firmware->leds > > > setting->OpenRGB setting. > > That would work if OpenRGB gets to ship the LampArray bpf object (not > > saying that it should). Because if OpenRGB is not installed, you'll get > > a led class device, and if/when OpenRGB is installed, full LampArray > > would be presented. > > The idea in my head is still that there is some kind of sysfs switch to > enable/disable leds. FWIW, I'm never a big fan of sysfs. They become UAPI and we are screwed without possibility to change them... > > My idea is then that a udev rule shipped with OpenRGB sets this switch to > disable before loading the BPF driver so leds never get initialized for the > final LampArray device. FWIW, udev-hid-bpf can inject a udev property into a HID-BPF. So basically we can have a udev property set (or not) by openrgb which makes the BPF program decide whether to present the keyboard as LampArray or not. > > > But anyway, BPF allows to dynamically change the behaviour of the > > device, so that's IMO one bonus point of it. > > > > > > FWIW, the use of BPF only allows you to not corner yourself. If you > > > > failed at your LampArray implementation, you'll have to deal with it > > > > forever-ish. So it's perfectly sensible to use BPF as an intermediate step > > > > where you develop both userspace and kernel space and then convert back > > > > the BPF into a proper HID driver. > > > I don't really see this point: The LampArray API is defined by the HID Usage > > > Table and the report descriptor, so there is not API to mess up and > > > everything else has to be parsed dynamically by userspace anyway, so it can > > > easily be changed and userspace just adopts automatically. > > > > > > And for this case the proper HID driver is already ready. > > Yeah, except we don't have the fallback LED class. If you are confident > > enough with your implementation, then maybe yes we can include it as a > > driver from day one, but that looks like looking for troubles from my > > point of view. > > To be on the safe side that we don't talk about different things: My current > plan is that the leds subsystem builds on top of the LampArray > implementation. I would say that the HID subsystem knows how to translate LampArray into a subset of LEDs. But I think that's what you are saying. > > Like this the leds part has to be only implemented once for all LampArray > devices be it emulated via a driver or native via firmware in the device > itself. yep, that's the plan. However, not sure how to fit LampArray into LED. > > And I feel confident that the UAPI should be that the userspace gets a > hidraw device with a LampArray HID descriptor, and every thing else is, by > the HID spec, dynamic anyway so I can still change my mind in implementation > specifics there, can't I? Yeah... I think?
