By default the InputRedirectionCursor is created and only the X11
standalone platform creates the X11 specific cursor.
This is a preparation step for moving the X11 specific cursor
implementation into the x11standalone platform plugin.
Summary:
So far SharingPlatformContext was only used if the OpenGL context
supports EGL_KHR_surfaceless_context. If not supported, KWin tried to
create a context through the Wayland API. Unfortunately on hwcomposer
platform this results in a crash as libhybris only supports the init
of EGLDisplay for one native platform.
This change tries to also use the SharingPlatformContext if there is
an OpenGL context in general. It reuses the native EGLSurface created
for the compositing scene and makes its own OpenGL context current on
that surface, too. As KWin creates an FBO, it never renders to it, so
it shouldn't matter at all.
In order to prevent EGL_BAD_MATCH errors when making Qt's OpenGL context
current also the EGLConfig from the scene is used to create the context.
Test Plan: Tested on Nexus5 with qtvirtualkeyboard in KWin
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2231
Summary:
KWin needs to support restarting the OpenGL compositor in case of a
graphics reset event.
On Wayland the tricky part is that the applications should not notice
this. Most importantly KWin cannot just destroy the EGLDisplay and create
a new one. But this is how a restart works: the complete compositor gets
torn down and recreated - including the EGLDisplay.
This change moves ownership of the EGLDisplay to the Platform.
The AbstractEglBackend subclasses query the Platform whether there is
already an EGLDisplay. Only if there is no EGLDisplay the EGLDisplay is
created and only if no EGLDisplay is registered with Wayland the bind
is performed.
Another change is regarding the destruction: the AbstractEglDisplay does
no longer unbind the Wayland display and does no longer destroy the
EGLDisplay. The EGLDisplay is destroyed by the Platform - so very late
on application exit. The Wayland display is unbound when the Compositor
terminates.
Test Plan:
Limited testing with the added auto-test. This one needs to
be extended to fully verify that OpenGL applications continue to work.
But this requires build.kde.org to support OpenGL on Wayland.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2202
Summary:
When the cursor changes the old and the new cursor geometry needs to
be repainted. Also when the cursor image changes a repaint of old and
new geometry is needed.
To support this the current cursor geometry is tracked instead of just
the cursor position. From the cursor position it's not possible to get
to the cursor geometry once the cursor image or hotspot changes, thus
the complete geometry needs tracking.
CCBUG: 356328
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2023
Summary:
A new virtual method createOpenGLSafePoint is added to Platform.
This is invoked through the Compositor with a PreInit and a PostInit
argument pre and post creating the SceneOpenGL.
The Platform plugin can implement this and use it for detecting whether
creating the OpenGL compositor on this platform crashed in the past.
Thus it's the base for the openGLIsBroken platform check.
The x11 standalone plugin is the first to implement this functionality
using the previous code which was designed for X11.
This also means that a crash of the OpenGL compositor during init on
Wayland won't result in OpenGL being disabled.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1582
Summary:
CompositingPrefs is only relevant for X11 standalone. It had some
"hacks" to make it not block Compositing on Wayland. Thus it was in
its current form not really useful.
Now all the functionality is provided through Platform with a default
implementation which is sensible for Wayland platforms.
The X11 standalone platform implements the new methods with the
Wayland checks removed.
In addition all calls to CompositingPrefs now go through the platform
directly and CompositingPrefs is completely dropped.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1576
Summary:
This change reduces the windowing system specific code pathes. Instead
of checking whether we are on X11 or Wayland to decide whether
compositing is required, we just ask the Platform.
The default is true, only x11 standalone allows to not require
compositing.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1575
Removes a diversion between X11 and Wayland. The base class Platform
creates an instance of class Edge with plugin implementations being
able to create a different type.
The X11StandalonePlugin does that and creates a WindowBasedEdge. For
this the implementation of WindowBasedEdge is moved from screenedges
into the plugin.
Unfortunately an ifdef is needed to make the screenedge test still
work as expected. This should be improved in future, e.g. have a good
way to load the platform plugin from the tests.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1419
Summary:
This is the first change in a refactoring series. The aim is to:
* rename AbstractBackend to Platform
* move backends/ to plugins/platforms/
* don't bind platforms to Wayland only
* provide a platform plugin for "normal" X11
* share more code between X11 and Wayland
This change moves the platform/backend from waylandServer to Application.
The init of the plugin happens directly in the Application from the
KPluginMetaData. There is no need to externally init it and set the
parent.
WaylandServer::backend() currently just delegates to
kwinApp()->platform(), the idea is to drop this method completely.
The test infrastructure is also adjusted to this change.
Test Plan: kwin_wayland still works, all tests pass
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1331
This patch implements read access to the outputmanagement interface in
kwin_wayland's drm backend.
- outputdevices are created in DrmOutput, just like the wl_outputs
- wayland_server implements the outputmanagement interface and
- passes the changesets down into the backend
This means that the interface is announced, independently of the DRM
backend, but the actual outputs are currently only there if the DRM
backend is used.
The changes are not applied (passed into the kernel's drm interface
yet). This is obviously work-in-progress, so it's incomplete. Since it
allows us to run kwin[master] with the libkscreen KWayland backend, it's
a significant step allowing testing and further development.
Reviewed-by: Martin Gräßlin
So far updating the cursor image was not really defined. It was possible
to use the cursor image from the wayland seat or have a custom set cursor
image. But there are no rules in place to decide which one to use when.
With this change a dedicated CursorImage class is introduced which tracks
the cursor image changes on the seat, on the decoration, in the effects
and so on. In addition it tracks which is the current source for the
image, that is whether e.g. the cursor from the seat or from effects
override should be used. Whenever the cursor image changes a signal is
emitted, which is connected to the signal in AbstractBackend.
Based on that the backends can directly show the image. The existing
code in the backends to install a cursor shape or to install the cursor
from the server is completely dropped. For the backend it's irrelevant
from where the image comes from.
A new feature added is that the cursor image is marked as rendered. This
is then passed on to the frame rendered in the Surface and thus animated
cursors are finally working. Unfortunately animated cursors are broken in
Qt (see https://bugreports.qt.io/browse/QTBUG-48181 ).
For this AbstractBackend has a new virtual screenGeometries() method
which returns a QVector<QRect>. By default it's just one QRect at 0/0
with the size of the one screenSize().
X11, Wayland, virtual, Framebuffer and hwcomposer have extremely
similar screens implementations. Let's add a base implementation
for them as a BasicScreens.
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
Martin Gräßlin
Sebastian Kügler
Martin Gräßlin
Luboš Luňák
Laurent Montel
Nadeem Hasan
Karol Szwed
Dirk Mueller