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:
The position of the output being resized was adjusted instead of only
the other outputs.
Test Plan: Resized windows, verified xrandr
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2235
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:
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:
When sharing surface and config used by the compositor scene with
QtQuick's OpenGL context an RGBA surface makes Qt way more happy.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2232
Summary:
With this change the Wayland platform plugin uses the XdgShell to
create the window if available. This allows to close the window and
thus quit the nested kwin_wayland properly.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2201
Some error conditions did not have a warning, so all we got is
"Could not initialize rendering context". Which is not helpful to
figure out what is going wrong.
For virtual machines with Cirrus device the drmModeAddFB fails. So
far there was no error message at all, we only saw it failed.
With this change the drmModeAddFB is checked for error and a warning
is shown. Also further debug messages are added for other cases where
things can fail.
Reviewed-By: Eike Hein
Summary:
So far if the framebuffer platform run into an error on initialization
it did not continue and caused the system to freeze. With this change
it properly emits the initFailed signal in all error conditions which
causes kwin_wayland to terminate. This is a much better situation than
just staying in a running, but frozen state.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2149
Summary:
If it's not possible to create a buffer to blank the output, KWin won't
be able to render to the output. In that case the output should not be
added to the list of outputs.
To support this DrmOutput::blank and DrmOutput::init return bool to
indicate whether they succeeded. DrmBackend handles this situation and
doesn't add the output to the list of outputs if init failed.
If after init there are no outputs KWin is in a state where it won't
be functional. Thus the platform emits the initFailed signal to
terminate.
BUG: 365242
FIXED-IN: 5.7.2
Test Plan: No hardware to reproduce the condition
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2135
Summary:
If the format of the framebuffer is BGR we cannot create an RGB image
format from it - the rendering is incorrect. Unfortunately QImage does
not support a BGR image format.
To solve this problem we still use an RGB image format but on rendering
the front buffer is rgbSwapped to convert the RGB image to a BGR image.
BUG: 365243
FIXED-IN: 5.7.2
Test Plan: Tested on a neon kvm
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2134
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:
So far the drm platform did not verify whether creating and mapping a
DrmBuffer for a cursor works. This could result in a crash in the worst
case.
This change verfies whether mapping the two cursor buffers works, if
not software cursor is enabled. The code is adjusted to ensure that
none of the cursor buffers is accessed in case software cursor are
enabled.
Please note that right now the drm platform's rendering does not
support software cursors. Thus currently this change results in no
cursor at all. This will be addressed by following patches.
BUG: 364740
FIXED-IN: 5.7
Test Plan:
Verfied that it properly falls back to software cursor,
but could not verify that the crash is actually fixed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2026
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
Summary:
When we get a configuration request, we also need to update the global
position on the DrmOutput, otherwise Wayland will know about the new
position, but KWin internally does not.
In addition we also need to trigger the changed signal on KWin::Screens,
so that internally code can react on the change.
With this change configuring layout of connected screens in KScreen
does work also in KWin.
Reviewers: #kwin, #plasma_on_wayland, sebas
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1858
Summary:
To use eglCreateImageKhr for an X11 pixmap we need an EGLDisplay created
for the same XDisplay as the X11 pixmap. This means if we created an
EGLDisplay for a GBM device, we are not allowed to load a texture from
the X11 pixmap and can result in a crash in the driver.
Similar in the nested X11 setup the EGLDisplay is created for the
rendering window, but the X11 pixmaps are from the Xwayland server KWin
started. They don't belong to the same windowing system.
This change addresses this problem by moving the loading of X11 pixmaps
from AbstractEglTexture to EglTexture of the EglOnX11Backend. Thus for
any usage on a non X11 platform we cannot hit the code path any more.
In addition the nested X11 platform can indicate that it doesn't support
it and thus also doesn't go through the code path.
Test Plan: Tested standalone and nested X11 platform
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1857
We didn't check whether creating the QPlatfromInputContext worked and
accessed the m_inputContext unconditionally which obviously crashed.
Now the connects related to QInputMethods are not setup if we failed
to create the QPlatfromInputContext.
Reviewed-By: bshah
Summary:
The idea is to have KWin provide a virtual keyboard. To support this
KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
QPA plugin loads it.
KWin has a new class VirtualKeyboard which acts as the focus object and
the "proxy" for input methods. The QPA plugin ensures that this is the
focusObject, so that all input method related events are sent to this
class. From there it will be possible to delegate to other applications
through the Wayland interfaces.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1638
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:
When the pointer device gets plugged off the cursor is hidden, when
a pointer device gets plugged in the cursor is shown again.
This allows to easily turn a tablet into a proper system by showing
the cursor only when it makes sense.
Test Plan: Tested on exopc with external mouse
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1682
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:
So far the OpenGL is unsafe check functionality in Compositor disabled
OpenGL compositing if glx is not available and we are in standalone X11
mode.
This is technically no longer correct for quite some time. Just because
GLX is not available doesn't mean that OpenGL doesn't work. We have an
EGL backend. So let's try to use that if glx is not available.
This change removes the check completely from Compositor. Instead the
standalone x11 plugin checks whether glx is available prior to createing
the glx backend. If not available it falls through to the egl backend.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1581
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
Summary:
If a user specifies the QT_WAYLAND_FORCE_DPI env variable, KWin uses
it to force a logicalDPI, just like QtWayland.
Test Plan: Normally sized window decorations
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1605
Summary: This seems to just have been forgotten here.
Test Plan: Builds
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1499
The hwcomposer plugin doesn't need it. It was only created for the
need of libinput relying on it. As libinput doesn't need it any more,
hwcomposer doesn't need to integrate with VirtualTerminal.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1444
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:
KWin's plugins are now all in a plugins subdirectory. This is a good
argument to also move the window decoration plugins there. The name
clients was not really good anyway and makes it difficult for people
not familiar with the code base to find it. Having it under plugins
is the more expectable location.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1414
Summary:
The EglOnXBackend is no longer needed in the core. It's only needed by
the two x11 platform plugins. To best share it, it's moved into a common
directory and compiled into a static library which in turn is linked by
the two plugins.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1413
Summary:
It's only needed by the standalone x11 variant. This allows us to
simplify the creation of the OpenGLBackend: it's created by the
platform plugin - we don't need custom complex logic.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1392
