Hacker News Reader

Comment by p12tic | Hacker News Reader

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.

View on HN

Thanks for your efforts!

In my view there's absolutely space for Xorg in the future. Not every OS can run Wayland well and Wayland lacks some X features like network transparency.

I kinda hope it'll be backed by an organisation that's really keen on taking it forward. Augmenting the security model for example. And going back to some client rendering enabling features like anti-aliasing. I really think there's a lack of a viable remote display tool in Linux, where Windows has RDP. Block pushers are just too slow. VDI usecases are picking up again heavily, as do other security based techniques which could benefit, like remote browser isolation. Filling up my desktop with Windows running on a bunch of other computers is just so powerful.

So in other words I'd love to see an X12 that really moves towards the future. As I understand it, it's currently with RedHat which only sees future in Wayland and X is just on life support. I regret that because I see a lot of concepts in it that are still very valid and that have been lost in current alternatives.

Which OSes can't run Wayland well?

The last I checked, the BSDs and most other Unix-likes (and genuine Unix™ variants) don't support Wayland. In fact, Wayland is pretty much Linux-only in practice.

Wayland is viable on FreeBSD, at least. It is very much not “Linux-only”.

From the FreeBSD wiki:

https://wiki.freebsd.org/Graphics/Wayland

> While Wayland isn't ready for general use.

I can't readily find anything to indicate that this claim is out of date. I am aware that Wayland has been ported, but I have not heard of it being widely used, or being "production ready" as per se.

FreeBSD wiki is a bit notorious for being out-of-date, and that particular page is marked “CategoryStale”. Anyway, first result on DuckDuckGo is someone using Wayland on FreeBSD successfully [1].

[1]: https://euroquis.nl/freebsd/2021/03/16/wayland.html

Isn't that because FreeBSD provides an emulation of Linux?

No, wayland bits generally run well enough without needing the linuxolator.

> I really think there's a lack of a viable remote display tool in Linux, where Windows has RDP. Block pushers are just too slow. VDI usecases are picking up again heavily, as do other security based techniques which could benefit, like remote browser isolation. Filling up my desktop with Windows running on a bunch of other computers is just so powerful.

I think it's just a tooling problem; Apache Guacamole or Xpra can trivially stick windows in a browser window, VNC is... okay, not amazing, but passable, and even RDP can be made to work well on Linux, it's just that setting up any of those is a horrible pain on Linux (in my experience at least).

For Wayland there is waypipe for single-window forwarding over SSH, and there is wayvnc for wlroots-based compositors (Phosh, sway) which can run in headless mode with llvmpipe rendering, and weston has an RDP backend (but I recommend wlroots with wayvnc over weston).

X is a dead end. If you want an evolution of X with network transparency, Arcan seem to be the most likely alternative https://arcan-fe.com/2020/10/28/a12-advancing-network-transp...

I successfully use X11 and its network and OS transparency daily. Macbooks don't have 2TB of RAM or schedule 256 threads at the same time.

Arcan looks pretty amazing actually. I'll have a closer look at that over the coming days, thanks!

> Wayland lacks some X features like network transparency.

This, IMHO, is the most tragic loss in functionality desktop systems suffered.

It’s hard to justify being unable to do something we’ve done since the mid 90’s. The fact I could sit in front of a computer while running GUI software from different machines with different OSs as if they were local and that, now, the best I can hope for is what VNC gave me in the early 2000’s is nothing short of depressing.

I can relate as I'm one of the few people I personally know who has used that feature in the last twenty years. In the last ten years or so however, I used some variation of NX in any case, whenever I needed a remote X application, as then I typically need to preserve the session as well. I think the last time I used plain X11 protocol across the network was when I still had Sun Rays (between the Sun Ray server and the application's host).

Waypipe has entered the chat.

*waypipe kicked by admin (reason: "lol")

Ah ... the good old days of IRC :)

Wayland is not the only thing thats lead to this. Modern Qt apps work so badly over network transparency as to be totally unusable.

Yet another reason to dislike Qt.

Most toolkits now use client-side text rendering which makes using X strictly worse than VNC for remoting.

I routinely use a program that renders X protocol, gitk, remotely, forwarded via SSH tunnel through a Wireguard VPN.

If there is a better way to do that, I would welcome knowing it. Also, how one would achieve the same result for a Wayland program.

That will continue to work in Wayland, they haven't broken X forwarding. It works similarly to how XQuartz works on the mac.

X forwarding "just works" in Wayland via XWayland. None of that has changed significantly.

But I'm disappointed to see this myth keep popping up. X in general isn't "network transparent." Some X11 clients are, but only if they're built in a very specific way, which also tends to degrade performance locally.

Thanks for the effort you are putting into comments here lately! Maybe you have ideas on improving the "Are we Wayland yet?" site: https://github.com/mpsq/arewewaylandyet Yesterday I sent a PR for a "Missing" section.

There isn't much for me to say. To be honest, I would probably not contribute to that website. Wayland isn't that exciting of a technology and I don't think end users should even need to care about it or care that any of those utilities supports Wayland, if distro developers are doing their jobs then it will all "just work" and nobody has to worry about it. Also that website is misleading, many of those utilities are wlroots specific and not really useful on other implementations.

It may be an Ubuntu issue then. I’ve tried to start gnome-terminal on the Linux laptop from the Mac running XQuartz and what happened was a terminal starting on my screen on the Linux box, totally ignoring I was sshing into the Linux machine from the Mac.

Maybe you were using the wayland backend, you might have to force X11 with the environment variable "GDK_BACKEND=x11".

Though part of this weirdness is due to the clunkiness of the way X forwarding is implemented, I wish there was a way to do it that didn't involve kludging around with environment variables. But that is what we are stuck with.

