The last stage for window rendering is triggered by
Scene::finalDrawWindow. Adding a security check there if screen is locked
no non-lock screen window should be rendered.
Unfortunately this method is virtual so the check needs to be done in the
base and all implementing child methods (currently only OpenGL).
REVIEW: 126144
Most of those effects didn't need special screen locking handling on
X11 as they prevented screen locking. On Wayland though, we don't
want the lock screen shown on a cube.
REVIEW: 126122
the stackingOrderChanged() signal came before the window turned an effect window
usually this is no problem as the change shall not be caught anyway, but
the window may have changed its stack position
BUG: 353745
FIXED-IN: 5.5
REVIEW: 126134
window wasn't correctly represented in
zoom, present windows and desktop grid effects
on the fly code streamlining:
- logout and above windows were handled equally in different code paths
- windows were painted on 0 opacity instead of just aborting the paint
local semi-paintdata because PaintData isn't assignable
(const dptr, I think) and we're post freeze.
BUG: 355539
FIXED-IN: 5.5
REVIEW: 126133
This is similar to the applications to start. That is the value of the
command line argument is interpreted as a command to start.
The difference is that when this application exits, KWin will also quit.
The argument is so to say interpreted as a session.
Reviewed-By: Bhushan Shah
We need to update the pointer position, also if the screen is locked.
Otherwise the pointer doesn't move on the locked screen with libinput.
In addition we need to use the m_globalPointer for finding the correct
lock screen window as updatePointerWindow also does sanity checking on
the coordinates.
Also we need to introduce security checks where we use the signal.
REVIEW: 126103
Ensures that all Wayland objects are destroyed and the cleanup handling
is performed before tearing down the Compositor. This fixes for example
a crash if a Surface with a Shadow is still around at tear down.
Eg. if a window is closed while "timeline.currentValue() == 0",
slotWindowClosed() will shortcut exit and not be removed from the
managers, thus dangle around forever.
Maybe there're other ways for a window to be deleted w/o
the closed slot being entered.
CCBUG: 339970
REVIEW: 126034
This allows to pin the focus on certain window as well
as to more easily give it away on others (typically launchers)
BUG: 185060
CCBUG: 337798
FIXED-IN: 5.5
REVIEW: 126059
it seems we can "loose" focus reversions when the closing client hold a grab
(eg. the screenlocker or some games) thus we catch the typical pattern
(though we don't want the focus on the root anyway)
BUG: 348935
FIXED-IN: 5.5
REVIEW: 126033
We use the hw module's backlight and set the color to either 0
or FF depending on whetehr we want to have the screen on or off.
This turns the backlight off properly. It is bound to the toggleBlank
functionality so that we always turn on/off the backlight depending
on whether our compositor is on or off.
In addition we listen to key release events on the power button to
toggle the state.
REVIEW: 126083
X11, Wayland, virtual, Framebuffer and hwcomposer have extremely
similar screens implementations. Let's add a base implementation
for them as a BasicScreens.
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.
