If we don't have a dedicated device identifier we should use the default
mechanismn which involves using the WAYLAND_DISPLAY or WAYLAND_SOCKET env
variable.
We are going to switch to a proper nested approach similar to the
x11 backend. Given that we don't want to run on fullscreen anymore
but just open a nested window.
It's possible that the Deleted gets created before destroying Workspace
and due to the deleteLater outlives Workspace. In that case we may not
call into Workspace as this might crash.
When unloading all effects we should make sure that also the ones
scheduled for loading are canceled. For this a new method clear()
is added to the AbstractEffectLoader and all inheriting classes which
clears the current load queue. For the scripted and plugin effect loader
it should also cancel the future, but that's not yet implemented.
When screen is locked,
- No window other then screenlocker or inputmethods gets rendered
- Only screenlocker gets keyboard events
- Only screenlocker and inputmethods get mouse events
Things that are not secured/tested are :
- Touch events
- Global shortcuts for screenlocker
- Fallback/emergency screen not yet working
REVIEW: 126015
This introduces Toplevel::isLockScreen() and Toplevel::isInputMethod(),
this can be used to allow only lockscreen/inputmethods to get input
events and shown when screen is locked.
There are slight differences between GL_ARB_debug_output and GL_KHR_debug
affecting how it works on GLES. With GL_KHR_debug the context should be
created with a debug flag. With the ARB extension there is no such
requirement. Empirical data (Mali) shows that it doesn't work if the
context is not created with the flag, although the spec seems to allows
it.
So:
* if we have GL_ARB_debug_output we assume it works
* if we only have GL_KHR_debug we check whether the context is created
with debug support (which we don't do yet, but maybe should?)
* on GLES we can only query with version 3.2 (which we don't request yet)
* with anything older we just assume it's not enabled (which is correct
given that we don't enable the debug flag)
REVIEW: 126053
The extensions specify that you are only allwoed to use the robust
functions if the context is robust. Given that we need to query
whether the robust is context and fall back to our workaround if
the context is not robust.
REVIEW: 126051
This gives a better tear down experience as it goes to black instead
of showing outdated screen and also it disables vsync which fixes a
crash on teardown.
WaitForFinished blocks our main thread, but Xwayland wants to talk
to Wayland and blocks as well. So let's ensure events are processed
while terminating Xwayland.
Some effects do X11 calls in their cleanup code through external
libraries (e.g. KSelectionOwner). As we cannot control that we need
to ensure the effects are unloaded prior to destroying the Xwayland
connection.
stupid clients think it's relevant to withdraw other states
when going fullscreen, this means we trigger an
nmaximization animation and when that's done, the
window is fullscreen...
Unfortunately one of the stupid clients is QWidget and also
the window could get other, *legit*, resizes during the
animation, so we cancel it on occasion
BUG: 336467
FIXED-IN: 5.5
REVIEW: 125989
and also hint the proper blocking condition (if turning
off swap control)
The detection vars are global, but the swap control requirement
is not preserved, so the detection must re-occur.
Alternatively (and better) the swap control should be saved
and re-applied, but there's trouble on initial detection
CCBUG: 343184
REVIEW: 125659
The way it was implemented it allowed an X11 unmanaged window to become
a key logger. Basically as soon as there was an unmanaged window it got
all key events. This problem was discovered through the xembed-sni-proxy
which broke key input to all Wayland windows in a Plasma/Wayland session.
With this change Unmanaged windows don't get any key events at all. This
might break some applications as e.g. context menus are using override
redirect windows. A test with Qt applications shows that the menus are
still functional and the events are delivered correctly internally.
If applications show problems with this change, we might need to weaken
the restriction.
For the functions from GL_FOO_robustness we want to resolve it by
ourselves in order to add a custom implementation if it's not available.
Unfortunately once epoxy.h is included this breaks as epoxy defines the
names and so through the preprocessor epoxy always wins.
So we need different names: all functions from robustness get a "kwin"
prefix and the usage is changed everywhere in kwin source code.
REVIEW: 125883
We need to destroy the ClientConnections we create. Also we need
to disconnect our Xwayland error handling before destroying it, otherwise
it would trigger the abort for crashing Xwayland.
During Compositor tear down Xwayland is already destroyed. Thus it
doesn't make sense to try to delete the support properties: either
it freezes in xcb or it crashes because the connection is null.
At the same time we also ensure that the connection internally is
reset to null. Note: the one in kwinglobals.h caches and could cause
use-after-free errors. Any tear-down code must be migrated to
kwinApp()->x11Connection().
ASAN righly complained: we need to delete our Wayland objects before
we destroy the internal client connection. Solved by better setting
parent relationships in the QPA plugin and correctly delete objects
in destroy of internal client connection.
We need to destroy the compositor after Xwayland terminated and after
the internal Wayland connection is destroyed. This means when destroying
the Workspace we may no longer destroy the Compositor at the same time.
Also we need to ensure that other tear down functionality doesn't call
into the no longer existing internal client connection.
With this change kwin doesn't crash when exiting with Wayland and/or
X11 windows still open.
