Can't update Key Colors individually unless Brush is applied.

[jrankin2]

Updating individual colors is broken because of

c4ac6f0#diff-caac9f90950af58ae566e770d533738aR209

ApplyColorData(_colorDataSave) overwriting the LedMapping's state no matter what.

Tested using Corsair k70 RGB.

Workaround: apply a brush before updating individual key colors.

[DarthAffe]

Oh, nice catch - this is obviously not intended. I'll look into it.

[DarthAffe]

I've looked into this issue and I'm sorry, but I won't change anything to fix this.
Every change would break the "default"-brush-behavior, which is way more important to me than individual color changes (which isn't the recommended way to work with CUE.NET anyway).
I think the workaround to enable individual color changes by calling

CueSDK.KeyboardSDK.Brush = (SolidColorBrush)Color.Transparent;

is reasonable and doesn't prevent the usage of that feature.

[jrankin2]

Can't you just change this line https://github.com/DarthAffe/CUE.NET/blob/master/Devices/Generic/AbstractCueDevice.cs#L332

To something like
foreach (KeyValuePair<CorsairLedId, CorsairColor> corsairColor in _colorDataSave.Where(x => !LedMapping[x.Key].IsDirty)) ?

Not sure what the intended behavior is, I just know that it worked when I tried doing some simple color changes.

If not, that's fine, but you might want to update the wiki here https://github.com/DarthAffe/CUE.NET/wiki/Perform-basic-lighting.

Thanks for the quick response.

[DarthAffe]

I thought about this too, but it's only a solution if the colors are set for every call to update. As soon as a update is triggered (which is happening all the time if UpdateMode.Continuous is used) it'll overwrite the colors again.
The only way around this is to use locks, but they work without that fix too.

I've already added a line to the example showing how to "enable" individual color changing.