Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
Summary:
So far KWin didn't send axis_source, axis_discrete, and axis_stop. Even
though most of those events are optional, clients need them to work as
expected. For example, one needs axis_source and axis_stop to implement
kinetic scrolling; Xwayland needs axis_discrete to prevent multiple
scroll events when the compositor sends axis deltas greater than 10, etc.
BUG: 404152
FIXED-IN: 5.17.0
Test Plan:
* Content of a webpage in Firefox is moved by one line per each mouse
wheel "click";
* Scrolled gedit using 2 fingers on GNOME Shell, sway, and KDE Plasma;
in all three cases wayland debug looked the same (except diagonal scroll
motions).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19000
Summary: use a new function to get the logind, instead of assuming seat0
Test Plan: kwin still starts
Reviewers: #kwin, davidedmundson
Reviewed By: davidedmundson
Subscribers: davidedmundson, rkflx, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9552
Summary:
With the Wayland enabled Mouse KCM we do not need the workaround
to control button mapping and acceleration anymore.
Depends on D11468
Test Plan: Compiles.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11472
Summary:
expose in the libinput wrapper a property that tells whether
a tablet mode switch input device is present on the machine,
expose it trough dbus
Test Plan:
still not complete, I need a way to either access the connection
from TabletModeManager or setting to TabletModeManager from input.cpp
Reviewers: #kwin, #plasma, graesslin
Reviewed By: #kwin, #plasma, graesslin
Subscribers: graesslin, ngraham, davidedmundson, plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9944
Summary:
This change adds support for the switch devices introduces with libinput
1.7 (lid) and 1.9 (tablet mode). So far it's not yet used internally in
KWin, but only exposed through the Device and Events.
As KWin currently only requires libinput 1.5 and we are rather late in
the release cycle the new functionality is ifdef'ed. The requirement
will be raised once master is 5.13. It is already available on
build.kde.org, but e.g. Neon only has 1.6.
The switch events are interesting as they report whether the lid is
closed (might be interesting for e.g. powerdevil) and whether a
convertible is in tablet mode (supported for e.g. Lenovo Yogas with
recent kernel). This can be used by KWin internally to enable/disable
the virtual keyboard. And can be exposed globally to switch to Plasma
Mobile shell in future.
Test Plan:
Only through test case as my Lenovo Yoga uses Neon which has a
too old libinput
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9516
Summary:
This change finds the screen for a touch screen device based on:
* number available screens
* output name defined on the touch screen device
* internal screen
* and physical size
The id of the screen is stored in the Device allowing to adjust the
touch points accordingly. This means instead of transferring to the
combined display size the touch points are transferred into the output
space and the position of the output is added. Thus in a multi screen
system the touch points are properly mapped to the output.
Furthermore the screen orientation is passed to the Device and a
calibration matrix is set accordingly. Thus a transformed screen has the
touch screen transformed accordingly.
Please note that this only affects libinput on Wayland and not on X11!
The x11 standalone platform needs to gain similar code.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8748
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
Summary:
Making QActions with the Connection as a parent is dangerous as it gets
moved to a new thread, moving all child objects to that thread.
KGlobalAccel and QAction aren't thread safe and we shouldn't be using it
in two threads. This was notably seen when runnng invokeShortcut over
DBus which then invokes it on the main thread. Something my laptop was
doing when I closed the lid.
This patch simply moves the code to the Input class, where we set up the
libinput connection.
Test Plan:
Closed lid, kwin_wayland was still there when I resumed
Set manual shortcut for toggling touchpad, that still worked
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5733
Create auxiliary class for Connection class in order to connect to DBus
from main thread.
Reviewers: #kwin, davidedmundson, graesslin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D4081
On registering object use the object in the right thread.
Otherwise there are multiple errors.
BUG: 374554
Differential Revision: https://phabricator.kde.org/D4027
Summary:
No need to capture the variable as it's static. Also apparently wrong.
Used to get the following error message:
/home/apol/devel/frameworks/kwin/libinput/connection.cpp:103:56: error: 's_self' cannot be captured because it does not have automatic storage duration
connect(s_self, &Connection::deviceAdded, s_self, [s_self](Device* device) {
^
/home/apol/devel/frameworks/kwin/libinput/connection.cpp:45:25: note: 's_self' declared here
Connection *Connection::s_self = nullptr;
^
/home/apol/devel/frameworks/kwin/libinput/connection.cpp:106:58: error: 's_self' cannot be captured because it does not have automatic storage duration
connect(s_self, &Connection::deviceRemoved, s_self, [s_self](Device* device) {
^
/home/apol/devel/frameworks/kwin/libinput/connection.cpp:45:25: note: 's_self' declared here
Connection *Connection::s_self = nullptr;
^
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3703
This patch is made in preparation for the Touchpad KCM for Wayland.
Summary:
* KWin has a Libinput version requirement bump to 1.5
* new isTouchpad property to distinguish touchpads from mice
* new lmrTapButtonMap property
* new disableWhileTyping property
* new pointerAccelerationProfile property
* new defaultPointerAcceleration property
* save to config mechanism added for new propertys and pointerAcceleration
* new D-Bus interface org.kde.KWin.InputDeviceManager and method devicesSysNames
* removed unnecessary additional D-Bus service name org.kde.KWin.InputDevice
* changing acceleration in the Mouse KCM doesn't influence touchpads anymore
Reviewers: #kwin, #plasma, davidedmundson
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3479
Summary:
Device gets a KConfigGroup injected and supports loading device-specific
settings. This is invoked from Libinput::Connection when adding a new
Device.
Whenever a Device option is changed successfully through the DBus
interface it gets synced into the KConfigGroup, thus on next loading of
the Device it gets restored.
The config group follows a pattern of:
[libinput][vendor][product][name]
Thus every device has a specific and persistent configuration.
Test Plan: So far only tested through autotests
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3264
Summary:
The Xkb implementation starts to track the state of the LEDs in the
keymap and emits a signal whenever the LEDs change. This signal is
connected to a method in LibInput::Connection which updates the led
state on all devices and uses it to init the state of the led when a new
device gets connected.
BUG: 369214
FIXED-IN: 5.8.2
Test Plan: Connected a keyboard with LEDs and enabled NumLock and ScrollLock.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2943
Summary:
If KWin interacts with Libinput the RelativePointerManager interface
gets created on the Wayland server. The ForwardInputEventFilter does
forward the relative motion events in addition to the normal motion
events.
In order to properly support the relative motion events as they are
expected by the Wayland protocol the handling of pointer motion events
got slightly adjusted:
* Libinput Pointer event extended by the additional data points
* Libinput Pointer event carries the delta as a QSizeF instead of
QPointF
* PointerInputRedirection adjusted to take a pointer motion event with
more arguments
* Custom QMouseEvent subclass adjusted to carry the additional members
The DebugConsole is adjusted to show the relative motion events in
addition to the global position.
Test Plan:
Verified the manager object is created and verified the
events in DebugConsole. Unfortunately not aware of any test application.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2979
This causes an assert with debug build of Qt due to threading issues.
We don't need the setParent call as we use deleteLater when a device
gets removed.
Reviewed-by: Martin Gräßlin
Summary:
The Connection exposes a new service called org.kde.KWin.InputDevice
and every Device registers an own object exposing all properties.
This allows an external configuration tool to change the behavior of
the devices at runtime. E.g. to test configuration settings.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2407
Summary:
Gesture events are swipe or pinch events on a touch pad.
This change implements basic support by:
* wrapping them in LibInput::Event
* processing them in LibInput::Connection and emitting
dedicated signals
* Forwarding them in InputRedirection to PointerInputRedirection
* Support them in the internal input event filter
* Printing debug information in DebugConsole
Further handling is not yet done. In future the following should be
implemented:
* activating e.g. zoom and present windows on pinch/swipe gesture
* forwarding non global gestures to KWayland
Note that forwarding to KWayland is not yet useful as QtWayland does
not yet have support for the unstable protocol. No Qt application could
make use of it yet. So for the moment just global gestures is the best
we can get.
Test Plan: Looked at output of DebugConsole when triggering gestures
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2359
Summary:
Device is created from Connection::processEvents which is run in the
main gui thread, while Connection itself is in a different thread. Thus
passing *this* as parent is wrong.
This change removes the parent, moves the created Device into the
Connection thread and also deletes properly by using deleteLater.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1746
Summary:
The signals emitted by LibInput::Connection carry the Device for which
the input event was received. This Device is passed to the input handlers.
Custom event classes are added which extend QMouseEvent, QKeyEvent and
QWheelEvent respectively and expose the Device. The Device is only passed
around as a forward declared pointer, so even if compiled without libinput
support, it should still compile.
Event handlers which need to get access to the Device can now just cast
the event pointer to the custom class and access it. This can be used in
future to handle device specific key codes, etc.
As we don't have a proper event classes for touch events the event
handlers do not yet have access to the Device. Here the internal API
needs to be adjusted in future.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1667
Summary:
The Event class now holds a pointer to the Device and not only to the
native libinput_device.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1666
Summary: Similar to the already existing hasKeyboard, hasTouch and hasPointer.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1671
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 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
The Connection thread fills the event queue, it gets read from the
main thread. In order to properly support the threaded approach the
setup is changed to delegate into the own thread.
When the Connection is created we move it into a dedicated thread
so that even processing happens in the thread. Currently all events
are still queued directly.
This change is motivated by the fact that we need to suspend libinput
before switching the virtual terminal. Also we don't want to take over
libinput if we do not have a VirtualTerminal created - in windowed mode
we don't want libinput to be started. So binding it to the backends which
create the VirtualTerminal makes sense.
The KWin::Application gains a new signal virtualTerminalCreated which is
emitted from VirtualTerminal once it's properly setup. This is used by
Input to create Libinput integration instead of binding it to logind.
Furthermore Libinput gets suspended when the VirtualTerminal reports that
it is no longer active. For re-activation we still just use logind's
session active property.
When our session gets inactive libinput loses all devices, thus our
Seat would not have neither keyboard, pointer nor touch. To not confuse
all connected clients we block updates while libinput is suspended. After
resume we check whether something actually changed and emit the
corresponding signals to ensure everything is up to date.
We handle device added/remove to monitor whether we have keyboard,
pointer and touch devices and emit signals. Those are used to update
the SeatInferface from InputRedirection.
LogindIntegration starts monitoring the Active property on the session
and emits a signal when the state changes. The LibInput::Connection
connects to this signal during the setup and uses it to suspend/resume
the libinput context.
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.
