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:
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:
So far window rule specific functionality was only implemented in Client
and in ShellClient there was only a dummy implementation. This change
moves the client_rules member variable from Client to AbstractClient.
Areas which would not compile anymore are adjusted.
This is a first step to get window rule support for Wayland windows.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8090
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
With the new Wayland only mode we start too fast and it can happen that
the initWithWorkspace is called before the client connection is fully
setup. This would result in a crash in the idletime plugin once it tries
to create a seat.
To prevent this problem the code is split out into a dedicated method
and only invoked if all interfaces have been announced on the internal
connection.
BUG: 385397
FIXED-IN: 5.11.1
guix (like nix) used a separate prefix for each package. Thus the header
files for
qtdeclarative are in /gnu/store/…-qtdeclarative-5.9.1/include/qt5/ while
the ones for
qtbase are in /gnu/store/…-base-5.9.1/include/qt5/. This means that
*each* dependency's include directory must be specified. This is in
contrast to a "normal" Unix-system, where all includes end up in
/usr/include/qt5 and missing to defined some include-dependencies does
often not raise an error.
Differential Revision: https://phabricator.kde.org/D8112
Summary:
The load method and updateLayout ensure the virtual desktop information
is synced to RootInfo and thus to other X11 applications. Thus we need
to call it again when initing X11.
BUG: 385260
Test Plan: Not tested as I'm on Wayland, but given the changes it's obvious.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8086
It's confusing to search for usages of ClientList::Iterator and then
discover it's all just commented out. Before falling another time over
it: let's remove it.
Summary:
So far the method only operated on X11 clients. So when the last desktop
got removed Wayland clients were still on it. As the auto test showed:
this results in a crash.
Credits go to code coverage as it showed that area as red, which made me
look on it and realize this must be broken.
Test Plan: New test case added
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8082
The FreeBSD build is currently failing with:
kwingltexture_p.h:83:23: error: no function named 'cleanupGL' with type
'void ()' was found in the specified scope
friend void KWin::cleanupGL();
This change hopefully addresses the problem.
The connect to Compositor::sceneCreated must be disconnected again,
otherwise a restart of the Compositor results in Workspace being created
again.
Thanks to our autotests for finding this problem!
The integrationTest function takes a new optional argument whether the
test supports a Wayland Only mode. If that's the case the test is
compiled twice, once (as always) as "foo" with XWayland support and
once as "foo_waylandonly" without XWayland support.
This way we can ensure that our code always supports both modes. The
tests found multiple issues. At the moment fast running tests are
sporadically crashing on tear down. This needs further investigation.
With the new Wayland only mode we start too fast and it can happen that
the initWithWorkspace is called before the client connection is fully
setup. This would result in a crash in the idletime plugin once it tries
to create a seat.
To prevent this problem the code is split out into a dedicated method
and only invoked if all interfaces have been announced on the internal
connection.
The operation mode X11 and Wayland is no longer supported and probably
hasn't been supported for the last few years. But now there is the
possibility to run Wayland only, so introduce this as a dedicated new
OperationMode.
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:
Just continues with the steps without starting XWayland.
This does not yet fully support kwin_wayland without X11, it currently
still crashes on teardown.
Test Plan: kwin_wayland --socket=wayland-1 kwrite (note the missing --xwayland)
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7924
Summary:
This is required to start KWin/Wayland without XWayland support or
delayed XWayland support.
Test Plan: Run kwin_x11 in a nested Xephyr
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7897
Summary:
The xStackingOrder unlike indicated by it's name is relevant for both
X11 and Wayland and contains the stacking order of the windows used for
compositing.
So far it was determined whether it needs to be recreated based on
whether an xcb query is pending. This change introduces a boolean
variable to check whether the stacking order is dirty and guards the X11
specific code to only be run if we have an X11 connection.
This is to my current knowledge the last remaining issue where X11 was
used during the normal Wayland operation mode. Now it should be possible
to re-order the Workspace startup [1] and try to run kwin_wayland without
Wayland support.
[1] Workspace::Workspace and Workspace::init is still highly X11
specific and needs to be split into X11 only and general parts.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7856
Summary:
If an Effect has replaced the TabBox and wants to react on mouse events
the EffectsHandlerImpl also has an X11Filter, so we only need to make
sure the events go to that filter.
Motion: TabBox did not filter out, so events will go to the Effects
filter.
Press/Release: TabBox should not operate if Effects take the events.
The events are filtered out by Effects if there is a grab, so just
check for that and go out. Effects will take care.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7846
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
Summary:
Splitting out the handling from events.cpp and moves it into a
dedicated class created together with RootInfo.
Test Plan:
Test case for NET window move which goes through this
code path still passes.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7808
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:
The base idea behind this change is to keep the system responsive no
matter what other processes do. All input and rendering needs to go
through the windowing system, so keeping it responsive is important.
Currently KWin competes with all other processes for resources and this
can render the system unusable. Consider some processes running amok. In
this case the user might not be able to easily close the applications as
KWin does not get the cpu time to perform the input tasks requested by
the user.
Or in the case of playing a demanding game it is important that KWin
gets scheduled to forward the pointer input events. The user doesn't
want that the game (or another process) wins against the windowing
sytem.
The disadvantage is that KWin always wins against other processes with
real time scheduling. This could result in KWin running amok stalling
the system. On the other hand this is no change to the current situation
as if KWin runs amok the sytem is unusable.
The change uses libcap to set CAP_SYS_NICE on kwin_wayland executable.
KWin_wayland on start sets the scheduling policy to SCHED_RR with the
lowest possible priority. Thus any other SCHED_RR process will win
against KWin. So real time processes are not affected by this change!
After adjusting the scheduling (which requires CAP_SYS_NICE) KWin drops
this capability again.
Test Plan:
Verified that KWin adjusts the scheduler, that it is not passed
to child processes, that the capability gets dropped and not passed to
child processes.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7757
Summary:
Instead of calling reconfigure() on screen size changes, which deletes
and recreates the effect, we can just update the one texture that's mapped to
the screen size.
---
From the wayland commit.
>What surprises me is that BlurManager recreates for Output changes.
>That sounds like a bug in KWin (or an area which could be improved).
I had thought the same and wrote this (though wanted to have kwayland fixed first)
Test Plan:
Logged in and out (my screen resizes on startup due to scaling)
Tested on my X machine by turning a screen off. Nothing broke, plasma
panels looked the same.
Note: Eike tried this patch last week and claimed kwin still crashed.
We don't have a backtrace so it could have been something unrelated,
applied wrong or that he was deliberately lying to wind me up.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7877
Summary:
Similar to the Blur patch. Arguably rven less reason as this doesn't
have a texture the size of the workspace.
We don't need to delete and recreate the entire effect every time the
screen changes; This deletes the wayland global which causes quite a bit
of extra work for the clients.
Test Plan:
Changed resolution under X, and scale under wayland
Panel looked the same and nothing exploded
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7937
Keeps it from loading the Svg and all the Plasma stuff (Theme etc) that comes with it on startup.
Differential Revision: https://phabricator.kde.org/D8011
