For my last couple of laptops I've used libinput first because everyone says it's the best option, but it always feels incredibly hard to perform small, precise movements. For example: try moving the mouse in a small circle (perhaps the size of the "Y" logo above). So both times I ended up switching to the old synaptics driver which seems to work better. I hope this project helps fix that so I'm sponsoring it
Agreed. I'd love to use Wayland for everyday use but the libinput touchpad drivers are impossible.
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.
You're most likely experiencing https://gitlab.freedesktop.org/libinput/libinput/-/issues/28.... The workaround is very simple: just comment out the tp_detect_wobbling call in tp_process_state. The real fix is a bit more involved, and I've been meaning to get to it for the last few years, but since commenting out that one line just works, there's little motivation.
I agree that this isn't an ideal user experience. On the other hand, recompiling libinput in 2020 takes about as much time as taking out a credit card from your wallet and paying for another closed source macOS app.
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.
Oh and I'm tempted to argue that this is, in fact, a user experience we deserve. ThinkPads are used by many developers worldwide. Most of my friends at Red Hat have it. Last time I could check (2011), Google gave developers ThinkPads with Linux as one of the options. Any single one of us could have fixed this bug in one day, and then spend maybe another full day communicating with Peter to get the fix in shape and merged. Yet it still isn't fixed.
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.
> On the other hand, recompiling libinput in 2020 takes about as much time as taking out a credit card from your wallet and paying for another closed source macOS app.
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.
> My point is that it's incredibly unfair to take something with which you're obviously quite familiar with and claim it takes longer 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. :-)
I see what you're getting at, but you're missing that not everyone can be a specialist at libinput development, someone might spend his day developing software for 3D rendering, someone else is a data scientist, a third one designs websites. It makes more sense that each one spends his time doing what he does well instead of spending 4 hours figuring out how to modify libinput.
Wow, I've never seen it so clearly described how to download/modify/rebuild/install a debian package before.
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!
There are a million ways to do it, but dpkg-buildpackage has been here for ages and if all you need is rebuilding a package for your personal use and for your current system and architecture and don't mind installing builddeps into your system, it's definitely the easiest.
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.
As compared to any year of windows on the desktop where my touchpad randomly registers right click rather than simple tap and drivers are closed so I can't fix it? I'll take the possibility to recompile.
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.
You can easily turn off the "right side of trackpad is right click" thing. I don't know why this ships turned on, given so many machines implement it poorly, but it's just one config checkbox to turn a trackpad that is awful this way to one that is OK.
(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).
There's always some anecdote with worse outcome. Someone else will have a touchpad which doesn't work at all on windows. Someone else's sets the house on fire under Linux, etc. My point is you have the chance to fix on one side though. It may not be practical or something most people can do. But it's there.
YES to shipping something that's broken for many people, but that at least 1 in 1000 of them will dig up some esoteric knowledge, patch and recompile packages that many others depend upon, and "fix it"?
> YES to shipping something that's broken for many people, but that at least 1 in 1000 of them will dig up some esoteric knowledge, patch and recompile packages that many others depend upon, and "fix 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.
Sure, but the impact here is pretty massive. Pointing to a workaround that most people won't find and that takes developer knowledge to employ is of limited value to most users, but in the open source community is often used as an excuse to ignore what would otherwise be high priority bugs.
> ...but in the open source community is often used as an excuse to ignore what would otherwise be high priority bugs.
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.
"They" is really Red Hat, who are the ones pushing libinput and Wayland in the first place; and I imagine they would have no problem fixing this quickly if they hired more than one person to work on it.
I don't think this is as much about Red Hat not caring as it is people in general not caring. This issue is affecting many ThinkPads. I've seen it on T25, T470 and T440p, which happens to be the most popular laptop of /r/thinkpad these days as it's easy to take apart and switch components, and as we've seen in this thread it affects many other ThinkPads as well. So we're talking about thousands, possibly tens of thousands of hackers having a suboptimal touchpad experience, every one of them being able to fix it in a day of coding. No one did yet. Why?
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).
Personally, I see my laptop as a tool, and I have a day job. I don't want to spend my precious spare time fixing my tools, which for something as basic and ubiquitous as a trackpad should just work already. For how many decades have trackpads existed? Why are we still shipping broken trackpad experiences, and why is it me, the end user, who is being told that if I don't fix it myself then I don't care enough?
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.
> I don't want to spend my precious spare time fixing my tools…
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.
> You get the entire GNU/Linux desktop for free, so you aren't in a position to complain.
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.
Because there are very, very few companies actually depending on Linux touchpad drivers in any meaningful way, and of those, most of those few are happy to take what they get for free and if they contribute at all (tiny tiny minority already), they'll rather do that with a more visible core component that actually powers their business.
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.
When you say it like that it sounds like people are begging RedHat to step in and do their tech support for them. When in actual fact in the case of things like libinput and systemd they were developed at RedHat and I imagine that they also exerted some influence to increase their adoption. In these specific cases (high profile projects with a few noticeable issues) it makes sense to go back to the people who developed and maintain them to say "Can you please fix these issues"
Canonical used to have an entire team dedicated to touch input. Their contributions were rejected by the Linux community because he was already working on his own solution.
Don’t other large companies issue Linux laptops to their employees? I’d think somewhere like Google or Amazon would find it worthwhile to devote some funds to improving desktop Linux.
> 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'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:
> In 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
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?
Lots of touchpads (most, I believe) trigger hysteresis in libinput unnecessarily, either because of a declared fuzz value by the touchpad or because of the broken heuristic, and it's mushy afterwards. But no, it's not all.
Agreed. Libinput on an XPS, having no issues over here. I actually prefer it to my past MBP's from 10 years. Tested on the 2015, 2017, and 2019 models and libinput/XPS is much nicer to use.
100% agree with you. I have XPS 15 (9570) and I use libinput on sway. I have dual boot with W10 and I'm always amazed how much better the touchpad feels on linux.
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
I'm using Wayland and libinput on an X1 Carbon, which I'd expect to use a very comparable touchpad, and it works flawlessly. I easily can move the mouse by individual pixels by just rolling my finger, or throw it across the screen.
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.
I'm guessing it has to do with the trackpads' sensor resolution. MacBooks and newer laptops have high resolution glass trackpads that are much more precise
Odd, I'm using libinput (Dell XPS 9380), and don't see the problems you describe. With my index finger on the touchpad, I can "roll" my finger a little in any direction (without actually sliding the finger), and the mouse moves a few pixels immediately. It's hard to get single-pixel accuracy, but 2-pixel accuracy is doable. I also have no trouble tracing the Y Combinator logo.
I also have a dell xps but I'm on X11 right now due to teams screen sharing. I also have no problems doing exactly the same thing while my sisters MSI laptop on windows makes it almost impossible to move the pointer less than an cm on screen.
I suspect this is more a hardware issue than software.
Nah, it's software that has a broken logic for when to enable hysteresis for a touchpad and make it mushy, when most touchpads that it does this for will do much better without it.
That's strange, I'm running Ubuntu 20.04 on a MacBook Air, and I have no problems moving my cursor in a small circle around the "Y". Probably the only thing I do differently from the default is that I use Wayland instead of Xorg. I don't have any proprietary additional drivers installed.
I would've assumed this was a hardware issue - what else do we have set up differently?
As others have said, I'm not noticing this issue either on my HP ProBook 430 g5. It has a Synaptics touchpad, though not sure which model. xinput says "SYNA3067:00 06CB:8265 Touchpad".
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 think this is an intentional driver setting to avoid false touches/moves on crappy hardware. You can likely tweak it but I think that’s entirely the sort of thing the post author was trying to work on.
I believe there is also a tweaks dB to set better values for known hardware.
> For example: try moving the mouse in a small circle (perhaps the size of the "Y" logo above)
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…
It’s too bad we can’t condense all the rhetoric “i use Apple <x> because it just works” into actual useful energy. Something like this may have been solved a long time ago.
Glad to see movement about this. Was just considering converting my XPS 9560 into a full Linux machine next week (I will miss fingerprint sensor support, which brings up another point about just upgrading to a model that supports it). Going to use it as a testing ground for switching over my main rig to Linux and seeing progress like this is really encouraging that I’m making the right decision.
I will gladly install these test packages and help out.
I get the reasons recurring sponsorship helps projects, but is there any chance to sponsor as a one time payment?
As a resident of a non-USD country, my bank shafts me for foreign currency payments, which is partly a fixed fee and partly driven by the total amount. Therefore lots of small payments ends up paying a much larger portion to the bank, money that I'd otherwise prefer the project got!
You can use a service like Transferwise which charges you the market rate. A lot of expats and remote workers(including myself) use it to get paid and avoid currency changing. Or you can get cards which do the same thing (e.g. I have a Curve card is linked to my other bank cards). It depends which country you live in, these options are fairly straighforward in the EU. There are a few services which these cards don't work with, like pay-at-pump gas stations, but I've yet to find somewhere online it doesn't work. May be overkill for a one-off payment though.
> but is there any chance to sponsor as a one time payment?
You can simply start a monthly plan, then cancel it once the first payment is gone. It's a bit more overhead, but if you believe in it, it's worth it. (edit: never mind, this is not possible apparently, GitHub charges you for a whole year)
Also, slightly off-topic, and this entirely depends on where you live. Regarding your bank, you may be able to look into start up banks (also called Neo banks), they often have zero foreign currency fees and exchange at the Master Card or Visa base exchange rate. This has in the past saved me a huge amount, mostly for travel to foreign countries, but also for purchases, however, receiving money is the same.
As examples, in the UK we have Starling, Monzo and some others that all give you zero foreign exchange transaction fees. In many European countries Revolut is available (also in the UK), but I closed my account with them for ethical reasons. There is undoubtedly more neo banks available especially in the development world but you will need to do research for your country.
> I still have no idea what this project is trying to do exactly.
Raise funds, basically.
Getting too specific about their development plans would interfere with that. People spend money based on emotion and shiny things. Yes, even Linux users.
It's okay, neither does the blog author. Despite their only value-add being a PM-role, they aren't doing a good job of that either.
As evidenced by the fact that they've basically just resorted to doing tons of retrofit to bring benefits that already exist in Wayland to a legacy, deprecated, aging stack. (literally every single change listed). Also, it's no longer just about improving the touchpad (since libinput is already pushing the envelope there), and instead ... X11 Gestures? Okay? (Good luck to those brave enough to install a patched X11 from a PPA!)
I feel sorry for the people who thought there was enough substance to donate. How this project progresses with increasingly less clarity and continues to be celebrated here deeply confuses me.
The reasons why we chose the current path were explained in detail in the blog posts.
Touchpad gestures was the most popular feature to implement. In order to do that we needed a good reason why all the other project maintainers would want to spend time discussing a feature with us. Wayland is the future, yes, but currently a lot of users are still on X which makes our argument much less convincing. Now we can say that touchpad gestures will soon be available everywhere and get their attention this way.
I agree that X is legacy platform. Unfortunately it may still be used for quite some time. Core functionality such as screenshots and input record/replay is not universally available on Wayland. So X will still be used for significant amount of time.
Please tell me what else I could explain to increase the transparency of the project and I'll try my best to do so. Thanks!
> Core functionality such as screenshots and input record/replay is not universally available on Wayland. So X will still be used for significant amount of time.
This is exactly my case. For me it's the difference between earning money or not working: I do some screen sharing with my customers every day. Wayland is not an option for me yet.
Did you actually talk to other project maintainers and get feedback that they would only be interested if it were also available for X before starting down this path?
I haven't asked this question unfortunately. Adding touchpad gestures needs changes in every GUI toolkit library except GTK and every application we would like to support. So I trusted my own experience of seeing the amount of effort needed to contribute an improvement for niche use cases. To make matters worse, an initial OK from a maintainer often does not really mean a lot. What matters is the actual time commitment to discuss design and review patches. Issues that increase the amount of effort needed for long-term maintenance and end-user support tend to decrease maintainer engagement a lot. Wayland-only touchpad gestures splits the user-base long term and thus fits this criteria very well.
At this moment I'm not really sure if I would go the same path had I knew all the information I know now. Having said that, we've only spent around a single man-month of effort working on this. In the grand scheme of things this detour is tiny.
The whole ChromeOS UI and input stack is entirely different from a typical Linux desktop. I'm not sure there's a lot there that could be shared out to the Linux X11 desktop world.
The Pixelbook Go drops/skips samples all the time, and resamples everything to 48k for no reason. With all the dropped samples it's an unlistenable mess. Only works if you don't touch the machine at all while listening and have no background tabs. I don't think there's anything to be learned from this, except as counterexamples.
Apple supports only their own touchpads, ChromeOS also selected ones. Windows provides the great experience only for the Precision touchpads (i.e. not even to Apples under Bootcamp). Linux is expected to work with random crap, that even its vendors have given up upon.
> Linux is expected to work with random crap, that even its vendors have given up upon.
What prevents Linux from picking ONE touchpad to optimize for? After all, both Lenovo and Dell are now shipping certain laptop models with official Linux support.
That brings you back to the days when you have to compare model numbers on every piece of equipment you buy to see if it is compatible, and discovering all to often that the compatible version was last year's model and the one you can buy isn't supported.
Casting a wide net is necessary if you don't want just a niche audience.
All of this is just woefully overestimating how important the desktop market is to manufacturers at this point, Windows and Apple included.
Hardware manufacturers care a lot about the Linux market. But that Linux is Android, not desktop machines. Yes, the linux desktop segment is a tiny fragment of the market, but that market itself is shrinking and has been for almost a decade.
The point was, that the other OSes picked specific hardware and they provide great experience only on that hand-picked hardware and nothing else. I specifically noted, that Apple touchpads do not work under Bootcamp as nicely as the Precision ones do, as an example.
I don't think so, I think it's mfgs skimping on the hardware. I have an xps 13 and it is incredibly precise. My old lenovo was ok. Not terrible but nothing like the xps. Which in my opinion beats a macbook pro.
Yes, Synaptics produces closed-source drivers for Windows and ChromeOS. ChromeOS also uses its own low-level input/graphics stack, not X11, so even if you had the code to it you wouldn't be able to just compile it on GNU/Linux.
What driver stack is Google using for ChromeOS? Is it proprietary? I assume all the Chromebooks have decent touchpad functionality, can't that be mainlined or whatever?
Sadly, It does not. I have thought about how to do it and its a lot of work and time I don't currently have unfortunately. Part of the reason I hope this project continues to make something like this easier
Thanks for the update! Curious, is there anything specific in terms of which platforms you're seeking testing help on (e.g. older macbooks, newer haptic touch macbooks, synaptics-based sensors)?
Currently we're focusing on touchpad gestures (i.e. multi-finger touch swipe or pinch) as the poll [1] made in June indicated that touchpad gestures was the most wanted feature.
There's plenty of work just implementing the basic handling of touchpad gestures, not even talking about any kind of polish. So at this moment we just assume that libinput handles touchpad gestures well and don't test at all. Once the basic parts are done we'll start polishing and this is when we'll test on as much hardware as possible.
Cool! I've been using libinput-gestures for a while now as a hackish way to accomplish multitouch gestures. It's easy to use and works well if anyone wants this functionality without waiting
I've tried this with an Apple Magic Trackpad 2 (the best stand-alone trackpad/touchpad available). It doesn't work smooth. It is very strict on the gestures (low fault tolerance?), unlike the very same device within a MBP (2015) on macOS.
I wonder about this though. To me it seems this is very important to get to work for alternative Linux-based smartphone OSes such as SFOS, pmOS, UT, PureOS, etc etc.
Yes I agree about the smoothness issues, however you can really improve things by adding the line `timeout 0` to your ~/.config/libinput-gestures.conf to set the threshold to the lowest setting. The comments here are from the end of their example config https://github.com/bulletmark/libinput-gestures/blob/master/...:
###############################################################################
# You can set a timeout on gestures from start to end. The default is
# the value commented below. It can be any value in float secs >= 0.
# 0 = no timeout. E.g. set it to 2 secs with "timeout 2".
timeout 0
I've never been a fan of Linux on laptops as I feel its DE is just not there yet and prefer to stick to the terminal or the desktop, but I switched my laptop to Linux about six months ago to re-assess and ran into a number of big issues, the most unexpected of which was the poor state of basic touchpad support, not to mention multitouch input support - I genuinely thought it would be a solved problem by now, but I can't blame anyone but myself given that it's open source and anyone is free to contribute a fix (read on).
IMHO the most egregious offender is libinput because everyone and their pet fish seem to be in a massive hurry to drop the proprietary synaptics driver and replace it with libinput; you're not allowed to ask for synaptics support because all distro and project maintainers will lecture you about "upgrading" to libinput which has "superior" touch and multitouch support... except libinput absolutely does not, even if it is theoretically architectured in a way that would enable superior touch/multitouch support someday.
The biggest problem is that the acceleration curves libinput uses are vastly inferior to those that ship out-of-the-box with other operating systems or the proprietary solutions from the manufacturers. When you read about the TrackPoint and the research that went into developing acceleration curves/profiles for input devices [0], it is hubris to think you can throw it all away and expect to still have a superior product.
Anyway, long story short, if you're using a synaptics or synaptics-compatible trackpad, the old synaptics drivers have the best (by far) acceleration profiles and feel the most natural to use, but they are not supported by multitouch plugins for the desktop environments. That's not to say the drivers don't have multitouch support: they do, and they accurately report all motions, but only as raw events.
I wrote this simple program to read the raw input from the synaptics driver and recognize two-, three-, four-, and five-finger tap and swipe gestures from the raw event stream generated by the synaptics driver per the kernel multi-touch protocol [1]. I initially wrote it in an evening after studying the protocol to get just simple back/forward swipe navigations working with the only actually good touchpad drivers for Linux I could find (the synaptics one), and intended to clean it up before throwing it on GitHub for anyone else that might find it interesting but realized I wasn't sufficiently motivated to clean it up anytime soon so decided to just upload it as-is.
sygesture [2] is written in rust and processes the raw MT protocol events generated by the trackpad in real-time to recognize multitouch gestures. Currently it spawns an `evtest` instance rather than opening the input device directly, that was a hack to not have to deal with translating the binary protocol but adds a dependency on the `evtest` utility (should be in your package manager). The path to device is also hard-coded in `main.rs` (and currently it only supports a single input device), but all that is separated from the actual parsing logic because I planned on making that modular from the start, but never got around to it. The mapping of gesture to action is also hard-coded in `main.rs` and isn't currently configurable. (It's all very easy to change even if you don't know rust, as all it does is spawn a program with certain arguments in response to each motion.) I'll throw an MIT license in the repo as soon as I get a chance.
The utility is pretty bulletproof, even though the heuristic is fairly simple (the rationale behind the consensus algorithm is documented in the comments). It's extremely fast (don't have a reliable way to measure lag, but I'm extremely sensitive to it and don't detect any) and has low memory usage (CPU usage is basically zero except for the duration of a gesture, if you're polling at a high-enough frequency to pick up on that).
Something not accounted for at all in the code is support for non-swipe gestures such as pinch-to-zoom and (has anyone ever used it?) "circle gesture" that can be apparently be used for weird things.
Hey, this sounds awesome! Thanks for sharing. Please consider putting all this info in the GitHub readme, it's useful for anyone who wants to pick up the project. Also please consider posting this on relevant mailing lists.
I updated my PopOS packages today. My touchpad accel changed, my two-finger scroll broke, and I am left with a bunch of debugging to do and an urge to switch to Guix full-time. I came back to this HN thread and was delighted to find your post.
For what it's worth, I was very critical after the last update due to the lack of focus on Wayland. So much so, that I actually pulled my funding. However, Povilas was kind enough to come into the comments and explain their reasoning more thoroughly and managed to change my mind.
Today I restarted my, decidedly small, contribution. Even if I'm frustrated with the amount of work there is to do, I'd rather the project be thorough and really attempt to be a unifying solution to this problem.
Indeed this is a valid point, thanks. On the X server applications will get touchpad gestures regardless of whether one is running Plasma or GNOME. However, workspace-wide gestures are not implemented in either on X yet.
On Wayland the display server is the one which handles workspace-wide gestures. Additionally, all events go through it to the applications. Perfect touchpad gesture support needs support in both. As far as I know Mutter (GNOME) handles both parts already and KWin (Plasma) currently handles neither.
Implementing touchpad gestures on Plasma would fall within this initiative, I will most likely work on that at some point in the future. Please vote in the poll so that we know this is important to you.
I'm not entirely sure if it's built into Plasma, but I remember having a (hacky, not with direct response) workspace switching gesture on Manjaro (Wayland, of course).
I read through the post, but still am not totally sure: will Wayland eventually be supported? What about wlroots vs mutter? Is that a distinction that needs to be made?
Is it still almost impossible to adjust the mouse and trackpad scroll speed/sensitivity, something that has been set by an easy-to-find slider in every operating system ever written since the invention of the scroll wheel, in Linux?
