Q3 Linux touchpad update: Multitouch gesture test packages now ready

> 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.

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!

Yes!

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).

Sounds great compared to my Linux experience where the touchpad stops working completely after waking up from sleep because of kernel regressions.

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"?

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 would fix it if I knew how. Commenting out that line sounds like a bandaid to me. I don't know enough about the input stack to tell.

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.

Because beggars can’t be choosers.

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.

Which other companies do you think should be pitching in but aren't?

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.

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.

And they both are upstreaming improvements for those supported products.

For example: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

That's exactly not the point.

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.