HDMI EDID Custom Resolution: Make an Unusual TFT Timing Negotiable

HDMI EDID custom resolution work starts with a timing the sink can accept. A custom TFT with a non-standard resolution often works on a development board and fails on a customer’s player. The panel is fine; the HDMI source never learned the timing. EDID is the negotiation document, and a custom resolution is only viable when its detailed timing, checksum and hotplug behaviour are all correct. This guide turns the panel specification into an EDID package that a host can parse, accept and reproduce.

What must HDMI EDID custom resolution data describe?

It must describe a timing the sink can actually accept.

The EDID must advertise pixel clock, active and blanking values, sync geometry and image size for a timing the panel and scaler can process.

EDID is a structured description of the display’s capabilities. For a custom resolution, the important part is the detailed timing descriptor, which carries the pixel clock, the horizontal and vertical active and blanking values, the sync offsets and widths, the image size and the flag bits that describe the sync type. A second block may carry extension data, such as additional timings or audio capabilities.

The descriptor must describe a timing that the whole sink can accept, not only the panel. If a scaler sits between the HDMI receiver and the panel, the scaler’s input range and processing limits apply. If the receiver only supports certain pixel clocks, the advertised timing must fit. The EDID is a promise; the product has to keep it.

Record the source of every number: which fields came from the panel drawing, which from the scaler datasheet and which from the host’s supported mode list. A field copied from a similar display is a guess, and a guess in a timing descriptor produces a negotiation failure that is hard to diagnose.

Which detailed-timing fields come from the panel specification?

The panel drawing supplies the timing numbers.

Pixel clock, horizontal and vertical totals, sync offsets, widths and polarity come from the panel specification, not a generic video mode.

The detailed timing descriptor needs the pixel clock, the horizontal active and blanking, the vertical active and blanking, the horizontal and vertical sync offsets and widths, and the sync polarity. Those values come from the panel’s timing table, which is usually expressed as totals and porches rather than as a ready-made EDID entry.

The conversion is mechanical but easy to get wrong. The pixel clock is often expressed in MHz in the panel table and in 10 kHz units in EDID. The blanking values must be split into front porch, sync width and back porch. The sync polarity must match the panel’s requirement. A single misplaced field shifts the image or makes the timing unrecognisable to the host.

If the drawing gives a range rather than a single value, choose the value that the panel and scaler both support and record why. Keep the conversion table with the EDID source. A reviewer should be able to trace each EDID field back to a line in the panel drawing. The Linux EDID administration guide describes how the kernel handles EDID overrides and how to reproduce mode-enumeration problems; it does not define the panel timing.

How do preferred modes affect host selection?

The first detailed timing is usually the preferred mode.

Many hosts treat the first detailed timing descriptor as native, so its order and content determine what the source tries first at boot.

The preferred timing is the mode the sink recommends as native. Many sources read the first detailed timing descriptor and use it as the default, especially at boot before a user selects a mode. If the first descriptor is a fallback resolution rather than the panel’s native timing, the source may start in the wrong mode and scale or letterbox the image.

The order matters as much as the content. Put the native timing first, then the supported fallbacks in the order the product prefers. If the host supports only a subset, the fallbacks should be modes the host can actually generate; advertising a mode the host cannot produce leads to a rejection or a silent fallback.

Record the preferred mode and the fallback order in the release package. A later EDID edit that changes the order can change the boot behaviour without changing the panel or the source.

When does the scaler restrict an advertised timing?

A scaler may accept the signal but not the timing.

A scaler has its own input range, line buffer and output timing; an EDID can advertise a mode that is cropped, scaled or rejected downstream.

A scaler is not a transparent cable. It has a maximum input clock, a maximum line length, a line buffer or frame buffer and an output timing range. An EDID entry can describe a signal that the HDMI receiver accepts but the scaler cannot process at full width or rate. The result may be a cropped image, a scaled image or a blank screen.

The scaler’s datasheet or integration guide defines its limits. The EDID should advertise only the timings that the scaler can pass or scale within its specification. If the product needs a non-standard timing that the scaler cannot handle, the architecture may need a different scaler or a direct panel interface.

