Bug 371734 - Multiscreen lost configuration of the desktop
Summary: Multiscreen lost configuration of the desktop
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Multi-screen support (show other bugs)
Version: 5.8.4
Platform: Archlinux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords:
: 362812 365249 370434 371819 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-27 08:10 UTC by humufr
Modified: 2019-10-09 06:39 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
one of the desktop does not have the wallpaper and does not interact with the mouse (1.37 MB, image/png)
2016-10-27 08:10 UTC, humufr
Details
second screen is back to default configuration (2.04 MB, image/png)
2016-10-27 08:11 UTC, humufr
Details
plasmashellrc file (1.53 KB, text/plain)
2016-10-27 08:12 UTC, humufr
Details
plasma desktop applet configuration (11.12 KB, text/plain)
2016-10-27 08:12 UTC, humufr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description humufr 2016-10-27 08:10:53 UTC
Created attachment 101824 [details]
one of the desktop does not have the wallpaper and does not interact with the mouse

I got two different problems which are probably linked.

When I connect my laptop to my second screen, plasma lost the configuration for the second screen. In the screenshot attach it show the two problem.

1. The screen on the left doesn't have a wallpaper anymore and the mouse does not interact with the desktop anymore (no right click, no plasmoid)

2. The second screenshot seems normal but in reality it shows that the second screen went back to the default configuration. 

There are some similarity with the bug I reported before https://bugs.kde.org/show_bug.cgi?id=369665
Comment 1 humufr 2016-10-27 08:11:26 UTC
Created attachment 101825 [details]
second screen is back to default configuration
Comment 2 humufr 2016-10-27 08:12:18 UTC
Created attachment 101826 [details]
plasmashellrc file
Comment 3 humufr 2016-10-27 08:12:52 UTC
Created attachment 101827 [details]
plasma desktop applet configuration
Comment 4 Marco Martin 2016-10-31 14:15:44 UTC
this happens at startup? when connecting/disconnecting a screen?
Comment 5 humufr 2016-10-31 14:21:18 UTC
It happens when connecting/disconnection a screen. It is also random and if I disconnect and reconnect the screen the configuration can come back in its normal state. 

There are clearly something wrong (as the screenshot shows) but it is difficult to reproduce in a coherent way.
Comment 6 humufr 2016-11-02 09:39:52 UTC
I updated yesterday for 5.8.3 and now the situation is even worse than before. Same kind of behavior but in addition to that if I am choosing as main screen the attached screen, it used to move the whole desktop on it (not the windows but the background and the plasmoid) but not anymore only the panel is moved to the attached screen. 
Another new behavior is that when trying to play with the configuration on sytemsettings and enabling the second screen, changing the main screen etc, sometimes the screen is enabled but doesn't show anything for real. Plasma is clearly using it but the hardware doesn't work.
Comment 7 Marco Martin 2016-11-09 14:59:53 UTC
Git commit b8d3e09b3687082037a6d280d2032617121ae5e5 by Marco Martin.
Committed on 09/11/2016 at 14:54.
Pushed by mart into branch 'Plasma/5.8'.

make sure all outputs are known

at startup, if a screen id is missing from the screenpool mapping
containment::screen() will return -1 for a moment in the startup
phase even if it has a valid lastScreen

populate mappings of eventual missing stuff at screenpool ctor

make sure destroyed containments don't get assigned a view

reviewed-by: David Edmundson
Related: bug 372099, bug 371858, bug 371991, bug 371819

M  +11   -0    shell/screenpool.cpp
M  +7    -1    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/b8d3e09b3687082037a6d280d2032617121ae5e5
Comment 8 David Edmundson 2016-11-10 10:28:49 UTC
Git commit 8a472f17ce11f3b79d740cdc21096d82b8683f3d by David Edmundson.
Committed on 10/11/2016 at 10:28.
Pushed by davidedmundson into branch 'Plasma/5.8'.

Avoid connecting to screen changed signals twice

Summary:
load() can be called multiple times; either from setShell or
loadLookAndFeelDefaultLayout. We still only want addOutput once when a
screen is added

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D3320
Related: bug 372099, bug 371858, bug 371819
CBUG:371991

M  +3    -3    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/8a472f17ce11f3b79d740cdc21096d82b8683f3d
Comment 9 David Edmundson 2016-11-10 12:03:45 UTC
Git commit 7154fb681adc73c482e862febc7ad008f77058dd by David Edmundson.
Committed on 10/11/2016 at 12:03.
Pushed by davidedmundson into branch 'Plasma/5.8'.

Load screenpool at the same time as we connect to screenchanged signals

Summary:
Otherwise we have a gap during load (waiting querying kactivities))
between screen pool being created and us connecting to the screen
changed signals, which in turn are used to update screen pool.

