Replaces the functionality of the WaylandBackend and makes it available
to all backends by providing the functionality directly in
AbstractBackend. By default a backend is not ready and the implementation
must call setReady(true) to indicate that setup has finished
successfully. The compositor won't start till the backend indicates that
it is ready.
Creates two buffers with the size queried through the drm capabilities.
The actual cursor image is retrieved using the software cursor
functionality from the AbstractBackend and rendered into the shared
memory buffer. The the buffer is set as the new cursor image and the
rendering buffer for the cursor is swapped.
The position is updated whenever the cursor image changes or the mouse
position changes.
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.
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.
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.
Martin Gräßlin