libinput is a library to handle input devices in Wayland compositors and to provide a generic X.Org input driver. It provides device detection, device handling, input device event processing and abstraction so minimize the amount of custom input code compositors need to provide the common set of functionality that users expect.
libinput is expected to replace input drivers such as synpatics in the future, and there’s already a drive to move input stack in Fedora 22 to libinput as can be seen in the discussion here. Most of the software would transparently work, except – as quickly noted in that discussion – the KDE touchpad configuration. Tochpad KCM exposes almost every knob present in the synaptics driver. In contrast, libinput exposes very few options to configure – such as tap-to-click and keeps most of the other options enabled by default – such as disable touchpad while typing. This is more sensible and efficient to do – when using synaptics driver, disabling touchpad while typing was accomplished by the synclient daemon.
As an aftermath of the discussion in Fedora, libinput maintainer Peter Hutter contacted KDE developers, including yours truly who is guilty of porting the kcm-touchpad to KDE Frameworks 5. As I know nothing about input stack or touchpads in general (phew), Peter was kind enough to step up, clone the kcm-touchpad and add support for libinput in addition to (existing) synaptics driver. All I had to do then, is to port it again to Frameworks 5.
As of last week, the review request to do that has been reviewed by Martin Gräßlin and David Edmundson and merged into the master branch – in the meantime I have obtained KDE developer commit access. In other words, Touchpad KCM now supports both libinput and synaptics drivers! If both are installed, libinput is preferred and exposes only the relevant options. As the KCM user interface exposes a lot of options, most of them remain disabled. Ideally, it should be re-designed – for example the GNOME mouse/touchpad configuration (including GNOME Tweak tool) exposes very few options. Alexander Mezin, kcm-touchpad maintainer has mentioned plan to rewrite it, I hope he will be able to find some time.
The updated kcm-tochpad packages for Fedora 20, 21 and Rawhide (what to become F22) are available for testing in the copr in Fedora repositories. For some caveats such as edge scrolling available only on single-touch touchpads, see the discussion and associated bug here. There’s still some issue with edge scrolling setting, I’m investigating it.
Soliloquies 
13 responses to “Libinput support added to Touchpad KCM”
What is the benefit for leaving the options out? Honestly, the large amount that I can customize is one of the benefits. I currently have touchpad disabled when: 1. typing and 2. mouse is plugged in. I would hate to see these features thrown out.
What’s happening, is configurability sudenly a NO word i KDE? I sertanly hope I have missunderstud something.
Thanks, for your contribution by the way. To be a bit more constructive after reading your article again a couple of times. I think that your Touchpad KCM looks good and should display all the options as disabled when not available from libinput. That way you would know that there is unlevereged potential in further development of libinput. Witch means that we at a later time might have our dear configurationoptions back.
First of all, before the whole world panic – please read the post, especially the part “both libinput and synaptics are supported”. Libinput “automatically disables touchpad while typing”. Most other options like Scrolling Distance or Coasting Speed are mostly not used or even tested. The benefit of libinput are explained elsewhere linked in the article, I won’t repeat here.
Rajeesh, you wrote: “…and hides most of the other options enabled by default…”
Now I see what you meant, but you must understand that there is more than one way to interpret this phrase. I (and others too apparently) read it the way that you did not intend. Anyway, as Kjetil says, thanks for your contributions. Panic averted.
BTW – no panic present. This is one of the reasons that I love opensource and linux. The interaction with the developers.
FYI, kcm_touchpad is updated already in fedora 22 and fedora rawhide(f23) repos, so no need to carry those in your copr anymore. And thanks. 🙂
Thanks, Rex. I have updated the post.
Thanks, I have rephrased that sentence a bit, hope that makes it clearer.
Thanks to port it the problem for what I see is not KCM but libinput. Great that means that the touchpad will work with wayland but it seems also that means that we can forget to have any possibility to configure our touchpad in any way. From the screenshot it seems that the one and only one option available is “Mouse click emulation”. It seems that now the gnome philosophy to remove all the option is going one step further and now it is not only remove on the gnome environment but system wide… I don’t think that I do appreciate it a lot.
-any possibility to configure our touchpad in any way-
No. That’s a dramatic over statement.
Look at the screenshot again to find 4 other tabs for Scrolling, Enable/Disable etc.
It’s not just GNOME. It’s more sensible. Even Windows is doing something similar – unifying input stack rather than having a thousand horrible vendor drivers. See http://images.anandtech.com/doci/8983/TrackpadSettings.png
Honestly I do not care of windows. I am not using it and one of the reason is that it doesn’t fit my needs (neither MacOSX) and windows has never been, for me, the path to follow. I am using KDE and not Gnome for the same reasons. I can adapt KDE to my workflow not the wokflow that someone else decide for me. I am not saying anything agains unifying the input stack also. I am saying that I do not like the fact that I will not be able to configure what kind of tap I am affecting to one/two/three fingers (and it is only one sample took from the screenshot).
Could you improve the interface when libinput is used? Like hiding all non-compatible options, a cleaner GUI.
Current touchpad kcm is in best efforts support mode. It is very difficult to refactor existing code base cleanly to support both synaptics and libinput options in the gui. There’s a new input kcm being worked on by Alexander Mezin, hopefully that will land soon.