Summary:
Qt's touch event API is rather difficult and complex to implement.
As none of KWin's internal windows supports multi-touch gestures yet,
this is going the easy route and just simulates a left mouse button
press. If in future need arises for touch gesture support on KWin's
internal windows, this can be added.
Test Plan: Tested on exopc with DebugConsole and auto test
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1661
It's currently failing on build.kde.org. I'm not able to reproduce the
failure localy so I can only interpret the failure. The failure looks
like a window is still present in the next executed test case thus
breaking the positioning.
This change ensures that the window is properly gone before going into
the next test case.
When KWin goes down the DecorationBridge might be destroyed before the
last AbstractClient is destroyed. Thus we should destroy the Decoration
when the DecorationBridge gets destroyed.
If we get a compositingToggled because the Compositor is going down we
don't need to recreate the Renderer as KWin as a whole is going down.
Thus we disconnect the compositingToggled connection when the Compositor
is about to be destroyed.
KWayland was changed: the ShellSurfaceInterface does no longer get
destroyed when the parent SurfaceInterface gets destroyed. For the
wl_shell_surface there is no dtor request in the interface so the
resource sticks around and also the ShellClient is kept.
This change ensures that the ShellClient also gets destroyed when
the Surface is destroyed. This should fix some broken tests.
Summary:
The usage of libinput is completely mocked. The test covers all the
constant properties read by Device.
There are some features which are not yet tested:
* alphaNumericKeyboard
* supportedButtons
* enabled
The setters for leftHanded and pointerAcceleration are also covered
including the variants where it can fail.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1648
Summary:
Most likely the window is in the process of getting destroyed. In that
case the following destroy of the Surface is also going to destroy the
decoration.
This was causing an interesting effect with the QQuickRenderControl used
by Aurorae. When getting destroyed it ensures that all posted events get
processed. This includes the destroy of the Surface which entered
ShellClient::destroyClient which again destroyed the decoration. In other
words a recursive destroy which ended with wonderful crashers due to
double deletions.
If the window is not unmapped this might still cause problems: more
testing needed.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1641
Summary:
A new virtual method createOpenGLSafePoint is added to Platform.
This is invoked through the Compositor with a PreInit and a PostInit
argument pre and post creating the SceneOpenGL.
The Platform plugin can implement this and use it for detecting whether
creating the OpenGL compositor on this platform crashed in the past.
Thus it's the base for the openGLIsBroken platform check.
The x11 standalone plugin is the first to implement this functionality
using the previous code which was designed for X11.
This also means that a crash of the OpenGL compositor during init on
Wayland won't result in OpenGL being disabled.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1582
Summary:
So far the OpenGL is unsafe check functionality in Compositor disabled
OpenGL compositing if glx is not available and we are in standalone X11
mode.
This is technically no longer correct for quite some time. Just because
GLX is not available doesn't mean that OpenGL doesn't work. We have an
EGL backend. So let's try to use that if glx is not available.
This change removes the check completely from Compositor. Instead the
standalone x11 plugin checks whether glx is available prior to createing
the glx backend. If not available it falls through to the egl backend.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1581
Summary:
Client uses a static Xcb::Window helper. This so far didn't get
explicitly destroyed, so the application finalize cleaned it up.
To destroy the window the xcb_connection_t* is used which the
QGuiApplication already destroyed.
This change ensures that the window gets destroyed before the xcb
connection gets destroyed.
In addition an assert is added to KWin::connection() to ensure that
we still have the QGuiApplication::instance() when it's invoked.
This way we'll notice if we have more cases where we call into xcb
after the application went down.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1573
Summary:
Toplevel::window() is the actual X11 window. This makes it difficult
to use as the generic identifier for both X11 and Wayland. The Wayland
ShellClient already had a windowId() which is now added to Toplevel as
a virtual method. On X11 (Toplevel default) it returns the window().
The method window() now returns XCB_WINDOW_NONE for classes without
the Toplevel::m_client, such as ShellClient. Thus it allows to properly
check whether we are on Wayland or X11.
The code is adjusted to use windowId where a generic id is needed and
to properly check whether the window is valid before using it where
a window() is used.
This also fixes at least one additional unknown issue in
Workspace::setActiveClient
where the windowId of a Wayland client was passed to X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1527
Summary:
CompositingPrefs is only relevant for X11 standalone. It had some
"hacks" to make it not block Compositing on Wayland. Thus it was in
its current form not really useful.
Now all the functionality is provided through Platform with a default
implementation which is sensible for Wayland platforms.
The X11 standalone platform implements the new methods with the
Wayland checks removed.
In addition all calls to CompositingPrefs now go through the platform
directly and CompositingPrefs is completely dropped.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1576
Summary:
This change reduces the windowing system specific code pathes. Instead
of checking whether we are on X11 or Wayland to decide whether
compositing is required, we just ask the Platform.
The default is true, only x11 standalone allows to not require
compositing.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1575
Summary:
Touch events are emulating mouse events, in particular left mouse
button.
With this change one can move windows through the decoration, use
the decoration buttons and also support the double click action.
As finding the decoration is pretty much exactly the same as for
pointer events, a new base class is introduces which provides the
functionality of updating the decoration and the shared common
variables.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1604
Summary:
If a user specifies the QT_WAYLAND_FORCE_DPI env variable, KWin uses
it to force a logicalDPI, just like QtWayland.
Test Plan: Normally sized window decorations
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1605
Summary:
This ensures that frameRendered is also sent if we start a Wayland Server
on X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1597
Summary:
Instead of reset a proper beginInsertRows, beginRemoveRows is used.
In addition changes in the device are also listened on and emit the
proper dateChanged signal.
Test Plan:
Opened debug console, selected the touchpad device,
toggled shortcut and verified that this updated the data column.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1547
Summary:
Mouse actions like wheel and double click were restricted to the titleBar
area. This made the top most pixel non-interactive as it's not part of the
titleBarArea.
This change makes the complete titlebarPosition interactive. That is it
includes for a "normal" (top) setup also the TopLeft/Top/Right section.
Thus the top most pixel can be double clicked, mouse wheeled, etc.
For the Wayland case the test case is adjusted.
BUG: 362860
FIXED-IN: 5.7.0
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1596
Summary:
The window will be cleaned up automatically once all bound resources
are destroyed. A manual delete though might cause protocol errors on
client side as the unmap and resource destroy happen together and we
are in a race condition.
To ensure that we don't leak the interface is set as the parent, so
on tear-down remaining resources will be destroyed eventually, even
if it triggers a protocol error on the client.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1595
Summary:
The LibInput::Device provides a way to enable/disable the device.
This is used by the Connection to toggle all touchpad devices on/off
when the touchpad key is pressed. For this KWin "steals" the global
shortcuts from the touchpad kded.
Detecting what is a touchpad is unfortunately not tivial. The code
uses the following approach:
* it's a pointer
* it's not also a keyboard or touch screen
* it's at least one of the following:
** supports multiple tap fingers
** supports disable while typing
** supports disable on external mouse
If the code finds a touchpad and changes it's state successfully,
it triggers the touchpadEnabledChanged on Plasma's osdService.
Test Plan: Tested on notebook with toggle touchpad button
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1545
Summary:
The configuration file kcminput, group Mouse is parsed to decide whether
pointer devices should be in left handed mode. The config is applied
whenever a new device is added.
In addition the Connection listens to KGlobalSettings for a mouse
settings changed signal which might be emitted by the mouse KCM.
When such a signal is emitted, all pointer devices are reconfigured.
This allows to change the mouse handed settings on Wayland.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1543
Summary:
The delay to next cycle dance is needed for Aurorae. Maximizing a
window can result in the decoration being destroyed, in which case
QtQuick can trigger a crash.
A test case is added to simulate the situation and ensure that maximize
still works also after the change.
BUG: 362772
FIXED-IN: 5.6.5
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1586
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:
This change ensures that kwin_wayland does not pull in KCrash. We
don't want and need KCrash in the Wayland case. If KWin crashes the
session goes down - restarting doesn't make any sense, we need to
relogin.
Similar drkonqi just doesn't work as it doesn't have a windowing
system to connect to. After all the windowing system just crashed.
Also the AlternativeWM dialog doesn't make any sense on Wayland.
Similar thought: there is no windowing system to show this nice dialog.
Overall it's better to have system default behavior
(e.g. systemd-coredump) than using KCrash in the very special case of
kwin_wayland.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1550
Allows to toggle Activity Manager and bring up KRunner by hitting the configured screen edge.
BUG: 358627
BUG: 245979
Differential Revision: https://phabricator.kde.org/D1105
Apparently libinput is too old and LIBINPUT_DEVICE_CAP_TABLET_TOOL is
not yet available. As we don't use it yet, it's put into the #if 0 part
for future use.
Summary:
The Device class wraps all the information we can get from libinput
about the device, like whether it's a keyboard, pointer, touch, etc.
In addition some more information is queried to figure out how "useful"
a device is. For a keyboard all alphanumeric keys are checked whether
they exist, for a pointer all (normal) buttons are queried.
All the information is exposed as Q_PROPERTY and used by the
DebugConsole. The DebugConsole gained a new tab "Input Devices" which
renders all devices and their properties in a tree view. When plugging
in/out a device, the model gets reset, so it's always up to date.
The new Device class can be used in future to configure the device,
e.g. disable touch pad, set mouse acceleration, etc.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1538
Summary:
This ensures that QWindow::setMask works for KWin internal windows.
Without KWin sends all pointer events to the QWindow, even if the
mask says it shouldn't get events.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1509
Summary: It's instantiated, but never created. This means that libkscreen's wayland backend is going to hang initializing.
Test Plan: Ran libkscreen against it, works with and doesn't work without patch.
Reviewers: graesslin, #plasma
Reviewed By: graesslin, #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1524
Summary:
Instead of checking the operation mode for X11, we check whether the
damage_handle is created. This fixes a bad damage warning for Wayland
windows in kwin_x11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1490
Summary:
To check which code path we should take just check whether
* we have a surface -> Wayland
* we have a pixmap -> X11
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1487
Summary:
If the Toplevel has a Wayland Surface we don't want an X11 damage
handle. Ideally we would just check for the Surface and get rid of
the operation mode check. But setupCompositing is called for Xwayland
clients before the surface is set.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1486
Summary:
Instead of binding to the OperationMode whether the damage_handle
should be destroyed, we bind it to whether damage_handle got created.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1483
Summary:
Instead of having the Application invoke initOutputs after creating
the Screens, we can just connect to the signal emitted there.
This allows to make initOutputs a private, WaylandServer internal
method.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1482
Summary:
In order to start the WaylandServer in kwin_x11 we need to make sure
that WaylandServer does not start the KScreenLocker integration. On
X11 the lock screen is provided by a different application (in Plasma
by ksmserver).
A new init flag is added to WaylandServer to not integrate with
KScreenLocker. Thus the default is still to integrate with KScreenLocker.
All direct usages of KScreenLocker are guarded to not be called if
the screenlocker integration is not present.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1481
Summary: This seems to just have been forgotten here.
Test Plan: Builds
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1499
