We announce support for it and depending on whether we have a plugin
or not set the default mode to Server or None.
When a decoration interface is created it gets installed on the
ShellClient. But there it isn't properly used yet as we don't have
support for decorations in ShellClient yet.
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.
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.
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.
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.
This allows to check if specific ShellClient is from LockScreen or not,
as well as this adds method to verify if ShellClient is from input
method like maliit.
Now that KWin knows about which window is from Screenlocker it can apply
various security restrictions like no other window then greeter is on
top of it.
Reviewed-By: Martin Gräßlin
This introduces --lockscreen option in kwin_wayland which when used will
lock screen immediately. Also dependency to newly created kscreenlocker
repo is introduced.
REVIEW: 125954
Allows to interact with the Registry for the internal connection in
other parts of KWin and makes it possible to create more than just the
ShmPool for this Registry.
The creation of PlasmaWindowInterface is moved from WaylandServer into
AbstractClient. This allows the sub classes to better control when to
create/destroy the Client.
For creation it's bound to becoming visible - that is Windows which are
only created but never shown are not announced at all.
For Client it's destroyed with the normal tear-down of a Client, for
ShellClient it's destroyed on unmapped (which also means a new one
will be created again in case of another mapping of the surface).
As a side effect, this works around the problem that ShellClients do not
yet get destroyed for QtWayland's menus (needs further investigation).
So far this only allows to trigger show desktop functionality and exports
the state.
In future this should be restricted to just one dedicated desktop shell
process.
Input-method servers, like maliit, need to be known to KWin since KWin
needs to know about virtual keyboards. Virtual keyboards should be shown
as OSD layers, and they are one of the types of windows that actually
should be showable when the lock screen is active.
kwin_wayland --inputmethod /path/to/your/input-server
tries to start the input server. The input-server's window never gets
keyboard focus and is shown on top of all windows except for KWin's
internal clients.
The PlasmaShell interface allows to create a PlasmaShellSurface for a
given Surface. Through this interface the Surface can request:
* a specific position
* a window type
So far only the window types Normal, Panel and Desktop are supported
which is a sufficient subset for getting plasmashell to work.
In future there should be security checks so that only the dedicated
desktop shell can bind these interfaces.
Adds all internal ShellClients into a dedicated list. This ensures that
we don't perform "normal" window management on them.
In addition we add them to the top of the stacking order. This restores
behavior as it is on X11: internal windows are using BypassWindowManagerHint
and thus on top of everything.
The internal used window Id consists of two parts identifiying the
Client and one identifying the Surface. That is the first 16 bits
are set to the ClientConnection, the last 16 bits are taken from
the Surface id. As the Surface id is 32 bits, but we only use 16 bits
there is a chance of overlap. So this might need some improvement.
If the ShellClient got created for a Qt internal window, we try to
find the QWindow and if we get one, we use the geometry directly as
it got set by KWin in the first place.
Also a windowId() is added to ShellClient which can be used by the
effect system to find an EffectWindow. If it's an internal QWindow
we just use that window id. For other clients we still need some
smart solution.
QtWayland and mesa might dead lock KWin if we start rendering a QWindow
before Qt/Mesa got the last frame callback. They perform blocking wayland
event reading on the main gui thread which makes it impossible for KWin
to do the compositing and send the callback.
To workaround this problem we fake a frameRendered directly after each
damage event for a Qt internal window. Unfortunately this is not yet
completely sufficient, thus we also need to ensure that the wayland
events are processed before any events are processed which would cause
a repaint and block. Thus we first flush QtWayland's wl_display and then
our Server connection. If there were any damage events we can be sure
that the frameRendered is sent before Qt attempts to render.
QtWayland only creates popup windows if they have a parent QWindow or
if there is any window which had input. It's not enough to fake an
enter, it needs to be either a pointer button press or key press.
As KWin's useraction menu doesn't have a parent and we most likely
never send a pointer press to any QWindow it doesn't get shown. To
circumvent this we create a dummy window and fake a button press/release
on the window. After that Qt is tricked into believing there's a parent
window and shows the popup.
Faking the input is only done with at least Qt 5.5 as QtWayland crashes
on pointer event without a keymap being installed. As KWin does not yet
send keymaps we better disable the dangerous code path. With Qt 5.5 the
crash condition is fixed.
The ShellClient is a Toplevel subclass for a
KWayland::Server::ShellSurfaceInterface. It gets created when a new
ShellSurfaceInterface is created and destoryed when it gets unmapped.
So far the usage is still rather limited. The ShellClient is opened
at position (0/0). While it's possible to pass pointer events to it,
it's not yet possible to activate it, so no keyboard focus.
Getting the cursor image from the cursor theme is unfortunately not
straight forward. We have three different libraries and all have
drawbacks:
* XCursor - we just kicked it out
* xcb-util/cursor - only provides xcb_cursor_t, so a dependency on X
* wayland-cursor - only a client side API
The picked solution is using wayland-cursor. It provides the cursor in a
wl_buffer. Unfortunately the client side API does not easily allow to
a) read it back
b) init without a wl_shm_pool
Thus we need to work this around:
* create an internal connection
* get a ShmPool on it
* init WaylandCursorTheme with this ShmPool
* get the cursor wl_buffer from the theme
* trigger a roundtrip
* get the corresponding BufferInterface for the buffer
* set the content as the software cursor
The AbstractBackend registers itself in the WaylandServer allowing
external users to easily get to the backend and not needing to test
manually which backend is used.
WaylandServer allows to create a ClientConnection which is intended for
QtWayland. This allows us to easily identify our "own" surfaces. The
created file descriptor is set as env variable WAYLAND_SOCKET prior to
creating the Application. Wayland will unset it after connecting, so we
don't need to unset it. This removes the hack of setting and resetting
the WAYLAND_DISPLAY environment variable.
Creates a socketpair in WaylandServer and creates a ClientConnection for
Xwayland. The created file descriptor is passed to Xwayland through the
WAYLAND_SOCKET env variable.
The WaylandServer is at the moment only used to support starting an
Xwayland. It does not support Wayland clients yet, so don't get
excited.
For Xwayland it's using the trick of creating the Display before the
QApplication is created with manual event dispatching.
