Like you stated, the big problem is very fine movements just don't work in libinput. On X11/synaptics I can make movements as fine as rolling my fingertip in place on the touchpad, or drawing a minuscule circle, and it will pick it up. Libinput on the same touchpad does nothing, it's like it's stuck in molasses. And libinput has almost no configuration options so there's nothing I can even tweak.
I really hope they address this soon, or I'll be stuck on X11 forever!
Edit: I'm using a Thinkpad P1 Gen2, a top-tier recent-gen workstation laptop, and this is a big enough problem where it's forcing me to use X11 on Ubuntu 20.04.
I suspect this is more a hardware issue than software.
Just tried that on my Dell XPS on sway (wayland, thus libinput), and rolling the tip of my finger on the touchpad allows me to move the cursor in single-pixel increments on an unscaled 4k display. :/
Maybe this is a libinput issue specific to your touchpad type?
Sure windows has better gesture support but I've always felt them sluggish and controlling sway through the keyboard is lightning fast so I really have not missed gestures much. However for browser etc 2-finger swipe to go back would be nice to see
See this discussion: libinput's bus factor is 1, https://news.ycombinator.com/item?id=23254871
Likewise, there's no established, dependable, working-at-all way to sell something like this. You can sell things like BetterTouchTool on macOS (a small utility that makes the Touchbar more configurable), because closed-source is fine on mac and people are ready to open their wallets in exchange for a better UX. That's simply not possible on Linux, everything meaningful must be open source and free as in beer (and, for drivers, probably free in all other ways, too), or it either can't work structurally or won't because the philosophy behind Linux and its ecosystem is incompatible with that sort of thing. Hence, it won't happen unless someone really enjoys doing this, or does it for their own needs and gives it away and maybe even supports it long-term despite of the negative experience that can be (entitled people etc.)
As for companies with employees using Linux, I guess quite a few shops would probably be kinda happy if the UX got so crappy it became unusable, because office IT for an an all-Windows shop is easier and cheaper to run – network printing just works for everyone, ActiveDirectory works for everyone out of the box, IT can ensure everyone is on the latest Windows update, security solutions run everywhere, everyone can use all productivity tools you could ever buy and you can roll them out easily using policies, no weird graphics issues that prevent people from presenting, no expensive "exactly this laptop with exactly that configuration" hardware purchases, one-size-fits-all tech support, etc. pp. This is also one of the reasons why WSL2 is such a clever move – make Windows the best (corporate) Linux around and get another large swath of developers to use Windows. It's also probably going to solve a lot of the Linux UX issues, but not in a way that benefits Linux in the least.
My best guess is that it just isn't annoying enough to most people. Another way to understand this is to imagine what happens when you put someone with bad visual acuity in charge of font rendering: they'll think it's good enough, and you can't blame them. It _is_ good enough, as far as they can see (pun intended).
In any case, a non-kernel developer fixing it in a day of coding is IMHO wildly unrealistic. While I have 20 years of programming experience, I have zero experience with kernel development--which some of the most complex software in existence--let alone input stack development. I don't even have the domain vocabulary to describe the problem. A lumberjack might know how to cut wood, but that doesn't automatically make him a carpenter.
You get the entire GNU/Linux desktop for free, so you aren't in a position to complain. If you value your precious spare time, part with some of your money. Pay someone to fix this for you. Ask your employer to pay someone so that your "tool" works. Whatever.
> In any case, a non-kernel developer fixing it in a day of coding is IMHO wildly unrealistic.
Please... at least read the linked issue to see what the problem really is. This isn't kernel development. This is a userspace library, and the problem in question is isolated to a single C function that spans one or two screens. This really isn't rocket science. I wouldn't hesitate to ask students to fix an issue like this in a followup programming course.
I would buy that argument if we were talking about some new technology that still has some warts. But we're talking about trackpads here. Technology deployed on the scale of billions of units over many decades. At some point users must demand a basic standard of quality for technology that is not only old, but ubiquitous. If libinput shipped a version that randomly duplicated keystrokes on a keyboard, I'd be the one on the hook to fix it and I'm not allowed to complain because it's free? Really?
> This isn't kernel development.
This perfectly illustrates my point. My day job is not in this sector and I don't even know the right place to start looking. And I'm supposed to fix this in just a day, like any old amateur student supposedly could, otherwise it's my fault? Give me a break.
Edit: In this very thread we have one user who submitted a kernel patch that possibly might solve this (but who knows), and another user who points to a year-old libinput bug that possibly might be what I'm talking about (but who knows). Not even the experts agree on where the problem even lies, but I'm supposed to fix it in a day. OK, right.
You may want to experiment with your desktop environment's mouse settings, and if that doesn't help, you should consider providing a detailed report to the libinput folks and see if they can address it.
All software is broken in some way, so everyone says yes to shipping something that's broken. All things considered, it's not an important feature, especially considering it has a work-around. They have have the ticket for the issue and it's on a backlog. As with all software projects, they have to triage bugs, prioritize their work and allocate resources. The awesome thing about open source is that anyone can create a patch for the fix, and resolve it for everyone.
Compare this to some Apple Radar bugs that are old enough to vote, but only Apple employees can fix.
Key word here is community - it's not just up to the maintainers and regular contributors (who may already be overtaxed with both their day jobs and managing the software project for no pay). Users who have a particularly urgent itch to scratch have to step up - if they're not technical, perhaps put a bounty on the fix so someone else is financially motivated to fix it. Abusing (IMO) maintainers by screaming at them to hurry-up-and-fix-it is not helpful, especially since they are volunteering their free time.
Just to provide one anecdotal example, I have a Asus Zenbook Windows 10 laptop (OEM installed), where the touchpad just randomly breaks after some Windows updates every few years.
Right now my laptop isn't recognizing any multi touch gestures, which makes scrolling a pain in the ass.
I can't exactly remember what I did to fix it the last time, but it involved downloading some drivers from the touchpad manufacturers website (not the laptop vendor), which looked really dodgy. A non-technical user would have zero chance of getting it to work.
For a technical user such as myself, it would be much easier to recompile libinput with some patch I grabbed from their issue tracker.
As a bonus, there's less chance of getting malware from the latter than going to some Asian hardware manufacturer's poorly translated website in search of a compatible driver download.
(I'm referring to "Press the lower right corner of the touchpad to right-click" box. The Dells that the school I teach at has are near unusable with this clicked, but improve significantly with it off and using two-fingers to right click instead).
I've not had any problem before with clicks being misinterpreted this way, though.
I just timed myself doing it on a fresh vagrant VM, and it took me less than two minutes. One full minute was downloading and installing build dependencies, and that would normally be a few seconds as most people already have gcc.
The steps I took were:
sudo apt build-dep libinput
sudo apt install fakeroot
apt source libinput
cd libinput-1.12.6/
grep -r tp_detect
vim src/evdev-mt-touchpad.c
dpkg-buildpackage -b
sudo dpkg -i -O ../libinput*.deb
Free software often is free as in beer, but the real point is that we can, and we should, participate. Throwing money through GitHub Sponsors is one option, but often the best way is to just roll your sleeves up and do the work.
I thought that there were like a billion ways to do this -- pbuilder, debootstrap, fakeroot, sbuild, ./debian/rules, probably a few others I'm forgetting. Every time I've interacted with this over the last decade it's given me a headache.
In 2020, is `dpkg-buildpackage` the official way to do this? It seems very easy!
The other options are good if you need to ensure the package will build elsewhere, or if you need to cross build for a different architecture (which you might need if you're running a multiarch system and you need to patch a library like Mesa that's still needed by some 32 bit apps), or if you don't want to clog your system with build deps or something like that.
Last time I needed to do that, I used cowbuilder, but I'm not really an expert in this area, I'm just a Debian power user, not involved with the project directly.
Without the reference you've provided here I would estimate about three hours for me to do all of that, and that might be pretty optimistic. From figuring out what to search for, to understanding the code that needs to change, to making the change, to building it, to determining what's ~~best practice~~ at least not worst practice for installing it.
And I'm someone who's fairly confident in my abilities, has been using linux for about 15 years, and is comfortable in C and familiar with other packaging systems.
I'm sure I could come up with at least a dozen exercises like this that would take me under a minute but would take the average HN reader hours if not days to complete.
My point is that it's incredibly unfair to take something with which you're obviously quite familiar with and claim it takes less time than buying an app online, just because with experience you can do it that fast.
You're kind of right and kind of not. It is indeed incredibly unfair to claim that anyone can do it in 2 minutes if I could, especially considering that I did it this fast after mentally preparing to do it fast to demonstrate that it can be done fast.
But also remember that I really do believe that we should all participate in the development of the software that we get to use for free. Fixing a bug in some piece of software should, in my opinion, be the most normal thing you do every once in a while. Just like everyone can use a screwdriver at home, every programmer should be able to modify, build and run the software they use. If we did live in such a world, this wouldn't be specialized knowledge, this would really be something most people could do under 10 minutes.
Yeah, I realize that we don't live in a such a world. But please don't take away my hope that if we all try hard enough, one day we just might. :-)
Tried it on the integrated 13" FHD screen as well as on an external 24" FHD screen. I can move the cursors easily along the branches of the Y in page header.
I'm also on a P1gen2. I just added support for the Trackpoint/Thinkpad through the more advanced RMI4 interface in the kernel, instead of going through PS/2 emulation mode:
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.g... https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.g...
This will be in Linux 5.10 and should improve things quite a bit.
Also you said Trackpoint/Thinkpad. Did you mean Trackpoint/Trackpad?
I would've assumed this was a hardware issue - what else do we have set up differently?
I believe there is also a tweaks dB to set better values for known hardware.
Holy shit, you're right! I never noticed! There goes my plan to play old FPS games (like Wolfenstein: Enemy Territory) on Linux without any major hassle…
† N=1, but it worked fine before libinput (using 'xset m 1 0').
Summary for those interested:
- flat profile didn't actually work on touchpads.
- a fix was merged into master on 2020-05-27. [0]
- judging by the merge date and tag dates, the fix is included in libinput 1.15.6 (released 2020-06-18) [1]
- Ubuntu 20.04 reports libinput 1.15.5. I hope they upgrade it so I can use Ubuntu on my laptop.
- My Arch install reports libinput 1.16.2
[0] https://gitlab.freedesktop.org/libinput/libinput/-/commit/03...
[1] https://gitlab.freedesktop.org/libinput/libinput/-/tags/1.15...