BRIDGE CHAIN FORMAT SELECTION(9)

💅 NAME 💅

bridge chain format selection — the whole "which bus format does this chain actually speak" saga, from the Kernel API Manual (yes bestie, the bridge chai...at selection(9) page, we're getting into it)

---

✨ DESCRIPTION ✨

okay so picture this: a bridge chain runs from the display output processor all the way to the connector, right? and along the way it can contain bridges that are capable of converting between bus formats on their inputs and output formats on their outputs. that's the whole vibe.

but — and this is the part that gets messy — a bridge might be able to convert from RGB to YCbCr 4:4:4, and pass through YCbCr 4:2:0 as-is, but it cannot convert from RGB to YCbCr 4:2:0. so no cap: not all input formats map to all output formats. the math is not mathing 1:1, and we just have to live with that.

and it gets even more unhinged 🫠 a desired output color format, as specified with the "color format" DRM property, might not correspond 1:1 to what the display driver should actually set at its output. like, the bridge chain it feeds into may only be able to reach that desired output format if a conversion from a different starting format is performed. so the thing you asked for isn't always the thing you set. iykyk.

so how do we deal with this complexity? the recursive bridge chain bus format selection logic starts with the last bridge in the chain — usually the connector — and then recursively walks the chain of bridges backwards to the first bridge, trying to find a path. it's giving main character energy in reverse 💅

for a display driver to work in such a scenario, it should read the first bridge's bridge state to figure out which bus format the chain resolved to. and if the first bridge's input format resolved to MEDIA_BUS_FMT_FIXED, then its output format should be used. that's the rule, periodt.

---

🎀 HDMI special handling 🎀

special handling is done for HDMI as it relates to format selection. instead of directly using the "color format" DRM property for bridge chains that end in HDMI bridges, the bridge chain format selection logic will trust the logic that set the HDMI output format. (respect the other girl's work, fr fr.)

for the common HDMI state helper functionality, this means that DRM_CONNECTOR_COLOR_FORMAT_AUTO will allow fallbacks to YCBCr 4:2:0 if the bandwidth requirements would otherwise be too high — but only if the mode and connector allow it. bestie, it's a conditional slay. 🌸

for bridge chains that do not end in an HDMI bridge, DRM_CONNECTOR_COLOR_FORMAT_AUTO will be satisfied with the first output format on the last bridge for which it can find a path back to the first bridge. first come, first served, no auditions after that. ✨

---

🌈 SEE ALSO 🌈

the whole friend group, in no particular order (okay, in this exact order):

• Kernel file ./drivers/gpu/drm/drm_bridge.c overview(9)
• display driver integration(9)
• special care dsi(9)
• dsi bridge operations(9)
• drm_bridge_enter(9)
• drm_bridge_exit(9)
• drm_bridge_unplug(9)
• drm_bridge_get(9)
• drm_bridge_put(9)
• drm_bridge_clear_and_put(9)
• drm_bridge_put_void(9)
• drm_bridge_add(9)
• devm_drm_bridge_add(9)
• drm_bridge_remove(9)
• drm_bridge_attach(9)
• bridge operations(9)
• drm_bridge_chain_mode_valid(9)
• drm_bridge_chain_mode_set(9)
• drm_atomic_bridge_chain_disable(9)
• drm_atomic_bridge_chain_post_disable(9)
• drm_atomic_bridge_chain_pre_enable(9)
• drm_atomic_bridge_chain_enable(9)
• drm_atomic_bridge_chain_check(9)
• drm_bridge_detect(9)
• drm_bridge_get_modes(9)
• drm_bridge_edid_read(9)
• drm_bridge_hpd_enable(9)
• drm_bridge_hpd_disable(9)
• drm_bridge_hpd_notify(9)
• of_drm_find_and_get_bridge(9)
• of_drm_find_bridge(9)
• of_drm_get_bridge_by_endpoint(9)
• devm_drm_put_bridge(9)

---

🫶 that's the page, bestie. source: ./drivers/gpu/drm, dated October 2026, and the header still says bridge chai...at selection(9) because the terminal truncated it and honestly? it ate. 💅✨🎀