Bug 373880 - desktop background messed up after connecting external display (docking)
Summary: desktop background messed up after connecting external display (docking)
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (show other bugs)
Version: 5.10.5
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-19 08:37 UTC by Erik Quaeghebeur
Modified: 2022-02-23 04:36 UTC (History)
3 users (show)

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


Attachments
Messed-up desktop (7.43 KB, image/png)
2016-12-23 07:55 UTC, Erik Quaeghebeur
Details
Another version of the messed-up desktop (856.96 KB, image/png)
2016-12-23 11:27 UTC, Erik Quaeghebeur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Quaeghebeur 2016-12-19 08:37:27 UTC
I use a laptop with intel video (i915, 4.8.14 kernel) and have a docking station at work. The screens are setup such that upon docking, the laptop screen is disabled and the external display is the one used. When docking while powered, the desktop on the (higher resolution) external display is messed up. Namely, the plain color I have as the background for each of the active activity does not fill the whole screen, but only the top-left part (area equal to laptop display area, I think) and there are black bands on the right and bottom. Moreover, All activities have their background replaced with this background of the active activity. This replacement is not permanent, meaning that when restarting, the original background is reinstated (somewhat, but that is another bug I reported).

Expected behavior: upon connecting an external display, the background is the same as on the laptop display, so a plain color one fills the whole screen area.
Comment 1 Marco Martin 2016-12-20 15:25:53 UTC
can you post screenshots?
Comment 2 Marco Martin 2016-12-21 12:52:23 UTC
I reproduced the following (that i think is the issue)
after i switch screen, recreated the setup, only external screen used upon connection, and i switch activity, then i can't switch it back, and i lose the containment i had on the former current activity
Comment 3 Marco Martin 2016-12-21 15:57:27 UTC
possible fix https://phabricator.kde.org/D3777
Comment 4 Erik Quaeghebeur 2016-12-21 22:16:10 UTC
(In reply to Marco Martin from comment #1)
> can you post screenshots?

I'll do this once I get back to my work setup and the problem occurs.

(In reply to Marco Martin from comment #3)
> possible fix https://phabricator.kde.org/D3777

The fact that you encounter an issue in the same context and that you have identified the underlying cause is hopeful. Great!
Comment 5 Erik Quaeghebeur 2016-12-23 07:55:51 UTC
Created attachment 102952 [details]
Messed-up desktop
Comment 6 Erik Quaeghebeur 2016-12-23 11:27:36 UTC
Created attachment 102954 [details]
Another version of the messed-up desktop

As you can see, the bottom and right borders just take material from elsewhere in the desktop, a Firefox window in this case.
Comment 7 Marco Martin 2016-12-25 19:24:15 UTC
Git commit 20b439a4f4a1aa652f7960f0e6dfa8201f89aa11 by Marco Martin.
Committed on 25/12/2016 at 19:24.
Pushed by mart into branch 'master'.

notice when the only screen changes

Summary:
in a corner case that is used a lot, the internal laptop screen
gets automatically disabled when an external screen is connected.
the only QScreen* available from the QGuiApp gets recycled for the
new screen and there is no signal this switch occurred.

To work around this, as all the view get an expose event when this happen,
monitor the rename of the desktopview's qscreen and manage this separatedly
in the shell.

Test Plan:
connection and disconnecting an external screen to the laptop
both in the case of internal screen enabled or disabled

Reviewers: davidedmundson, #plasma

Reviewed By: davidedmundson, #plasma

Subscribers: davidedmundson, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D3777

M  +12   -7    shell/desktopview.cpp
M  +2    -0    shell/desktopview.h
M  +14   -0    shell/shellcorona.cpp

https://commits.kde.org/plasma-workspace/20b439a4f4a1aa652f7960f0e6dfa8201f89aa11
Comment 8 Marco Martin 2016-12-25 19:25:14 UTC
Git commit f7b170de9fd9c4075fee324d33212b0d69909ba4 by Marco Martin.
Committed on 25/12/2016 at 19:25.
Pushed by mart into branch 'Plasma/5.8'.

notice when the only screen changes

Summary:
in a corner case that is used a lot, the internal laptop screen
gets automatically disabled when an external screen is connected.
the only QScreen* available from the QGuiApp gets recycled for the
new screen and there is no signal this switch occurred.

To work around this, as all the view get an expose event when this happen,
monitor the rename of the desktopview's qscreen and manage this separatedly
in the shell.

Test Plan:
connection and disconnecting an external screen to the laptop
both in the case of internal screen enabled or disabled

Reviewers: davidedmundson, #plasma

Reviewed By: davidedmundson, #plasma

Subscribers: davidedmundson, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D3777

M  +12   -7    shell/desktopview.cpp
M  +2    -0    shell/desktopview.h
M  +14   -0    shell/shellcorona.cpp

https://commits.kde.org/plasma-workspace/f7b170de9fd9c4075fee324d33212b0d69909ba4
Comment 9 Erik Quaeghebeur 2017-01-09 08:34:40 UTC
This persists in 5.8.5, so this is not fixed. Reopening.
Comment 10 Marco Martin 2017-01-11 17:32:04 UTC
(In reply to Erik Quaeghebeur from comment #9)
> This persists in 5.8.5, so this is not fixed. Reopening.

how did you test it?
Comment 11 Erik Quaeghebeur 2017-01-11 21:16:37 UTC
(In reply to Marco Martin from comment #10)
> how did you test it?
Dock my running laptop, as in the initial 19 december description.
Comment 12 Nate Graham 2021-08-16 21:48:53 UTC
Sorry for the forward-dupe, but we are using Bug 391531 to track the multi-monitor wallpaper issues.

*** This bug has been marked as a duplicate of bug 391531 ***
Comment 13 Nate Graham 2021-10-06 18:37:18 UTC

*** This bug has been marked as a duplicate of bug 371717 ***
Comment 14 Nate Graham 2022-01-24 19:41:29 UTC
Actually this is different after all, sorry for the run-around.
Comment 15 Nate Graham 2022-01-24 19:41:36 UTC
Can you reproduce this with Plasma 5.24? Wayland session only if you are using a scale factor and the screens have different resolutions; otherwise you can test X11 too.
Comment 16 Bug Janitor Service 2022-02-08 04:37:09 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 17 Bug Janitor Service 2022-02-23 04:36:35 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!