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:
Normally the xclipboardsyncer should terminate because the socket
becomes unusable. But we have reports of it not really going down and
running amok.
In order to prevent such situations this change registers SIGTERM to be
sent to xclipboardsyncer when the parent process (that is kwin_wayland)
dies in whatever way. This ensures that xclipboardsyncer cannot become
an orphan.
BUG: 371862
Test Plan: Only compile tested, no way to get into the problematic situation
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5589
The capability tablet tool is new in Libinput 1.2. As build.kde.org
does not yet support this version, it's only an optional check.
So far the code only detects whether the capability exists and reports
this accordingly.
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 clipboard sync is done by a dedicated helper binary launched by
KWin. This helper binary is forced to xcb platform to piggy-back on
Qt's implementation of the X11 clipboard. In addition it implements
the Wayland clipboard - which is much simpler. Reading the Wayland
clipboard is based on the implementation in QtWayland.
KWin internally knows the DataDeviceInterface belonging to the helper
application. Whenever an xwayland client is focussed, this DataDevice
is allowed to set the selection and KWin manually updates the current
selection in the SeatInterface. By that the sync from X11 to Wayland
is implemented. When afterwards a Wayland client is selected, it's sent
the current selection which references the X clipboard and a data
transfer can be initiated in the normal Wayland way.
For the other direction KWin sends the current selection to the helper's
DataDevice whenever an xwayland window is focused. The helper application
reads the Wayland clipboard and sets it on the X11 clipboard. Thus the
Wayland clipboard is synced to X11.
The approach used here will also be useful for implementing a clipboard
manager (aka klipper).
Currently the implementation is not yet fully completed. We need to
make sure that the helper application gets restarted in case of a crash.
Test Plan: See added test case
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1973
Summary:
Similar to[[ https://phabricator.kde.org/D1216 | D1216 ]] add procctl call to disable ptrace on FreeBSD.
We cannot do the procfs-lookup to check whether the process is already being run inside gdb -- however, on FreeBSD, we could use the P_TRACED flag of the process to figure this out:
> sys/proc.h:#define P_TRACED 0x00800 /* Debugged process being traced. */
And the code would look something similar to
```
pid_t pid = getpid();
struct procstat *prstat = procstat_open_sysctl();
struct kinfo_proc *procinfo;
unsigned int cnt;
procinfo = procstat_getprocs(prstat, KERN_PROC_PID, pid, &cnt);
long p_flags = procinfo->ki_flag;
int p_traced = p_flags & P_TRACED;
if (p_traced != P_TRACED) {
mode = PROC_TRACE_CTL_DISABLE;
procctl(P_PID, getpid(), PROC_TRACE_CTL, &mode);
}
procstat_freeprocs(prstat,procinfo);
procstat_close(prstat);
```
But as wayland is [far] in the future on FreeBSD, and that check above is a bit lengthy, I think it is enough if we add it once it is needed.
Reviewers: rakuco, graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1425
Summary:
KWin needs the plugin id of the breeze decoration plugin. Instead
of hard coding that it's now resolved through an optional dependency.
If the optional dependency is not available, the default is adjusted
to aurorae/plastik.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1344
Replaces the timer based polling approach. If XInput is available we
listen for the RawMotion event on the root window and use this to
trigger a mouse pointer position.
BUG: 357692
FIXED-IN: 5.6.0
REVIEW: 126733
In order to increase the security we disable ptrace on kwin_wayland.
This makes it impossible for a another process running as the same
user to attach to kwin_wayland to install a key logger. It doesn't
protect against higher privileged users, but that's no problem: they
can just read the input device file and don't need to attach to KWin
to become a key logger.
This change is highly inspired by a similar change to kscreenlocker.
A difference is that KWin checks whether we are running under a
debugger. In such a case we still want to allow ptrace.
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
The problem with KToolInvocation is that it creates a dead lock on
Wayland in case kdeinit is not already running. It starts kdeinit
and does a QProcess::waitForFinished and our kdeinit needs to interact
with the wayland server. So dead lock.
As KRun also calls into the dangerous code path it's no option which
leaves us with QProcess to start the processes.
A nice side-effect is that we no don't need to link KF5::Service any
more from kwin_core. Now once Plasma and Notification don't use it
any more, it will be gone completely.
We need XCB 1.10 for sync to work. Sync was optional with a version check
to make it work on build.kde.org. The CI system supports XCB 1.10 now, so
it's better to have it as a mandatory requirement.
This backend interacts with libhybris to create a hwcomposer which is
used for creating the egl context and surface. The initial version of
this backend is based on test_hwcomposer.cpp provided by libhybris.
Please note that using the hwcomposer backend requires a newer libepoxy,
the latest stable release is not able to bring up OpenGLES, so one needs
a master build of libepoxy.
Notes on licensing:
libhybris is Apache 2.0 licensed, which is not compatile with GPLv2.
But it is compatible with GPLv3. Thus the source files in the hwcomposer
backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one
uses KWin without the hwcomposer backend (which is obviously the default)
the licence doesn't change. But if the hwcomposer backend is used the
overall license of KWin changes to GPLv3+.
Uses EGL_MESA_platform_gbm to get an EglDisplay from a gbm_device.
The DrmBackend can provide a DrmBuffer for a gbm_surface and present
it.
Unfortunately buffer age seems to be slightly broken and we still have
artefacts.
Introduces a new (optional) dependency: libdrm.
The DrmBackend currently supports finding the first connected output.
It can create shared memory buffers which are used by SceneQPainter to
do double buffered rendering.
There is still lots to do, the following things are not yet working:
* multiple outputs
* page flip
* OpenGL (through gbm)
* restoring mode setting to start value
We released three versions with it being disabled and it doesn't look
like it will come back any time soon. Also the build was broken at least
since the repo splitting due to incorrect path to dbus xml.
In addition the connection to decorations got dropped already with the
change to kdecoration2. Which means it anyway needs large adjustements
to get the code working again.
Overall it doesn't look like it makes lots of sense to keep the code
around for someone working on it in future. If that happens this change
can be reverted.
Adds optional dependency to X11_XCB and gets used in X11WindowedBackend
to create an XLib Display if dependency is present.
This allows to create an EGL backend for the X11WindowedBackend.
Since XCB 1.10 the sync extension is working properly. At the time of
the 5.3 release 1.10 will have been out for ~15 months, enough time
for distros to catch up and should allow us to use it.
As our CI system only supports 1.9 at the moment we cannot hard depend
on the version, instead we use feature info. As soon as our CI system
supports it, we should update the required min version and kick out the
ifdef.
REVIEW: 122377
Straight forward port from XLib based XCursor library to the
xcb variant which is considerably new. The xcb variant only allows
to create xcb_cursor_t for the default theme and size. Which suits
the needs in Cursor quite well, but means it's not a replacement for
the usage in zoom effect.
REVIEW: 122290
Add QT_VERSION_STR in addition to qVersion(). This could be useful
to see whether the runtime version is different to the Qt version
used at compile time.
Also adds the XCB_VERSION_STRING which is used at compile time.
This is useful as for example XCB::SYNC was broken prior to 1.10.
REVIEW: 122375
The build option got introduced for Plasma Active back in a time
when we did not properly aim for convergence. In a Plasma 5 world
we want to have only one shell and one window manager which adjust
itself. This means we don't want a differently compiled kwin for
plasma active, but the same one. Thus the build option doesn't
make much sense any more. A KWin for touch interface needs to support
screenedges for the case that mouse is plugged in.
CCBUG: 340960
REVIEW: 121200
Libinput is an optional dependency for getting low level input events.
As opening the input devices requires root privs this is rather
pointless in the current state. But there is a small added test app which
can be executed with root privs to demonstrate the functionality. To
properly get input events we need a wrapper like it's used in weston.
So far the following is setup:
* opening devices found by udev
* forwarding keyboard events to InputRedirection
* forwarding pointer button events to InputRedirection
* forwarding pointer axis events to InputRedirection
* signals emitted for pointer motion events
Pointer motion events need some further work as they are provided
as delta events. We need to track that and map them properly.
Also missing are touch events due to me not having a touch screen.
It should be fairly simple to setup the touch events, though.
Also hotplugging of devices is not yet implemented.
This servers two purposes.
1. it makes KWin/5 co-installable with KWin/4 as now binary and
all libraries etc. are renamed or installed to a different
location.
2. In future we need a dedicated X11 and Wayland main function
anyway. Thus it makes most sense to rename to kwin_x11 directly
instead of first renaming to kwin5. The reason why we need to
have dedicated main functions is that kwin needs to check early
whether X11 is working or Wayland is working. Right now the first
thing kwin does is trying to connect to the XServer. This happens
before the QApplication is constructed and before command line
args are processed. On Wayland we won't want to test whether we
can connect to the XServer. As it's too early to check whether we
are starting kwin for X11 or Wayland the most convenient way is to
have dedicated binaries - thus a rename is needed. Just renaming
kwin for wayland is also not a good idea as in future the "main"
kwin will be for wayland not for X11. Another case for the dedicated
binaries is the Application class, which right now first tries to
claim the X11 Window Manager Selection. Again on Wayland even with
XWayland we won't need that. KWin will be the window manager for
XWayland if KWin is the Wayland compositor. There is no need to even
try to support anything else. Most likely it will even be KWin to
start the XWayland server, so we can be sure that there is no other
WM running and thus no need to claim the selection and abort if it
fails.
REVIEW: 118266
ICCCM dependency is a beast due to two different existing versions in
different packages. Thus it cannot be a hard dep without causing problems
for our downstreams.
This change ensures that ICCCM is really considered as an optional dep
and that the version we need is found, if not we mark it as non-found.
ICCCM is only used by one test application which can easily be disabled
and some enum values are used in events.cpp. If ICCCM is not found those
are replaced by defines generated in config-kwin.h.
BUG: 336035
Major new functionality is xkbcommon support. InputRedirection holds an
instance to a small wrapper class which has the xkb context, keymap and
state. The keymap is initialied from the file descriptor we get from the
Wayland backend.
InputRedirection uses this to translate the keycodes into keysymbols and
to QString and to track the modifiers as provided by the
Qt::KeybordModifiers flags.
This provides us enough information for internal usage (e.g. pass through
effects if they have "grabbed" the keyboard).
If KWin doesn't filter out the key events, it passes them on to the
currently active Client respectively an unmanaged on top of the stack.
This needs still some improvement (not each unmanaged should get the
event). The Client/Unmnaged still uses xtest extension to send the key
events to the window. So keylogging is still possible.
Scripting has proved it's point of being useful so it's time to turn it
into a mandatory part of KWin.
Also I start to use features provided by Scripting in more and more
parts of KWin core (e.g. sharing QQmlEngine) which makes it in the
long to complicated to have a build option and ifdefs for it.
REVIEW: 116587
This build option is added to make it easier to build just KWin without
kde-workspace. This is a common requirement by developers wanting to
contribute to KWin and only want to build KWin but use everything else
from their normal distribution.
Building KWin standalone is very often difficult due to Oxygen. If the
library has changed it is not possible to build just KWin without also
building the workspace libs and if you do so you run into ABI problems
when trying to start KWin - either the decoration or the style is
crashing due to not matching libraries.
To circumvent this common issue for new developers this build option
is introduced to just exclude the Oxygen window decoration and defaulting
to Plastik.
Of course by default this option is turned ON, so that the Oxygen
decoration gets build. By default there is no change at all.
REVIEW: 106303
As discussed on the mailinglist [1] the tiling support is
removed from KWin. The main reasons for this step are:
* it is unmaintained
* it is a mode not used by any of the core KWin team
* original developer said at Akademy 2012 that he is not
interested in picking up the work again
* tiling has quite some bugs, e.g. multi screen not supported
* is conflicting with other concepts in KWin, e.g. activities
There is ongoing work to get tiling supported through a KWin
script, which is a preferred way as it does not influence the
existing C++ code base.
[1] http://lists.kde.org/?l=kwin&m=133149673110558&w=2
BUG: 303090
FIXED-IN: 4.10
REVIEW: 105546
A CMake variable is used to specify the name of the binary.
By default this is "kwin" but building for PA changes the
name to "kwinactive". The variable adjusts all names, e.g.
kwinnvidiahack becomes kwinactivenvidiahack.
The remaining usage of kwinrc in core and libs is replaced
by a cmakedefine for the configuration name and all data
installations are moved to the defined name. Dynamic loading
for scripts & co is adjusted for loading based on defined name.
This change allows the side-by-side installation of both kwin
for desktop and kwin for Plasma Desktop without the known
issues like conflicts in config files or missing build options
if kwin desktop is used for Plasma Active.
Likewise the KCMs are not adjusted as they are not intended to
be used for kwinactive.
REVIEW: 104299
BUG: 296084
FIXED-IN: 4.9.0
CCMAIL: active@kde.org
