Summary: | Unable to modify displays since 6.2 | ||
---|---|---|---|
Product: | [Plasma] KScreen | Reporter: | Kristen McWilliam <kristen> |
Component: | common | Assignee: | kscreen-bugs-null <kscreen-bugs-null> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | kde, kdedev, nate, xaver.hugl |
Priority: | NOR | Keywords: | multiscreen, regression |
Version First Reported In: | 6.2.2 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=496410 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
kscreen.log with debug enabled
kscreen-doctor with WAYLAND_DEBUG=1 drm debug log |
Description
Kristen McWilliam
2024-10-31 17:41:32 UTC
Created attachment 175418 [details]
kscreen.log with debug enabled
Please run kscreen-doctor with WAYLAND_DEBUG=1 when this happens, and also attach KWin's log after trying to change the configuration Created attachment 175564 [details]
kscreen-doctor with WAYLAND_DEBUG=1
Attaching the kscreen-doctor output when run with WAYLAND_DEBUG=1.
The wiki says the kwin logs should be at ~/.local/share/sddm/wayland-session.log but the sddm folder doesn't exist on my system, and I have QT_LOGGING_RULES="kwin_*.debug=true" in my /etc/environment (and rebooted).
Is this still an issue? (In reply to David Edmundson from comment #4) > Is this still an issue? It is. I've been very time constrained lately, so I have only looked into it a little bit so far and haven't tracked down the issue as yet. Also present on the master branches as of last week when I was looking at it. Can you attach kwin logs too please? (when kscreen fails to enable or disable a monitor) Also, it would be great if you could capture drm log output. https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues Created attachment 178000 [details]
drm debug log
I got kwin logs by doing: > journalctl --since "2 minutes ago" -f --user-unit plasma-kwin_wayland .. and reproducing the issue. The only thing that outputs when I do so is: > Feb 05 12:37:14 SHODAN kwin_wayland[2151]: kwin_core: Applying config failed Which I believe is from https://invent.kde.org/plasma/libkscreen/-/blob/cbe11cd62064a2e9f85b3664f5cd97b10d553903/src/doctor/doctor.cpp#L491 Fixed my logging rules
> QT_LOGGING_RULES="kwin_*.debug=true"
It provides a few more lines of output now:
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_wayland_drm: Atomic modeset test failed! Cannot allocate memory
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_wayland_drm: Atomic modeset test failed! Cannot allocate memory
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_wayland_drm: Atomic modeset test failed! Cannot allocate memory
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_wayland_drm: Atomic modeset test failed! Cannot allocate memory
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_wayland_drm: Atomic modeset test failed! Cannot allocate memory
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_wayland_drm: Atomic modeset test failed! Cannot allocate memory
Feb 05 19:30:59 SHODAN kwin_wayland[4109]: kwin_core: Applying config failed
> Cannot allocate memory That suggests it may be bandwidth or maybe some actual memory constraint from the GPU. If you follow the steps at https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues, you might be able to get more information about the underlying issue. (In reply to Zamundaaa from comment #11) > If you follow the steps at > https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues, > you might be able to get more information about the underlying issue. I did follow the steps there, does the drm debug log I attached not contain the necessary info? I've looked through it a bit, but as you say it is quite verbose and I am not sure what to look for. oh, sorry, I overlooked that. It does contain what we're looking for: [415629.422484] [drm:update_stream_scaling_settings [amdgpu]] Destination Rectangle x:0 y:0 width:3840 height:2160 [415629.422814] [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 712750) pixel_encoding:YUV444 color_depth:10-bpc failed validation -- Encoder validation failure [415629.423187] [drm:update_stream_scaling_settings [amdgpu]] Destination Rectangle x:0 y:0 width:3840 height:2160 [415629.423517] [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 712750) pixel_encoding:YUV444 color_depth:8-bpc failed validation -- Encoder validation failure [415629.423849] [drm:create_validate_stream_for_sink [amdgpu]] create_validate_stream_for_sink:7391 Retry forcing yuv420 encoding [415629.424219] [drm:update_stream_scaling_settings [amdgpu]] Destination Rectangle x:0 y:0 width:3840 height:2160 [415629.424549] [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 712750) pixel_encoding:YUV444 color_depth:10-bpc failed validation -- Encoder validation failure [415629.424917] [drm:update_stream_scaling_settings [amdgpu]] Destination Rectangle x:0 y:0 width:3840 height:2160 [415629.425251] [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 712750) pixel_encoding:YUV444 color_depth:8-bpc failed validation -- Encoder validation failure [415629.425583] [drm:dm_update_crtc_state [amdgpu]] dm_update_crtc_state: Failed to create new stream for crtc 75 [415629.425913] amdgpu 0000:2b:00.0: [drm:amdgpu_dm_atomic_check [amdgpu]] ENABLE: dm_update_crtc_state() failed [415629.426249] amdgpu 0000:2b:00.0: [drm:amdgpu_dm_atomic_check [amdgpu]] Atomic check failed with err: -12 My best guess for what that means is that amdgpu's "forcing yuv420 encoding" doesn't always work, and you could make a bug report about this at https://gitlab.freedesktop.org/drm/amd/-/issues I don't think there's anything we can do about it certainly, the issue is completely in the layer below us. Thanks for looking at that, appreciate it! I made a bug report here: https://gitlab.freedesktop.org/drm/amd/-/issues/3967 (In reply to Zamundaaa from comment #13) > I don't think there's anything we can do about it certainly, the issue is > completely in the layer below us. Occurs to me we should still find a way to catch this sort of error, and present a message to the user about it rather than failing silently. KScreen does at least show "Couldn't apply output configuration" now, but unfortunately that's all. Drivers don't report more actionable information than "that didn't work", and we've unsuccessfully asked driver developers for more information in the KMS API for a very long time. Outside of that debug script with root permissions, and someone manually analyzing its output, there's no way to know more :( Ah that's unfortunate. Guess that'll have to do for now. Thanks :) |