I still have no idea what this project is trying to do exactly.

I always got decent multitouch on linux (when the touchpad is even recognized, but that's another problem).

The first post's discussion is here: https://news.ycombinator.com/item?id=17547817

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

Povilas from the linked blog post here.

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.

And sadly their audio stack too, down to drivers which are hard/impossible to get to work in recent machines.

A total waste because the latest Pixelbook Go is both really cheap and high quality.

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.

Oh, that's bad. I tried one and the machine looked fine. But it was only a 30 min test.

Is there something about the standard Linux input stack that makes it especially difficult to create a great touchpad experience?

Apple got it right a long time ago, ChromeOS is good, and Windows is too. What's different about Linux?

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.

That's the difference.

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

If one laptop vendor provides a particularly stellar experience, then it would gain in popularity and encourage others to compete.

A "jack of all trades, master of none" approach would only condemn everyone to mediocrity.

I think you're overestimating how much hardware manufacturers care about the Linux market.

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.

also, why create a linux driver when drivers for other OS's can have phone home/telemetry/postsales monetization/etc

You have to start somewhere.

I'd argue that mediocre on most hardware and excellent on a few particular models is better than mediocre everywhere.

And they both are upstreaming improvements for those supported products.

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

Linux input still sucks with hardware that works great on other OS's.

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.

Apple got it right because they built a stable api around it, and integrated all their applications with it.

Linux hasn't got it right because there is still no unified api, even if there was, all apps must implement it to be useful.

This is where OP push comes in. To make all of this possible through donations. You should read his older blog posts. They're worth a read.

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.

> Apple got it right a long time ago, ChromeOS is good, and Windows is too

frankly even in 2020 I have yet to find one non-mac-hardware which is 50% as good as the apple touchpad experience

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?

i believe chromeos uses a custom kernel with their own stack.

ChromeOS has taken the path of Android on a lot of things, so drivers are usually hard to mainline.