MIPI DSI RGB565 vs RGB888: Verify Packing Before Changing Bandwidth

MIPI DSI RGB565 RGB888 mismatches rarely look like a format problem at first. A display that shows correct colours at boot and wrong colours after a firmware update is usually not a broken panel. The framebuffer, the display controller, the DSI packet format and the panel input each carry a colour format, and one of them changed. This guide treats RGB565 and RGB888 as a chain of boundary decisions rather than a single setting, and shows how packing, padding, test patterns and resume checks expose a mismatch before it becomes a bandwidth change.

Which MIPI DSI RGB565 RGB888 formats are mutually supported?

Only formats supported at every boundary are usable.

Framebuffer, display controller, DSI packet format and panel input must all agree; a format the host supports but the panel does not is unusable.

RGB565 uses 16 bits per pixel with five bits for red, six for green and five for blue. RGB888 uses 24 bits, eight per channel. Between them sits RGB666, which nominally uses 18 bits and is often transported in a packed or padded form. Each of these formats can appear at four boundaries: the graphics framebuffer, the display controller’s output, the DSI packet stream and the panel’s input interface.

A format is mutually supported only when every boundary can accept it. A host controller that can output RGB888 is not enough if the panel is configured for RGB666 and the DSI packet format is set to RGB565. The image may still appear, but the colours will be wrong or the low bits will be discarded without notice. The check is a table, not a single register read.

The panel drawing defines the input format and the packing it expects. The host datasheet defines what the controller can produce. The bridge, where present, adds another conversion. Record all four and mark any combination that has not been tested.

How does packed pixel data differ from padded data?

Packed data uses every bit; padded data inserts gaps.

Packed formats place pixels continuously, while loosely packed formats insert unused bits to align pixels or lanes, changing the byte count for the same image.

In a packed format, pixel bits follow one another continuously in the byte stream. In a loosely packed or padded format, unused bits are inserted so that pixels or lanes align to a byte or word boundary. The visible image is the same, but the number of bytes on the link is different, and the panel must be configured for the same convention as the host.

The difference matters most for 18-bit formats. A nominal 18-bit pixel can be sent as three bytes with six unused bits, as a tightly packed stream, or in a format that pads to a lane boundary. Each has a different byte count and a different packing rule. A host that sends one and a panel that expects another will produce shifted colours, banding or a corrupted image.

Record the packing convention as part of the format, not as an implementation detail. Two systems that both say RGB666 can still disagree on how the bits are arranged. The ST AN4860 DSI host application note documents packet and pixel-format configuration for specific STM32 families and is a useful example of how the convention is expressed at the host.

Where can host and panel format settings disagree?

Disagreement usually hides at the controller-DSI boundary.

The framebuffer may be ARGB8888 while the controller outputs RGB565 and the panel expects RGB666; each boundary can convert or truncate.

The framebuffer format is chosen for the graphics pipeline, not for the panel. It may include an alpha channel and a colour depth that the display does not use. The display controller converts that framebuffer to its output format, and the DSI host packetizes the result. The panel then interprets the packet according to its own configuration. Every one of those steps is a possible mismatch.

A common failure is a controller configured for RGB565 while the panel expects RGB888, or the reverse. The image appears because the timing is correct, but the colours are wrong: a channel may be missing, the green channel may have a different weight, or the low bits may be zeros. A less obvious failure is a controller that outputs RGB888 and a panel that truncates to RGB666 without dithering, producing banding in gradients that were smooth in the framebuffer.

The mismatch can also be introduced by a bridge. A bridge may accept one format and output another, and its configuration registers may default to a different mapping after a reset. A bridge such as the SN65DSI83 accepts one format and outputs another, so its limits and configuration belong in the boundary table as their own row. The DRM panel and bridge helpers describe the lifecycle around these components, but the format itself is a device configuration.

Which test patterns expose channel and bit-placement errors?

Channel ramps and walking bits expose placement errors.

Red, green and blue ramps show channel swaps, while walking-bit patterns reveal bit-order and significance errors that colour bars can hide.

A full-screen red, green and blue field is a good first check, but it only proves that the channels are present. A red-only gradient and a green-only gradient show whether the channel is receiving the full range. If the gradient steps or banding appear, the low bits are being truncated or the significance order is wrong. A white gradient does the same for the combined channels.

Walking-bit patterns are more precise. Set a single bit in one channel and step it through the word, observing which colour and which brightness change. A bit that changes the wrong channel indicates a channel swap. A bit that changes the wrong weight, such as the most significant bit behaving like a low bit, indicates a bit-order error. A bit that has no visible effect indicates that the bit is being dropped.

