SUMMARY *** I have a projector connected to my RX480 over HDMI which I use with kwin_wayland. When I connect the projector, kwin_wayland configures the output with the following settings: - 3840 x 2160 resolution - 60 Hz refresh rate - 10 bpc (instead of 8 bpc) - No chroma subsampling (YUV444 instead of YUV420) The HDMI port of the GPU supports HDMI 2.0b. I think the bandwidth of that output is enough to support any 3 of the 4 settings, but not all 4 at once. With the default settings the display stays just black (it works fine with another computer that has a newer GPU). If I reduce the resolution or the refresh rate the display lights up. I would however prefer to reduce the BPC of the connection since my input anyway only has 8 bpc. Please make this configurable. *** STEPS TO REPRODUCE 1. Connect a display that supports 4K, 60Hz, 10bpc to an HDMI 2.0b port. OBSERVED RESULT The default configuration results in a black screen, I can only change the resolution or refresh rate to fix it. EXPECTED RESULT The default configuration should work. The BPC of the output configuration should be adjustable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7
Please attach the output of > journalctl --user-unit plasma-kwin_wayland --boot 0 with the output not working to give some more insight into what's happening. Most likely this is a driver bug though, KWin can only set a maximum bpc and has no knowledge or control of the actually used connector bpc and subsampling. The display driver is supposed to (and in the case of amdgpu does) use chroma subsampling and reduced bpc to make the given mode work. If it can't make it work, it should reject attempts to use the output, so that the compositor can react accordingly. As a workaround, you can set kwin to globally use 8bpc only: https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#kwin_drm_prefer_color_depth I'm not convinced bpc is a thing that should be exposed as a proper setting though, if at all possible it should automatically be handled correctly in all cases.
Created attachment 154386 [details] log of plasma kwin_wayland This is the requested log. I changed the refresh rate from 30 Hz to 60 Hz at 22:57 which resulted in a black screen. Unfortunately the output does not seem too helpful.
> The display driver is supposed to (and in the case of amdgpu does) use chroma subsampling and reduced bpc to make the given mode work. If it can't make it work, it should reject attempts to use the output, so that the compositor can react accordingly. Ok, then it might be a driver bug. I somehow assumed that user space would know about it.
> Dez 06 22:57:36 OleDesktop kwin_wayland_wrapper[1304]: Mesa: 5 similar errors > Dez 06 22:57:36 OleDesktop kwin_wayland_wrapper[1304]: Mesa: User error: GL_INVALID_OPERATION in glGetFramebufferAttachmentParameteriv(invalid pname GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING) That seems odd, even if it's probably unrelated. If you set the KWIN_DRM_PREFER_COLOR_DEPTH=24 env var, does that make the display work at 4k60?
(In reply to Zamundaaa from comment #4) > > Dez 06 22:57:36 OleDesktop kwin_wayland_wrapper[1304]: Mesa: 5 similar errors > > Dez 06 22:57:36 OleDesktop kwin_wayland_wrapper[1304]: Mesa: User error: GL_INVALID_OPERATION in glGetFramebufferAttachmentParameteriv(invalid pname GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING) > > That seems odd, even if it's probably unrelated. If you set the > KWIN_DRM_PREFER_COLOR_DEPTH=24 env var, does that make the display work at > 4k60? No, unfortunately it does not help. I thought this would be the cause because the projector reported 10bpc / yuv444, but now it still fails. I tried to get debug information with drm.debug=0x1ff (see attachment), - but I can't tell from it what's going on and if it is a driver bug. It seems strange though that kwin again and again removes the frame buffer after the atomic mode set and then tries to add a new frame buffer?
Created attachment 154466 [details] Repeating part of dmesg with drm.debug=0x1ff
Did you check if the env var was applied correctly? You can check the actually used format in dmesg (it's printed on resolution changes iirc) or with drm_info (https://gitlab.freedesktop.org/emersion/drm_info). It'll be ARGB2101010 for 10bpc and ARGB8888 for 8bpc Also, does the output work with Xorg or Weston? > It seems strange though that kwin again and again removes the frame buffer after the atomic mode set and then tries to add a new frame buffer? That's entirely normal. A new buffer gets added and presented, the old one gets removed afterwards.
(In reply to Zamundaaa from comment #7) > Did you check if the env var was applied correctly? You can check the > actually used format in dmesg (it's printed on resolution changes iirc) or > with drm_info (https://gitlab.freedesktop.org/emersion/drm_info). It'll be > ARGB2101010 for 10bpc and ARGB8888 for 8bpc I didn't check yet but I will check in the afternoon. > Also, does the output work with Xorg or Weston? I checked, it does not work with Xorg either. > > It seems strange though that kwin again and again removes the frame buffer after the atomic mode set and then tries to add a new frame buffer? > That's entirely normal. A new buffer gets added and presented, the old one > gets removed afterwards. Ah, ok. Dmesg didn't show anything else in the log buffer anymore, but it is there in the journal. I will upload a full log for enabling and disabling the projector (without the env var set).
You can find the log here: https://stuff.salscheider.org/gpu.log
(In reply to Niels Ole Salscheider from comment #8) > (In reply to Zamundaaa from comment #7) > > Did you check if the env var was applied correctly? You can check the > > actually used format in dmesg (it's printed on resolution changes iirc) or > > with drm_info (https://gitlab.freedesktop.org/emersion/drm_info). It'll be > > ARGB2101010 for 10bpc and ARGB8888 for 8bpc > > I didn't check yet but I will check in the afternoon. The output of drm_info says that the environment variable is taken into account. The max bpc setting of the connectors changes to 8 and the FBs now have type ARGB8888. But unfortunately this does not help.
As Xorg has the same problem it's relatively safe to assume it's a driver bug. Please report it to https://gitlab.freedesktop.org/drm/amd/-/issues While I don't see anything obvious in the dmesg log myself, attaching it and the output of drm_info there might help