Hacker News Reader

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

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

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!

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

> 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

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.