Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
Summary:
Depending on whether the underlying platform supports offscreen surfaces,
QOffscreenSurface may create an invisible QWindow. In our case that's the
case, for each offscreen surface a native window is created. This may
lead to some funky results related to window decorations, see bug 407612.
There are several ways to implement offscreen surfaces - either use pbuffers
or utilize a surfaceless context extension. For the sake of simplicity
this change sticks with pbuffers, but it's a good idea to support both
methods.
CCBUG: 407612
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, alexeymin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22150
Summary:
Using the Wayland protocol for OpenGL is no longer used or useful. KWin
internal windows only use OpenGL through QtQuick. We either have the
sharing context (KWin uses OpenGL for compositing) or we have the
QPainter compositor which also turns QtQuick to use software renderer.
Thus a situation where the Wayland platform context is useful doesn't
exist any more. Removing it helps getting the QPA plugin Wayland free.
Test Plan:
Run nested KWin triggering Outline once with OpenGL and once
with QPainter compositor.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19012
Summary: Required for kwin_wayland to find it's own plugin.
Test Plan: My kwin_wayland was crashing and gdb showed wrong plugin being loaded
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19010
Summary:
This is a preparation step to move this to ECM (or possibly CMake),
which makes sense now that qtbase is using this too (for Qt6).
Reviewers: #build_system, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17547
Summary: This file was required for Qt 5.8. We require 5.11 as minimum version.
Test Plan: Grepped for the file being used in other cmake code, rebuilt KWin without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16654
This makes QCursor::pos and QCursor::setPos function correctly. KWin
actually wouldn't need it as KWin has the KWin::Cursor replacement, but
it allows Qt internal API to have it function correctly and also the
zoom effect does use QCursor::setPos.
This is needed to make KWin build-able on non-Linux, but is actually
only a workaround. The dependency should also be available on non-Linux.
This disables the EGL integration in the Wayland backend (QPainter still
available) and the EGL fallback in the qpa plugin (preferred context
sharing still available, but requires a working OpenGL Scene).
REVIEW: 126202
This introduces an own QPA plugin for KWin. QtWayland's plugin is not
a good solution for KWin as QtWayland is meant for Wayland clients and
not for a Wayland server. Given that it makes more sense to have a very
minimal QPA plugin which supports the use cases we actually have.
With our own QPA plugin we should be able to improve the following
areas:
* no need to create Wayland server before QApplication
* Qt::BypassWindowManagerHint can be supported
* no workaround for creating OpenGL context in main thread
* sharing OpenGL context with Qt
* OpenGL context for Qt on libhybris backend
The plugin supports so far the following features:
* creating a QPlatformWindow using KWayland::Client (ShellSurface)
* creating a QPlatformBackingStore using a ShmPool
* creating a QPlatformOpenGLContext with Wayland::EGL
* or creating a QPlatformOpenGLContext which shares with KWin's scene
* creating a QPlatformScreen for each KWayland::Client::Output
* QPlatformNativeInterface compatible to QtWayland
