Bug 477480 - Prevent monitors, widgets, and windows from re-arranging themselves when adding/removing a monitor.
Summary: Prevent monitors, widgets, and windows from re-arranging themselves when addi...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (other bugs)
Version First Reported In: 5.27.9
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-24 23:11 UTC by andy
Modified: 2024-01-22 19:52 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andy 2023-11-24 23:11:26 UTC
SUMMARY
In the Display Configuration, we drag monitors to re-arrange them in a specific config. This should be "glued together" so that when a new monitor is added, the existing monitors and their relative positions do not change. Currently when a new monitor is added, these get reset to some default arrangement which is completely different. The overlay with options for how to add the new monitor appears after everything is already re-arranged, and I haven't had luck with it having any effect. I am using 4 monitors.

Similarly, we put widgets on specific monitors. I like to have a specific monitor with some clock widgets on it. I like a specific monitor to have the task manager oriented a specific way. These widgets should stay glued to the monitor they are assigned. However, when adding a new monitor, these widgets may re-arrange and appear on a different monitor. This is frustrating and sometimes challenging to enter edit mode and move things back. (Challenging example: Connecting an 800x600 projector and task manager and clock widgets moving to it, and they are crammed into the tiny screen resolution, and I can't see any of them yet because I didn't turn on the projector. Additional challenges:  sometimes widgets get stuck when dragging between montiors, or change size, or get dropped onto another widget). Many times per week I have to enter edit mode to drag my task manager back to the right monitor and also re-size/re-orient it, drag my desktop widgets back to the right screen and also re-size/orient them. I try not to disconnect screens, especially displayport, but it's inevitable.

Ideally, we should only ever move windows or widgets if a screen is removed. If a screen is removed, the windows and widgets should just move to the primary monitor. The remaining screens should still be "glued together". If a screen is removed and there is now a gap in the screen arrangement, move the two (or more) "islands" so that they touch again. The algorithm for this can be simple, like finding the nearest point between the islands and closing that distance.

As a partial workaround I used to disable KScreen to prevent monitors from re-arranging themselves, but this isn't an option anymore (at least on Wayland).

STEPS TO REPRODUCE
Example for adding a new monitor:
- Have 4 monitors arranged a specific way
- use xdp screencast portal to create a new virtual output
- observe whether widgets like task manager move to a different screen
- observe whether the 4 existing monitors become rearranged differently
- make any corrections by going to display settings and re-arranging monitors back to preferred way, and arrange the new virtual output as desired
- make any corrections to widget locations by entering edit mode and moving/resizing widgets
- stop screencast
- observe monitor arrangement and widget locations after the virtual output is removed

OBSERVED RESULT
- the monitors become re-arranged when adding the new output
- the task manager moves to a different monitor when adding the new output
- the task manager moves to a different monitor again (not the original) when removing the new output

EXPECTED RESULT
- The layout of monitors set in display settings should be "glued together", and adding a new monitor should not unglue and move the other monitors around
- Same for widgets - they should be glued to the monitor they are placed on. If a screen is added/removed, the widgets should not move unless that specific screen was removed.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11

ADDITIONAL INFORMATION
Comment 1 andy 2023-11-24 23:14:52 UTC
To clarify the desired behavior when removing a screen: 
If a screen is removed, the windows and widgets __that were on the removed screen__ should move to the primary monitor. The windows and widgets on the other monitors should not be affected.
Comment 2 Nate Graham 2023-11-29 22:32:54 UTC
Arrangements are remembered on a per-number-of-monitors basis.

So if you have a particular arrangement with three monitors plugged in, and you unplug thr fourth monitor, the system will change to the arrangement used when you last had "only" (lol) three monitors.

To achieve what you want, arrange the monitors in the KScreen KCM exactly how you'd like them for each number of connected monitors.

If you've already done that and still didn't get the effect you wanted, there's a bug somewhere. Can you confirm?

Also, are you using X11 or Wayland?
Comment 3 andy 2023-11-30 01:47:26 UTC
Using wayland. 

> To achieve what you want, arrange the monitors in the KScreen KCM exactly how you'd like them for each number of connected monitors.

I'm not sure if I understand in relation to the issue. Is Kscreen KCM the page in System Settings > Display and Monitor > Display Configuration?  If so see below.

