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
At least the framebuffer backend does not have support for an overlay
cursor. Thus the cursor needs to be rendered by the scene. This change
allows a backend to set that it needs a software cursor which triggers
tracking in the AbstractBackend. A repaint for the old cursor region is
triggered whenever the cursor pos changes.
So far only the QPainter/framebuffer scene is adjusted to render the
software cursor. This is done after rendering a frame with the up to
date cursor position.
There is one problem, though: the KWin internal cursors don't work
as we need to get it from the theme. Using wayland-cursor doesn't help
as it gives us a (client) wl_buffer* and we cannot read the memory back.
A new Singleton VirtualTerminal is added. It interacts with Logind to
get the VTNr to take over. To get the signal to release and acquire the
VT we use a signalfd with a QSocketNotifier to monitor for signals. The
used signals must be blocked for all threads prior to startup otherwise
they are delivered to secondary threads causing issues.
When our session gets inactive libinput loses all devices, thus our
Seat would not have neither keyboard, pointer nor touch. To not confuse
all connected clients we block updates while libinput is suspended. After
resume we check whether something actually changed and emit the
corresponding signals to ensure everything is up to date.
The AbstractBackend provides a virtual method to create the Screens.
A concrete backend can implement this method to create the backend
specific Screens instance.
This removes the casting logic from Screens::create.
Adapt to API changes introduced by b62e8888cd39301e00ad98dfe791fa66676408fb.
It adds DecoratedClient::color(group, role) for getting colors that are
not included in QPalette. Breeze used to read these colors from
kdeglobals, breaking per window color schemes. KWin now handles reading
these colors along with QPalette loading with DecorationPalette.
REVIEW: 122883
This adds "Quick Tile Window to the Top" and "Quick Title Window to the Bottom" shortcuts. These are
useful for those using displays that are in portrait orientation.
CCBUG: 310005
REVIEW: 123153
We handle device added/remove to monitor whether we have keyboard,
pointer and touch devices and emit signals. Those are used to update
the SeatInferface from InputRedirection.
InputRedirection gains basic support for processing touch events which
are delegated to KWayland::Server.
WaylandBackend accepts touch events from KWayland::Client and delegates
them to the InputRedirection.
* Vendor name
* Vendor release
* Protocol version
* All Extensions used by KWin (name, present and version)
Need for this recognized due to a bug related to no xrandr present.
CCBUG: 345448
We released three versions with it being disabled and it doesn't look
like it will come back any time soon. Also the build was broken at least
since the repo splitting due to incorrect path to dbus xml.
In addition the connection to decorations got dropped already with the
change to kdecoration2. Which means it anyway needs large adjustements
to get the code working again.
Overall it doesn't look like it makes lots of sense to keep the code
around for someone working on it in future. If that happens this change
can be reverted.
It didn't get adjusted for Xwayland, so probably doesn't work any more.
The rendering mode seems not very useful if honest and it's better to
use the QPainter backend.
Both Wayland and X11 backend are bound to the --windowed flag. Which
one to create is decided whether DISPLAY or WAYLAND_DISPLAY env variables
are set with Wayland having precedence over X11. Passing the display as
command line argument overwrites the env variable and takes further
precedence. E.g. if WAYLAND_DISPLAY is exported and --x11-display
argument is provided, it will create X11 backend. Similarly there is now
a --wayland-display command line argument.
If no backend got created, kwin_wayland will exit.
The singleton variant of WaylandBackend is adjusted to take the display
as argument and pass it to the Connection.
When a sync object is deleted, the fence it is connected to must already
be signalled, or the driver will busy-wait forever.
Signal fences before deleting syncs to avoid this.
BUG: 343551
FIXED-IN: 5.3
REVIEW: 123090