This is a placeholder bug tracking the adoption of the new kcm_pointing_devices (https://cgit.kde.org/scratch/alexandermezin/pointing-devices-kcm.git/), or else some other method of configuring things when Libinput is being used. All bugs complaining about poor libinput support should be duped to this one in order to centralize information on that subject as well as gauge the number of people using libinput.
*** Bug 374214 has been marked as a duplicate of this bug. ***
*** Bug 383360 has been marked as a duplicate of this bug. ***
*** Bug 379020 has been marked as a duplicate of this bug. ***
*** Bug 365488 has been marked as a duplicate of this bug. ***
*** Bug 348265 has been marked as a duplicate of this bug. ***
*** Bug 350688 has been marked as a duplicate of this bug. ***
*** Bug 361151 has been marked as a duplicate of this bug. ***
*** Bug 351145 has been marked as a duplicate of this bug. ***
*** Bug 357749 has been marked as a duplicate of this bug. ***
*** Bug 384518 has been marked as a duplicate of this bug. ***
Hello, We are SLIMBOOK TEAM, and we want to join this bug. We have developed a small application to change the configuration of libinput, and we tell you a little how it works to see if you can solve it. It is best that you can change the touchpad settings without installing third-party applications. Image of options of our app: https://slimbook.es/images/imagetuto/touchpadevdev.png We have never developed for Plasma, but I think it should be another "kcm" when it is not a Synaptics touchpad (the synclient status service) or in our case the Unique ID: AH6Q.bGO0sOimOM3 - To get touchpad hardware id: hwinfo --mouse *Previous command returns the line: 'Unique ID: AH6Q.bGO0sOimOM3' and line 'Model: "ImExPS/2 Generic Explorer Mouse"' (model name used later for setting properties using 'xinput') - To get touchpad properties we can modify: xinput --list-props "ImExPS/2 Generic Explorer Mouse" *We can use model name (like previous line) or number id related with model name obtained when running command 'xinput': xinput --list-props 11 - To modify values of properties 'libinput Accel Speed' and 'libinput Natural Scrolling Enabled': xinput --set-prop "ImExPS/2 Generic Explorer Mouse" "libinput Accel Speed" 1 xinput --set-prop "ImExPS/2 Generic Explorer Mouse" "libinput Natural Scrolling Enabled" 1 *Like in previous step, we can use number id instead of model name. Propertie "libinput Natural Scrolling Enabled" accepts values 0 or 1. Propertie "libinput Accel Speed" accepts values between -1 and 1. More information in our app: https://github.com/slimbook/slimbook-touchpad Thanks,
Fantastic work, guys! Here's some documentation on how to develop a KCM: https://techbase.kde.org/Development/Tutorials/KCM_HowTo Probably the best option would be to modify the existing touchpad KCM to present a different set of settings and user interface elements when it detects that libinput is being used. But if you want to developer a new, separate KCM that only handles libinput, that's okay too, since synaptics isn't supported with Wayland and eventually everyone will have to use libinput anyway.
Slimbook team, any progress on turning your app into a KCM visible in System Settings?
Sorry Nate, but we have not had time to learn a new system of programming. Much of our work is to assemble the client hardware and we have little time to learn how to program. We thought that someone from KDE would have it easy and quick to make it work.
There is a patch that implements this feature: https://phabricator.kde.org/D8168 If anybody is available to test this, please do so and offer comments. KDE Slimbook team, this might be a great collaboration opportunity.
Thank you very much! I like it! It looks very interesting I just installed a new KDE Neon and I'm updating it. I do not really know how to apply these changes. I only have 2 folders in the system called "kcms" and none have any "input" or anything similar. Thanks.
*** Bug 386157 has been marked as a duplicate of this bug. ***
Created attachment 108954 [details] Wayland version of the touchpad KCM We're getting there. FWIW, there is a simple Libinput touchpad config available on Wayland (screenshot attached). And patches to make this more complete and available on Xorg are working their way through Phabricator.
Turned this into a master bug tracking blockers so we can concentrate on individual issues and knock when out one at a time.
Comment on attachment 108954 [details] Wayland version of the touchpad KCM Wow! Wonderful!!
Wow! Wonderful!! Thank you very much. What can I do?
> What can I do? Option 1: Work towards shipping your devices with Wayland as the default, and preferably help fix some of the biggest Wayland-related KDE bugs (e.g. Bug 385693) Option 2: Push on Bug 387153
*** Bug 389227 has been marked as a duplicate of this bug. ***
I just tried Wayland session with KDE Plasma 5.12.0 (Debian testing), and xinput wasn't working anymore and my setting for middle click emulation with right click + left click disappeared. So for now I switched back to X session. Will such libinput features be accessible through System Settings > Input Devices in the future?
yes, they have to be, because xinput isn't supported on Wayland. See Bug 390761.
(In reply to Nate Graham from comment #25) > yes, they have to be, because xinput isn't supported on Wayland. See Bug > 390761. Just for the reference, I'm talking about the mouse, not touchpad here, but I suppose the idea is similar.
Here's an update for folks who are interested in this: X11 - Touchpad KCM: I am mentoring a student for Google Summer of Code who plans to tackle this work and then continue to polish up input device handling in KDE software - Mouse KCM: in progress, thanks to Roman Gilg: https://phabricator.kde.org/D11469 Wayland - Touchpad KCM: already fully libinput-compatible, modulo a few missing features (tracked as dependent bugs here) - Mouse KCM: in progress, thanks to Roman Gilg: https://phabricator.kde.org/D11468
It would be awesome if this can be done while there is work on input device handling: Touchpad settings are lost after resume if there is a mismatch between Touchpad-KCM and xorg.conf https://bugs.kde.org/show_bug.cgi?id=391693 Setting to disable middle click paste https://bugs.kde.org/show_bug.cgi?id=389710 https://bugs.kde.org/show_bug.cgi?id=392488
Yep, we'll consider those. They seem like good tasks for my GSoC student.
Jesus christ, maybe just not implement shit that you know you then wont let user configure?
Please keep comments constructive and technical. See: - https://community.kde.org/Get_Involved/Bug_Reporting#Bug_tracker_etiquette - https://www.kde.org/code-of-conduct/
Anyway, an update: - Libinput-on-x11 mouse KCM is done and will be released in Plasma 5.13 - Libinput-on-x11 touchpad KCM is in progress now and should be in Plasma 5.14
(In reply to Nate Graham from comment #32) > - Libinput-on-x11 mouse KCM is done and will be released in Plasma 5.13 And Wayland one too?
An yes, I forgot that the Wayland mouse KCM was already done! That'll be in 5.13 too.
(In reply to jey.and.key from comment #30) > Jesus christ, maybe just not implement shit that you know you then wont let > user configure? Sorry about temper, the scroll wasn't working on chrome along with back and forth buttons (didn't realize the exclusivity)
That's a Chrome problem, since they handle their own scrolling. Please report it to them.
*** Bug 405203 has been marked as a duplicate of this bug. ***
A summary of that "dupe": it is a low priority accessibility feature that used to exist under evdev where you could use the keypad for controlling the mouse cursor. While it was said that "...mouse KCM is done...", I might beg to differ it was supposed to include every feature previously under evdev. If it was just about enabling the minimum configuration, then job done. I was able to learn about the XKB from the Arch Linux wiki and after creating the needed file in /etc/X11/xorg.conf.d/, all I had to do to (en|dis)able it was press SHIFT-NUMLOCK. Given that was all I needed, I figure it could be easy enough to implement in the mouse KCM, though I guess there would be a permission issue for creating that /etc file. I don't know how evdev managed to do it.
*** Bug 402740 has been marked as a duplicate of this bug. ***
This is effectively done now! We can track the remaining wishlist items separately.
Is there a way to get back some of the more extended mouse settings (such as scroll wheel scrolling speed)? While this is "fixed" as in "the absolutely essential minimal set of options is there", configurability is currently much more primitive than it was before the changeover.
(In reply to philipp.reichmuth from comment #41) > Is there a way to get back some of the more extended mouse settings (such as > scroll wheel scrolling speed)? While this is "fixed" as in "the absolutely > essential minimal set of options is there", configurability is currently > much more primitive than it was before the changeover. See Bug 403842.