On Wayland, the primary screen notification and
QGuiApplication::screenAdded signals are desync. The primary output
watcher addresses that by emitting its primaryOutputNameChanged() signal
when the corresponding QGuiApplication::screenAdded() signal is emitted.
However, since the primary output watcher processes the screenAdded
signal before ScreenPool, it can emit the
ScreenPool::primaryScreenChanged signal before ScreenPool::screenAdded
signal that can confuse the ShellCorona.
(cherry picked from commit bb822a3359)
index desktop views by qscreen instead of id, making ScreenPool
the single source of truth for the mapping between screen names
and ids. This is less error prone and easier to consistency check
(if view->screenToFollow() is ever different to its has key it will
assert)
The whole logic of screen management is moved to ScreenPool.
ShellCorona will have to never call QGuiApp->screens, but only trust what ScreenPool it's telling it
Also adds an autotests on screenpool which makes a fake wayland server which sends screen added/removed/changed events
Refactors XRandr support together with the new Wayland code into a
PrimaryOutputWatcher class.
For X11 it listens to xcb events.
For Wayland it uses the kde_output_management_v2 protocols.
There is no primary on Wayland, we were trying to make one up and making
everything worse in turn.
Instead, have the screen to connector mapping be stable across
executions. Each screen will look as configured, which makes it all more
predictable and we do not run into cases where we swap displays
configurations because the other one happened to be the primary this
time around.
Summary:
The macro is on its way to getting deprecated, so we better start
adopting the suggested alternative just as well.
Test Plan: plasmashell runs fine
Reviewers: #plasma, ngraham
Reviewed By: ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21493
Summary:
If a user logged in with one screen connected plugs in
a second screen, which becomes the new primary screen,
this screen would stay black or behave weird.
Unplugging the screen again would mess up plasmashell.
Added to ScreenPool::setPrimaryConnector():
In the case primary output changed m_idForConnector
doesn't contain the new primary, so a screen mapping
is created for it.
Test Plan:
Testing on virtualbox or vmware player seems impossible, because
these don't allow disabling the first display (VGA-1) and booting
with the second (VGA-2) only.
1. Boot machine with one screen connected to HDMI-3 (primary output).
2. Log in
3. Plug in second screen to HDMI-2:
--> primary output changes from HDMI-3 to HDMI-2
4. OSD appears: extend to right
--> Without this patch, the new screen (HDMI-2) would stay blank.
--> With this patch applied, the screen content moves to the new
second screen.
5. Unplug second screen (HDMI-2)
--> Without this patch, the background would get black, control panel
would disappear, could only be restored by restart of plasmashell
--> With this patch applied, screen content moves to the right and
works
Reviewers: #plasma, mart, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D13853
Summary:
CCBUG: 358231
CCBUG: 342056
Even the icon with the number of tasks pending moves from time to time.
To reduce the frozen time, a similar patch must be applied also to
frameworks/kwindowsystem src/platforms/xcb/kxmessages.cpp
frameworks/plasma-framework src/plasma/private/effectwatcher.cpp
According to the documentation (and a look to the source code)
http://doc.qt.io/qt-5/qabstractnativeeventfilter.html
The type of event eventType is specific to the platform plugin chosen
at run-time, and can be used to cast message to the right type.
On X11, eventType is set to "xcb_generic_event_t", and the message can
be casted to a xcb_generic_event_t pointer.
The other eventType are "windows_generic_MSG" and "mac_generic_NSEvent".
No other eventType starts with an 'x'.
Test Plan:
Cut & paste 2000 small files.
Before, a freeze (plasmashell not responding) of minutes
After, a freeze of seconds
Reviewers: #frameworks, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: broulik, davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10627
Summary: BUG: 390499
Test Plan:
See callgrind in bug report
Added debug in the relevant section, unplugged a monitor. Saw my output
Reviewers: #plasma, broulik
Subscribers: jtamate, mart, broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10538
Summary:
this replaces the approach with the expose event in
20b439a4f4 by directly monitoring the xcb screen change
notify native event
Test Plan:
attaching and detaching the external screen on a laptop
configured to deactivate the internal screen upon connection
same behavior as D3777
Reviewers: sebas, davidedmundson, #plasma
Reviewed By: davidedmundson, #plasma
Subscribers: pmuralidharan, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3822
Summary:
this replaces the approach with the expose event in
20b439a4f4 by directly monitoring the xcb screen change
notify native event
Test Plan:
attaching and detaching the external screen on a laptop
configured to deactivate the internal screen upon connection
same behavior as D3777
Reviewers: sebas, davidedmundson, #plasma
Reviewed By: davidedmundson, #plasma
Subscribers: pmuralidharan, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3822
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
CCBUG:372099
CCBUG:371858
CBUG:371991
CCBUG:371819
CCBUG:371734
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
CCBUG:372099
CCBUG:371858
CCBUG:371991
CCBUG:371819
CCBUG:371734
don't index m_desktopContainments by screen id
that will change and will break.
also, in createcontainmentForActivity, don't return one
that is already taking another desktop view
BUG:366394
BUG:366395
reviewed-by: Sebastian Kügler <sebas@kde.org>
Summary:
We used to append them, but that didn't work well and was crashing plasmashell
on fresh start.
A default desktop would be created alongside with the one provided by the
layout instead of replacing it.
If a layout wants to provide an additional screen for a desktop in the secondary
screen, it should specify the screen.
Test Plan:
Now the plasmashell tests pass. In fact I noticed it was broken due to an e-mail
Jonathan sent me that the test on neon was timing out. The test in neon will
freeze when the test crashes. Probably something to look into.
It can be reproduced by running:
```
xvfb-run -a --server-args="-screen 0 1024x768x24" dbus-launch --exit-with-session <exec>
```
Where `exec` is the process we need to run.
Now the test passes.
It's a crash that I had reproduced locally in the past. I can't now.
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: sitter, jriddell, plasma-devel, #neon
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2117