Bug: Older models interpretting green as red

[Julusian]

It is debatable if this is a bug or intentional, but for my usage this is a bug, and I don't see a way that I can workaround it.

Both the LINEAR and LEGACY backlight modes, interpret a green value as illuminating the red led: https://github.com/SuperFlyTV/xkeys/blob/master/packages/core/src/xkeys.ts#L501

In companion, we do not want to do this (it has been decided that this will be confusing for our users), so have been working around this by simply omitting the green value. But with the newer rgb models, we need to provide this value.
I don't see a way for us to detect what backlight mode the model uses, so I can't see a way for us to conditionally provide this, or a way to disable this 'green is red' behaviour.

Is there a particular reason for interpreting values in this way?
Are you open to an an option being added to the method to disable this interpretation? or should some info about the backlight be exposed so that we can figure this out ourselves?

[nytamin]

I looked through the commit history to see if any of the commits triggered my memory of why that particulal quirk was added
(The change was introduced in this commit). I might misremember this, but I believe there is some old xkeys model that has blue and green LEDs, instead of the conventional blue and red, so this was probably to take into account for that model.

I believe that at the time (before the rgb-models) we didn't really consider the actual colors to be important, rather the ability to distinguish between a "black", "primary" and "secondary" color.

I agree that nowadays (with the rgb-models in play) it's an issue that a green rgb-value results in a red color, I would be fine if we'd modify the lines to improve this (unless @michaelhatPIengineering is of another opinion (?) ).

[michaelhatPIengineering]

yes, now that RGB is fully released, it seems RGB should be RGB not RRB.