A checkerboard or a fine text pattern can reveal packing errors that a flat field hides, because neighbouring pixels are affected differently. Test at the panel’s native resolution and at the product’s normal refresh, and compare each pattern with the approved baseline rather than judging it by eye.

How much link budget changes with the selected format?

RGB888 needs half again the payload of RGB565.

Moving from 16 to 24 bits per pixel raises payload by half at the same resolution, so lane rate or refresh must change unless margin exists.

The payload is proportional to bits per pixel. At the same resolution, refresh and blanking, RGB888 carries 50 percent more data than RGB565. That increase must be absorbed by a higher lane rate, more lanes or a lower refresh. If the link was designed for RGB565 with little margin, switching to RGB888 may exceed the host or panel limit even though the image fits.

The packet structure matters as well. A larger pixel may produce longer packets, which can improve efficiency, or it may require a different packing that adds padding. The actual byte count should be measured from the packet stream, not inferred from the nominal bit depth. A format change is therefore a link-budget change, even when the resolution does not move.

Record the selected format, the lane rate and the measured traffic together. If the product needs RGB888 only for occasional images, a dual-format path may be possible, but each format needs its own validation and its own timing record.

When does dithering belong elsewhere in the pipeline?

Dither once, at the boundary that needs it.

If the panel accepts 18-bit data, dither a 24-bit source before truncation; dithering again in the panel or application adds noise without recovering information.

Dithering trades spatial or temporal noise for the appearance of more levels. If a 24-bit source is displayed on an 18-bit panel, dithering before truncation can preserve the look of gradients. If the same image is dithered again by the panel or by the application, the result is more noise without more information, and the pattern may be visible on flat areas.

The right place depends on where the truncation happens. If the controller truncates to RGB666 before the DSI packet, the dither should happen in the controller or the graphics pipeline before that point. If the panel truncates internally, the host may need to dither before sending. Doing both is usually wrong, and doing neither may produce banding.

Record whether dithering is enabled, where it is applied and what pattern it uses. A dither change is a visible change and should be treated like a format change in the validation record.

How should format changes be checked after resume?

Reapply and verify the format after every resume.

Resume can reset the controller or panel to a default format, so reapply the packed format and confirm the image with a known pattern before declaring success.

A resume path does not necessarily preserve every register. The display controller, the DSI host and the panel may return to defaults, and the defaults may use a different format or packing from the one the application set. The image may appear, but with wrong colours or a shifted channel order, and the fault may be intermittent because it depends on which component was reset.

The driver should reapply the format and packing after resume, then verify the result with a pattern that exposes the format. A grey ramp and a walking-bit test are enough for most cases; a short colour-field check confirms the channels. The verification should run before the backlight is enabled, so the user does not see a wrong-colour frame.

The rail that supplies the panel may be switched, and a device such as the TPS22918 documents a controlled rise that affects when the format can be applied. Record the resume path in the format matrix. If the panel retained its state, the reapplication may be a no-op; if it did not, the reapplication is required. The DRM KMS documentation describes the pipeline state that the driver is responsible for restoring.

What should the approved format matrix record?

The matrix records format and packing at each boundary.

List framebuffer, controller output, DSI packet format and panel input, with packing, colour order, test pattern, result and revision for each approved combination.

The matrix is the release record for the colour path. It should name each boundary, the format at that boundary, the packing convention, the colour order and the revision of the device or document that defines it. It should also record the test pattern and the result, so a later change can be compared with a known baseline.

Include the boot path and the resume path as separate conditions. A format that is correct after a cold boot may be wrong after a resume, and a bootloader handover may leave a different default. The matrix should show which combinations were tested under which condition.

The table below is a template for the boundary record. It is not a set of limits; the values come from the host, the bridge and the panel documents.

Pixel-format boundary record

Signal or rail	Power state	Trigger or capture point	Observed behavior	Source of acceptance limit
Framebuffer	Active	Graphics pipeline output	Source format and alpha handling	Application requirement
Display controller output	Active	Controller configuration	Output format and dither setting	Host datasheet
DSI packet stream	HS	Lane trace or host counter	Packet format and byte count	DSI host documentation
Panel input	Active	Panel configuration	Expected format and packing	Panel drawing
Backlight enable	On	Driver enable pin	First visible frame after format set	Panel drawing

The LVDS versus MIPI DSI comparison covers the interface choice at a higher level; this page owns the pixel-format boundary record. A panel supplier can confirm the input format and packing from the drawing, but the framebuffer and controller settings remain part of the product’s graphics pipeline.