Posted on by Martin Flöser

Improved input device support in KWin/Wayland

One of the areas I’m currently working on is improving our support for input devices in KWin. While general usage is already quite good in Plasma 5.6, we are not yet able to configure the input devices. This is something I’m working on to improve for Plasma 5.7.

Input devices are provided by libinput and KWin integrates with that for quite some time. What it didn’t do yet is to configure them and keep track of them.

So as a first step we created a Device wrapper class which encapsulates a libinput device in a way that we can easily use it from inside KWin. The Device allows us to gain knowledge about what it supports and also to configure it.

The used Devices and their states can be queried through KWin’s new Debug Console:
Input Devices in Debug console

The Debug Console is also new in Plasma 5.7 and allows us to have a deeper introspection into KWin. It can be opened through KRunner (Alt+Space) and then with the command “KWin”. The functionality set is inspired by tools like xprop (one tab allows to read all window properties), xwininfo -tree (one tab shows a (sub)surface tree), xev (input events).

Back to input devices. Once we had the Device wrapper class in place we could start making use of it to configure devices. And today I landed a series of commits in KWin master which bring us back many features from X11. From the configuration point of view it’s really easy for us as we can just reuse our existing configuration tools. For example the mouse configuration module writes to a config file which KWin can read. When the settings change the configuration module sends out a DBus signal which KWin uses to trigger a reconfigure.

So KWin now supports setting pointer devices (mouse) to left-handed usage and modifying the pointer acceleration.
Toggle Touchpad

In addition KWin started to integrate changes for touchpads. KWin listens to the global shortcut for touchpad toggle and uses this to enable/disable the touchpad. Of course this comes with triggering the new on-screen-display notification for enabling the touchpad. Next step will be to integrate more options for touchpads, but this will require writing a kwin-backend for our touchpad control module.

28 Replies to “Improved input device support in KWin/Wayland”

  1. I’m already using kwin Wayland at home. Can’t wait to start using it at the office! Keep up the good work!

  2. Awesome, will that also enable support multitouch on screens? Since currently touchscreens are handled as single point devices (just like a mouse).

    Also will that allow control of mouse pointer speed (not acceleration) ?

    1. Multi touch on Wayland has been supported for quite some time. I do not get the question about mouse pointer speed.

      1. I believe he means the constant mouse movement speed, not the acceleration which lets the pointer move additionally further on faster movements. This setting is absent in the Mouse – KDE control moddule.

        In my case I have to adjust this property “Device Accel Constant Deceleration (281)” with xinput, and make it slower (about 3 times), else my mouse is much to fast. This is mostly a problem if you have a high dpi mouse.

        1. Ah the flat profile. Yeah that’s still missing in mouse KCM and due to that in KWin. Noted down for implementation.

          1. Note: X11 lacked direct configuration of mouse pointer speed increase either. But there was a hack — it could be configured with Transformation Matrix, see this for example http://unix.stackexchange.com/a/177640/59928

            It is definitely nice to have some way to do it, because mice often lack acceleration buttons, especially the office ones.

  5. Yeah, configuring stuff like middle button emulation for mouse (using right and left click) in System Settings would be useful. Right now I need to run xinput for that.

      1. System Settings > Input Devices can for example have some advanced section, which could expose something similar to that console that you showed in the post, but also would allow users to modify those settings. This way you can make a generic method to configure various devices that libinput understands (and it would cover this middle click emulation too). Of course users would have to know what they are doing, that’s why it should be “advanced”. May be providing a way to reset to defaults can be useful too in case users would mess it up.

        For instance, right now I put this in my $HOME/.xsessionrc

        xinput set-prop “Logitech G400s Optical Gaming Mouse” “libinput Middle Emulation Enabled” 1

        And there are quite a number of other properties that xinput shows for it.

        1. I thought about more device specific settings in the config file. Something for the future, though.

  6. Can’t believe the amount of progress done in such a short time.
    You really rock ! Thanks so much.

  7. Sorry for the double post (and for the offtopic) but forgot to ask something.
    You may already know that NVIDIA’s last proprietary driver now supports Wayland via EGLStreams. What’s your take on it ? Do you plan to support eglstreams assuming NVIDIA doesn’t come with a kms/gbm solution ?
    Thanks again.

    1. I do not have an nvidia card so that’s not of any interest to me at the moment.

      1. Would you be interested in such tests if someone could sponsor a card for you? There are quite a lot of KDE desktop users who use closed Nvidia drivers, which is unfortunate, but hard to avoid given that nouveau still is lacks reclocking for the most part.

        1. No, at the moment I still have enough work without caring about incompatible EGL implementations. That’s something the NVIDIA and Wayland devs need to figure out first. If Weston accepts the required patches, we will start looking into it.

  9. nice
    I always disable pointer acceleration. Last time I checked, the KDE’s input settings didn’t affect libinput, so I had to change it via config files. libinput docs have been inconsistent on how to achieve that but I somehow managed to get it done.
    So I assume this is a problem of the past?!

    1. This is a change for Wayland. If an X11 system uses libinput this change does not affect it. So don’t expect problems to be fixed by that change.

      Sorry, but Plasma on X11 doesn’t support libinput yet. Distributions should IMHO not combine that yet or adjust the code in Plasma.

    1. yes sure, that’s something we want to implement, but AFAIK QtWayland doesn’t have support for it yet, so from a more global point of view it doesn’t make that much sense to spend time on it any time soon

  12. If you have both plasma and plasma-wayland sessions available, how is input configuration going to work from the settings interface? From what I understand it would have to detect whether you’re in an X or Wayland session to make the correct adjustments.

Comments are closed.