Bug 376341 - dual screen setup broken after suspend
Summary: dual screen setup broken after suspend
Status: RESOLVED FIXED
Alias: None
Product: KScreen
Classification: Plasma
Component: common (show other bugs)
Version: 5.8.4
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: kscreen-bugs-null@kde.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-11 09:47 UTC by smihael
Modified: 2022-12-05 18:27 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
broken configuration (243.16 KB, image/jpeg)
2017-02-11 09:47 UTC, smihael
Details
plasmashell (777 bytes, text/plain)
2017-02-11 09:54 UTC, smihael
Details
appletsrc (13.78 KB, text/plain)
2017-02-11 09:55 UTC, smihael
Details
desired configuration (234.18 KB, image/jpeg)
2017-02-11 10:02 UTC, smihael
Details
kscreen.tar.gz (193.18 KB, application/x-gzip)
2017-02-11 16:21 UTC, smihael
Details
attachment-30658-0.html (1.53 KB, text/html)
2017-02-28 09:34 UTC, smihael
Details

Note You need to log in before you can comment on or make changes to this bug.
Description smihael 2017-02-11 09:47:52 UTC
Created attachment 103971 [details]
broken configuration

After suspend (Ubuntu 16.04) dual screen setup is broken (see screenshot). This happened each time I don't plug the HDMI cable out prior to suspend and it's getting annoying. 

Laptop screen should be left to the external display (as seen in the settings) but it is shown on the right (folderview with mountains as background). The panel that should be corresponding to laptop display is hidden beneath the panel that is supposed to be shown on external display but both are shown on laptop display. The plain view should be on the right side (external monitor) but is shown on the left (laptop). Furthermore, my selected wallpaper always gets replaced by the default plasma background.

I'm using Asus Zenbook UX32VD with dual graphic card setup, but effectively only the integrated Intel one is used. I don't experience such problems with other DE such as KDE 3 fork Trinity, so it cannot be only driver related issue. It is pitty because Plasma 5 is my favorite DE and I use it for the most of time. 

I'll append plasmarc file in a comment.
Comment 1 smihael 2017-02-11 09:54:00 UTC
Created attachment 103973 [details]
plasmashell

PlasmaRunnerManager and KFileDialog Settings are hidden for privacy reasons
Comment 2 smihael 2017-02-11 09:55:29 UTC
Created attachment 103974 [details]
appletsrc
Comment 3 smihael 2017-02-11 10:02:10 UTC
Created attachment 103975 [details]
desired configuration
Comment 4 Sebastian Kügler 2017-02-11 15:59:59 UTC
Thanks for the bugreport!

