During tearing down the WaylandServer it's possible that ShellClients
are getting unmapped. For them make sure that they don't call into
the no longer existing Workspace.
The problem we had was closing a glxgears through an Aurorae theme
crashed KWin inside QtQuick.
This test case simulates the sequence:
1. starts glxgears
2. wait till we have a Client for it
3. send mouse move to guessed close button position
4. send mouse press/release at that position
5. verify the window is closed
6. verify glxgears exits
With the given commit reverted this crashes, with it in place it passes.
Please note: on CI it might fail as glxgears is not yet installed. [1]
Also we cannot enforce using Aurorae from the test yet, though on
the CI system it should get picked automatically as no other deco
plugin should be installed.
[1] Sysadmin ticket already created
Apparently it's not allowed to set root context properties multiple
times. If one goes to systemsettings, opens effects kcm, closes it
and opens it again it crashes due to setting a context property with
same name again.
This change eliminates the need for the context property by modifying
the property of the QML objects directly.
BUG: 354164
BUG: 351763
FIXED-IN: 5.4.3
REVIEW: 125737
It was broken on so many ways, it's unbelievable:
* action was read but did nothing
* config was saved into a different file than read from
REVIEW: 125701
CCBUG: 331841
Removes the ElectricAction for ShowDashboard and the relevant code
in screenedges and the KCM.
Also a leftover in the glide effect.
REVIEW: 125700
BUG: 353928
Our decoration is deleted using deleteLater() and that might cause access
to the bridge. Given that we also need to deleteLater() the
PreviewBridge.
To do so the PreviewBridge is no longer directly exposed to QML, but
in a wrapper object which holds the bridge as only element.
BUG: 344278
FIXED-IN: 5.4.3
REVIEW: 125724
This changes how we synchronize through vsync. We use a mutex and a
wait condition to synchronize the threads. When presenting the frame
our main gui thread blocks and will be woken up by the vsync event
(or a timeout of max 1 frame time slot). In order to minimize the
blocked time we use the blocksForRetrace functionality from the GLX
compositor.
Given this change we no longer need to tell the compositor that we
are swapping the frame, it's blocked anyway. Also we don't need the
failsafe QTimer anymore.
With this change applied on a Nexus 5 it's succeeding the "Martin
tortures phone test". It doesn't tear anymore and has a smooth
experience.
I'm rather disappointed by the fact that we need to block in order
to get vsync. This means Android/hwcomposer is as bad as GLX. So
much for the "Android stack is so awesome", in fact it's not. Anybody
thinking it's awesome should compare to DRM/KMS and especially atomic
modesetting. Yes it's possible to present frames without tearing and
without having to block the rendering thread.
Reviewed-By: Marco Martin and Bhushan Shah
The check whether Workspace is created is not sufficient. There's a
time when Workspace is already created but Compositor not ready yet
and where we can hit this code path.
The newer API is designed for the case that outputs are disabled and
makes sure that we don't have to abuse the aboutToSwapBuffers. This
also prevents possible conflicts between blocking during rendering and
screens being off.
Reviewed-By: Bhushan Shah
Basically dead code given that Plasma doesn't have a dedicated dashboard
mode anymore and also doesn't set the required window role for it to
work.
By deleting we save one string comparison for each newly opened window.
REVIEW: 125686
According to the hwcomposer documentation:
"It is a (silent) error to have HWC_EVENT_VSYNC enabled when calling
hwc_composer_device.set(..., 0, 0, 0) (screen off)".
Because of that we may not enable vsync directly after toggling the
output, but need to wait till after calling the set call.
Reviewed-by: Bhushan Shah
Apparently we don't get a vsync event for the first frame during startup
which blocks the compositor till the end of days. Thus a timer is added
which calls vsync after 1 sec if we didn't get an event.
Workaround, this *seems* a Qt problem.
The grab fails while the button is down - Qt then also seems
to release the keyboard.
Not sending it to the deco didn't help either - nevertheless it seems
(from the Qt code) as if the button is currently grabbed
(the code is a dumb forward to xcb_grab_pointer)
As a workaround, the patch simply ensures a grab on releasing a button when
the popup is visible.
BUG: 351112
FIXED-IN: 5.5
Implementation goes to AbstractClient, method is no longer virtual.
The X11 specific code is moved to a new virtual protected doMove
method implemented in Client.
Method added so that we can call into TabGroup::updateStates from code
in AbstractClient. Default implementation does nothing, implementation
in Client performs the actuall call.
As a first case added to Client::move in order to be able to move the
implementation to AbstractClient.
The usage was always to trigger repaints on the old and the new
visibleRect. And store the new visibleRect as the future old one.
This is now encapsulated in a dedicated method called
addRepaintDuringGeometryUpdates().
Note: qt5-qpa-hwcomposer-plugin does the vsync in a different way:
it uses a wait condition to truly block in present till the vsync.
Maybe we need to do that as well.
If the size is the same it's basically just a window movement. That's
nothing we need to roundtrip to the client, but can adjust the geometry
change directly.
The quick tiling test is adjusted to test this together with
sendToScreen. Each window is also sent to the next screen to verify the
state doesn't change and geometry is updated.
Note: the flag for quick maximization seems to get lost in this setup.
Very basic: all screens have same size and are ordered from left to
right. It's mostly meant to allow easy test cases with multi-screen.
The quick tiling test demonstrates how it's used.
Last commit removed a setGeometry call that I thought was only used to clear an edge (which we don't want) but was in fact crucial to the next test.
REVIEW: 125635
This is needed to properly restore to a valid geometry after quick
maximizing. Note: this is not yet perfect, actually it should be done
after initial placing, which means we do need a manage method like
Client.
The autotest for quick tiling is extended to cover maximize changes
and cover this case.
Base test verifies the quick tile positions. No maximization or direct
state changes tested yet.
Required to have Toplevel and AbstractClient exported. Otherwise we
cannot use the SignalSpy.
Change required to get methods using TabSynchronizer moved to
AbstractClient. Unfortunately we need to cast to Client when calling
updateStates. It's save as if it's not a Client we
a) don't have a tabGroup in the first place
b) the check if (main == only) will hit and the method returns
Martin Gräßlin