| Summary: | Screen hangs when losing focus and refocusing fullscreen app/game while USB-C external monitor is set as primary monitor on laptop | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ready2rumbel |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | kithop, nate, xaver.hugl |
| Priority: | NOR | Keywords: | regression |
| Version First Reported In: | 5.25.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://gitlab.freedesktop.org/drm/amd/-/issues/2075 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Kscreen files
Wayland Session log with KWin Debugging Sample script for detecting if the external GPU is plugged in on an AMD multi-GPU laptop |
||
There was one test I didn't think to try until after I made the initial post. With both screens active, while the laptop screen is set to 'Primary', I ran a game which loaded up on the laptop screen (obviously). I then set the game to windowed, dragged it over to the external monitor and made it full-screen. The result was that it hung in the exact same way. So it seems that this happens solely on the external monitor, whether it's set to primary or not or whether the laptop screen is enabled or disabled. I would've amended this information in the main post to reflect this but I can't edit it. For what it's worth, I keep KDE updated through zawertun's COPR (https://copr.fedorainfracloud.org/coprs/zawertun/kde/). Sorry for the extra post but as this issue started today, and I'm trying to think what could've caused it, the only thing that has changed on my system between yesterday and today are some updates related to Mesa-git and a few KDE packages from the COPR:
dnf history info:
Upgrade libkworkspace5-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded libkworkspace5-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-lookandfeel-fedora-5.25.3.1-2.fc36.noarch @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-lookandfeel-fedora-5.25.3.1-1.fc36.noarch @@System
Upgrade plasma-workspace-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-workspace-common-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-common-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-workspace-geolocation-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-geolocation-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-workspace-geolocation-libs-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-geolocation-libs-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-workspace-libs-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-libs-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-workspace-wayland-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-wayland-5.25.3.1-1.fc36.x86_64 @@System
Upgrade plasma-workspace-x11-5.25.3.1-2.fc36.x86_64 @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded plasma-workspace-x11-5.25.3.1-1.fc36.x86_64 @@System
Upgrade sddm-breeze-5.25.3.1-2.fc36.noarch @copr:copr.fedorainfracloud.org:zawertun:kde
Upgraded sddm-breeze-5.25.3.1-1.fc36.noarch @@System
Zawetun's COPR has been invaluable as a means to get immediate KDE updates over Fedora's pace and has worked great since I started using Fedora last year, from Fedora 35 up to Fedora 36.
Considering the symptoms, could it potentially relate to any of the above packages?
I did a rollback on the Mesa and KDE updates via 'dnf undo history last', placing the system in the exact state as it was last night when this issue didn't occur. Unfortunately, it still is.....so it's not related to these specific updates. The power cut I mentioned in the initial post happened earlier today and is the only time that the external monitor was disconnected while the desktop was running......so the only thing, as far as I can tell, that has changed is that KDE/Kwin/Kscreen managed to re-detect the laptop screen and since then I can't reliably run any games full-screen on the external screen if it de-focuses and refocuses in any way. It could be that this particular quirk has been around for a while but it just never manifested due to the way kwin/kscreen was only detecting my external as the sole monitor up till now. But it's still strange that, despite replicating that situation (by purging the laptop screen entry in Kscreen), it still freezes...... I shall await thee awesome experts on your analysis and advice. Please let me know if there is any further info/testing I can provide. Hi - for what it's worth, I've been experiencing the same issue on my all-AMD gaming laptop (ASUS ROG Strix G513QY 'AMD Advantage Edition') with an external USB-C -> DisplayPort monitor with VRR under Artix Linux, and have been deliberately holding back actually on the last versions of: kscreen (5.24.5-1) kwin (5.24.5-2) kwayland-server (5.24.5-1.1) kwayland-integration (5.24.5-1) While letting everything else stay up-to-date as normal with so far no ill repercussions. There's definitely some kind of regression with this particular combination of Wayland + Plasma 5.25 + an external monitor on a dGPU (though 5.24 itself fixed a lot of issues on this front for me, especially around either it being DisplayPort or because the DP connection is connected to the dGPU while HDMI is on the iGPU, and there's no MUX here, so PRIME and Reverse PRIME are involved, I think.) A quick search of pkgs.org shows me that for Fedora 36, it's the 'Fedora Updates' channel that's pulling in Plasma 5.25.4-1, while the base 'Fedora' one still is on 5.24.3-4. It looks like kwayland-server was rolled into kwin itself at some point, so if you want to try rolling back here to see if this works around the issue, you may want to manually install kwayland-server 5.24.3 as well. Thanks for the feedback, Gary. It's helpful that I'm not the only one experiencing this, especially on the same model laptop I'm using. In the process of troubleshooting this issue, I think I may have determined something crucial. If the desktop environment has the iGPU set as the primary display adapter, the issue occurs (even if the games are set & running on the dGPU). However, if the dGPU is set as the primary display adapter then this issue does not occur at all. Gary (and whomever else wishes to try), could you test this by making a script file (i.e amdtest.sh) in /etc/profile.d with the following in the script? export KWIN_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0 If you open System Settings -> About this system, by default, the Graphics Processor should be listed as 'RENOIR'. If the script loaded successfully, it should list as 'AMD Radeon RX 6800M' instead. Huh, wow! I can confirm this does indeed also resolve the issue for me, though for whatever reason my particular setup has the cards reversed (checked with lspci and what /dev/dri/by-path was linking to), so I had to flip the card order in that profile script, but after upgrading to 5.25.4 and relogging, I do see the change in the About panel to the 6800M from RENOIR, and my initial testing so far here lets me launch things like games from Steam (Timberborn via GE-Proton-7.29, for reference), get to the main menu, and Alt-Tab out and back in without everything freezing (MangoHud's frame time graph is a good indicator as that freezes up, too). I wonder if this bug & relevant commit is related? https://bugs.kde.org/show_bug.cgi?id=453386 Or whatever this is doing about 'multi-GPU' setups: https://invent.kde.org/plasma/kwin/-/commit/6012e409a61cf4100455c2db664fe6e058a57165 (I'm just looking at the changelog at https://kde.org/announcements/changelogs/plasma/5/5.24.5-5.25.0/) So there's a few things you can test to narrow this down: 1. with the dedicated GPU set as primary, do games freeze if they're on the laptop screen? 2. with the integrated GPU set as primary and KWIN_DRM_NO_DIRECT_SCANOUT=1 set, do games still freeze when they're on the external screen? 3. set QT_LOGGING_RULES="kwin_*.debug=true", trigger the bug and upload the output of "journalctl --boot 0 --user-unit plasma-kwin_wayland" here afterwards Created attachment 151419 [details]
Wayland Session log with KWin Debugging
Bug triggered with QT_LOGGING_RULES="kwin_*.debug=true"
(In reply to Zamundaaa from comment #7) > So there's a few things you can test to narrow this down: > 1. with the dedicated GPU set as primary, do games freeze if they're on the > laptop screen? No, everything (mostly) works fine regardless of screen with the first workaround, though I don't get a mouse cursor while over on the laptop panel in multi-monitor mode for some reason... > 2. with the integrated GPU set as primary and KWIN_DRM_NO_DIRECT_SCANOUT=1 > set, do games still freeze when they're on the external screen? This also fixes the issue! I tried swapping the card order and then not exporting KWIN_DRM_DEVICES at all, and confirmed the System Settings -> About panel went back to showing RENOIR, and I can still Alt-Tab just fine. (I did also try KWIN_DRM_DEVICES once more and re-confirmed that the bug *does* come up in that case) > 3. set QT_LOGGING_RULES="kwin_*.debug=true", trigger the bug and upload the > output of "journalctl --boot 0 --user-unit plasma-kwin_wayland" here > afterwards I'm on Artix, which uses OpenRC (so no journalctl), *but*, I believe I figured out where that logging went (~/.local/share/sddm/wayland-session.log) and attached. I can already see something that looks suspicious, though - a whole lot of this around when I triggered the bug: kwin_wayland_drm: Presentation failed! Invalid argument kwin_wayland_drm: Atomic commit failed! This should never happen! Invalid argument kwin_wayland_drm: Flags: kwin_wayland_drm: DRM_MODE_PAGE_FLIP_EVENT Let me know if there's anything else you'd like me to test; I'm more than happy to help. Thanks! (also, while looking for what, exactly, 'KWIN_DRM_NO_DIRECT_SCANOUT' does, I stumbled on this bug filed against the AMD drivers: https://gitlab.freedesktop.org/drm/amd/-/issues/2075 ) So not sure then if this sounds like a Mesa or AMDGPU bug. Yep, this is the same amdgpu bug. You might want to comment on that issue you linked so that it gets prioritized. Will do once my account registration there is approved - in the meantime, I'm assuming that the 'right' workaround is still switching the card order in KWIN_DRM_DEVICES, as it sounds like KWIN_DRM_NO_DIRECT_SCANOUT implies there could be other knock-on effects? (e.g. https://pointieststick.com/2021/02/05/this-week-in-kde-kwin-gains-direct-scan-out-and-gwenview-gets-a-lot-of-love/ mentions specifically that direct scan-out helps with latency & performance in games.. but that's assuming it works with the swapped cards here anyhow) Thanks again either way! Neat! At least the issue is pinpointed now. I'd set my dGPU as the primary adapter for a while now but what I didn't notice, when the kscreen quirk happened, is that (despite the script being there) the iGPU was the primary and that presented the issue that inspired this bug report to begin with. I'll follow the issue tracker on the amd git, along with Gary, and provide any assistance I can. Thanks Gary & Xaver :) (In reply to Gary Carter from comment #12) > Will do once my account registration there is approved - in the meantime, > I'm assuming that the 'right' workaround is still switching the card order > in KWIN_DRM_DEVICES, as it sounds like KWIN_DRM_NO_DIRECT_SCANOUT implies > there could be other knock-on effects? (e.g. > https://pointieststick.com/2021/02/05/this-week-in-kde-kwin-gains-direct- > scan-out-and-gwenview-gets-a-lot-of-love/ mentions specifically that direct > scan-out helps with latency & performance in games.. but that's assuming it > works with the swapped cards here anyhow) yes, direct scanout also works with the cards swapped. The only downside of swapping the cards vs disabling direct scanout is power consumption, because the dedicated GPU needs to stay powered on when KWin uses it for compositing Created attachment 152526 [details]
Sample script for detecting if the external GPU is plugged in on an AMD multi-GPU laptop
Hi all,
While we wait to see if Mesa will acknowledge + potentially resolve this upstream, I'm attaching a little script I have in /etc/profile.d that checks to see if a monitor is plugged into the dGPU's DisplayPort (USB-C), and if so, puts the cards in the 'right' order in KWIN_DRM_DEVICES (and similarly, forces the opposite order if the port is disconnected).
This way at least, it's just a log out and back in as opposed to having to manually edit that variable in your profile.
The usual caveats apply here in that this could mess with power consumption + thermals by potentially unnecessarily keeping the dGPU powered up.
Thanks for the script, Gary. Hopefully the amdgpu team will attend to solving this sometime soon. |
Created attachment 150884 [details] Kscreen files SUMMARY Hey there, I'm using a laptop with Fedora KDE running Plasma 5.25.3 (Wayland) and an AMD CPU and GPU (running Mesa 22.2.0-dev). From the tail end of the 5.24 releases, up till 5.25.3, Kscreen was only detecting my external monitor. While this is/was a bug, my laptop is tethered to power and I only use the external screen anyway. After experiencing a power cut while in use, my external monitor powered off and the laptop monitor became the primary display. Since then, Kscreen is detecting both the laptop and external monitor. At this point, I configured Kscreen to have the laptop monitor disabled and the external as the sole, primary functioning monitor. What I noticed when running games full-screen is that if it loses focus for whatever reason, whether it be a background notification or I alt+tab, the game screen hangs with the last image that was showing before re-focusing. If I alt+tab to another app window or the KDE app switcher shows, I can see the game running fine but the moment I re-focus on the game window, the image/screen freezes. This does not occur when running the game windowed. To troubleshoot further, I experimented with enabling just the laptop screen, just the external screen and both with either set to 'Primary'. From my testing, this issue occurs specifically when the external monitor is set as primary (whether the laptop screen is enabled or disabled). Assuming it might be an issue with the kscreen entries, I deleted everything in .local/share/kscreen and rebooted. Despite the refreshed listing of both monitors, the symptom persists. The last tinkering I did was to test removing the laptop screen file in the 'output' folder and editing the main file in the root of the kscreen folder, to purge recognition of the laptop screen entirely. After rebooting, kscreen was detecting only the external monitor and it was set to primary. In this instance, not only were fullscreen games still having the same issue but now the desktop environment was too. I'd have to alt+tab, expose the KDE app switcher and the desktop was responsive again. More specifically concerning the desktop, I would be moving the mouse cursor around and the desktop would "freeze" after a few seconds of movement (only alt-tabbing would "wake" it up). I'd alt+tab, move the mouse around and it would hang again. Curious about this, I eventually alt+tabbed and navigated the desktop with just the keyboard...and it didn't hang. So not only is this hanging occurring when losing focus and refocusing fullscreen games but mouse movement (also) triggers the desktop environment to behave in the same way whilst the laptop screen entries in Kscreen are purged. As long as kscreen detects the laptop screen as well, the desktop environment runs fine without mouse movement triggering any hangs. Lastly, mouse movement in the game itself doesn't cause any hanging (whether kscreen entry detects the laptop screen or not). STEPS TO REPRODUCE 1. Run KDE 5.25.3 w/ Wayland on a laptop with an external screen via USB-C (preferably an AMD GPU w/ Mesa 22.2.0-dev) 2. Set external monitor as 'Primary' in Kscreen (with laptop screen enabled or disabled) 3. Run GPU accelerated app full-screen (any game will do), alt+tab and attempt to refocus on the game window. 4. For deeper testing, delete laptop screen entry in Kscreen/Output and edit file in root Kscreen folder to purge the laptop screen entry. Reboot and re-test games with alt-tabbing and refocusing & move mouse cursor on the desktop. OBSERVED RESULT While the external monitor is set as 'Primary', losing focus on the full-screen game will cause the game process to only show the last frame when refocused. If Kscreen entries are modified to purge the laptop screen, the issue persists with fullscreen games & it's also triggered on the desktop environment itself when moving the mouse cursor around consistently for a few seconds. Navigating with the keyboard does not induce the symptom. EXPECTED RESULT Full-screen games should operate & display properly, without freezing, when losing and regaining focus while the external monitor is set as primary (whether laptop monitor is enabled or disabled). More-so, the desktop environment should operate properly, without the same type of freezing (triggered by mouse movement) while laptop screen entry is purged from Kscreen. SOFTWARE/OS VERSIONS Linux: Fedora 36 KDE KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Attached is the contents of the kscreen folder, if it will help in any way.