[plasma-desktop git repo]/kcms/touchpad/src/kcm/touchpadconfigcontainer.cpp has the following code: { Q_DECL_EXPORT void kcminit_touchpad() { if (KWindowSystem::isPlatformX11()) { TouchpadConfigXlib::kcmInit(); } } } TouchpadConfigContainer::TouchpadConfigContainer(QWidget *parent, const QVariantList &args) : KCModule(parent, args) { if (KWindowSystem::isPlatformX11()) { m_plugin = new TouchpadConfigXlib(this); } else if (KWindowSystem::isPlatformWayland()) { m_plugin = new TouchpadConfigLibinput(this); } } That's fine for Wayland where libinput is mandatory, but there is no logic for handling the (very common) case where libinput is being used with X11.
*** Bug 374214 has been marked as a duplicate of this bug. ***
*** Bug 384518 has been marked as a duplicate of this bug. ***
Is it really a bug? On X11, even if you're using libinput driver, libinput is configured via XInput. Even it's all "libinput" they will need to use different code path. You can configure touchpad with old UI for libinput X11 driver. On the new UI side, I assume that the new UI is only designed for libinput because it don't want to carry the burden from X11 (on X11 we support synaptics and libinput), so it's only used on wayland. FYI X11+Libinput: kcms/touchpad/src/backends/x11/libinputtouchpad.{h,cpp}
The old XInput-based touchpad KCM does indeed *sort of* work with libinput-on-xorg, but 90% of the UI is grayed out, since those options aren't supported on libinput. *Everything* on the Sensitivity tab is disabled! And libinput-specific settings aren't exposed (e.g. left handed mode, click method). The result is a poor user experience. It seems like it might be possible to fix those problems, but why bother when we already have a better libinput-specific UI that's used on Wayland? When libinput is being used on X11, couldn't we show the nice UI but use the XInput backend?
(In reply to Nate Graham from comment #4) > The old XInput-based touchpad KCM does indeed *sort of* work with > libinput-on-xorg, but 90% of the UI is grayed out, since those options > aren't supported on libinput. *Everything* on the Sensitivity tab is > disabled! And libinput-specific settings aren't exposed (e.g. left handed > mode, click method). > > The result is a poor user experience. It seems like it might be possible to > fix those problems, but why bother when we already have a better > libinput-specific UI that's used on Wayland? When libinput is being used on > X11, couldn't we show the nice UI but use the XInput backend? Emm, the problem is, xinput may use different driver at the same time so I assume it's not an easy issue to resolve.
At least on Ubuntu-based distros, if you have xserver-xorg-input-synaptics and xserver-xorg-input-libinput installed at the same time, libinput takes precedence. So if libinput is installed, we would always want to use that as the backend, regardless of whether or not synaptics was also installed. And newer Ubuntu releases like 17.10 don't even install the synaptics one at all by default.
*** Bug 391693 has been marked as a duplicate of this bug. ***
The Mouse KCM now has a special libinput X11 backend and uses similar GUI as with libinput Wayland backend. There is currently a GSoC project under way to do something similar for the Touchpad KCM.
Is it possible to just turn off KDM's pointer handling altogether? Or at least make it possible to run a script when configuring a device. My problem is that I have three pointing devices: touchpad, trackpoint and intermittent USB mouse. Every time I plug the mouse in, kcminit screws up the settings for both touchpad and trackpoint. Prior to recent updates my /etc configuration worked fine with no interference, but now KDE cannot be persuaded to just let things alone. Here's the config I have in /etc. This works just fine without kdminit's meddling: # Match on all pointing devices but joysticks Section "InputClass" Identifier "cfr libinput pointer catchall" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Driver "libinput" EndSection # llaw chwith : llygod = pointers *heb* touchpads & trackpoints Section "InputClass" Identifier "cfr libinput llygod" MatchIsPointer "on" MatchIsTouchpad "off" NoMatchProduct "TrackPoint" MatchDevicePath "/dev/input/event*" Driver "libinput" Option "Left Handed Enabled" "1" EndSection # dim ond trackpoint # addaswyd o https://bbs.archlinux.org/viewtopic.php?pid=1747203#p1747203 Section "InputClass" Identifier "cfr libinput trackpoint" MatchIsPointer "on" MatchIsTouchpad "off" MatchProduct "TrackPoint" MatchDevicePath "/dev/input/event*" Driver "libinput" Option "Accel Speed" "1" Option "Accel Profile" "flat" Option "Left Handed Enabled" "0" EndSection # dim ond touchpads Section "InputClass" Identifier "cfr libinput touchpad catchall" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" Driver "libinput" Option "Tapping" "1" Option "TappingDragLock" "1" Option "Accel Speed" "1" Option "Left Handed Enabled" "0" EndSection And here is kcminit-undo, which I must run shortly after I plug a mouse in: #!/bin/bash - #set -x PATH=/usr/bin export PATH allan=0 usage="Usage: $0 Ceisio dadwneud kdminit sy'n torri config llygoden, touchpad a trackpoint." error () { echo "$@" 1>&2 ((allan++)) usage_and_exit $allan } warning () { echo "$@" 1>&2 ((allan++)) return 1 } usage () { printf %b "$usage\n" } usage_and_exit () { usage exit $1 } try () { xinput set-prop $1 "$2" $3 || warning "Gwall: na allaf gosod "$2" $3 am $4." } tempargs=$(getopt -o h --long help -- "$@") if [ $? != 0 ]; then usage_and_exit fi eval set -- "$tempargs" while true do case "$1" in -h | --help) usage; exit $allan;; --) shift; break;; *) error Unrecognised option "$1". esac done touch=$(xinput list --id-only "SynPS/2 Synaptics TouchPad") track=$(xinput list --id-only "TPPS/2 IBM TrackPoint") mouse=$(xinput list | grep "Mouse" | sed 's/^.*id=\([0-9][0-9]*\)[^0-9].*$/\1/') [[ "$mouse" != "" ]] && xinput set-prop $mouse "libinput Left Handed Enabled" 1 try $track "libinput Left Handed Enabled" 0 TrackPoint try $track "libinput Accel Speed" 1 TrackPoint try $track "libinput Accel Profile Enabled" "0, 1" TrackPoint try $touch "libinput Accel Speed" 1 TouchPad try $touch "libinput Tapping Enabled" 1 TouchPad try $touch "libinput Tapping Drag Lock Enabled" 1 TouchPad try $touch "libinput Left Handed Enabled" 0 TouchPad exit $allan # vim: set nospell: The module seems to have no discretion at all. It sets everything left-handed, whereas I only want the mouse that way - not the trackpoint. And it drastically slows pointer speed for the touchpad and, to a lesser extent, the trackpoint. Please provide an option to disable this functionality in KDE without uninstalling KDE altogether. I know I have a somewhat specific setup. I don't expect a GUI to accommodate it. But the GUI needs an off switch so KDE keeps out of the way again.
*** Bug 398893 has been marked as a duplicate of this bug. ***
Doesn't seem like Furkan will be fixing this, darn. It's probably up to Roman at this point!
This is affecting at least some of us on the latest Kubuntu (Cosmic). I have nvidia so it will be awhile until Wayland is possible on this box.
We have a new patch to fix this, courtesy of the touchpad KCM's new maintainer Atul Bisht: https://phabricator.kde.org/D20186 Thanks Atul!
Welcome, Nate :D
*** Bug 406778 has been marked as a duplicate of this bug. ***
Git commit ce84d6ab4babc80707f4e4c1deb02cfe3ac5b7bb by Nate Graham, on behalf of Atul Bisht. Committed on 14/05/2019 at 15:02. Pushed by ngraham into branch 'master'. [libinput-touchpad-kcm] Use wayland specific touchpad KCM UI when libinput is used on X11 Summary: Earlier when libinput was used on X11, XInput specific UI was shown, due to which most of the options were grayed out. Now we show libinput specific UI that is already used on wayland if libinput driver is used on X11. - loaded all libinput properties that are available on X11. - exposed all Q_PROPERTY to Libinput specific UI. Related: bug 392709 FIXED-IN: 5.16.0 Reviewers: ngraham, romangg, davidedmundson, #plasma Reviewed By: ngraham, romangg, #plasma Subscribers: GB_2, jriddell, knambiar, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D20186 M +1 -0 kcms/touchpad/src/backends/kwin_wayland.cmake M +2 -0 kcms/touchpad/src/backends/kwin_wayland/kwinwaylandbackend.cpp M +6 -27 kcms/touchpad/src/backends/kwin_wayland/kwinwaylandtouchpad.cpp M +27 -385 kcms/touchpad/src/backends/kwin_wayland/kwinwaylandtouchpad.h C +4 -8 kcms/touchpad/src/backends/libinputcommon.cpp [from: kcms/touchpad/src/kcm/touchpadconfigplugin.cpp - 072% similarity] C +130 -142 kcms/touchpad/src/backends/libinputcommon.h [from: kcms/touchpad/src/backends/kwin_wayland/kwinwaylandtouchpad.h - 084% similarity] M +1 -0 kcms/touchpad/src/backends/x11.cmake M +370 -27 kcms/touchpad/src/backends/x11/libinputtouchpad.cpp M +102 -2 kcms/touchpad/src/backends/x11/libinputtouchpad.h M +3 -1 kcms/touchpad/src/backends/x11/synapticstouchpad.h M +67 -0 kcms/touchpad/src/backends/x11/xlibbackend.cpp M +9 -0 kcms/touchpad/src/backends/x11/xlibbackend.h M +7 -1 kcms/touchpad/src/backends/x11/xlibtouchpad.h M +27 -0 kcms/touchpad/src/kcm/libinput/main.qml M +2 -3 kcms/touchpad/src/kcm/libinput/touchpadconfiglibinput.cpp M +1 -0 kcms/touchpad/src/kcm/libinput/touchpadconfiglibinput.h M +9 -2 kcms/touchpad/src/kcm/touchpadconfigcontainer.cpp M +3 -2 kcms/touchpad/src/kcm/touchpadconfigplugin.cpp M +1 -1 kcms/touchpad/src/kcm/touchpadconfigplugin.h M +2 -4 kcms/touchpad/src/kcm/xlib/touchpadconfigxlib.cpp M +1 -0 kcms/touchpad/src/kcm/xlib/touchpadconfigxlib.h M +5 -0 kcms/touchpad/src/touchpadbackend.cpp M +13 -1 kcms/touchpad/src/touchpadbackend.h https://commits.kde.org/plasma-desktop/ce84d6ab4babc80707f4e4c1deb02cfe3ac5b7bb
*** Bug 393755 has been marked as a duplicate of this bug. ***
How this can be closed? I still have the issue, unless my bug report that was reported a duplicate wasn't a duplicate after all... Nate, can you look into that? The original report was here: https://github.com/bulletmark/libinput-gestures/issues/146#issuecomment-639436753 This led to open the bug 393755 which then was marked as duplicated of this bug. This one here is marked as resolved but the issue remains! 3 swipes still create notices on desktop. Why? We hate that and we don't want that. I wished to use 3 finger swipes to libinput gestures but since this is still hard-coded in Plasma for pasting notices, the problem is still there. After that time, UI changed drastically but the fact remains: there is no GUI for 3 swipes, and we can't change or turn it off. Plasma overrides it every time. I'm not even sure what THIS BUG HERE was about but it looks like mine was incorrectly forwarded here.
I figured out with someone's help that the pasting notices on desktop was caused by desktop setting: emulate mouse middle click as paste. When I disabled it, the issue was gone.