Open phomes opened 6 years ago
I think clamping it is the right thing to do here. We could add capabilities in the form of LED_BIT_DEPTH_1, LED_BIT_DEPTH_8, etc. but we'd have to figure out what piper does in response to that.
We also have device that don't do RGB at all.
Maybe we should just put this in the .device file so that piper can get access to it too?
should the device files be exported to piper? I don't think so, better to have this abstracted in the API. the device files are just for things that we can't query from the device.
https://github.com/libratbag/libratbag/pull/360 has the start of LED color depth support
should the device files be exported to piper? I don't think so, better to have this abstracted in the API. the device files are just for things that we can't query from the device.
Agreed -- the only thing Piper should bother with is the DBus API exposed by ratbagd.
we'd have to figure out what piper does in response to that.
I think there are two options:
How noticeable would it be for the user when we present the current UI and the colors are clamped? If this is acceptable, that'd have my preference. If the difference is too large, I think we should go for the second approach.
The current UX is fairly un-intuitive, as the picked color is many times far away from the clicked one. For reference, this is how the UI looks in the Logitech (via a YouTube review)
The G300 has a single LED that can be configured in 8 different colors. It is basically 1 on/off bit for each of red, green, and blue.
How should we support this from libratbag? The getter is easy but how should we deal with setting? Just clamp to nearest on/off value? Is it overkill to have a new capability and let piper show a different color picker?