SUMMARY I have an LG 24UD58-B monitor (3840x2160@60Hz) and a Dell P2414H (1920x1080@60Hz), and when the two monitors DPMS cycle off, everything is fine. When the LG monitor powers back on, due to a bug in its deep sleep state, it causes a DRM hotplug event, which causes only that monitor to bounce out of the desktop layout. This causes all my windows to pop over to a desktop that's one quarter of the size and half the scale of the primary display. The only applications I have right now which are affected oddly by this are Steam (XWayland) and WezTerm (Wayland). Steam shrinks so its window now fits into the top left quarter of the screen, while WezTerm shrinks itself to the minimum allowed window size and becomes unusable until I resize it again. STEPS TO REPRODUCE 1. Acquire the listed monitors, any video card to drive them, but AMDGPU in this case. 2. Allow DPMS to cycle the displays off completely. 3. Move the mouse to cycle them on. OBSERVED RESULT Windows move around, some of them shrink, others shrink unusably. EXPECTED RESULT Desktop should make an attempt to absorb the DRM event and seed a new DRM surface handle to the compositor. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, kernel 6.9.1-2-cachyos (64-bit) (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION Bug is a minor nuisance, but at least better than whole apps crashing on monitor hotplug like some other desktops on the machine do. It would be nice if a slight delay could be added to actual hotplug events to coalesce a monitor disappearing for just a moment into a DRM handle refresh.
Are the misbehaving windows tiled in any way before the screens turn off? There's a whole bunch of fixes related to that + hotplugs in 6.0.5 > Desktop should make an attempt to absorb the DRM event and seed a new DRM surface handle to the compositor. Delaying drm events by multiple seconds is not an option, and wouldn't reliably fix this either. No, the compositor needs to handle hotplug events properly, and KWin does have a bunch of code in place to do so.
(In reply to Zamundaaa from comment #1) > Are the misbehaving windows tiled in any way before the screens turn off? > There's a whole bunch of fixes related to that + hotplugs in 6.0.5 They are not tiled, they are merely scattered around my primary display. > > > Desktop should make an attempt to absorb the DRM event and seed a new DRM surface handle to the compositor. > Delaying drm events by multiple seconds is not an option, and wouldn't > reliably fix this either. No, the compositor needs to handle hotplug events > properly, and KWin does have a bunch of code in place to do so. You're right. But there's probably no adequate solution to this that also won't have some form of jank. If I'd known what I know about this monitor now, I probably wouldn't have bought it.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Fine, since you didn't accept my submitted info, I'll just close this and cease using Plasma.
Calm down, it's just a bot. To shut it up, you just have to set the bug status back to "reported" when providing the requested information
Sorry, I shouldn't have acted like that in a bug tracker. The situation gave me too much anxiety to think clearly and handle it succinctly. I'll try to remember that I need to move the "reported" status manually in the future when dealing with Bugzilla trackers.
It's okay. As for the bug report itself, could you give me the output of > kscreen-doctor -o before and after unplugging the screen, and the position and size of any window before it got misplaced? You can get exact coordinates with the kwin debug console (just search for it in krunner). I want to plug those numbers into our autotest, which should've caught issues like this
.
Created attachment 170399 [details] kscreen-doctor before disconnect This is before the first disconnect.
Created attachment 170400 [details] kscreen-doctor after reconnect After reconnect. Terminal didn't respond to keyboard input during the brief moment where all the windows were on DP-2.
I'm going to throw out a guess. This appears to only be happening to Steam now, which is an X11/Xwayland app. When the primary display detaches, the windows migrate to the other display. But then the global Xwayland scale factor automatically changes to the highest scale factor, which is now 1.0. This causes the 3840x2160 virtual surface to compact to 1920x1080 and all the window positions to become cropped to the top left quadrant of the previous surface. It would be nice if the integer scale factor could be configured manually, or retained for longer in the event of a disconnect bounce like this.
Aha, yes that scale change is relevant - most likely the automatic resizing conflicted with restoring the window geometry. With that Xwayland scale change + Steam I managed to reproduce the issue on 6.0.4 and 6.0.5, but I also wrote an autotest and it doesn't happen with the autotest or manual testing on Plasma 6.1. So I'm cautiously optimistic that this bug is already fixed. Please make sure to test with 6.1 as well once that's out.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5884
Git commit e16069ae77cbacaeae1db9bca6641918ae3ada5e by Xaver Hugl. Committed on 17/06/2024 at 18:41. Pushed by zamundaaa into branch 'master'. autotests: add Xwayland scale changes to the output changes test M +1 -1 autotests/integration/CMakeLists.txt M +78 -0 autotests/integration/outputchanges_test.cpp https://invent.kde.org/plasma/kwin/-/commit/e16069ae77cbacaeae1db9bca6641918ae3ada5e
Git commit ed1bb6c6f0cecba01d15b75b212fdc839b2756c4 by Xaver Hugl. Committed on 18/06/2024 at 13:24. Pushed by zamundaaa into branch 'Plasma/6.1'. autotests: add Xwayland scale changes to the output changes test (cherry picked from commit e16069ae77cbacaeae1db9bca6641918ae3ada5e) M +1 -1 autotests/integration/CMakeLists.txt M +78 -0 autotests/integration/outputchanges_test.cpp https://invent.kde.org/plasma/kwin/-/commit/ed1bb6c6f0cecba01d15b75b212fdc839b2756c4
The bug with Xwayland windows seems to be fixed with Plasma 6.1. Steam seems to maintain a consistent sizing and position when the hotplug happens. Wezterm behaves badly, but the bad behavior seems unrelated to this issue, and is probably a different issue. It also behaves really badly when dragged across the edge of the two displays. I'll post a video to the new issue. It may even be a Wezterm issue and not a Plasma issue. It seems their app probably does not like scaling change events.
Disregard that, I spoke too soon. Steam maintains window positions, but the sizes behave badly. The shrink to 1.0 scale shrinks the window sizes, then they stay 1.0 until I click them again after the restore to the correct output. When I click them, they restore to 2.0 scale, but the window frame size does not double to match the scale change.
Created attachment 170725 [details] Screen shot of the messed up Steam announcement window Yeah, this is what the Steam announcement window did in the background. It's ordinarily a non-resizable window. So I guess that may complicate the size restore. Still a little weird that the scale doesn't switch back upon being restored to a 2.0 display, but also weird that the window size shrinks on scale reduction, but doesn't grow on scale growing.
It turned out that my fix was incomplete, but with https://invent.kde.org/plasma/kwin/-/merge_requests/5935 it should be properly fixed in Plasma 6.2. If you still see it causing any issues, just reopen this again :)