Open cfrenette opened 3 days ago
There is a known bug in AMDGPU on 6.11. Not sure if it would produce this specific behavior: https://gitlab.freedesktop.org/drm/amd/-/issues/3693
That's caused some issues on cosmic-comp with certain AMD hardware. I think it also produced dmesg
errors. That's something to check.
Otherwise, it may be worth checking what drm_info
outputs on both 6.10 and 6.11.
There is a known bug in AMDGPU on 6.11. Not sure if it would produce this specific behavior: https://gitlab.freedesktop.org/drm/amd/-/issues/3693
I'd heard of this issue before the bisect was done and they seem to have found the root cause. I'm not seeing (many) freezes on 6.11.3 so I didn't think this was related but with the knowledge that UB is happening I guess we can't rule that out until it's fixed. Luckily it looks like a patch is coming soon!
Otherwise, it may be worth checking what
drm_info
outputs on both 6.10 and 6.11.
I'll attach these here anyway:
drm_info_6-10.txt drm_info_6-11.txt drm_info_6-11_30hz.txt
At least this seems to confirm that cosmic-comp
is setting the mode correctly.
Thanks for the info -- I'll keep an eye on the overlay planes fix and report back if it resolves my issue.
Oh, and if it is that issue, or another issue related to direct scanout planes, COSMIC_DISABLE_DIRECT_SCANOUT=1
should make cosmic-comp work.
Oh, and if it is that issue, or another issue related to direct scanout planes,
COSMIC_DISABLE_DIRECT_SCANOUT=1
should make cosmic-comp work.
Just tried this, disabling direct scanout doesn't resolve the issue. The only seemingly relevant dmesg error also occurs for the (working) internal display surface:
Oct 24 17:28:37 frmwrk kernel: WARNING: CPU: 7 PID: 2416 at drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:1446 link_set_dpms_on+0xd15/0xdd0 [amdgpu]
Hm, that definitely looks relevant. If it's failing to set DPMS on for the output. Not sure what the issue is though.
Oct 24 17:28:37 frmwrk kernel: WARNING: CPU: 7 PID: 2416 at drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:1446 link_set_dpms_on+0xd15/0xdd0 [amdgpu]
Hm, that definitely looks relevant. If it's failing to set DPMS on for the output. Not sure what the issue is though.
Okay, got some more time to play with this -- the dpms_on error does not happen when attempting to set the 4k@60Hz mode it happens when connecting the displays, ultimately they do turn on if the problem one is set to 30Hz so I think it's unrelated. The only dmesg
output I get when I try to set the mode is the DMUB interrupt callback notification.
I've attached DTN logs when 30Hz is set and when 60Hz is set for info, maybe you might know how to make sense of them. If not, I'll retest after the amdgpu
fix and maybe submit a bug there.
amdgpu_dtn_log_30hz.txt amdgpu_dtn_log_60hz.txt
Thanks again!
Moved from https://github.com/pop-os/cosmic-randr/issues/32 as it appears
cosmic-randr
is fine.My hardware is a Framework 13 AMD (7840U) connected to a Thunderbolt 3 dock with 2 displays connected via DisplayPort.
I'm seeing a particularly difficult to debug issue where one of my displays will not output a 4k@60Hz mode:
boltctl
output is the same under both kernels (not a TB issue)There seems to be some tricky interaction under 6.11 and
cosmic-comp
(or the libraries implementing the protocols or KMS backend) that is resulting in this behavior.cosmic-comp
does not output any error info withRUST_LOG=debug
set andcosmic-randr list
shows the display with the 4k@60Hz mode set as if successful, but the display goes into standby mode as if an unsupported mode is set.Let me know if I can gather any more relevant info!