The Egl backend opens the drm device and creates a gbm_device from it.
From that it creates the EGL device. The EGL device outlives the EGL
backend (e.g. for compositor restart). So far the EGL backend destroyed
the gbm_device when going down which mesa did not like at all when a
new context got created on that EGL device.
Thus the ownership of gbm_device is also passed to the Platform so that
the compositor can be restarted.
This makes the TestSceneOpenGL no longer crash during the restart
compositor test.
Screens::init sets up a Qt::QueuedConnection connect from countChanged
to changed. This means that when first setting up the connection a
changed signal will be delivered in the next event cycle. This can mess
with other code. E.g. WaylandServer recreating outputs which can make
Xwayland crash or KWin internally crash.
To solve this problem we just need to make sure to set the output count
to the initial value before performing the init.
Reviewed-By: bshah
Summary:
The egl implementation for the virtual platform tries to use a render
node if available. If there is no render node it looks for a virtual
(kernel driver vgem) device, which unfortunately does not create a
render node in mainline kernel (there are patches in ChromiumOS).
For this the Udev wrapper is extended to search for renderNode devices
and for virtual dri devices.
If either render node or vgem dri device is found, it is tried to be
opened (without logind escalation) and on success a gbm device is
created on it. If any step of this fails the so far default behavior
of default device is tried for creating the EGLDisplay.
All of this is compile optional, so that the virtual platform does not
hard depend on udev and/or gbm.
Test Plan:
Auto tests which need OpenGL executed and verified that they
use the render node or vgem device.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2216
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:
Most platforms like the nested and virtual do not handle the outputs
themselves and WaylandServer announces the Outputs to Wayland.
So far this was static: at startup it got announced once to Wayland
and any changes were not catched.
This change makes WaylandServer listen to changes to the Screens and
sync them to Wayland.
Unfortunately KWin's internal Screen information is not sufficient to
properly synchronize this to Wayland and also Wayland by not supporting
adding/removing modes does not help.
Thus the solution implemented here is to add new outputs reflecting the
changes and then removing the old ones. This creates situations with more
outputs being present than actually there, but prevents that there are
no outputs at all.
Test Plan: Auto test added which verifies this for the virtual platform
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2233
Summary:
No need to delegate the painting of the software cursor into the backend.
The core has enough information to perform the rendering itself.
This change means less code duplication and all platforms which might use
a software cursor in QPainter compositor gain support for it without any
further adjustments.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2028
Summary:
Platform::setSoftWareCursor creates connections to the Cursor in order
to trigger repaints whenever the cursor position changes. The Cursor is
created before Platform::init is called, but after the Platform is
created. Thus the call needs to happen in init, otherwise the cursor
is not rendered correctly.
BUG: 356328
FIXED-IN: 5.7.0
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2025
A signal is added to the VirtualBackend to change all screen geometries.
This can be used from auto tests to change the screens. But it's not yet
correctly reflected in other areas. E.g. not forwarded to Wayland Output,
etc.
Summary:
Source code reorganization:
The base class AbstractBackend got renamed to Platform, thus the
"backends" are "platforms" now. As they are plugins they should go
together with other KWin plugins which are nowadays in the folder
plugins.
So new location is plugins/platforms/
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1353