Could you attach the files in ~/.local/share/kscreen/* to this bugreport? The problem may be either in plasmashell or in kscreen, so we need to check if kscreen gets the positioning of the display wrong, or Plasma gets the assignment of containments wrong.

Before you do, could you also please test 5.8.5, since we fixed an issue there which may cause this problem?
Comment 5 smihael 2017-02-11 16:21:39 UTC
Created attachment 103981 [details]
kscreen.tar.gz

Attached you will find all files from ~/.local/share/kscreen/

I give quite a lot of presentations in different lecture rooms so there are
many screen files, but the problem is occurring mainly with screen
c3ec4764bde5c8aa5eda6ec1f38eb778.

I can not test with 5.8.5 earlier than in 3 weeks.. I have tons of other
stuff to get done, so I don't have time to deal with broken dependencies,
that I get when I try to update my system. Maybe it's time to switch from
Ubuntu to Neon.

On 11 February 2017 at 16:59, Sebastian Kügler <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=376341
>
> --- Comment #4 from Sebastian Kügler <sebas@kde.org> ---
> Thanks for the bugreport!
>
> Could you attach the files in ~/.local/share/kscreen/* to this bugreport?
> The
> problem may be either in plasmashell or in kscreen, so we need to check if
> kscreen gets the positioning of the display wrong, or Plasma gets the
> assignment of containments wrong.
>
> Before you do, could you also please test 5.8.5, since we fixed an issue
> there
> which may cause this problem?
>
> --
> You are receiving this mail because:
> You reported the bug.
>
Comment 6 Sebastian Kügler 2017-02-11 18:18:24 UTC
Another option would be the Neon Live image. Thanks for the configuration files!
Comment 7 Sergey 2017-02-28 05:44:58 UTC
I have exactly the same problem and it just drives me crazy.

Reproducible 100%

I found a way to restore screen though. For that I have to keep screen settings open (since after resume it may be more complicated to open them). Then I twice change positions of monitors and their sync mode.
But even after this procedure sometime I lose my wallpaper.

And wallpaper on my extra hdmi monitor is never shown after resume (just black screen with some previously opened windows on top).

hw configuration is also similar: laptop Clevo P170EM with Intel and Ati cards, but I use just Intel.

Gentoo Linux, Plasma 5.9.2
Comment 8 Sergey 2017-02-28 05:54:53 UTC
Forgot to say.
My extra monitor usually has a small delay to init. May it somehow affects Plasma.

Also weird effects after resume a pretty much random for me. for example: both monitors become in sync for ome reason, wallpaper on primary monitor sometimes is hidden as well (IIRC), Panels configuration is absolutely random (you never know panel of which monitor will be shown on primary monitor. And for secondary monitor it's usually just absent. Also taskbar may show no windows opened while I have them on both monitors (I configure taskbars to show tasks from current screen/display/room on both panels)).
Comment 9 smihael 2017-02-28 09:34:18 UTC
Created attachment 104268 [details]
attachment-30658-0.html

The workaround described by Sergey works for me usually too. I was still
unable to test with Neon, but I'm afraid it is hardware specific problem.

On 28 February 2017 at 06:54, Sergey <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=376341
>
> --- Comment #8 from Sergey <rion4ik@gmail.com> ---
> Forgot to say.
> My extra monitor usually has a small delay to init. May it somehow affects
> Plasma.
>
> Also weird effects after resume a pretty much random for me. for example:
> both
> monitors become in sync for ome reason, wallpaper on primary monitor
> sometimes
> is hidden as well (IIRC), Panels configuration is absolutely random (you
> never
> know panel of which monitor will be shown on primary monitor. And for
> secondary
> monitor it's usually just absent. Also taskbar may show no windows opened
> while
> I have them on both monitors (I configure taskbars to show tasks from
> current
> screen/display/room on both panels)).
>
> --
> You are receiving this mail because:
> You reported the bug.
>
Comment 10 Sergey 2017-03-22 03:17:17 UTC
It seems another workaround is to switch to cosole and type there pm-suspend  to go to sleep.
Resumed in console monitors are recognized properly by DE then.
Comment 11 Sergey 2018-10-19 07:10:35 UTC
Just gave it another shot after 1.5 years with xfce.
Still same way buggy.
5.14.1 is here
Comment 12 Sergey 2018-10-19 07:54:54 UTC
Just in case

rion@dizzynb ~ $ cat ~/.local/share/kscreen/56e40e2cebeace281ad87eb77d19cacd
[
    {
        "enabled": true,
        "id": "e998bf1b7cde6dafb866ed2bdb0e5cfc",
        "metadata": {
            "fullname": "xrandr-HSD173PUW1-6893",
            "name": "LVDS-1"
        },
        "mode": {
            "refresh": 119.93699645996094,
            "size": {
                "height": 1080,
                "width": 1920
            }
        },
        "pos": {
            "x": 0,
            "y": 0
        },
        "primary": true,
        "rotation": 1,
        "scale": 1
    },
    {
        "enabled": true,
        "id": "92c1086a209df219ec740d3fd9afee1b",
        "metadata": {
            "fullname": "xrandr-LG ULTRAWIDE-154353",
            "name": "HDMI-2"
        },
        "mode": {
            "refresh": 59.999534606933594,
            "size": {
                "height": 1080,
                "width": 2560
            }
        },
        "pos": {
            "x": 1920,
            "y": 0
        },
        "primary": false,
        "rotation": 1,
        "scale": 1
    }
]

Just one file is there.
Comment 13 Sergey 2018-10-19 08:21:45 UTC
Hm I'm not sure but just did one test. Removed everything from ~/.local/share/kscreen, closed lid and then waited 5+ mins, opened lid and the screen restored correctly!

No new files in ~/.local/share/kscreen, just that one I posted earlier. Previously I had two configuration files there.

I'll try to put it to sleep for longer. It's probably my second monitor goes to its powersave mode in more than 5 minutes.
Comment 14 Sergey 2018-10-19 20:47:24 UTC
Well. after longer delay I still see this bug.
Comment 15 Sergey 2018-10-20 06:51:00 UTC
Just tried another thing. Removed all the kde/plasma files I was able to find in ~/, ~/.config, ~/.local, ~/.cache. Put my laptop to sleep for whole night. 
In the morning it's restored properly. 
The only difference, previously it restored to my logged-in account, now it's kind of password-protected lock screen.
Comment 16 Sergey 2018-10-22 08:31:13 UTC
it happended again. so no miracles. it's still broken.
Comment 17 Sergey 2018-10-29 08:23:12 UTC
I just compared ~/.local/share/kscreen/56e40e2cebeace281ad87eb77d19cacd with and without the bug. The only difference is in the offset of my second monitor. It's set to 0 when has to be 1920.
Comment 18 Sergey 2018-10-29 16:34:57 UTC
any developers here? any idea what code can I check to try to fix?
Comment 19 Sergey 2018-10-30 07:49:18 UTC
same problem with openSUSE Tumbleweed

kscreen-5.14.1
Comment 20 Sergey 2018-10-31 08:38:58 UTC
I found it easier to have a small script with 
xrandr --output LVDS-1 --primary --auto --left-of HDMI-2

so after resume I can press alt+f2 and start it.

In other words this bug is not that critical for me anymore.
Probably I'll just update my script to start this script once per 10 secs. So it won't require any manual actions. It will solve the problem completely.
Comment 21 Sergey 2018-10-31 20:30:31 UTC
xrandr shell script seems to work good.
Bug I just rewrote it based on this https://askubuntu.com/questions/183516/how-do-i-detect-when-my-system-wakes-up-from-suspend-via-dbus-or-similar-in-a-py

def handle_sleep_callback(sleeping):
  if not sleeping:
    os.system("sleep 5; xrandr --output LVDS-1 --primary --auto --left-of HDMI-2")


If I notice any issues I'll report back.
Comment 22 Sergey 2018-11-01 20:18:02 UTC
seems to be the same https://bugs.launchpad.net/ubuntu/+source/kscreen/+bug/1573345

wrt my scripts no issues so far.
Comment 23 hoshiyamazaki01 2018-11-02 01:08:46 UTC
Appears to affect wayland too.
Comment 24 hoshiyamazaki01 2018-11-02 01:10:26 UTC
(In reply to hoshiyamazaki01 from comment #23)
> Appears to affect wayland too.

Distro I use is Arch Linux.
Comment 25 smihael 2019-02-09 19:59:17 UTC
This seems to not be an issue anymore using KDE neon 5.14 with Plasma 5.14.5, KDE Frameworks 5.54.0 and generic Linux 4.15.0 kernel.
Comment 26 Sergey 2019-02-09 20:16:57 UTC
I currently use Plasma 5.14.5, KDE Frameworks 5.54.0 but I'm not sure how long.

I'll try to disable my scripts and check.
Comment 27 Sergey 2019-02-11 19:41:58 UTC
yep. seems to work properly
Comment 28 Sergey 2019-02-13 19:15:14 UTC
just reproduced it again..
so not fixed..
Comment 29 M. Raymond Vaughn 2020-02-28 00:15:47 UTC
Dear KDE bug wranglers,

May I ask what the current disposition of this bug is, and whether there is anything at all I can do to help resolve it? My research indicates the problem is widespread on a variety of hardware, and I have yet to find anything approaching a root cause analysis or a limitation to the circumstances that may yield symptoms.

I have two Gentoo Linux systems both running Plasma 5.17.5 on Xorg 1.20.6: one always reproduces the issue, and one never reproduces the issue. I am in a position to perform comparative testing, and the system with symptoms matches the reporter's description precisely with the exception that it is not a laptop and both displays are identical.

The machine that does reproduce the issue every time has two identical displays both attached to the dual HDMI outputs of a single AMD Radeon Vega 56 discrete graphics card. The graphics are currently supported by the xf86-video-amdgpu open source drivers, but I have had the same results with respect to this issue using the proprietary drivers. The system runs kernel 5.5.5 with the Gentoo patchset. Its integrated graphics controller is disabled.

The machine that behaves exactly as expected on resuming from DPMS states has two identical displays both attached to the dual DisplayPort outputs of an integrated Intel i915 graphics controller, and runs kernel 4.19.97 with the Gentoo patchset.

Both machines otherwise run similar or identical software (including ) with similar or identical configurations, both having been installed and configured from scratch for my exclusive use based on the same template. It is difficult to assess at this time what minor differences may be relevant, as I have only recently begun descending into the madness of attempting to troubleshoot this issue once more by comparing the two machines, though I am hopeful additional exploration may bear fruit.

If I may be of service, please let me know the state of your investigation and which particular diagnostics would be most useful to you. I am able to perform low-level debugging, but will need your superior familiarity with the software for direction.

Thank you for your attention.
Comment 30 M. Raymond Vaughn 2020-02-28 01:20:10 UTC
I hesitate to make a claim so quickly, but... it is entirely possible that plasmashell/kscreen are doing exactly what they are supposed to.

On the machine with symptoms, I have been forcing my displays to switch off using `xset dpms force off` again and again, while watching my system logs in a remote terminal. I could reliably get this to mess with my display arrangement every single time. I noticed two things happen in each iteration, even if I killed the kscreen background service so it couldn't try to change things on me.

One -- when the displays received the blanking signal, they immediately tried to switch to a different input (they both have a disconnected VGA input); then, finding nothing there, they switched back to the HDMI input and went to sleep.

Two -- this line from plasmashell *always* appeared in the log when my primary/secondary display arrangement was broken:

Feb 27 19:34:23 pygoscelis plasmashell[3988113]: Old primary output: QScreen(0x55dc2c64a910, name="HDMI-A-0") New primary output: QScreen(0x7fd2f80ae920, name="HDMI-A-1")

I thought to myself: why would plasmashell want to rearrange the outputs if the connected devices aren't changing?

I answered myself: but the connected devices *are* changing. The displays are automatically cycling inputs when their signal goes away. From the software's point of view, the displays have been physically disconnected and then reconnected as their input selections cycle. Though both displays appear to do this simultaneously, they could very well be racing against one another, and if the wrong one goes away or comes back first... you have a new primary display.

I recalled that the displays on my asymptomatic computer do not have this automatic input switching feature.

So I changed one thing. The problematic displays have an "Auto Source" setting in their OSD menus. I turned that off. No need for checking the VGA input, anyway.

I then created a new Plasma session and repeated the test. The displays detected the blanking signal and simply went to sleep. No input cycling.

When I woke up the displays, everything was restored exactly as it had been before I put them to sleep. I can no longer reproduce the problem. This result is consistent.

I'd really like some of the other folks experiencing this problem to try the same thing or report their observations about their displays' behavior when they see an input signal go away. It seems that if you can suppress the input cycling, you suppress the race condition that causes displays to be reinitialized in the wrong order.

Alternatively, it *might* be a good idea for KDE to remember the unique IDs of previously connected displays (to the extent possible) and expose an option to the user to allow pinning a specific remembered display to the primary position in a display arrangement whenever it is reconnected.
Comment 31 Sergey 2021-01-25 09:33:23 UTC
I don't remember when last time it was reproducible for me on Gentoo Linux (always fresh).
But I noticed another problem. I have dualboot with Windows and sometimes after rebooting from Windows to Gentoo my laptop display is disabled. I have to press Fn key to change display configuration. And I'm lucky enough if the second monitor is connected when it happens (at least I see where I switch to). Otherwise just black screen and seems nothing can change it (I tried backlight Fn keys and Ctrl+Alt+N).
Comment 32 Lamdarer 2022-03-03 21:37:36 UTC
I think I also have the same issue, if I login after both monitors went to sleep my primary display does not have a background anymore and also not a taskbar.
Automatically searching and switching to different input signals was indeed turned on on my primary screen, however disabling didnt fix it, @M. Raymond Vaughn can you specify what you mean with new "Plasma session"? Like a new user?

In addition that that my windows move in between both of my displays or to my second screen entirely. Not sure if this is related to the same problem...
I use Manjaro KDE, a fresh install and AMDGPU with Open Source drivers.

(In reply to M. Raymond Vaughn from comment #30)
> So I changed one thing. The problematic displays have an "Auto Source"
> setting in their OSD menus. I turned that off. No need for checking the VGA
> input, anyway.
> 
> I then created a new Plasma session and repeated the test. The displays
> detected the blanking signal and simply went to sleep. No input cycling.
> 
> When I woke up the displays, everything was restored exactly as it had been
> before I put them to sleep. I can no longer reproduce the problem. This
> result is consistent.
> 
> I'd really like some of the other folks experiencing this problem to try the
> same thing or report their observations about their displays' behavior when
> they see an input signal go away. It seems that if you can suppress the
> input cycling, you suppress the race condition that causes displays to be
> reinitialized in the wrong order.
Comment 33 Lamdarer 2022-03-19 11:20:42 UTC
I(In reply to Lamdarer from comment #32)
I guess turning off automatic input selection really fixes it.
Though I sometimes have other problems with my screens after sleep mode(e.g. Blackscreen(except for the mouse cursor), Taskbar moves to the other screen)
Comment 34 rasmus.oltrogge 2022-10-07 11:07:17 UTC
Very similar to: 396071 and 401581.

The problem still consists. But it seems, it is not an issue on Plasma solely. I see it every day on XFCE, but XFCE uses parts of KDE Plasma, afaik.
Anyhow, I say, this should even be put into the #15-minute-initiative
In my company a lot of people have this issue as well.
I have a suggestion: Why doesn't write Plasma a file somewhere with the Hardware-ID (and assigning a number to it). This file will not be deleted. If the user uses the same computer for years but uses even 150 different monitors, then there are 150 different files. One for each monitor.
Additionally there will be one file for every configuration.
If the user uses one laptop with a docking station and two monitors, there is one config file written with all three displays on. In the config file is the display arrangement, widgets, application menu position and so on written into. And there will be another file written, if the user closes the laptop lid.
What do you think?
Comment 35 Nate Graham 2022-11-10 18:17:07 UTC
> This seems to not be an issue anymore using KDE neon 5.14 with Plasma 5.14.5, KDE Frameworks 5.54.0 and generic Linux 4.15.0 kernel.
Sounds like it's fixed for smihael now. Unfortunately each of you who are also experiencing this issue could easily be experiencing it for a completely different reason. Multimonitor bugs are weird like that.

Can I ask each of you to file a new bug report, and paste the output of `kscreen-doctor -o` before and after suspend? Thanks! Also please mention what GPU hardware you're using. Thanks a lot, folks!
Comment 36 Julius R. 2022-12-03 12:11:46 UTC
I doubt that this bug is resolved, nor fixed. I am running Manjaro with a dual screen setup and just recently updated to 5.26.3. After updating to the forementioned version from 5.25, my main screen did not wake up after energy save mode. I made a fresh reinstall of the system, then it became even worse: The primary monitor would not be recognized at all at boottime! I found that the config in .local/share/kscreen was messed up. No matter if I choose the primary to display to be "primary" and "enabled" in the GUI system settings, kscreen did neither apply the setting and / pr forgot about it (probably never saved the setting in the config file). 

I changed the setting manually from false to true, now it works as expected. See this thread for further explanation
https://forum.manjaro.org/t/monitor-does-not-turn-back-on-after-energy-saving/128030/9
Comment 37 Nate Graham 2022-12-05 18:27:48 UTC
Your issue is 100% sure to be something else, as the original report is over five years old and the code has changed completely. We track bug reports by root cause, not symptoms, and unfortunately with multi-monitor issues, the same set of symptoms can be triggerds by myrial root causes. Based on your description, it sounds like the issue could be Bug 460341 if you have an NVIDIA GPU.

If not, please do file a new bug report.