UPDATE:

Pardon for the resurrection of this thread, but there really isn't that much of a need to make a whole new thread when this one has all of the information.
So Corsair did release an update to CUE and to the firmware in order to get the "full" 16.8 million colors for their RGB keyboards. "Full" being in quotations on purpose.
http://forum.corsair.com/forums/showthread.php?t=140249
Because the update introduces this if you try and enable the full gamut option. The first half of this short video is with it turned off. The second half is with it turned on.
And another video with a more static color scheme:
Basically they lied when they said it wasn't a hardware problem. Because it is very much a limitation of the hardware.
Here is a good explanation by creedcarl @ reddit/mk:
-
"First, we have found that the LED driver chip used has a limited set of current sources that can’t be multiplexed over the 12x12 LED matrix. Second, the LED driver chip is not fast enough to implement software driven LED matrix current source multiplexing . As such, instead of multiplexing current sources, the current sources are to be assigned to groups of LEDs on the 12x12 matrix.
-
This means that when the number of LED groups doesn’t exceed the available current sources, full Red, Green, and Blue 8 bit PWM can be set out of a palette of 16.8M colors. Internally the LED driver chip works with a 10bit resolution for its current sources and the incoming 8bit PWM is mapped by firmware to the LED driver chip’s internal settings. When the number of unique colors exceeds the available current sources, colors needs to be averaged together. Going back and forward over the number of current sources / unique colors, the effect of averaging colors is visible as color skew - that is visible colors deviate from the assigned colors and the color skew jumps can be perceived as one form of flicker.
-
Second, because of the LED driver chip scans the LED matrix in a particular order under some circumstances when updating PWM values some LEDs could light up erroneously. This is known as “ghost lighting”. To mitigate this issue, all LEDs are temporally switched off when updating the current sources PWM values. This blanking of LEDs is perceivable as minute flicker. As a consequence even static colors that share a Red, Green, Blue color component with another LED color group that is being updated, the static color LED group will also show this type of flicker. When the static color groups do not share a Red, Green, Blue color component with the color group that is being updated, this type of flicker will not show with the static colors. Running at higher framerate could bring improvement to perceived (blanking) flicker, but running at higher framerate could make the keyboard less responsive, which is not desired for a gaming keyboard."
If you would like to return yours, at least they are still leaving the option to get a refund on your board if you are out of your return period from wherever you bought your keyboard.
Quote from Corsair James@CorsairForums:
I'm not about to tear down a $170 keyboard to see what chips are inside, but from marketing (aka the side of the box) we know it has:
* 32-bit ARM processor
and
* Panasonic display controller
Now, I did a search for Panasonic LED matrix ICs, their website lists 20 results.
http://industrial.panasonic.com/www-...+CCA7000+5++WW
Of those results, only 13 are actually matrix drivers. The K70 RGB is almost certainly a matrix due to the number of LEDs (111 LEDs x3 for R/G/B, but up to like 24 more per channel on the K95 RGB). Of those matrix drivers, only one has enough channels to even come close, the AN32181B, which supports a 12x12 matrix. If you remember my reverse engineering, I came up with 144 total slots. 12x12 = 144! I think I'm on to something here.
Here is the AN32181B datasheet:
http://www.semicon.panasonic.co.jp/ds4/AN32181B_E.pdf
Unfortunately, it is only a single channel driver, so the datasheet says it's good for up to 48 RGB LEDs. BUT WAIT! The USB protocol clearly splits up red, green, and blue channels into discrete blocks, so it's entirely possible they are using three of these ICs, one per channel. So, what does this chip's actual PWM controller look like?
Here's a screenshot from the PDF's register map:

So what do we have here? If this is the actual chip used, it's pretty darn revealing of what's going on. The chip appears to have 7 PWM drivers, LED1-7, which are matrixed into all 144 LEDs. Each PWM driver has a 4-bit brightness register. Each LED in the matrix has its own "selection" register which chooses which one of the 7 PWM drivers is used to light that LED. The byte layout of these LEDSELx registers matches the USB protocol perfectly (including that there are 72 LEDSEL registers and 72 bytes in each color block). The PWMxCTL registers set a 6-bit PWM value per PWM driver. This gives a total possible bit depth of 6+4, though not completely as there is likely a lot of overlap between low-brightess and low-PWM values.
So, if my hunch is correct and Corsair is using this IC, I believe the PWM drivers are all set to fixed values, in increments of 1/8 from 0 to 100%. Instead of writing PWM values over the USB port, you're actually writing selection values, which selects one of 7 fixed-PWM values for the LED. Since the controller does not actually store a PWM value per-LED and instead only per-controller, actually making each key 8-bit would involve rewriting the PWM channel register very very quickly as it scans the matrix, something that is likely not happening (and dare I say impossible?). The hardware brightness key would then change either the brightness register or scale the 7 PWM channels in a way that adjusts the 7-step scale linearly, which is how it can theoretically generate more than 7 levels though not on different keys simultaneously.
Again, NONE OF THIS IS CONFIRMED, it's just my quick electronics engineering detective investigation given the limited information we have available, but this puzzle fits together all too well. If someone has already ripped the logo off their K70 (or K65/K95) to reveal the screw likely hidden beneath it and wants to completely tear it down I'd really love to know if this is indeed the chip being used. As far as I can tell it's the only Panasonic LED matrix IC that fits the bill.
I think he may be referring to the Anandtech review, which does have a picture of the CPU. I just sent an email to the author of that article asking if he/she could possibly confirm the part number or take a photo of the LED controller. I'll look at your article as well.
EDIT:
AHA! I was right :P
3x Panasonic A32181 LED matrix ICs
Thanks to the user CalcProgrammer1 over on Corsair forums for doing the research on this. Quite shady if this rumor turns out to be 100% sure.
Weistang.com picture originated from this review: http://www.weistang.com/article-1992-6.html
Edited by Kinaesthetic - 4/24/15 at 8:36pm











