LVDS VESA vs JEIDA Mapping: Diagnose Washed-Out and Incorrect Colors
LVDS VESA vs JEIDA mapping guide: trace bit order through source, bridge and panel, and use walking-bit tests to find swapped lanes or bits.

LVDS VESA vs JEIDA mapping errors rarely look like a mapping problem: the timing is correct, the image is stable and the connector fits. An LVDS panel that shows pale colours, a shifted hue or a posterized gradient is often described as washed out. The timing is correct, the image is stable, and the connector fits. What is wrong is the mapping: the bits of each colour are being placed in different positions by the transmitter and the receiver. VESA and JEIDA define different conventions, and a bridge or a new panel can change which one applies. This guide traces the mapping through the signal path and gives tests that distinguish a swapped lane from a swapped bit.
Where does LVDS VESA vs JEIDA mapping enter the signal path?
Mapping sits between the parallel RGB bus and each lane.
VESA and JEIDA assign different bits within the serialized words, so the transmitter or bridge setting must match the panel receiver.
An LVDS link takes a parallel RGB bus and serializes it into a small number of differential pairs. Each pair carries a word made of bits from the colour channels and the control signals. VESA and JEIDA are two conventions for assigning those bits to positions in the word. They can carry the same image and the same timing while placing the bits differently.
The mapping is set at the transmitter, which may be an SoC LVDS output, an FPGA, a bridge or a discrete transmitter. It is interpreted at the receiver inside the panel. If the transmitter uses one convention and the panel expects the other, the image appears but the colours are wrong. The error can be a channel swap, a bit-order reversal, a lost low bit or a combination.
The DS90C385A LVDS transmitter datasheet is an example of a device that documents its parallel-to-LVDS mapping and timing; the panel drawing documents what its receiver expects. The two documents, not the connector, define compatibility.
How do 18-bit and 24-bit configurations differ?
18-bit uses fewer bits per colour and often fewer lanes.
An 18-bit link carries six bits per colour on three pairs, while 24-bit carries eight bits per colour and typically a fourth pair, so mapping and lane count change.
An 18-bit LVDS link carries six bits for each of red, green and blue, usually on three data pairs plus a clock pair. A 24-bit link carries eight bits per colour and typically uses four data pairs plus the clock. The extra pair carries the additional two bits per channel and, depending on the convention, some control signals. The mapping of the bits within each pair changes with the depth.
That difference matters when a product supports both depths or when a panel is replaced with one of a different depth. A transmitter configured for 18-bit cannot drive a 24-bit panel at full depth, and a 24-bit transmitter configured for the wrong convention can produce an image that looks almost right but loses the low bits or swaps them.
Record the depth, the lane count and the mapping mode together. A change in any one of them is a change to the interface, even when the connector and the resolution stay the same.

Which walking-bit patterns reveal a mapping mismatch?
Walking-bit ramps show which bit lands where.
Set one bit at a time in each colour channel; a bit that changes the wrong channel or weight identifies the mapping error more precisely than a colour bar.
A walking-bit test sets a single bit in one channel and displays it, then moves the bit to the next position. If the bit appears in the wrong channel, the channel mapping is wrong. If it appears at the wrong brightness, the bit significance is wrong. If it has no visible effect, the bit is not reaching the panel.
The test should cover every bit in each channel at the product’s colour depth. An 18-bit panel has six bits per channel; a 24-bit panel has eight. The pattern should be displayed as a full-screen field or a large patch, so the result is visible without a meter, but a photometer or colorimeter can quantify the step if needed.
A grey ramp and a fine gradient complement the walking-bit test. They show banding and lost low bits that a single-bit test may not reveal, especially when dithering is enabled. Compare the result with the approved baseline rather than judging it by eye.
How should source and panel mapping be confirmed?
Confirm the mapping from both drawings, then measure.
The transmitter document defines its output mapping and the panel drawing defines what it expects; continuity and a walking-bit test confirm the cable matches both.
Start with the documents. The transmitter or bridge datasheet should state which convention it uses and how the bits are assigned to each pair. The panel drawing should state the convention it expects and the pin assignment at its connector. Compare the two, then compare both with the cable drawing, because a cable can swap pairs even when both ends are correct.
Continuity testing confirms the physical assignment. It does not confirm the logical mapping, because two pairs can be wired correctly and still carry the wrong bits if the transmitter or panel is configured for a different convention. The walking-bit test supplies that evidence.
Record the source, bridge, cable and panel revisions in one place. A mapping that is correct for one combination may be wrong for another, even when the part numbers look similar.
What distinguishes swapped lanes from swapped bit significance?
Lane swaps move groups; bit swaps change weight.
A swapped lane moves a whole colour or bit group and produces a large hue error, while a swapped bit changes significance and produces banding or a washed-out channel.
A lane swap exchanges the data carried by two pairs. The result is usually dramatic: a whole colour channel appears in the wrong place, or a group of high bits is replaced by a group of low bits. The image may look strongly tinted or posterized, and a colour bar may show the error immediately.
A bit swap within a lane is subtler. The bit positions keep their lanes, but the significance changes: a high bit behaves like a low bit, or two adjacent bits exchange places. The result can be a slightly wrong colour, a washed-out channel or banding in gradients. Because the image is stable and mostly plausible, it is easy to misdiagnose as a gamma or panel-quality problem.
The walking-bit test distinguishes the two. A lane swap moves the bit to a different channel; a bit swap keeps the channel but changes the observed weight. Record which bit produced which change, and compare it with the mapping table.

