search

libratbag / libratbag

A DBus daemon to configure input devices, mainly high-end and gaming mice
MIT License
2.05k stars 254 forks source link

LED support for G300 #335

Open phomes opened 6 years ago

phomes commented 6 years ago

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?

whot commented 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.

bentiss commented 6 years ago

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?

whot commented 6 years ago

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.

whot commented 6 years ago

https://github.com/libratbag/libratbag/pull/360 has the start of LED color depth support

Hjdskes commented 6 years ago

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:

  1. Piper keeps the current UI and libratbag clamps the color to the nearest on/off values, or
  2. Piper can show a different UI (or, if GtkColorChooser allows this, the same UI with a more limited color palette) depending on the capabilities (like you started with in #369). I'm not sure yet how this would look like.

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.

captn3m0 commented 3 years ago

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)

image