-
Notifications
You must be signed in to change notification settings - Fork 74
Add support for K70 Rapidfire (non-RGB) 0x1b3a #87
Conversation
|
Hmm, something went wrong there. |
|
OK, think I solved the merge conflict (testing branch had changed after I forked it). |
|
From my understandint, the difference between a device being (!IS_RGB) or (IS_RGB && IS_MONOCHROME), is that the latter, while leveraging the RGB protocol, can allow for per-key lighting. Looks OK to me. |
|
I've compiled and tested with my K70 LUX non-RGB. The Rainbow demo stopped working. The Trippy demo still worked. I guess the IS_MONOCHROME is no good then? |
|
Couldn't get it to work at all with !IS_RGB. I'm removing them both from IS_MONOCHROME for now. |
|
There must be some difference with the Strafe model (that has the IS_MONOCHROME macro) and at least this K70 LUX (non-RGB). Most things work in the GUI, except that pressing the Change Color button freezes the interface, but this happens both with if it is in IS_MONOCHROME and not (and it has always been like that with this model). |
|
|
|
Cross-reference to #86. Works for @koanya who owns such keyboard. See #55 (comment). |
|
My guess is these keyboards discard the colour packets, so it should be safe to add them for now. |
See issue mattanger#87. If the KB is noted as a monochrome, the brightness of the keyboard does not change if a color profile is loaded.
This is now done against testing branch. I've also added the KB in question and the K70 LUX non-RGB to the IS_MONOCHROME macro. Hopefully this is correct.