Which bridge registers need a controlled configuration record?
Record the bridge mapping mode and output format.
Record VESA or JEIDA mode, lane count, bit order and output format with the firmware revision, because a reset can restore a different default.
A bridge that converts one interface to LVDS usually has registers for the mapping mode, the lane count, the output format and the timing. Some bridges also have a bit-order or channel-swap setting. Those registers are part of the interface definition, not tuning parameters, and they should be recorded with the firmware or configuration revision.
A reset can restore a default that differs from the value the application programmed. If the driver does not reapply the mapping after a reset, the panel can come back with the wrong colours after a power event. The configuration record should state which values are defaults and which are set by the driver.
The SN65DSI83 and SN65DSI86 datasheets are examples of bridge devices with device-specific register maps; their limits and defaults apply to those devices, not to every LVDS bridge. The Linux EDID administration guide covers mode and display-identity handling on the host side, which is a separate layer from the bit mapping.
How should mapping be tested after a panel substitution?
Re-run the full mapping test after any panel change.
A substitute panel that lights does not prove correct mapping; repeat walking-bit and grey-ramp tests and compare with the approved baseline.
A panel substitution can change the convention, the bit depth, the lane count or the connector pinout. Even when the new panel is described as compatible, the mapping must be verified against the approved baseline. A lit image is not evidence of correct colour.
Repeat the walking-bit test for every channel and bit, the grey ramp and the colour fields. Compare the results with the baseline for the previous panel. If a difference appears, determine whether it is a mapping change, a depth change or a panel characteristic, and record the decision.
Test after a cold boot and after a resume, because a bridge or controller default may differ from the programmed value. The DRM KMS documentation describes the pipeline state that the driver must restore.
What must the approved pin-and-bit map include?
The map names every pin, lane and bit position.
The record should list connector pinout, lane assignment, VESA or JEIDA mode, bit order, colour depth and the test pattern that verified each combination.
The approved map is the reference for every future build. It should state the connector pinout, the pair assignment, the mapping mode, the bit order within each pair, the colour depth and the clock arrangement. It should also name the source, bridge and panel documents and their revisions, so a change in any of them can be assessed against the same baseline.
Include the tests that verified the map: the walking-bit pattern, the grey ramp, the colour fields and the conditions under which they were run. A map without evidence is a drawing, not a qualification.
The table below is a template for the mapping record. It is not a set of limits; the values come from the transmitter, bridge and panel documents.
| Host or bridge setting | Panel requirement | Cable or pin condition | Diagnostic evidence | Compatibility decision |
|---|---|---|---|---|
| VESA mapping mode | Panel expects VESA | Pair order matches drawing | Walking-bit result per channel | Approved for this build |
| JEIDA mapping mode | Panel expects JEIDA | Pair order matches drawing | Walking-bit result per channel | Approved only if panel supports it |
| 18-bit output | Six bits per colour | Three data pairs plus clock | Grey ramp and low-bit test | Depth-limited approval |
| 24-bit output | Eight bits per colour | Four data pairs plus clock | Grey ramp and all-bit test | Full-depth approval |
| Bridge default after reset | Panel-required mapping | Same cable and connector | Read-back and image test | Driver must reapply |
The TI LVDS impedance and termination guidance covers the channel side of the same interface; correct termination does not correct a mapping error, but a marginal channel can make the error harder to see. The eDP versus LVDS migration page covers the link-level decision; this page owns the bit-and-pin map.
FAQ
Can 18-bit input hide a 24-bit mapping error?
It can. An 18-bit mode uses fewer bits per colour, so a fault in the upper bits of a 24-bit path may not be exercised at all. The image can look acceptable in 18-bit and fail when the product switches to 24-bit. Test the mapping at the colour depth the product will ship with, and repeat at any other depth it supports.
Does a red test screen distinguish all channel permutations?
No. A red field shows that some red data arrived, but it does not show whether the red channel is receiving the correct bit weights or whether green or blue bits are mixed in. Use separate ramps for each channel and walking-bit patterns to distinguish channel swaps from bit-order errors within a channel.
Should mapping be documented in the cable drawing or firmware release?
Both, with one owner. The cable drawing defines the physical pin-to-pair assignment, and the firmware or bridge configuration defines the logical mapping mode and bit order. A single approved map should reference both documents and their revisions, so a change in either is visible against the same baseline.
If an LVDS panel shows wrong colours after a substitution or a bridge change, send the pinout, mapping mode and test-pattern results to the CDTech engineering team for a bit-map review.
Related articles
Touch Screen Grounding: Debug Floating and Earth-Referenced Installations SeparatelyCustom Displays, Sourcing & Manufacturing
Capacitive Touch Glove Thickness: Validate Material and Fit Before Setting SensitivityCustom Displays, Sourcing & Manufacturing
Capacitive Touch Water Rejection: Distinguish Droplets, Films and Flowing WaterCustom Displays, Sourcing & Manufacturing
Capacitive Touch Charger Noise: Correlate Raw Data with Power-Supply ConditionsCustom Displays, Sourcing & Manufacturing