On Mon, Dec 03, 2018 at 11:48:49AM +0100, Linus Walleij wrote: > On Fri, Nov 30, 2018 at 6:03 AM Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > > > Given the bits I've seen from openrazer, > > there is quite a struggle to get things to work on all devices correctly, so > > there's a high chance that a) this won't work on the devices and b) that > > you're locking yourself into an API that cannot be supported on next year's > > device. > > The ABI (not API, but maybe I'm being picky) used here is that > of the LED class, extended with one sysfs file that selects a > keyboard effect from an enumerated list of effects. here's the problem: we all (mostly) agree on what on/off mean. beyond that it gets a bit more complicated. What's the list of effects you envision? On the mice we've seen in libratbag we have breathing, heartbeat, cycle, and some mice with custom waveforms. You have to (just like we did) figure out which effects are common and which ones are esoteric and to be left to userspace. Let's assume you pick cycle. Can we pick the colours to cycle? Because I think if you don't let them do that, you might as well skip it. How about the cycle frequency? If you pick breathing or heartbeat, same thing. Colours and frequency probably matters to users. Except that you can't parameterise the frequency in all cases (iirc). These are all decisions to be made and they can be made. But the real issue I have with all the above and it affects development in libratbag as well is that neither I nor Benjamin are those use any of these. I cannot tell you what the minimum baseline would be and so far we got almost zero feedback what users actually want to do. So we're mostly stabbing in the dark, making the libratbag bits as flexible as possible. Regardless what you pick for the kernel support, you need to make sure it covers the 90% use-case so that we don't *have* to implement all this in userspace. Otherwise, if you only cover 50% we end up with two implementations that can't leverage each other and the situation is worse than now. Right now, what I pessimistically predict is the latter case where we end up with kernel support that's not enough. Cheers, Peter > > Anything more esoteric than that is not part of the patch > and maybe should be handled by userspace rather than the > kernel. > > Let me iterate this point: both/and not either/or. > > Yours, > Linus Walleij
