SUMMARY My current setup consists of a full HD monitor (LG 24MK430H 23.8") in front of me and to its right the laptop (Dell 5567 with KDE Neon Unstable and using Wayland) with the lid closed. When I go into System Settings and configure Displays so that the laptop screen is disabled, apply, then logout, login screen will have my laptop screen re-enabled and accessible through mouse despite me not seeing it, as the lid is closed. (need to recheck to see if this is 100% reproducible) Regardless of whether the screen is re-enabled or not on the login screen, and regardless of whether my mouse can move to the laptop screen on a new session, System Settings always displays laptop screen as Enabled. The laptop screen frame in Displays also appears underneath the monitor screen frame (need to recheck to see if 100% reproducible), a fact which seems to be the cause for a few graphical glitches perceivable in the menu, as the glitches disappear after disabling laptop screen once again. "Start with an empty session" is enabled. "Save as new global values for this display" is selected. STEPS TO REPRODUCE 1. Disable laptop screen in System Settings while lid is closed and apply 2. Logout normally through menu and logout screen 3. Login normally through login screen * By moving the mouse, it's possible to verify that the laptop screen is active while on the login screen. 4. Verify System Settings * Laptop screen lies underneath monitor screen. * Graphical glitches occur in the menu and possibly in other areas. OBSERVED RESULT After login, both screens are activated, differently from what was defined by the user. EXPECTED RESULT After login, only the monitor is activated, as defined by the user. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.16.80 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.3 Kernel Version: 5.0.0-23-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz Memory: 7,7 GiB ADDITIONAL INFORMATION As soon as I can, I'll retest the reproducibility of all steps. What is always reproducible is the fact that laptop screen gets activated every time. I don't know if this is the correct product to file this bug report.
I just retested it. All of the occurrences mentioned (two screens active while on login screen, laptop screen underneath monitor, graphical glitches) are 100% reproducible. In addition, aside from the menu glitch, I found two others: 1. Maximized windows will be maximized only up to 1366x768 2. Lock and login screens will also be confined to 1366x768
Created attachment 122167 [details] This is how Display looks immediately after login.
Created attachment 122168 [details] Moving the monitor screen, laptop is shown underneath, and it is enabled.
Created attachment 122169 [details] Notice the restore icon; seems limited to 1366x768; it maximizes at that place regardless of original position.
Created attachment 122170 [details] Logout screen also confined to 1366x768; lock screen the same, couldn't take print.
Just checked, the following: > login screen will have my laptop screen re-enabled and accessible through mouse despite me not seeing it, as the lid is closed. occurs regardless of the original session being Xorg or Wayland. However, in Xorg, > System Settings always displays laptop screen as Enabled. does not occur. In other words, Xorg session will remember that the laptop screen was originally disabled, whereas Wayland session will not. So there seems to be two non-related issues: one is that the login screen will activate both screens even if the laptop lid is closed, and the other is that Wayland cannot remember that the laptop screen was originally disabled.
Sorry, my mistake, I got confused with all the logouts I did. Xorg session **also** forgets which screens were enabled. A.k.a. both Xorg and Wayland are not able to remember that I disabled the laptop screen in System Settings. I'll rename this bug report accordingly. In this case I assume that both sessions are checking which screens are active during the login screen and using its reported state to determine whether screens should be active or not in the desktop.
I'm closing this because this ended up becoming an absolute mess of an explanation. I can no longer reproduce this issue regardless after reinstalling (although I vaguely remember this started happening after I set up an i3 session and managed windows with arandr/xrandr).