SUMMARY In both the KCM & with kscreen-doctor I can no longer enable/disable monitors at will; I think it began with 6.2. kscreen-doctor fails silently. Trying to configure the displays in the KCM causes the changes to appear reverted immediately after clicking Apply, and it does not seem like the displays tried to change configuration. I have 3 displays connected; 2 monitors and 1 TV. One monitor uses DP, other other displays both use HDMI. It only happens sometimes, but I can't seem to find a pattern. When I am unable to switch to the TV the only thing that works is to unplug the power from one of the monitors, then it suddenly works. STEPS TO REPRODUCE 1. Have 2 monitors enabled, TV disabled. 2. Disable both monitors and enable the TV. OBSERVED RESULT Changes revert/fail silently. EXPECTED RESULT Monitors' output should be disabled, output to TV should be enabled. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.11.4-201.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 47.0 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series ADDITIONAL INFORMATION ``` ❯ kscreen-doctor --outputs [ 16:38:13.617 ] kscreen.kwayland: KScreen::WaylandConfig::addOutput 195: adding output 63 [ 16:38:13.617 ] kscreen.kwayland: KScreen::WaylandConfig::addOutput 195: adding output 64 [ 16:38:13.618 ] kscreen.kwayland: KScreen::WaylandConfig::addOutput 195: adding output 65 [ 16:38:13.618 ] kscreen.kwayland: KScreen::WaylandBackend::WaylandBackend 31: Loading Wayland backend. Output: 1 DP-1 enabled connected priority 1 DisplayPort Modes: 1:3840x2160@60*! 2:3840x2160@60 3:3840x2160@60 4:3840x2160@50 5:3840x2160@30 6:3840x2160@30 7:3840x2160@25 8:3840x2160@24 9:3840x2160@24 10:2560x1440@60 11:1920x1200@60 12:1920x1080@60 13:1920x1080@60 14:1920x1080@60 15:1920x1080@50 16:1920x1080@24 17:1920x1080@24 18:1920x1080@24 19:1920x1080@24 20:1600x1200@60 21:1680x1050@60 22:1280x1024@60 23:1440x900@60 24:1280x960@60 25:1280x800@60 26:1280x720@60 27:1280x720@60 28:1280x720@60 29:1280x720@50 30:1440x576@50 31:1440x576@50 32:1024x768@60 33:1440x480@60 34:1440x480@60 35:1440x480@60 36:1440x480@60 37:800x600@60 38:800x600@56 39:720x576@50 40:720x480@60 41:720x480@60 42:720x480@60 43:720x480@60 44:640x480@60 45:640x480@60 46:640x480@60 47:1600x1200@60 48:1280x1024@60 49:1024x768@60 50:2560x1600@60 51:1920x1200@60 52:3840x2160@60 53:3200x1800@60 54:2880x1620@60 55:2560x1440@60 56:1920x1080@60 57:1600x900@60 58:1368x768@60 59:1280x720@60 Geometry: 0,0 2560x1440 Scale: 1.5 Rotation: 1 Overscan: 0 Vrr: Automatic RgbRange: unknown HDR: disabled Wide Color Gamut: disabled ICC profile: none Color profile source: sRGB Brightness control: supported, set to 85% Output: 2 HDMI-A-1 disabled connected priority 0 HDMI Modes: 60:3840x2160@60*! 61:4096x2160@60 62:4096x2160@60 63:4096x2160@30 64:4096x2160@30 65:4096x2160@24 66:4096x2160@24 67:3840x2160@60 68:3840x2160@60 69:3840x2160@30 70:3840x2160@30 71:3840x2160@30 72:3840x2160@24 73:3840x2160@24 74:1920x1200@60 75:1920x1080@60 76:1920x1080@60 77:1920x1080@60 78:1920x1080@30 79:1920x1080@30 80:1920x1080@24 81:1920x1080@24 82:1600x1200@60 83:1680x1050@60 84:1280x1024@75 85:1280x1024@60 86:1440x900@60 87:1280x960@60 88:1280x800@60 89:1152x864@75 90:1280x720@60 91:1280x720@60 92:1280x720@60 93:1280x720@30 94:1280x720@30 95:1280x720@24 96:1280x720@24 97:1024x768@75 98:1024x768@70 99:1024x768@60 100:800x600@75 101:800x600@72 102:800x600@60 103:720x480@60 104:720x480@60 105:640x480@75 106:640x480@73 107:640x480@60 108:640x480@60 109:640x480@60 110:720x400@70 111:1600x1200@60 112:1280x1024@60 113:1024x768@60 114:2560x1600@60 115:1920x1200@60 116:1280x800@60 117:3840x2160@60 118:3200x1800@60 119:2880x1620@60 120:2560x1440@60 121:1920x1080@60 122:1600x900@60 123:1368x768@60 124:1280x720@60 Geometry: 0,0 2560x1440 Scale: 1.5 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: unknown HDR: disabled Wide Color Gamut: disabled ICC profile: none Color profile source: sRGB Brightness control: supported, set to 100% Output: 3 HDMI-A-2 enabled connected priority 2 HDMI Modes: 125:1920x1080@60*! 126:1920x1080@60 127:1920x1080@60 128:1920x1080@50 129:1680x1050@60 130:1600x900@60 131:1280x1024@75 132:1280x1024@60 133:1440x900@60 134:1280x800@60 135:1152x864@75 136:1280x720@60 137:1280x720@60 138:1280x720@60 139:1280x720@50 140:1280x720@50 141:1024x768@75 142:1024x768@70 143:1024x768@60 144:832x624@75 145:800x600@75 146:800x600@72 147:800x600@60 148:800x600@56 149:720x576@50 150:720x576@50 151:720x480@60 152:720x480@60 153:720x480@60 154:720x480@60 155:640x480@75 156:640x480@73 157:640x480@67 158:640x480@60 159:640x480@60 160:720x400@70 161:1280x1024@60 162:1024x768@60 163:1280x800@60 164:1920x1080@60 165:1600x900@60 166:1368x768@60 167:1280x720@60 Geometry: 2560,348 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: unknown HDR: incapable Wide Color Gamut: incapable ICC profile: none Color profile source: sRGB Brightness control: supported, set to 85% ```
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 :)