In an own QPA plugin we want to make the OpenGL context sharing with
our compositing context and bypass the windowing system for OpenGL
windows. In order to achieve this we need a surfaceless context.
The AbstractBackend now forwards whether such a context can be created on
the EGLDisplay used by the Compositor.
We don't need to queue the method invokation any more to ensure the
Wayland server connection is flushed since we have the dispatch method
in waylandServer().
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.
This new backend allows to start a kwin_wayland server nested on an
X-Server by using a normal X11 window as output. This allows testing
kwin_wayland without needing to start another Wayland server first.
The behavior is triggered by using new command line arguments:
--windowed
--x11-display=<:0>
With optional --width and --height arguments.
In this mode the WaylandBackend is not created at all.
So far the backend is not fully integrated yet and only the QPainter
backend supports this mode.
being v2+ (right now it says just GPL, which according to GPL itself
means any GPL). Decoration clients will come later.
CCMAIL: kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=742302
"We strongly recommend that all subclasses of QObject use the Q_OBJECT macro regardless of whether they actually use signals, slots and properties or not."
svn path=/trunk/kdebase/kwin/; revision=239883
enabled by default, but will be made configurable soon. There is a known
issue with an incorrect geometry shown with konsole, but that's its fault,
and I'll get to that shortly (xterm does the right thing).
Disclaimer:
If it jams - force it. If it breaks, it probably needed replacing anyway.
svn path=/trunk/kdebase/kwin/; revision=197992