Public bug reported:

The amdgpu driver has a logic bug that forces YCbCr 4:4:4 on monitors
that support the signal format, despite being suboptimal for desktop
purposes.

This YCbCr mode causes washed out colors and patterns due to the
multiple lossy conversions (desktop framebuffer in RGB -> YCbCr over
HDMI -> RGB for driving the LCD panel), as well as forcing "limited RGB
(16-235)" which causes even further signal degradation.

This is a widespread known issue, with multiple bug reports over the internet 
dating back to 2018, and with advanced EDID workarounds as the only solution:
 - https://lists.freedesktop.org/archives/amd-gfx/2021-May/063434.html
 - https://monado.freedesktop.org/edid-override.html
 - https://www.wezm.net/v2/posts/2020/linux-amdgpu-pixel-format/
 - https://www.camillescott.org/2020/12/16/amdgpu-edid/

This is caused by the function
fill_stream_properties_from_drm_display_mode in
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:

        /* TODO: un-hardcode */
        if (drm_mode_is_420_only(info, mode_in)
                        && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
                timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
        else if (drm_mode_is_420_also(info, mode_in)
                        && aconnector
                        && aconnector->force_yuv420_output)
                timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
        else if ((connector->display_info.color_formats & 
BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
                        && aconnector
                        && aconnector->force_yuv422_output)
                timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422;
        else if ((connector->display_info.color_formats & 
BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
                        && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
                timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
        else
                timing_out->pixel_encoding = PIXEL_ENCODING_RGB;

While YCbCr 4:2:0 and YCbCr 4:2:2 can be manually enabled and disabling
using properties of the display, YCbCr 4:4:4 is forced by the function
logic as long as supported by the display.

Until the patches for manually changing the pixel encoding are merged
(https://lkml.org/lkml/2026/3/24/1938 is the latest version from 2026,
the first being from 2021), I suggest that the function is modified to
*never* output YCbCr 4:4:4, by eg using a "#ifdef 0" block. Rationale
being:

 - Intel and NVidia already prefer RGB 4:4:4, so this would make amdgpu behave 
as the other two mainstream drivers.
 - Unlike YCbCr 4:2:2 or 4:2:0 which result in lower bandwidth, YCbCr 4:4:4 
uses the exact same HDMI bandwidth as RGB 4:4:4, so there is bandwidth 
budgetary reasons that would make it a preferred option over eg limited HDMI 
links.
 - YCbCr 4:4:4 is an optional mode specified in EDID. The CEA-861 standard 
*mandates* that all YCbCr 4:4:4 displays also support RGB, so supporting this 
mode does not allow using any more displays than RGB alone.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2154769

Title:
  amdgpu forces YCbCr 4:4:4 on compatible HDMI monitors

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154769/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to