SicVolo

@Frickler: Good writeup - should probably go into the main docs. One comment - your fixes were pulled into the main branch. Any particular reason your documentation tells people to check out the newfx branch instead?

Just fixed that, along with the corsair logo backlight on Strafe in my testing branch and got the pull request going. Should show up in the main repo soon. As a side note. We should probably package CKB into debs as well, and get a ppa going. Any takers?

Changing the firmware would break ckb only if it also breaks CUE, which ckb emulates at the USB level. Does one need a new version of CUE to go with the new fw? What's fixed in 1.33?

Yes, it is supported. I added the Strafe RGB support, and tested along with a couple of other folks. It's in the testing branch and will be official in the upcoming release of ckb from ccMSC. Please report any bugs/feature requests for Strafe on the GitHub.

The code I wrote for the Strafe RGB is in the testing branch of MSC's repo - beta-v0.2.1+t06. You need to get that branch and compile manually. I've not tried compiling it on OS X, but someone else did - https://github.com/ccMSC/ckb/issues/138. Note the small fix you need to do before it compiles.

Read the README.md on github. If that did not help, your problem is not the drivers but something else on your system.

The window is updated on timer, every 1/60 of a second, which then sends the LED codes to the driver. The driver is very gentle on the USB communication when no lights are being updated. However if you have an animation running the worst case is 4*60 USB packet writes a second and 60 packet reads. Yes, a ton of wakeups.

I've extended the driver to support the new Strafe RGB. You can test it from the testing branch of my repo for now (https://github.com/SicVolo/ckb/tree/testing) or from the MSC's repo after the pull request is merged.

I am not surprised - ckb spams /dev/input/ckb[12]/cmd like crazy, posting the full LED map with colors every time the main window gets a re-draw/update even if no LED's changed. The daemon wakes up to process it every time. It then drops it silently because nothing changes. @MSC, I suggest frameUpdate in kblight.cpp is made smarter to check if anything has changed before posting the cmd. Kind of like updatergb does it in led_keyboard.c, when determining if it needs to post to usb. It would save CPU, heat, battery, electiricy, and eventually the world ;)