Here's an example just now, with screenshots: https://imgur.com/a/wtJP98l
Before image: Two monitors plugged in, initial layout.
After image: what happens after plugging in a 3rd monitor, showing re-arranged screens and the overlay prompting action (which doesn't work).

One point of my request is, why does it rearrange the existing two monitors in "After"? Initially I had the 2560x1440 screen on the bottom left,  and the 3840x2160 screen next to it on the right (as they are on my desk). After plugging in the next screen, it decides to re-arrange them so the 3840x2160 screen is at the far left, the 2560x1440 screen moves to the middle, and the new screen at the far right. My ideal expected result is "The layout of monitors set in display settings should be "glued together", and adding a new monitor should not unglue and move the other monitors around". It's really annoying to have to mess with this all the time. Especially for something like adding a virtual display for screen sharing in wayland (described in original post).

Another point is that the overlay for extend to left/right/etc (as shown in the "After" screenshot) does nothing when I click on them. Does it even make sense for anything other than 2 monitors?

I can follow up with other screenshots for the issues with widgets.

>  "only" (lol) three monitors

Just wondering... is 3+ monitors assumed uncommon and less tested here?
Comment 4 Nate Graham 2023-11-30 20:35:50 UTC
Yes, three monitors is very uncommon, and 4 even more so. That would be one reason for the overlay not making much sense for your use case.

Are you on X11 or Wayland?

Can you try Wayland the Plasma 6 beta to see if it works any better there? Many many multiscreen bugfixes have made it in already, with more to come.
Comment 5 andy 2023-11-30 23:29:44 UTC
I'm on wayland. Maybe I'll try the KDE-Unstable repo on arch later...
Comment 6 Bug Janitor Service 2023-12-15 03:46:05 UTC
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!
Comment 7 Bug Janitor Service 2023-12-30 03:46:07 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now 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

Thank you for helping us make KDE software even better for everyone!
Comment 8 andy 2024-01-19 04:26:51 UTC
I'm now on the Plasma 6 beta and I can report many issues within a few minutes of playing with a laptop and one external monitor

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: arch linux
KDE Plasma Version: 5.92.0
KDE Frameworks Version: 55.248.0
Qt Version: 6.7.0
Kernel Version: 6.6.12-1-lts
Graphics Platform: Wayland

The whole OS config I booted into was provisioned from a script, so it's controlled in that sense and I can tweak/rollback/reboot as needed for a clean testing environment.

The laptop is an ASUS Flow X16 with an RTX4050 DGPU and Intel IGPU. The monitor is a 4k screen over HDMI 2.1 via usb-c adapter

Actions taken and issues observed:

1. Enable the Track Mouse effect so you can still "see" the mouse cursor if it disappears, because it will disappear in the steps below
2. Have the "Application Dashboard" as your menu in the panel
3. Press Super key on and off to show/hide the dashboard

Expected result: the application dashboard menu shows/hides every time
Actual result: Occasionally the whole screen freezes when the dashboard is shown (digital clock stops ticking, mouse cursor won't show movement) and will stay frozen for a minimum time and until you press Super again to hide the menu
- The journal shows "plasmashell[3078]: kf.windowsystem: static void KX11Extras::forceActiveWindow(WId, long int) may only be used on X11" every time the Super key is pressed
- When it freezes, on the first freeze it shows "kernel: i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun: port,transcoder" and every freeze after it instead shows "kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting PSR idle state"
- It freezes sometimes after pressing Super on and off 3-4 times, sometimes after more like 10 times

4. Connect monitor to the 1st USB-C port (non-dgpu port, the one that connects to the igpu) with a USB-C to HDMI adapter
5. The overlay asks which way you want to extend the monitor
6. Pick "Extend right"

Expected result: extends right
Actual result: it's extended left
Additional bug: The mouse cursor is now invisible on the laptop screen, and only visible on the external monitor

7. Unplug the external monitor
8. Plug the USB-C to HDMI adapter into the other port (connects to dgpu)

Expected: desktop shown on the external monitor
Observed: black screen on the external 

9. In display settings, uncheck "Enabled" for the external monitor, click Apply, then check "Enabled" and Apply again.

Observe: 
- the desktop is now shown on the external monitor, but also the panel has moved from the laptop screen to the external monitor.  Note: The laptop screen is still the "primary" display.
- The mouse cursor is still missing

10. Still with  "Application Dashboard" menu in the panel, press the super key

Expected result: shows the panel
Actual result: shows the panel and the external monitor goes black with occasional flicker of seeing the desktop wallpaper. Pressing Super again to turn the menu off results in the black screen going back to normal after another 1-2 seconds.


11. Disconnect the external monitor

Expected result: The panel moves back to the laptop screen (where it should have been always)
Actual result: The panel is not visible anywhere



Other than the journal entries mentioned above, nothing interesting was being logged during the flickering or other issues encountered.

I know this is many issues, and perhaps they should be split into multiple bugs? 
- Issue with "Application Dashboard" freezing the desktop when activated with no other monitors connected
- Issue with the "pick which way to extend the monitor" not working
- Mouse cursor disappearing when external monitor connected, depending on which screen the mouse is on
- Issue with "Application Dashboard" causing glitches on on external monitor when activated
- Issue with the panel jumping to another screen when external monitor connected
- Issue with panel completely disappearing when external monitor disconnected

Any guidance on how to slice and dice those?
Would it help to document each of these independently with a fresh-from-scratch booted system each time?

Other notes from messing around but with less documentation and steps:
- had the reverse situation where the mouse cursor was shown on the laptop screen and hidden on the external monitor
- had situation where the whole desktop would randomly freeze (e.g. moving mouse shows no movement) and animation only restored when after pressing the Super key to show the Application Dashboard.
- had a situation where clicking the application menu button on the panel did nothing, but the super key still worked. Right clicking the button seemed to click-through to the desktop.
Comment 9 andy 2024-01-19 05:04:51 UTC
Trying with 6.7 kernel seeing the same issues for all except I think the first one related to "kernel: i915 0000:00:02.0: [drm]" is resolved.

Seeing more examples of the panel jumping away from the primary screen when it shouldn't:
- Have external monitor connected and panel on laptop screen. Change laptop screen scaling from 150% to 100% results in panel moving to external screen
- Have external monitor connected and panel on laptop screen. In display settings move the laptop screen from the right side of the external to the left side. Results in panel moving to external screen
Comment 10 Nate Graham 2024-01-22 19:52:15 UTC
I think it would make sense to split this into multiple specific actionable bug reports, yeah--one per issue. Right now this mega bug report is not really actionable.

Also make sure you're testing with RC1 (not one of the betas) as a few of the issues you mentioned sound familiar and I believe were fixed in the RC1 release.