With the "max bpc" KMS connector property, userspace can arbitrarily restrict the upper end of the bits-per-component range. This is fine and good, except the HDMI state helpers never considered that max_bpc could be influenced by a userspace setting, so assumed it'll always be an even value from the HDMI standards.
This, unfortunately, is not the world we live in anymore. Patch 1 corrects sink_supports_format_bpc to return false on BPCs outside of what HDMI allows. Patch 2 then corrects handling of odd-numbered max bpcs by rounding the loop start value down to an even number instead. It also adds a KUnit test to make sure nobody breaks this again in the future. Signed-off-by: Nicolas Frattaroli <[email protected]> --- Changes in v3: - Move bpc check before vic check, and show debug message on failure - Link to v2: https://patch.msgid.link/[email protected] Changes in v2: - Use rounddown() from linux/math.h instead of the bespoke rounding. No functional changes. - Note: switch statement in patch 1 kept as-is, as 14bpc is not allowed by HDMI it seems. - Link to v1: https://patch.msgid.link/[email protected] --- Nicolas Frattaroli (2): drm/display: hdmi: Only allow BPC values of 8, 10, 12 and 16 drm/display: hdmi: Round odd max_bpc down to even numbers drivers/gpu/drm/display/drm_hdmi_state_helper.c | 13 +++- drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 71 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 1 deletion(-) --- base-commit: 24209d838338d162bb25aadfd637b11747a357ca change-id: 20260608-hdmi-max-bpc-fix-703019763834 Best regards, -- Nicolas Frattaroli <[email protected]>
