p12tic

All of these are great, but perhaps the most important would be money as it's the only thing that clearly indicates the level of community support. Once there's funding it's much easier to prioritize the work.

I've setup Patreon page at https://www.patreon.com/p12tic

I've created a Patreon page: https://www.patreon.com/p12tic.

Thanks!

It seems like there's at least some interest, you were the one that pushed me over the fence :-)

I've created a Patreon page: https://www.patreon.com/p12tic.

I think it does not make sense to involve X.org as we all want as little bureaucracy as possible because all that time is better spent in software development.

I think something around $4000 monthly would be enough for release management duties and minimal maintenance. Of course just one person part-time is not enough for large-scale changes, but for resolving regressions and just making sure contributions of other people are being merged, it's enough. I've been doing exactly that for the last half year.

> though you're not clear whether it's time, money or community you're asking for

All of these, but perhaps the most important would be money as it's the only thing that clearly indicates the level of community support. Once there's funding it's much easier to prioritize the work.

On Debian it's the same. I use Debian packages as the means to ship code to test devices and the most time consuming thing when converting X server from autotools to meson was the default configure flags (meson and autotools use different formats).

My own experience working on X server, clean ccache-based rebuild is a couple minutes faster on meson compared to autotools. These minutes add up quickly, switching my workflow to meson paid for itself the same day.

At least I would not have been driving this release.

Maybe someone else would have stepped up, it's hard to say. However there was no release manager for the last several years, so the likelihood of this outcome would have been small.

Hi, I'm the release manager responsible for this X release seeing the light.

This release would not have happened if an effort to improve touchpad support in Linux was not funded for the past year and half. X server 21.1 makes touchpad gesture functionality support universal so it's much easier to offer consistent user experience for everyone and downstream developers are less reluctant to accept contributions.

Thanks a lot to all the sponsors: https://github.com/sponsors/gitclear

By the way, I wonder if there is demand for long-term maintenance of X server specifically. If you think you could contribute, maybe write here and if there's enough interest maybe it's possible to crowd fund something.

Hey, thanks for interest in donating to the project.

I'm Povilas, the developer from the linked blog post.

If the donation is less than $100 you could setup a monthly donation on GitHub and then cancel it after the first payment.

Otherwise, you can contact me at "povilas@radix.lt". To verify the authenticity of this email address you can view my GitHub profile at https://github.com/p12tic, or check out https://github.com/p12tic/xorg-xorgproto/tree/p12-gestures branch and verify the author email of the last commit in the branch.

Whoops, I forgot the link to the results of the poll:

[1]: https://bill.harding.blog/2020/06/22/linux-touchpad-project-...

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.

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!

Fixing issues like this is the primary goal of this project. Unfortunately there's a long way to go.

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.

Povilas from the linked blog post.

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 think you should thank Peter Hutterer for his contributions to libinput. I'm just a random developer who loves complex problems and free software and was also interested in trying to improve Linux touchpad support :-)

> AFAIK GTK4 will be Wayland-only and out in a few months

I think this is incorrect. See the following, X11 backend is listed among supported backends. https://developer.gnome.org/gtk4/stable/extra-configuration-...

Say you have a widget toolkit that doesn't support touchpad gestures. The maintainers of that widget toolkit would be more willing to integrate this feature if there's support in both Xorg and Wayland compared to Wayland alone.

> To be clear, you're saying that implementation in the applications/toolkits ecosystem is the barrier to a better trackpad experience on Linux and that by unifying the feature set of both X and Wayland, this will encourage that implementation among the developers of the applications/toolkits?

Yes, exactly. AFAIK only Gtk right now supports any kind of touchpad gestures on Linux. Also, most of the users are still on Xorg and it's right now unknown when Wayland will be the default universally. So we would be in a weak position to demand maintainers attention, as there's little immediate benefit.

Povilas from the linked blog here.

In open source often no one really cares about a suggested feature or even a submitted pull requests. It means additional work for the project maintainers - discussing design, reviewing code and handling of eventual bug fixes. Often the person who made a PR disappears leaving all future bugs the problem of the maintainer. So naturally project maintainers are risk averse and often say no to new features. Things end up not being implemented, not because it's technically difficult, or there's nobody willing to do the work, but because the incentives don't align.

The above opinion applies to open source in general as I've witnessed during the past decade. I'm not describing any projects that are related touchpad or input that I've been interacting with lately.

Our work on X will expose enough information to the window manager and the applications to implement workspace switching in the way you describe.

Fusuma is not integrated with the display server, so it's limited in what it can do.

Povilas from the linked article.

It's not obvious, but adding touchpad gesture support to X will benefit you too even if you're not using X.

This will make our work of convincing the maintainers of other open source projects much easier. X and Wayland cover essentially al Linux users, so we will not need to estimate how many users will benefit from implementing gesture support in toolkit X or application Y.

This is really important, because maintainers of open source projects don't usually care about suggested features if they're not interested in them themselves. A new feature means additional work to them - discussing the design, reviewing PRs and handling of eventual bugs. Often the person who implements a feature disappears after the PR is merged. This makes the maintainers to view all feature proposals with a grain of salt. We need to have a convincing story of how majority end users would benefit in order to make the contributions easier.

Povilas from the linked article here.

Having support in X (even if only in proposal stage) will allow much easier work in the toolkit and application layers. X and Wayland cover essentially al Linux users, so we will not need to estimate how many users will benefit from implementing gesture support in toolkit X or application Y. It will make convincing project maintainers easier.

This is really important, because maintainers of open source projects don't usually care about suggested features if they're not interested in them themselves. A new feature means additional work to them - discussing the design, reviewing PRs and handling of eventual bugs. Often the person who implements a feature disappears after the PR is merged. This makes the maintainers to view all feature proposals with a grain of salt. We need to have a convincing story of how majority end users would benefit in order to make the contributions easier.

Technical skill is not enough when contributing in open source. Politics are often as important.

Povilas from linked article here. The design of how libinput handles gestures is exactly like you describe - the application will get a Start event when a gesture is identified, an Update event when finger position change and an End event when the gesture completes. This will allow to implement the macOS gestures in the end. There are more complex details of course, but the basic point stands.