I’m never sure whether to put these in rants or in the topically correct technical forum. It’s kinda ranty, but in a technical way about a Linux matter. If I had a Linux blog, it would not be off-topic.
A while ago, an anonymous poster wrote in the Linux forum about the poor support that Mint (which is no different than any other Linux distro in terms of the drivers available) has for touchpads, in his/her opinion. I wrote that I think the touchpad support is quite good, and I mentioned that I much prefer the synaptics driver (which, despite its name, is not a product of the Synaptics company, nor is it only for Synaptics touchpads) over the newer libinput driver. It’s the synaptics driver that makes my statement about Linux having great touchpad support true, in my opinion. If libinput was all there was, I’d agree with anonymous completely, and I can see how he or she would come to that conclusion based on how a given Linux distro works out of the box, so to speak.
Libinput is supposed to be the next-gen input driver that handles all input devices, whether they be keyboards, mice, touchpads, touchscreens, pointing sticks (the little eraser like thing in the keyboard of some laptops, like Thinkpads, famously), trackballs, joysticks… essentially anything input. It’s being designed in parallel with Wayland, which has different ways of handling input devices than the traditional X setup, and it’s the only input driver that works with Wayland. The older drivers, evdev (for everything other than touchpads, I think) and synaptics (touchpads) are written for X and don’t support Wayland.
Synaptics is now considered a legacy driver, as it is not in active development anymore (the devs for this are now some of the ones working on libinput), and distros recommend using libinput instead. Libinput has been out for five years now, so it should be pretty decent by now, right?
Well, in my opinion, no. While it is without question better now than when I first tried it, I still find it quite dreadful with mice and touchpads. On my desktop, I’m using evdev for the mouse, using the acceleration curves built into X11, and on my laptops, all four of them that are or have been recently in regular use in the past couple of years, I am using synaptics. I’ve tried libinput on each of them and found it unusable.
Well, maybe it’s just a matter of not having the right settings, right?
I wish that was all it was. One of the problems I have with libinput is that it is intentionally meant to have a lot fewer configuration options than the older drivers. The rationale given for this was that having so many options make the driver untestable, and that it is a ridiculous situation to expect users to have to mess with configurations and such to get the input devices to work properly. Most of the need for these options, they say, is to work around bugs that shouldn’t be there in the first place, so the real solution would be to fix the bugs, not provide workaround tools.
The new idea is that if you have a problem with the way the mouse or touchpad works, you’re supposed to file a bug about it and have them address it, whether it be by fixing an actual bug in the driver or by releasing a DPI override for the device in question, and if that is not enough, writing a “quirks” file that will be packaged with the next release of the libinput driver.
Is it truly reasonable to expect end users to install diagnostics packages, perform those diagnostics from the command line (after having to learn about things like input events and what they mean), then to file a bug report with the diagnostic info included, then to wait and hope the issue is resolved?
I don’t think it is reasonable or realistic to expect this.
When I installed Fedora recently, it (like most other distros) installed libinput by default for the touchpads on my Acer Swift and my Dell G3. I was not thinking of that specifically when the newly-installed OS first booted, but I noticed right away how lousy the touchpad feel was, and instantly I was reminded that I was back on libinput.
I tried (again, as I had attempted this years ago too) to use the available options to fix it, but nothing worked. The problem was that at low speeds, the sensitivity was far too high, making it difficult to hit small targets (like when trying to place the cursor between two letters of text) precisely, and at high speeds, the sensitivity was far too low, so I run out of room and have to lift my finger and place it on the touchpad again to get the pointer to where I want it.
I needed a significant increase in the amount of acceleration… not an increase in overall sensitivity (which would only make the problem at low speed worse), but an increase in the amount of added sensitivity with higher mouse speeds. I need a greater delta between the sensitivity at low speeds (~10mm/sec) and those at high speeds (~30mm/sec). Much higher speeds are possible with a touchpad, but I don’t tend to go that high in speed except when flinging for a scroll (a feature that works in synaptics, but is not in libinput, and probably will never be). Graphs that I’ve seen that depict the acceleration profile in libinput show that the acceleration doesn’t even begin at 30 mm/s, and that’s about the point that I want it to be reaching maximum!
Libinput, has two acceleration profiles (adaptive and flat, with the latter reflecting no acceleration), without most of the tunable parameters, including those that Xorg lists on their site as being applicable to all X input drivers. You get one scalar (the type of setting that uses a slider when there’s a UI for it) that has the effect of setting the acceleration curve to a higher peak speed, but it doesn’t change how soon, how steeply, or how smoothly the acceleration is applied, or how the mouse/touchpad slows (decelerates) at lower speed.
Annoyed, I installed synaptics and made sure that the system was configured to use it in /etc/X11/xorg.conf.d. In Linux, rebooting is not needed as much as in Windows when changing settings, so usually I do a logout and login cycle, which is much faster and just as effective. If that doesn’t do it, then I reboot. I’m not actually sure what I did in that case, but it was one of these.
Once I was back in, I went to the settings menu of KDE Plasma (like Windows Control Panel) and selected the Input Devices icon, then Touchpad. It’s all quite familiar to me, but I will describe it so that those who don’t know will get a mental picture of it.
Immediately, the number of options offered is greatly increased compared to what was there with libinput. Under the “pointer motion” tab, there were now three sliders, labeled “Minimum,” “Maximum,” and “Acceleration.” That’s exactly the kind of control I wanted in libinput! I set the Minimum almost all the way to the left, meaning almost the slowest speed possible, and moved the Maximum to the center-right of its slider. The Acceleration was also set to near the same position as the Maximum. After hitting Apply, it was vastly improved, and it was very intuitive and easy to use the three sliders to fine tune the performance to my own needs.
How is that a bad thing? It’s dead simple to understand, and the people who find that everything works nicely out of the box (so to speak) would never have any reason to go looking there anyway. Those three sliders allow the driver to cover nearly the entire spectrum of user expectations of what a touchpad should feel like, and if the settings are supported by the UI as they are in KDE, there’s no need for the user to go rooting around with config files at all. Just “set it and forget it,” as the guy on TV would say.
Was I really working around a bug when I used those options that were not found in libinput to tailor the feel and performance of the Dell G3’s touchpad (a “precision” touchpad, as reported by Windows 10) to my own preferences? If so, there were the same bugs in the Dell-branded Synaptics non-precision touchpad in my Inspiron 11, in the “precision” Elan touchpad in my Acer Swift, and the old, single-touch, definitely not precision Synaptics touchpad in my Core 2 Duo-era Asus. Interesting that the same bug would manifest with such varied touchpads (and I have the same complaint about libinput with my actual mouse on the desktop too). I must have terrible luck!
I suppose I could have downloaded and installed the diagnostic tool (which I did), discovered that it doesn’t generate any valid data (which I did), and then manually written the DPI file and found that it doesn’t have any effect either (which I did), then filed the bug with libinput even without the DPI data they requested, then waited for the devs to get back to me and find out whatever other data they needed, and then to fix it. I didn’t do that last bit.
That probably would have taken more than the minute or two that it took to fix the problem with synaptics, I’m thinking.
The supposedly untestable driver that hasn’t been developed in years is still, after half a decade of active development on its replacement, far better than that replacement for all of my laptop use cases. The idea that the main function of all of those options in synaptic is to allow people to work around bugs that wouldn’t be there in the first place with a simpler driver that was focused on getting things right, without requiring the user to configure it, is just nonsense. The idea that there is such a thing as “just right” that covers all use cases and all users is also nonsense.
Perhaps these deficiencies can be corrected in libinput with quirks, which supposedly can override the lack of the usual options in the driver. Well, yes, maybe it can… but if the libinput devs think the nasty acceleration curve they provide is what people want/expect, they’re probably not going to encode my expectations into a quirk for all users of the touchpad models my laptops use. Just because I want my touchpads to behave that way doesn’t mean everyone who uses those same touchpads will automatically agree. There’s no such thing as a “correct” setup!
What this suggests to me is that the driver actually is capable of having its performance modified in the manner I want, just like synaptics, but they’ve chosen not to expose those options in a way that the public can easily make use of them. Not only is that a cynical ploy to force people to contribute device data essentially as ransom for the kind of adequate performance that used to be available just by changing settings, but it also makes me question whether the options had to be removed to make the driver more stable and testable if they are actually still present, but hidden.
It turns out that a lot of complexity in something like an input driver is a reflection not just of the diversity of input devices the driver is meant to work with, but of the minds of the users themselves. Different people have different needs and desires, and you can’t make it “just right” or even “kinda right” for all people at the same time. It might be harder to test and maintain a thing with more options, but it’s better to have a complicated driver with a lot of options that might have more undiscovered bugs that render the driver unfit for a given person’s use case (until the bug is fixed) than a driver that definitely will be unfit for a certain percentage of users because it assumes that there is a single “right” way to do things.
That is about where I am right now, where the untestable driver is beautiful and the new, improved, simpler, testable, “just works” driver is still terrible after five years. I’m perfectly happy to keep using the old driver, but I’m not at all certain that it will always work. If at some point Wayland gets to the point that it becomes a dependency for KDE Plasma, libinput will become mandatory, and then I would be stuck with the poor touchpad support that anonymous mentioned. A “legacy” driver can stop working at any time if there’s no one to fix it when some other change elsewhere breaks it.
I’d like libinput to be usable, but with the development philosophy evinced by the devs of libinput so far, it doesn’t seem likely. They think there’s a single “correct” setup that reflects the way users expect a touchpad to act, and clearly, the way I want it to act is not at all like that. Even if I filed the bug and submitted the info, it’s quite likely that the only result would be that my touchpad behaves the way they think it should, not the way I think it should. That may be separate and distinct from being a bug to some people, but to me, it either works as I want it to or it does not. It probably is already at the point of behaving how they think it should, and no amount of bug filing would change that.
I’m quite evidently not the only one to have “incorrect” preferences, if you consider the volume of complaints about libinput that you can find across the web, and the high number of “just use synaptics” recommendations that are freely (and correctly, IMO) given in response to these complaints. Synaptics has some limitations, like incomplete multitouch support that makes implementing some multifinger gestures impossible, but that’s not a problem with my specific use case. I don’t use those anyway, and even if I did, having the pointer accurately move in the manner I expect is far more important.
These complaints about libinput don’t mean that the devs haven’t found the magical “correct” setup yet, though that’s probably their interpretation. What it really means is that there is no such thing as a singular, universally correct setup, even if you remove the variations in hardware from the picture.
I really like how I have synaptics set up right now, and to me it’s pretty dang close to perfect. Someone else could use my PC and find it to be horrible, even though it’s the same PC with the same touchpad and the same OS and driver and settings. There’s no such thing as “one [whatever] to rule them all” when it comes to computers, no matter how badly software devs pursuing the minimalism fad want it to be, because the people that use the things will always have different needs. The PC should adapt to the user, not force the user to adapt to it, and doing that requires some flexibility on the part of the PC, even if it is set up to a nominally ideal level as far as the hardware profile is concerned.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
