On wayland, we know we're always going to load our internal QPA. Instead
of shipping a plugin and loading it dynamically we can use Qt static
plugins.
This should result in slightly faster load times, but also reduce the
number of moving pieces for kwin.
This also prevents anyone outside kwin loading our QPA which wouldn't
have made any sense and just crashed.
VirtualKeyboard class does not implement the relevant VirtualKeyboard
protocol but rather implements the InputMethod protcol and can in theory
be used by other input method like e.g. ibus.
Make class name consistent with what it does to avoid confusion in
future.
For now only rename of main class is done and dbus service is kept as-is
to provide retro-compatibility, when input method protocol is
implemented fully, we can think of what to do wrt the dbus interface
later when we fully implement zwp_input_method_unstable_v1 protocol.
If the Xwayland executable can't be found, the whole session will die
because a criticalError() signal will be emitted.
This change replaces the criticalError() signal with a less severe
signal.
If the errorOccurred() signal has been emitted during the startup
sequence, kwin won't die and will just continue with spawning the
session process.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
If the Xwayland process crashes, it will bring down the entire session
together with itself. Obviously, we don't want that. At least, Wayland
clients should survive the crash.
This change refactors relevant X11 parts to handle Xwayland crashes in a
less fatal way.
In order to handle Xwayland crashes better, a pair of start() and stop()
methods had been introduced in the Xwayland class to allow starting and
stopping the Xwayland process at any moment.
If we detect that the Xwayland process has crashed, we will immediately
stop the Xwayland server, which in its turn will deactivate the socket
notifier and destroy all connected X11 clients. Unfortunately, a couple
of subtle changes in X11Client::releaseWindow() and Unmanaged::release()
had to be made to ensure that we are left with a valid state after the
Xwayland server has been stopped.
Sub-classes of the AbstractClient class need a valid instance of the
Workspace class to function as desired. We should not create xdg-shell
clients until the workspace is created.
The new signal is emitted when the Application has fully been initialized.
It allows us to change the startup sequence, for example create workspace
before starting the Xwayland server, without making any adjustments in our
test suit.
The bug reporter presents a use case of wanting to run a game and scale
down the result.
For everyone else kwin_wayland nested is just a test tool, so I don't
see any disadvantages.
It could be useful in testing.
BUG: 422141
Summary:
Since QProcess::setProgram() doesn't split the command, we need to do it
ourselves.
Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again.
Reviewers: #kwin, cblack, davidedmundson, apol
Reviewed By: #kwin, cblack, davidedmundson, apol
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29253
Summary: No need to keep them around for no reason.
Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28062
Summary:
Since we now use in the backends the OutputDeviceInterface for output data
all access must be complete before the Wayland server goes down. For that
introduce a new function to prepare shutdown in the backends.
While at it also remove the output deletion, since they get deleted through
Qt's object system leading to crashes on double free.
Test Plan: Shutdown works without seg faults in the Drm backend.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11459
Differential Revision: https://phabricator.kde.org/D23602
Summary:
This patch is a first take at splitting up of the Compositor class into
Wayland and X11 child classes.
In this first patch we mostly deal with setup and teardown procedures.
A future goal is to further differentiate the compositing part itself too.
Test Plan: Manually X from VT and Wayland nested. Autotests pass.
Reviewers: #kwin
Subscribers: sbergeron, anthonyfieroni, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22195
Summary:
When ShellClient tears down, it needs to access RuleBook in order to
discard temporary rules. The problem is that WaylandServer outlives
Workspace and therefore so does ShellClient.
We can't guard against the case when RuleBook::self() is nullptr as it
is vital to discard temporary rules.
This change adjusts termination sequence so all shell clients are
destroyed before Workspace(and thus RuleBook) is gone.
ASAN output:
==19922==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000142060 at pc 0x7fbc0fb878bb bp 0x7ffd7d464520 sp 0x7ffd7d464518
READ of size 8 at 0x606000142060 thread T0
#0 0x7fbc0fb878ba in QList<KWin::Rules*>::detach() /usr/include/qt5/QtCore/qlist.h:172
#1 0x7fbc0fb8538d in QList<KWin::Rules*>::begin() /usr/include/qt5/QtCore/qlist.h:324
#2 0x7fbc0fb808b6 in KWin::RuleBook::discardUsed(KWin::AbstractClient*, bool) /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/rules.cpp:1144
#3 0x7fbc0fe36e32 in KWin::ShellClient::destroyClient() /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/shell_client.cpp:435
#4 0x7fbc0fe7a726 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (KWin::ShellClient::*)()>::call(void (KWin::ShellClient::*)(), KWin::ShellClient*, void**) /usr/include/qt5/QtCore/qobjectdefs_impl.h:152
#5 0x7fbc0fe784c3 in void QtPrivate::FunctionPointer<void (KWin::ShellClient::*)()>::call<QtPrivate::List<>, void>(void (KWin::ShellClient::*)(), KWin::ShellClient*, void**) /usr/include/qt5/QtCore/qobjectdefs_impl.h:185
#6 0x7fbc0fe74de9 in QtPrivate::QSlotObject<void (KWin::ShellClient::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (/home/jenkins/install-prefix/lib64/libkwin.so.5+0x1677de9)
#7 0x7fbc04f27357 in QMetaObject::activate(QObject*, int, int, void**) (/usr/lib64/libQt5Core.so.5+0x2b3357)
#8 0x7fbc074e1970 in KWayland::Server::Resource::unbound() /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/build/src/server/KF5WaylandServer_autogen/EWIEGA46WW/moc_resource.cpp:142
#9 0x7fbc0766b4b4 in KWayland::Server::Resource::Private::unbind(wl_resource*) /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/resource.cpp:68
#10 0x7fbc00bdc2ae (/usr/lib64/libwayland-server.so.0+0x92ae)
#11 0x7fbc00bdc32f in wl_resource_destroy (/usr/lib64/libwayland-server.so.0+0x932f)
#12 0x7fbc0766b53f in KWayland::Server::Resource::Private::resourceDestroyedCallback(wl_client*, wl_resource*) /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/resource.cpp:76
#13 0x7fbbff481d8c (/usr/lib64/libffi.so.7+0x6d8c)
#14 0x7fbbff481179 (/usr/lib64/libffi.so.7+0x6179)
#15 0x7fbc00bdfa5f (/usr/lib64/libwayland-server.so.0+0xca5f)
#16 0x7fbc00bdc6d1 (/usr/lib64/libwayland-server.so.0+0x96d1)
#17 0x7fbc00bddc71 in wl_event_loop_dispatch (/usr/lib64/libwayland-server.so.0+0xac71)
#18 0x7fbc07541e50 in KWayland::Server::Display::Private::dispatch() /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/display.cpp:148
#19 0x7fbc075432de in KWayland::Server::Display::dispatchEvents(int) /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/display.cpp:220
#20 0x7fbc0fe864ca in KWin::WaylandServer::dispatch() /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/wayland_server.cpp:616
#21 0x451ce0 in KWin::WaylandTestApplication::~WaylandTestApplication() /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/autotests/integration/kwin_wayland_test.cpp:91
#22 0x42faa1 in main /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/autotests/integration/globalshortcuts_test.cpp:381
#23 0x7fbc04796bca in __libc_start_main (/lib64/libc.so.6+0x26bca)
#24 0x413ea9 in _start (/home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/build/bin/testGlobalShortcuts+0x413ea9)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22821
Summary: Otherwise it's hard to tell if it failed.
Test Plan: Found out that my session was crashing.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21465
Summary:
In a recent patch the newly added xwayland class ended up being
responsible for continuing the startup, calling back into the main app
to spawn the workspace.
It moves the flow of startup about so it's not very readable or
following class structure.
This patch moves the code back into main_wayland and removes the
duplication between xwayland and non-xwayland modes.
There was also a misnaming of methods.
Previously:
continueStartupWithScreens was called after platform screens are created
continueStartupWithScene was called after the scene was created
continueStartupWithXwayland was called before xwayland is created
This was confusing, so the names have been shuffled around to follow a
consistent pattern of what has been done so far.
Test Plan:
Started kwin_wayland in normal and xwayland mode
Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug)
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19232
Summary:
In this patch an infrastructure is created to represent generic X selections
in a Wayland session and use them for data transfers between Xwayland windows
and Wayland native clients.
The central manager is the DataBridge class, in which Selection objects can be
created. This is hard-coded and such a Selection object persists until the end
of the session, so no arbitrary selections can be created on the fly. For now
the X Clipboard selection is supported, whose corresponding mechanism in the
Wayland protocol is just called Selection.
A Selection object listens for selection owner changes on the X side and for
similar events into the Wayland server interfaces. If a data provider is
available a selection source object is created by the Selection object. In case
data is requested on the other side, a data transfer is initialized by creating
a Transfer object. A Selection keeps track of all transfers and makes sure that
they are destroyed when they are finished or in case they idle because of
misbehaving clients.
The Clipboard class translates the X Clipboard via a proxy window. Selection
changes on the Wayland side are listened to through a new signal on the active
KWayland seat interface.
The previously used X clipboard syncer helper is disabled. The clipboard sync
autotest is changed to the new mechanism.
BUG: 394765
BUG: 395313
Test Plan: Manually and clipboard sync autotest.
Reviewers: #kwin
Subscribers: zzag, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15061
Summary:
By using the new Xwayland class we can reduce code duplication.
An abstract parent class is introduced, that allows interfacing
with the Xwayland class from the test binaries.
Test Plan: Autotests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15022
Summary:
The Xwayland code path is moved from ApplicationWayland to a dedicated class
Xwayland in a new top-level directory xwl.
This is a direct preparation step for generic support of Xwayland Selections.
On a longer timescale this should also allow us to further separate Wayland
native functionality from Xwayland to allow us at one point to build KWin's
Wayland binary optionally without X dependencies. Another long term goal, that
becomes possible through this separation is to recover from Xwayland crashes.
Test Plan: Manually and auto tests
Reviewers: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15020
Summary:
So far we didn't try to do high DPI on kwin internal windows, such as
the user context menu and tab bars and whatever.
Due to wayland scaling they were the correct phyiscal size but upscaled.
This patch fixes our QPA to enable Qt's high-dpi support.
BUG: 402853
Note icons are still low res. This is because the global
QGuiApplication::devicePixelRatio which is the max of all connected
screens is static for the duration of the app. QIcon uses this when
determining the DPR to use. This will require a Qt change.
Test Plan:
Ran at 2x on my normal DPI screen (as that's easier to see anything)
* User action menu is high DPI
* Window deco tooltips are still fine
* Tab switcher is high DPI
* Overlay in present windows Desktop grid are still ok
Reviewers: #kwin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18042
Summary:
The SceneOpenGLES test was starting to randomly crash on my system. On
investigation I observed that there was a graphics reset ("Attempting to
reset compositing.") which triggered a delayed restart of the
compositor. This even was only processed while waiting for XWayland to
terminate. Which resulted in a crash in KWin::getXServerVersion as the
xcb connection broke.
It makes no sense to setup the compositor again during application
shutdown. Thus the dtors set a flag that they are terminating the
application and Compositor::setup is checking for it.
Test Plan: Test no longer crashes, although it goes through the crashing path
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18015
Summary:
This command line option is useful for KWin in embedded use case. That
is when KWin is just used as a compositor for one application instead of
a complete desktop environment. In such a setup global shortcuts are not
wanted and interfere with the application. E.g. one does not want Alt+F4
to close the window, that would render the system unusable.
This change introduces a command line option and disables the following
event filters and spies:
* global shortcuts
* modifier only shortcuts
* terminate session
* virtual terminal switching
* screen edges
KGlobalAccel still gets inited, otherwise the (non-functional) binary
would be launched when KWin registers it's global shortcuts.
Test Plan:
New test added based on existing tests for the global
shortcuts, ctest passes
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17304
Summary:
WaylandServer provides the initialization flag to disable lock screen
integration. This couldn't be used yet as there is no command line flag
for it. This change adds a new command line argument and hooks up the
functionality.
The no lock screen integration is useful for the embedded use case where
KWin is just used to render one application.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17279
Summary:
Kwin tried to not use kcrash by not linking against it.
KIO now links against KCrash as we link against KIO we indirectly link
against KCrash and thus now link and launch kcrash on wayland. This
breaks coredump.
Arguably it should be fixed in KIO, but it's non-trivial.
The advantage of this approach is it allows us to enable drkonqi for
nested mode in the future, or make a non-gui drkonqi that just saves
logs.
Test Plan: Compiles
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: zzag, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16834
Summary:
kwin_wayland now automatically chooses an appropriate backend, such as
DRM, nested wayland or nested X. If nested it will automatically go into
windowed mode regardless of whether --windowed is set and works fine.
Backend choosing logic existed duplicated in older code for kwin_wayland
--windowed, with the subtle unexpected difference that it preferred
running as an X client over running as a wayland cient if both are
present. This simplifies codes and syncs automatic resolution behaviour.
kwin_wayland --windowed with --x11-display or --wayland-display will
remain the same.
Test Plan:
Ran kwin_wayland with and without --windowed inside another wayland.
Got the same backend chosen
Tested that kwin_wayland (without --windowed) on an X machine worked just fine.
Reviewers: #kwin, mart
Reviewed By: #kwin, mart
Subscribers: mart, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13658
Summary:
On Wayland processXcbEvents calls workspaceEvents and updateX11Time but this
is already done in the native event filter.
Test Plan:
Manual test shows Xwayland still works and constant calls to
XcbEventFilter::nativeEventFilter are processed.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14215
Summary:
KWin is not designed to run as root. It is not hardened enough and
there is a great risk that applications could attack KWin through
X11 properties, Wayland protocol requests, etc. to trigger stack or
heap overflows and execute random code. As clients connected to KWin
could be remote there is a great risk in running KWin as root. Also
clients on the same system but started as a different user could
try to gain more privs by exploiting KWin.
Furthermore KWin is designed to not run as root. It interacts with
logind to get the devices opened which would require root. Whether
KWin would work as root at all is questionable.
We cannot guarantee that running KWin as root is secure, thus this
change disallows running KWin and thus a Wayland session as root.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13008
Summary: Now that the framebuffer device is queried, don't assume that the framebuffer device is /dev/fb0
Test Plan:
Add /dev/fb1 to seat1, start kwin with the framebuffer backend on seat1, verify with the stdio/stderr output it selected /dev/fb1.
Make sure manual device selection still works
There is an issue right now where /dev/fb1 is all black, if it is both selected manually or automatically. I think I might need see if the VSCREENINFO or FSCREENINFO framebuffer settings are changing or something (I had to do something similar to this to Weston's fbdev backend as well)
If I do find a solution, I'll send one separate from this series
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, rkflx, graesslin, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9557
Summary:
The main reason for not having it as a mandatory dependency was that BSD
doesn't support it. But as I learned recently it is available on our CI
system. So BSDs have support now.
Even more it showed that the code doesn't compile if the dependency is
missing. And there's one thing I hate: broken build configuration
options.
So let's make UDEV and libinput a required dependency and get rid of the
problems.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10057
Once again KActivities causes a delay in the startup of KWin. This is
not the first time it happens, that has been a problem since the start
of the Wayland project.
In the past we added a compile time switch due to that and added a
runtime switch once it stoped freezing (20a9a2a247).
And now it broke again, so let's disable again.
KActivities doesn't make sense on Wayland anyway as there is no activity
support for Wayland windows. Once KActivities is able to be used without
freezing KWin on startup and being able to ensure that it won't break
again we can reenable. But I expect guarantees about that. This must be
ensured by proper autotest support to verify that in future usage of
KActivities in the display manager doesn't freeze it.
This is maintainer decision, due to that no pre-commit review.
CCMAIL: plasma-devel@kde.org
BUG: 388628
Summary:
depends from D9521
listens to switch events and updates the tablet mode status
which is exposed to dbus in the org.kde.KWin.TabletModeManager
interface
Test Plan:
as hardware support is limited, testing of clients
so far is done by the setter in the dbus property,
which should be removed from the final version.
It has been tested to successfully work on a Thinkpad.
Reviewers: #plasma, #kwin, graesslin
Reviewed By: #plasma, #kwin, graesslin
Subscribers: graesslin, davidedmundson, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9764
Summary:
Loads settings on whether QtQuick uses GL or software rendering
Aurorae needed a fix. The rest "just works" with up-to-date plasma framework.
Test Plan:
Alt tabbed
Showed an OSD
Grepped kwin's QML for any custom shaders.
(which is the only part that doesn't work here)
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8040
Summary:
The SCHED_RESET_ON_FORK results in threads (not only processes) to have
the scheduling policy reset to default. This means that the libinput
thread is not real time, but this was actually intended.
To solve this problem KWin does start without the RESET_ON_FORK flag
during startup. Once createInput has been called the scheduling is
adjusted again and RESET_ON_FORK is added again. This results in the
libinput thread and all threads Qt starts in between (e.g. dbus) to gain
real time policy. But it is still not leaked to other processes or to
threads in KWin which don't need it.
Other options considered: just don't use RESET_ON_FORK and instead
manually reset on fork. This would mean all threads in KWin gain real
time, but we don't need this. It's only interesting for the main
(rendering, Wayland thread) and the input thread. Also the danger to
leak into another process is too high.
Keeping the capability till the libinput thread is created and adjust
the thread itself. This option was discarded as I don't want KWin to
have any capabilities when the QApplication is started.
Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8065
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 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:
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:
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
