Summary:
there is no need for createOutput to be static, make it non-static,
this also fixes the build failure introduced in commit
02d3daf28a.
Test Plan: builds
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8430
Summary:
On Wayland we have the sync disabled as it doesn't work properly. This
allows us to also move the sync event handling into the X11 standalone
platform.
The code is slightly refactored: instead of passing the event to each
Client, we search for the matching Client. For that the SyncAlaram struct
is added to public section of Client. The method to handle the sync
doesn't need the event any more and is moved from events.cpp to
client.cpp.
Test Plan:
Run Xephyr+kwin_x11, resized a window and verified through
gdb breakpoint that the sync still works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7942
Summary:
With the new try of all compositor types supported there is an automatic
fallback from OpenGL to XRender/QPainter in case OpenGL setup failed.
So there is no need to invoke a method to do just that.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8364
Summary:
The test DontCrashUseractionsMenu (Waylandonly) found an issue in our
screen handling implementation in the QPA. The code exposed a short time
frame between the dummy screen getting destroyed and the first screen
being added. This could result in a crash of KWin.
There is actually no need to implement Screen on top of Wayland screen.
KWin has all the knowledge, so we can also base this on top of the
Screens API.
Advantages:
* no delays due to Wayland roundtrips
* handle screen getting removed (was a TODO)
* handle resolution changes (was a TODO)
The new implementation has a disadvantage that it destroys and readds
all screens whenever something around the screen changes. This shouldn't
be an issue in practice as it's only for the internal QPA and thus only
affects KWin internal windows which is placed in global coordinates
anyway. If it turns out to be a problem we need to track better the
screen changes - so far those were not tracked at all.
Test Plan: Run a few unit tests which change screens
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8345
Summary:
Allows to share the implementation in a better way and is a requirement
to get the Screen implementation in the QPA plugin to be based on
KWin::Screens instead of KWayland::Output.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8344
Summary:
So far KWin does not know which Compositors the platform actually
supports. This results in KWin happily trying to use the OpenGL
compositor on fbdev or the QPainter compositor on hwcomposer although
that is obviously going to fail as the platform doesn't support this.
By adding a pure virtual method all Platforms can define what they
support. In a later step the Compositor can use this to create an
appropriate scene and also perform proper fallback handling in case the
scene creation fails.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8316
Summary:
The Platform API is extended by a call to create the EffectsHandler. In
X11 standalone Platform a new EffectsHandlerImplX11 is added which
contains the X11 only parts of the EffectsHandler, such as grabbing the
X keyboard and the X11 mouse interception window.
The EffectsHandlerImpl gains some virtual methods for the parts which
are now done in the X11 specific implementation. In return we get rid of
lots of if-else structures checking for the operation mode.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7955
Summary:
In 47343fb we made GBM buffer shared.
What we wanted to do was:
Unbox the shared_pointer<GBMSurface> to give us a GBMSurface* object
Call the gbm_surface*() on that operator
Then cast that to a void* for eglCreatePlatformWindowSurfaceEXT
What we did:
Cast the std::shared_ptr<GBMSurface> to a gbm_surface* then cast that
to void*.
This is just a garbage value and it crashes in Mesa when we do our first
paint.
I've replaced that with an explicit method then we can use shared_ptr's
-> operator rather than get() which does the right thing in a readable
way.
Test Plan:
It crashed after rebasing to master (for Aleix too)
No longer crashes
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8251
Summary:
The gbm_surface is owned by the EglGbmBackend, but it's not the only one
using it. The DrmSurfaceBuffer is also using it and needs it to destroy
the gbm_bo. Now this can become a problem in the following situation:
* a page flip is still pending
* the EglGbmBackend destroys the gbm_surface
-> when the page flip happens the DrmSurfaceBuffer will try to destroy
the gbm_bo and crash as the gbm_surface is no longer valid. This
situation can happen when switching screens or when switching compositing
backend (OpenGL 2 -> OpenGL 3).
To address this problem a class GbmSurface is added which wrapps the
gbm_surface pointer. The EglGbmBackend creates and holds a shared pointer
to the GbmSurface and passes that one to the DrmSurfaceBuffer. So when
cleaning up the gbm_surface only the shared pointer is reset and in case
the DrmSurfaceBuffer still needs it, it can access it without problems.
BUG: 385372
FIXED-IN: 5.11.0
Test Plan: Not yet
Reviewers: #kwin, #plasma, subdiff
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8152
Summary:
Unfortunately a rather large change which required more refactoring than
initially expected. The main problem was that some parts needed to go
into platformsupport so that the platform plugins can link them. Due to
the rather monolithic nature of scene_opengl.h a few changes were
required:
* SceneOpenGL::Texture -> SceneOpenGLTexture
* SceneOpenGL::TexturePrivate -> SceneOpenGLTexturePrivate
* texture based code into dedicated files
* SwapProfiler code into dedicated files
* SwapProfiler only used in x11 variants
* Safety checks for OpenGL scene moved into the new plugin
* signal declared in SceneOpenGL moved to Scene, so that we don't need
to include SceneOpenGL in composite
Test Plan: Nested OpenGL compositor works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7740
Summary:
A dedicated X11EventFilter is added and created from the X11Cursor in
case we have XFixes. This means some more X11 specific code is now only
on X11.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7843
If the system has a virtual device and KWin is run on virtual platform
we can assume the user intended that KWin should use the virtual device
and not a render node of the system.
This might fix the random test failures on build.kde.org (T6546).
Summary:
Only needed for kwin_x11 variant (required for the non-composited
Outline). As that's nowadays in the x11 platform, we can move the
complete XRenderUtils support into the platform. Thus KWin core does
no longer require to link it.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7760
Summary:
After changing the output configuration, the client expects that it is informed
whether or not a new configuration has been applied (or failed). This was ommitted
so far, meaning that clients wouldn't know what happened in kwin.
Since we don't track if a setting failed yet, send the applied() signal regardless.
CCBUG:384733
Test Plan: Verified that the signal arrived in libkscreen after changing scale of an output
Reviewers: graesslin, davidedmundson
Reviewed By: davidedmundson
Subscribers: kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7910
Summary:
In the DRM plugin the cursor is currently is drawn at the native size
given.
Therefore we don't want to scale the icon offset as that leads to it
being drawn every so slightly off-sync.
BUG: 384769
Fixed-in: 5.11.0
Test Plan:
Kate now selects lines based on the middle of the cursor, not the top left.
I'd previously gotten so used to it, I hadn't realised it was actually a bug :/
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7868
No idea why the code compiles on my system. This change is based on the
output on build.kde.org.
CMakeFiles/testXRandRScreens.dir/__/plugins/platforms/x11/standalone/screens_xrandr.cpp.o:
In function `KWin::XRandRScreens::event(xcb_generic_event_t*)':
/home/jenkins/workspace/Plasma kwin kf5-qt5 SUSEQt5.9/plugins/platforms/x11/standalone/screens_xrandr.cpp:210:
undefined reference to `KWin::Options::currentRefreshRate()'
...
Summary:
The code in events.cpp was problematic as it was called in a Wayland
session. So KWin changed outputs, this gets mirrored to XWayland and
then KWin reacted on the XRandR event and might have even changed the
refresh rate due to that - bad idea.
This change moves the code into the already existing X11EventFilter for
XRandR events in XRandRScreens.
Test Plan: Run kwin_x11 in gdb on Xephyr, breakpoint in new code and triggered XRandR event
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7654
Summary:
Several of the subclasses are already derived from QObject.
The main reason is that the class should be moved out of KWin core in
order to move the OpenGL scene into a plugin. As Compositor calls into
the AbstractEglBackend to unbind the wayland display this creates a
problem which is easily solved by turning the AbstractEglBackend into a
QObject and connect to the signal emitted by the Compositor.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7669
Summary:
By moving the functionality into the Platform API we can also implement
support on other platforms which support this in general (e.g. DRM once
Roman's color adjustment patches landed).
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7447
Summary:
Not needed except for X11/non-composited usage, so should be in the
plugin instead of core.
Platform API is extended to create a decoration renderer.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7444
This change is similar to D7232 and moves the scene_qpainter into a
dedicated plugin. Compared to the XRender case it's more complicated as
the platform plugins need to implement a platform specific backend.
The base implementation for this part used to be in scene_qpainter. As
the idea is to completly move it away from KWin core it would be point
less to still have the backend definition in KWin core, but it cannot
be in the scene plugin as otherwise all platforms need to link the
plugin.
To solve this a new platformsupport subdirectory is added which contains
the scene platform backend as a static library. For the OpenGL scene such
a static library will also be required.
Test Plan: SceneQPainter test still passes, nested compositor still works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7259
Summary:
First step for loading the compositor Scenes through plugins. The general
idea is that we currently needlessly pull in all the Scenes although only
one will be used.
E.g. on X11 we pull in QPainter, although they are not compatible. On
Wayland we pull in XRender although they are not compatible.
Furthermore our current Scene creation strategy is not really fault
tolerant and can create situations where we don't get a compositor. E.g
on fbdev backend the default settings won't work as it does not support
OpenGL.
Long term I want to tackle those conceptional problems together:
we try to load all plugins supported by the current platform till we have
a scene which works. Thus on Wayland we don't end up in a situation where
we don't have a working compositor because the configuration is bad.
To make this possible the switch statement in the Scene needs to go and
needs to be replaced by a for loop iterating over all the available
scenes on the platform. If we go there it makes sense to replace it
directly with a plugin based approach.
So this is a change which tackles the problem by first introducing the
plugin loading. The xrender based scene (as it's the most simple one)
is moved into a plugin. It is first tried to find a scene plugin and only
if there is none the existing code is used.
Test Plan: Tested all scenes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7232
Summary:
KWin::displayWidth and KWin::displayHeight are bound to X11 which
doesn't make much sense on X11. In addition KWin internally knows
the overall display dimensions through the Screens singleton class.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D1798
Summary:
Creating the OutlineVisual is moved into the Platform API. The default
implementation creates the composited OutlineVisual. The X11 standalone
platform overrides it and creates the non composited outline in case no
compositing is used.
Test Plan:
Run kwin_x11 with KWIN_COMPOSE=N and KWIN_COMPOSE=X,
non composited outline and composited outline loaded
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7450