> And going back to some client rendering enabling features like anti-aliasing.

The xrender extension already supports server side drawing, anti-aliasing, transparency, gradients and so on. If you use for example Cairo with the xrender backend almost everything except the tessellation of splines will be rendered server side and has a rather efficient wire protocol which will be better than even RDP.

The problem with XRender (and Cairo) is that it is still inherently an old-school immediate mode API. It's never going to be as performant as a fully parallelized GPU implementation.

All XRender operations are already GPU accelerated via Glamor. The spline tesselation step of drawing is notoriously hard to do on GPUs. Hence the separation at that point was actually a smart choice.

The GPU acceleration in Glamor doesn't really help, the issue here is that everything still needs to be serialized by the X protocol, rather than being drawn in parallel as they would on a GPU.

Edit: There has been some progress on GPU tessellation of splines, here is the most recent I can think of that was discussed here: https://news.ycombinator.com/item?id=23512897

> The GPU acceleration in Glamor doesn't really help

According to benchmarks at the time 700-800% speedup.

> everything still needs to be serialized by the X protocol

Drawing in general needs to be serialized. As soon as the object tree gets too big parallelized rendering on GPU will be slower because of the huge amount of branches. The link you posted solves this problem somewhat but introduces a huge amount of complexity to the renderer (also the benchmarks are done on Windows which obviously has no xrender backend). Xrender on the other hand is a simple standardized solution that works today.

7-8x speedup is not really that much when parallelized GPU algorithms can usually get 100x speedup or more. I would suggest to look at benchmarks compared to GPU based solutions such as piet-gpu, or even a parallelized 2d renderer like Blend2D, and see how that compares. IIRC the way you really want to do it is to build up the entire frame as a command buffer as you would in Vulkan and then submit that.

The recent developments here are actually because advancements showing that drawing didn't need to be serialized. The whole point of a GPU is to avoid that. I really don't know what to tell you, this is a complex problem, it's not solvable with simple solutions. The practice of the X server implementing the simplest possible solution has only really resulted in the complexity being moved into other projects, hence the existence of Wayland...

As soon as I get linux GPU drivers that don't crash randomly, I'll consider the need for a parallelized GPU implementation to be important.

> Wayland lacks some X features like network transparency.

There is waypipe for that:

https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://mstoeckl.com/notes/gsoc/blog.html

Hi, I am crowdfunding the Barrier effort [0] that would finally make Wayland usable for me.

In the meantime, I do need continuous Xorg updates. It's not by choice, Wayland just doesn't do the trick and is unusable on my machines until workflows like Synergy/Barrier are supported.

I really hope that there is an awareness in the DE communities that, for some use cases, Wayland is still not able to replace X and that left behind users are stuck with it until then.

[0] https://github.com/debauchee/barrier/issues/109

> By the way, I wonder if there is demand for long-term maintenance of X server specifically.

Hello and thank you for your work!

I'd love to see Xorg maintained at least.

It seems to me there still is dust to settle around wayland and xorg os getting little to no development.

Honestly, I'd just like xorg to keep working until the rest of the ecosystem has native wayland support.

Taking myself as an example: i just like xfce. Xfce is not on wayland yet. I don't care how buggy xorg is or how better wayland is, I won't switch if I can't run xfce.

So if the touchpad funding had failed there would have been no more Xorg release?

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.

That seems to be very much in line with previous statements from Redhat and others that X is almost abandoned.

The statements that they took the keys and then abandoned it.

You would be hard pressed to find any current-or-former Xorg developer who actually wants to work on Xorg anymore, regardless of their employer. The intersection between long-time core Xorg maintainers and people-who-started-the-Wayland project is nearly 100%.

The fact that Red Hat doesn't see much future in Xorg reflects this, rather than the other way around.

The other historically important corporate sponsor of Xorg development is Intel, and they seem to have reached the same conclusion.

(I work for Red Hat, but not on anything graphics related)

I'll bite. If wayland is so great why do we need X11 ? Last i heard wayland had no window manager.

Other sponsors could have done the work, I haven't heard of a long term X11 dev that didn't switch because they enjoyed working on X11.

Hi, I was recently trying to make some improvements to the build for XQuartz, which in turn was so I could make some changes to XQuartz and fix some issues with recent macOS changes too.

While I made some progress, it took much longer than I anticipated. I wonder if there's demand enough for X server on macOS to justify this work? Additionally, I'd have to find some funds to support my work as well, if I were to continue.

Yes there is! XQuartz is so important to keep going as there are a few beautiful tools that run on it that would be sad to see go.

Anecdata: I use and appreciate it every day. I'd be happy to contribute to sponsoring further development.

> By the way, I wonder if there is demand for long-term maintenance of X server specifically.

Certainly interested in that, though you're not clear whether it's time, money or community you're asking for.

Whatever happens, at some point momentum would have to gather outside of RedHat.

Still very happy with X here, and mainly running X applications across network rather than Qt/GTK toolkits and desktop environments.

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

What kind of money are you looking for? You mention crowdfunding, but it's not clear to me if you're looking from tens or perhaps hundreds from individual users, or tens of hundreds of thousands from institutions/corporations.

If it's the former then yes I'd back it depending on the price and what you're planning. With the latter I'm not in a position to influence my employer to participate.

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.

So perhaps you could consider publicizing a suitable mechanism? GitHub sponsorship? Patreon? Something else?

Is X.org interested in administering this process?

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 am eager to provide subscribe to this project, with recurring donations.

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

Thanks!

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

Are we talking money, time, tooling, etc.? I'm rather attached to Xorg and would like it to keep going; what would be the most helpful?

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

Reply on news.ycombinator.com