In particular the primary screen can get out of sync between the current
state and the screen pool.

Test Plan: Based on Christopher Feck's research and initial patch

Reviewers: #plasma

Subscribers: mart, rwooninck, fvogt, cfeck, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D3319
Related: bug 372099, bug 371858, bug 371819
    CBUG:371991

M  +1    -0    shell/autotests/screenpooltest.cpp
M  +8    -0    shell/screenpool.cpp
M  +1    -0    shell/screenpool.h
M  +3    -1    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/7154fb681adc73c482e862febc7ad008f77058dd
Comment 10 humufr 2016-11-15 09:08:15 UTC
Hi,

thank you to look at the bug. I noticed that last week I had some update (from archlinux package) and now everytime I am connecting my second screen. The activity which is presented has the default configuration (background, no plasmoid and toolbox). I have to change everytime (sorry I do not like the default background, just a matter of taste). I gave up to put any plasmoid on the second screen for an obvious reason. The funny things is that if I have another activity, the configuration of the second one remain intact. 

Take care.
Comment 11 Janek Bevendorff 2016-11-18 11:51:17 UTC
*** Bug 371819 has been marked as a duplicate of this bug. ***
Comment 12 Janek Bevendorff 2016-11-18 11:51:36 UTC
*** Bug 370434 has been marked as a duplicate of this bug. ***
Comment 13 Janek Bevendorff 2016-11-18 11:52:14 UTC
*** Bug 365249 has been marked as a duplicate of this bug. ***
Comment 14 Janek Bevendorff 2016-11-18 11:57:34 UTC
One funny thing I noticed here is: I have two of these desktop handles which bring up the desktop context menu (Show Desktop, Add Widgets, Activities, Lock Widgets etc.). One of them is clickable and movable, the other is fixed and doesn't react to any mouse events.
When I create a new activity, that new activity does not have duplicate handles. However, when I delete the original activity, the screen shortly goes black and then the new activity suddenly also has these double handles.

Right after logging in, only the screen which still has the correct wallpaper (but the wrong panels) has duplicate handles, the other screen (which lost its wallpaper and widgets) does not, just like the newly created activity. As soon as I correct the wallpaper, that screen also gets double handles.
Comment 15 Janek Bevendorff 2016-11-21 11:16:00 UTC
Looks like it's working since I deleted the old activity and created a new one. But it's still a bug that shouldn't occur and should be fixed. I also still have these double desktop handles which is rather peculiar.
Comment 16 Gábor Katona 2016-12-09 19:29:23 UTC
I think my problem, commented to bug #362812 has the same origin. My comment from that bug:

I also have this, or a very similar problem. Running Opensuse Tumbleweed with Plasma 5.8.4, Frameworks 5.28.0.

The symptoms are the same, I have folder view set up for the desktop, and it resets itself back to desktop view. However I use different monitor setups and I suspect that, at least in my case, the reset is connected to switching between the different setups.

I use a notebook, sometimes on its own, sometimes using a dock with 2 monitors connected (the notebook screen is switched off) and sometimes with a projector with the notebook screen on. I noticed, that changing the monitor settings, which happens automatically upon connection of the projector or docking he notebook, sometimes resets back the primary screen (!) to the default desktop view with the default wallpaper. But only the primary screen.

Also when I try to set up folder view again, the icons are not in the arranged order, and moreover, in some cases I simply cannot change the layout to folder view. This latter only happens on activities that were created by me, never with the original activity.

I have tried deleting plasma-org.kde.plasma.desktop-appletsrc and plasmashellrc, but the problem stays.

If my problem seems different, I will file a new bug.
Comment 17 Marco Martin 2017-01-11 17:15:16 UTC
*** Bug 362812 has been marked as a duplicate of this bug. ***
Comment 18 Marco Martin 2017-01-11 17:17:00 UTC
should be solved by https://cgit.kde.org/plasma-workspace.git/commit/?id=19a88030d3de12a96402a1103c964e5a7363646c
(and Plasma 5.8.5 / 5.9)
Comment 19 Germano Massullo 2019-10-04 20:28:20 UTC
Is this bug still happening on newer Plasma versions?
Comment 20 humufr 2019-10-08 13:30:48 UTC
I have no idea unfortunately. I have a new laptop with which I cannot use a second screen. It is a Lenovo X1 with two GPU and someone thought that it was smart to plug the HDMI and usb-c to the nvidia card only... but nothing related to this bug. Sorry to not be able to help more.
Comment 21 Germano Massullo 2019-10-09 06:38:55 UTC
Ok then I will close it since from January 2017 nobody reported a similar bug, moreover devs submitted a commit that should have fixed it.
I am testing multiscreen support and there have been new bugs not related to this one