Add a setting to choose if OpenRGB devices should be split into zones
DarthAffe opened this issue · comments
follow up of #278 (comment)
Would it be possible to do this for specific devices? I would need to load them first which doesn't make sense.
I'd say for most use cases it would be fine to be able to specify which types should be split which seems like it could be done by allowing to set a type-flag in the device definition.
I've had some requests about per-device control. One thing to keep in mind js that layouts break if we switch this around. I'm not sure what the best way to adapt to this would be, maybe include the zone name in the sub-device name?
I agree that for the vast majority of cases, the current solution is acceptable.
As for loading them first, we could have Artemis use the openrgb client directly, bypassing rgb.net, to have the user decide which devices to split.
As for loading them first, we could have Artemis use the openrgb client directly, bypassing rgb.net, to have the user decide which devices to split.
How would you configure that in RGB.NET?
While artemis could workaround that somehow for sure the solution here has to work indipendent of that too.
I'm not sure yet. We could store a collection of identifiers as a property, and check if any of the devices found during detection match those identifiers.
The hard part is finding an identifier that works. Name is obviously not perfect, because 2 of the same model device will have the same name. Serial number is not available for every device. Index changes if the user connects / disconnects a device, etc.
How about adding some kind of callback to the device provider (perhaps a delegate?)
The callback provides a device and expects a boolean return value a indicating whether to split the device.
That leaves the intricacies of determining which device is which and whether to split it with the user.
If they then opt to provide the callback they can look at the device type or whatever they need. If no callback is provided you can default to current behaviour.
I like that idea, we can just pass the device to the user just like it's currently used in the existing check.
Example of a problematic use case: Artemis-RGB/Artemis#758
This problem is getting more complicated:
Up until now, we had to decide if one OpenRgbDevice gets split into multiple RGB.NET.IRGBDevice or not. The next OpenRGB update will bring in the concept of "segments".
Just like each OpenRgbDevice is split into one or more OpenRgbZone, each OpenRgbZone can be split into one or more OpenRgbSegment. I added support for these segments in my client and I'm working on the device provider right now, but i'm now unsure how to handle this.
It seems to me like OpenRgbSegments should not be optional, since they are used exclusively (as far as i know) to split a zone like, for example, a channel on a corsair lighting node, into multiple fans. This means that a 32-LED strip can be logically split into 4, 8-led fans.
Possibilities:
- Leave it roughly as it is, but add logic to forcefully split a zone if it has segments
- Implement more complicated logic to let user decide if a device gets split by zones or not, and force segments to split?
- Something else entirely
Additional question: what should the name of these subdevices be? OpenRGB devices, zones, and segments all have separate names we can use. For example, here:
Device name - "Corsair Lighting Node Core" - Should we use this as a prefix for sub devices?
Zone names - "Corsair Channel 1" and 2 - This doesn't seem too relevant in case there are segments, but useful otherwise. name could be also like "IO Shield LEDs" or "Rgb Header 1"
Segments - "fan 1..4" - This is user customizable in the OpenRgb GUI. I think we should use these for the name as well.