A bridge such as the SN65DSI86 has its own input and output limits, which belong in the same chain. Test the advertised timing through the complete path, not only at the HDMI input. A capture at the panel connector shows whether the scaler preserved the timing or changed it.

How should an EDID checksum and parser result be checked?

Verify each block checksum and decode the result.

Each 128-byte block carries a checksum that must make the byte sum zero; a parser run confirms the fields and exposes truncation or extension errors.

EDID is organised in 128-byte blocks, and each block ends with a checksum. The sum of all bytes in the block, including the checksum, must be zero modulo 256. A single changed byte without a checksum update makes the block invalid, and many hosts will ignore it or fall back to a default mode.

Run a parser over the file and compare the decoded fields with the source table. The parser should show the detailed timing, the preferred mode, the extension blocks and any descriptor that is malformed. A parser that reports a valid checksum but a nonsensical timing is still telling you that the data is wrong, even if the block is structurally valid.

Keep the parser output with the release package. The DRM KMS documentation describes how the kernel consumes modes; the parser output shows what the kernel was given.

Which boot and hotplug cases need separate verification?

Test cold boot, hotplug and resume separately.

A host may read EDID at boot, on hotplug and after resume, and may cache it; each path can fail differently and needs its own verification.

The EDID read path depends on the host state. At cold boot, the source may read the EDID before the display is fully powered, especially if the display’s power is sequenced after the source. On hotplug, the source sees a transition and re-reads the EDID. After resume, the source may reuse a cached mode or re-read the display. Each path can produce a different result.

Test each case with the same EDID and the same panel. Record the time from power or hotplug to the first valid image, and the mode the source selected. A display that works on hotplug but not on cold boot may have a power-sequence or hotplug-detect timing issue, not an EDID content issue.

The Linux device power management documentation covers the resume callback ordering that can affect when the display becomes ready.

How can a known-good EDID isolate a controller issue?

A known-good EDID separates source from sink.

A validated EDID removes the custom data from the equation; if the host still rejects the mode, the source, cable or scaler is more likely.

When a custom timing fails, replace the EDID with a validated file for a standard mode and repeat the test. If the standard mode works, the custom data or the timing is the problem. If the standard mode also fails, the source, the cable, the hotplug path or the scaler is the problem.

The comparison should use the same board, cable and power sequence. Changing several variables at once defeats the purpose. Record which EDID was used for each result, including its checksum.

A known-good EDID is also useful for field diagnosis: a service tool can load it temporarily to determine whether the display accepts any HDMI signal. The result narrows the fault before any custom file is rebuilt.

What belongs in the released EDID file package?

The package includes the binary, source, checksum and tests.

Release binary, source table, checksum, decode log, hotplug and boot results and revision history together, so the file can be rebuilt and audited.

The binary is what the product uses, but it is not enough on its own. The package should include the source table that maps each EDID field to the panel drawing, the checksum for each block, the parser output, the test results for cold boot, hotplug and resume, and the revision history. Add the panel and scaler revisions, because a change in either can invalidate the timing.

Store the package with the product’s release record. A future engineer should be able to rebuild the binary from the source table and confirm that it matches the shipped file.

The table below is a template for the EDID acceptance record. It is not a set of limits; the values come from the panel and scaler documents.

EDID and hotplug acceptance record

Host or bridge setting	Panel requirement	Cable or pin condition	Diagnostic evidence	Compatibility decision
Preferred detailed timing	Panel native timing	HDMI cable and connector	Parser output and first image	Approved as native mode
Fallback timings	Panel supported modes	Same cable	Mode list and image result	Approve only tested modes
Block checksum	Valid EDID structure	Not applicable	Byte-sum and parser result	Required for release
Hotplug detect	Display ready before read	HPD line and power sequence	Time to first image	Approve if repeatable
Scaler input	Timing within scaler range	Input clock and line length	Capture at panel connector	Approve if preserved or scaled

The custom timing, EDID and scaler configuration guide covers the surrounding integration steps; this page owns the released EDID package. A bridge datasheet such as the SN65DSI83 defines that device’s timing and input behaviour, which belongs in the same package when a bridge is present.