The Panel
1b1c:1b8e, reported by the descriptor as iDisplay Technology. A 640×48 TFT
LCD, 126.2 × 9.4 mm, with a single-row capacitive touch strip. Firmware version
is readable from feature report 5, at offset 6.
Everything below was measured on real hardware. Where a number came from Corsair's marketing material it says so, and it was checked anyway.
The editor's preview is the 640x48 strip at 2x, drawn by the same code that drives the hardware — so what is on screen is what lands on the glass.
640 × 48 is 13.33 : 1.
That single number decides more about what this panel is good for than anything else in the specification. It is why:
- a sensor readout gets about 160 px of width and all 48 px of height, so a four-row desktop tile has to be compressed into two;
- emulation is a losing fight — a 4:3 frame scaled to fit is 64 px wide, about 4% of the source pixels;
- a spectrum analyser, a VU meter and a scrolling spectrogram are all natively this shape, and look better here than they do on a desktop.
Design for the ratio rather than against it.
Corsair's specification says "262K colours". 2^18 = 262144, so that is 6 bits per channel, not 8.
Confirmed by sweeping one bit at a time through a colour byte on the real panel: bits 0–5 produce nothing visible; only bits 6 and 7 register. That is an 8→6 truncation happening in hardware.
The consequence is that smooth gradients quantise. At this physical size the steps are not badly visible, but the fix is cheap: an 8×8 ordered Bayer dither is applied on the way out, so the panel's own truncation lands on a dithered value instead of a hard-quantised one. Ordered rather than error-diffused on purpose — it is stable frame to frame, so a static readout does not shimmer, and it costs one add per channel.
Measured on the glass, and the single most useful colour fact about this device:
- full green reads lime, not green
- blue + green reads white, not cyan
Any palette reasoned about on a monitor will not land where sRGB predicts. The classic green→amber→red meter ramp and any bass-to-treble hue sweep both need retuning by eye on the hardware. Segmented and near-binary displays sidestep the problem entirely, which is part of why they are worth having.
Pick colours by looking at the panel.
Measured 2026-09-07: 65.00 fps sustained — 390 frames in 6.0 s, 7.62 MB/s, 7864 HID writes per second. Per-frame best 15.10 ms, worst 18.37 ms.
That is 96% of the ceiling derived from the endpoint descriptor, so the limit is the bus rather than anything in software, and the derivation is accurate to 4%.
The application's design target is 24 fps, matching the rate Corsair's own animations play at. That costs 37% of capacity and leaves 2.7× headroom. The music visualizers run their screen at 30 fps and still hold it exactly.
Tested with USB audio genuinely streaming on the same bus: 64.87 fps, a 0.2% delta. The concern that a shared bus would starve the panel was measured and dismissed rather than designed around.
- Report rate 104.5 Hz
- X only — there is no Y axis, because there is only one row
- X is reported as a little-endian 0–639, so it is already in panel pixels
- X tracks a drag continuously, so full gestures are available, not just taps
The one thing that breaks naive handling. A quick flick produces two touch sequences about 10 ms apart, because one report is dropped in the middle. Code that treats each press/release pair as a separate gesture sees two half-swipes and does the wrong thing — usually skipping two screens instead of one.
The gesture layer stitches them back together. Any independent implementation will need to do the same.
Touch is 1:1 with the panel across its width, confirmed with three separate sweeps. There is a small apparent offset of roughly 55 px near the edges, and it is parallax — the glass sits above the pixels — not a calibration error. Correcting it in software would make the panel wrong for anyone viewing it from a different angle.