Bug 475653 - Primary monitor is switched when coming back from suspend/rebooting
Summary: Primary monitor is switched when coming back from suspend/rebooting
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: 5.27.8
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: multiscreen
Depends on:
Blocks:
 
Reported: 2023-10-15 09:16 UTC by James North
Modified: 2023-11-01 18:24 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James North 2023-10-15 09:16:00 UTC
SUMMARY
I have two monitors. I set one of the monitors as the primary display, but when the computer wakes up again, the monitor is switched (often, I'm not sure if this is always the case). I then need to set the other monitor back to primary and the taskbar will move back.

I experienced this issue on Fedora, but recently moved to Arch Linux and am still facing this issue. I have a NVIDIA card, and am running Wayland.

My second monitor uses a HDMI port but is converted to DisplayPort before being plugged into my GPU. My monitor uses HDMI.

There is nothing in my ~/.config/plasmashellrc related to Screen Connectors. This command produces no output: grep -A4 tors ~/.config/plasmashellrc

Output of inxi -GSxxz --vs:

inxi 3.3.30-00 (2023-09-25)
System:
  Kernel: 6.5.7-arch1-1 arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    Desktop: KDE Plasma v: 5.27.8 tk: Qt v: 5.15.11 wm: kwin_wayland dm: SDDM
    Distro: Arch Linux
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2060 SUPER] vendor: Gigabyte
    driver: nvidia v: 535.113.01 arch: Turing pcie: speed: 8 GT/s lanes: 16
    ports: active: none off: DP-2,HDMI-A-1 empty: DP-1,DP-3 bus-ID: 2d:00.0
    chip-ID: 10de:1f06
  Display: wayland server: X.org v: 1.21.1.8 with: Xwayland v: 23.2.1
    compositor: kwin_wayland driver: X: loaded: nvidia unloaded: modesetting
    alternate: fbdev,nouveau,nv,vesa gpu: nvidia d-rect: 2880x1620
    display-ID: 0
  Monitor-1: DP-2 pos: bottom-r res: 960x540 size: N/A
  Monitor-2: HDMI-A-1 pos: primary,top-left res: 1920x1080 size: N/A
  API: EGL v: 1.5 platforms: gbm: drv: nvidia
  API: OpenGL v: 4.6.0 vendor: nvidia v: 535.113.01 glx-v: 1.4
    direct-render: yes renderer: NVIDIA GeForce RTX 2060 SUPER/PCIe/SSE2
    display-ID: :1.0
  API: Vulkan v: 1.3.264 surfaces: xcb,xlib,wayland device: 0
    type: discrete-gpu driver: nvidia device-ID: 10de:1f06


STEPS TO REPRODUCE
1. Set a display as the primary monitor
2. Suspend or reboot the computer
3. Watch as the other display is selected as the primary monitor and the taskbar moves to the other monitor.

OBSERVED RESULT
My primary monitor changes.

EXPECTED RESULT
My primary monitor remains my primary monitor in perpetuity.

SOFTWARE/OS VERSIONS
Linux: 6.5.7-arch1-1 Kernel
(available in About System)
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.11

ADDITIONAL INFORMATION
I'm using Wayland with my NVIDIA GPU. The second monitor is a Wacom Cintiq graphics tablet.
Comment 1 Michael Butash 2023-10-15 17:22:49 UTC
I get a similar issue with mine my primary display changes randomly with hotplug events using same, nvidia gpu and wayland on a laptop (hard set to nvidia-only in bios). When displays change their ID with every hotplug with Wayland, I find every time KDE plays 50 first dates with building a new config for it. This means my primary window changes between displays, latte errors out and doesn't show my bars anymore (it sees a new graphic config when displays change), and worst at times it just hard locks in doing so when combined with the constant memory leak I have in kwin.

Every time my displays change, KDE chooses random ID's for them (DP-1, DP-3, DP-5), and it wreaks havoc on things. I suspect yours might be similar. Until someone makes wayland far more deterministic around display ID's, I suspect kde will remain a basketcase for multi-monitor.

After a while, I find KDE builds like 50 different display configs for them each time it changes randomly, which seems to just confuse the hell out of things. Per Nate Graham, clearing them fixed things, but they start building up with the shuffling again over time, and each time clearing them makes my life better since learning this, which I've done periodically over a bit since figuring this out. You probably should as well with hot plugging your second display probably causes similar.

My problem is mostly thunderbolt docks, randomly mine resets, jumbles things, makes a mess of everything. If KDE/Wayland continue to jumble displays every time as a result, and creates new tuples of display variations, it'll continue to cause a ruckus.
Comment 2 James North 2023-10-17 07:22:55 UTC
I am able to reliably reproduce this display shuffling bug whenever resuming from suspend.

(In reply to Michael Butash from comment #1)
> Every time my displays change, KDE chooses random ID's for them (DP-1, DP-3,
> DP-5), and it wreaks havoc on things. I suspect yours might be similar.
> Until someone makes wayland far more deterministic around display ID's, I
> suspect kde will remain a basketcase for multi-monitor.

Where are you seeing these IDs? I couldn't find anything in plasmashellrc.

> After a while, I find KDE builds like 50 different display configs for them
> each time it changes randomly, which seems to just confuse the hell out of
> things. Per Nate Graham, clearing them fixed things, but they start building
> up with the shuffling again over time, and each time clearing them makes my
> life better since learning this, which I've done periodically over a bit
> since figuring this out. You probably should as well with hot plugging your
> second display probably causes similar.

Where do I find these display configs to clear out? By "hot plugging", do you mean unplugging the monitor while the system is running? Because these monitors are permanently plugged in.

