-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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.