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.
BUG:373880
connection and disconnecting an external screen to the laptop
both in the case of internal screen enabled or disabled
| No Linters Available |
| No Unit Test Coverage |
At a minimum this needs an upstream bug report with a description of exactly what is happening in both QPAs and in QPlatformWindow.
It's one thing to have a temporary workaround, it's another to deliberately write hacks from the start.
| shell/desktopview.cpp | ||
|---|---|---|
| 208 | if you add this in setScreen you'll reduce a lot of false positive signals on initial connection/ startup | |
| shell/desktopview.cpp | ||
|---|---|---|
| 208 | when the outputs get switched, setScreen won't happen, the expose event is the only place that is guaranteed to be triggered when this happen | |
I meant if you add this m_screenName *also* in set screen you'll reduce the number of false emits.
note, 5.8.5 is out the 27th, and this needs to be there, as it fixes a major issue.
if no further comments before then, tomorrow 24th I'll push
Oh! I think I now see why we have this bug.
We get a disconnect then connect, which from Qt5.5 goes:
Old Real Screen
Fake Screen
New Real Screen
You never get any signals when you're going to or from the fake screen (by design), but implicitly that means we miss a real change.
Is that the conclusion you had reached from debug?
yes, I think what's happening, when the output switches the chain of events is
QXcbConnection::destroyScreen()
if (virtualDesktop->screens().count() == 1) {
// If there are no other screens on the same virtual desktop, // then transform the physical screen into a fake screen.
then the new output is enabled:
QXcbConnection::updateScreens()
...
} else if (!screen && output.connection == XCB_RANDR_CONNECTION_CONNECTED) {
...
// Transform the fake screen into a physical screen
screen->setOutput(output.output, outputInfo.data());
and in this, no primaryScreenChanged, not screenAdded/screenRemoved got emitted, because the only qscreen pointer was massaged into being fake, then real again, but the instance is always there.
so, is this workaround ok with a message to remove when/if we depend from a qt with a proper solution to https://bugreports.qt.io/browse/QTBUG-57785 ?
so, is this workaround ok with a message to remove when/if we depend from a qt with a proper solution to https://bugreports.qt.io/browse/QTBUG-57785 ?
Based on this I still don't really get why we're not just using a native event filter on xrandr configure events as I asked on IRC. You might need to the processing in a Qt queued connection, but it'd still be a billion times simpler, and you could put the logic in screenpool, where it logically should be.
You said it was because of wayland, but that doesn't hold true , because even if the Qt wayland QPA does the same thing (and a quick grep for the word "fake" implies it doesn't) we're the ones that control what order the QPA gets output events so could avoid the situation anyway.
this is an attempt so use the native event filter approach (can't test yet, as i'm away and don't have an external screen handy)
will proper test tomorrow (too bad it's getting really tight for release:/)
yep, you are right, at the beginning i tought this was a qscreen problen on top of the xcb qpa, but it turns out is x11 specific, so the nativeeventfilter is more correct
there seems to be no XCB_RANDR_SCREEN_CHANGE_NOTIFY ever arriving in the event filter.
I'll go with the expose event path for 5.8.5, then will try to change it to the event filter again for 5.9/5.8.6