For some reason, my graphics tablet is usually detected as the main monitor by Linux-based systems by default (I don't know about other operating systems). The Arch Linux install media reliably detected my graphics tablet as the main monitor and formatted the console as 1920x1080, leaving a very large space on my 4K monitor completely black.
Comment 3 Michael Butash 2023-10-17 16:12:33 UTC
This was my other thread on the matter.  https://bugs.kde.org/show_bug.cgi?id=465889

These tend to pile up in ~/.local/share/kscreen.

Also recommended was clearing these that seemed to accumulate display config fragments with this too, letting kde rebuild these clean certainly helped, but they begin piling up again.
~/config/plasma-org.kde.plasma.desktop-appletsrc
~/config/plasmashellrc

My displays attached to a tb dock rotate display id constantly with every reset.  This seems to be more a systemic problem in wayland than kde that this isn't more deterministic, but something's gotta make due with the quirk.  I have to keep latte-dock profiles for each of the 3 display variations I get, and when they blip, sigh, and go change latte dock for whatever they land on this time.
Comment 4 Michael Butash 2023-10-17 16:28:25 UTC
What I have observed over time seems to occur is there are multiple overlapping display profiles created that it seems to bounce between with the lack of deterministic behavior as stated by wayland in choosing display ID's, originally I found there was 40-some of them there.  All variations of my displays, but some minutae to make it separate, and this seems to cause chaos with things like KDE trying to put windows back in the right places upon reversion to a stable display config, which is my biggest problem and heartburn with KDE constantly.

Part of this is KDE can never seem to pick a proper "primary display" twice in a row, mine bounces between my two external displays with every display reset.  At times it'll default back the laptop display, which is a 15" vs the three 50" tv's I normally use next to it, and I have to squint to move things back in place.  Super annoying.
Comment 5 Nate Graham 2023-10-20 17:56:51 UTC
This situation should be improved in Plasma 6, where KWin has taken over screen management from KScreen, so we have a clearer set of responsibility. And it should not create 500 bazillion configs anymore.

Any chance either of you could try Plasma 6? See https://community.kde.org/Plasma/Plasma_6#How_to_use/test_it. That would be very helpful.
Comment 6 James North 2023-10-21 02:35:27 UTC
Checking ~/.local/share/kscreen, I see my three sets of config files for my displays. First, in a file in the root directory (DP-2 and HDMI-A-1), then in the outputs directory (HDMI-1 and DP-3), and then in the control/configs directory (HDMI-1 and DP-3).

I can't see any configuration files here though:
~/config/plasma-org.kde.plasma.desktop-appletsrc
~/config/plasmashellrc

As for trying Plasma 6...this might be beyond me. There doesn't appear to be an existing AUR package, so I'll probably need to compile it from source. The basic warnings seem simple enough but the actual instructions seem to be here: https://invent.kde.org/sdk/kdesrc-build/-/tree/master#quick-howto

And those aren't too bad either, although I think they leave out the final step of actually running Plasma 6...

Maybe it'd be best to try KDE Neon on an external SSD: https://neon.kde.org/download

Is the Testing Edition Plasma 6?
Comment 7 Michael Butash 2023-10-21 03:04:58 UTC
I've been itching to actually try plasma6, but like James I too am on Arch, it's not exactly cut and dry to get it or run it.  Plus a number of the issues mentioned were applicable to my use cases, so I've held off as I use my main rig for work and life in general.  Sadly trying it any other way like a vm or spare lappy isn't really doable as most of my issues seem to be directly hardware related either graphics drivers, my TB dock(s), or at least graphics related that I doubt my use problems would be the same.

Next time I get some downtime from customer projects, I will see if I can boot live neon to run for more than a quick weekend to be ready for work on monday.  Just watching current plasma5 soak up 70gb of my ram every few days is killing me enough I'm ready to try desperate measures and install plasma6 on my main rig anyways as a hail mary.
Comment 8 Nate Graham 2023-10-23 18:08:24 UTC
Neon Unstable edition is Plasma 6.

I'm not asking anyone to upgrade their primary system. Testing in a live session, or on a secondary system, or compiling it from source in your homedir, should be enough.
Comment 9 James North 2023-10-24 01:15:59 UTC
Thanks for the info, Nate. I'll give Unstable a try in a live session soon.
Comment 10 James North 2023-10-31 08:06:05 UTC
Sorry for the late response. Awful week.

I *tried* to run the Live ISO for KDE Neon Unstable, but it defaults to X11 in the live session and won't let me choose Wayland. For some reason, the graphics processor in About this System is detected as NV166 despite being a NVIDIA RTX 2060S.

I'll see if I can find a secondary drive somewhere to install it on.
Comment 11 James North 2023-10-31 08:36:28 UTC
The installer failed after about 20 seconds, which is probably not a good sign. The ISO I downloaded was from a week ago, so maybe it's fixed now. I'll see if I can download the latest KDE Neon Unstable ISO and try that.
Comment 12 James North 2023-10-31 10:50:48 UTC
Alright, I tried with the 29th October build of KDE Neon, and finally got it working. Had to workaround it to get the installer working, but nonetheless.

After launching Wayland, plasmashell immediately crashed. System settings also wouldn't launch, so I can't set my display configuration up and setup display scaling.

Running `systemsettings` from Konsole gets me:

> systemsettings: error while loading shared libraries: libKF6Kirigami2.so.6: cannot open shared object file: No such file or directory

On the plus side, it detected my primary monitor correctly the first time. I suspended, and when I came back, the primary monitor was still detected correctly.

So, issue fixed maybe?
Comment 13 Nate Graham 2023-11-01 18:24:51 UTC
Sounds like it's fixed, yay! FWIW I also cannot reproduce this issue with my dual-screen setup (though admittedly one of the screens is on a laptop, not a standalone one). That Kirigami issue is some kinf of Neon build issue.