Sort of. The foundational issue here is the longstanding premise "Wayland can replace X!". The problem is that Wayland can't replace X, only Wayland plus a bunch of other components - or as I like to call it, Wayland++.
So Wayland++ can provide network transparency, but whenever a W++ feature has issues and those issues are criticized, Wayland advocates will just motte-and-bailey the issue by saying "but that's not part of Wayland!", which is technically true but irrelevant. "Wayland" can mean Wayland++ or just Wayland-core, depending on what's convenient.
Wayland proper is a protocol specification. By it itself, it's completely inert and it's all up to an implementation.
The protocol uses shared memory buffers and file descriptors, so it can't be just transported through TCP as-is. You need something like waypipe, which parses part of the protocol, extracts things like file descriptors that won't make sense on the other end, and then reconstructs things on the destination.
waypipe turns out not to be that complicated, it's just 15K lines of code.
most software which did support network transparency in a way similar to what X11 started out with has giving up on it (like in the industry as a whole) and there seems to be a clear technical consensus that it's best to not to approach remote access this way, even in X11 it was kind of semi-abandoned long before X11 was semi abandoned (from developers not from people using it)
As far as I can tell from the POV of the discussion of weather Wayland (or any other hypothetical replacement) needs to support it the answer always had been a clear "no it doesn't need to, nor should it try to".
This doesn't mean that you can't have remote shared applications, desktops, screen sharing or similar just not using network transparency. I.e. not by pretending the things the application communicates with (compositor, GPU, etc.) are on the same computer and "transparently" routing (part of) them to a different computer. And if you consider the stark difference in latency, reliability and throughput between a Unix pipe/speaking to a GPU over PCIe and TCP over Ethernet it can feel surprising that it was ever considered to be a good idea (but then when X11 was build network transparency was just that big think people put into everything, from most of which it is removed by now).
So what replaces network transparency (and did replace it in many cases long before Wayland was relevant) is typical remote desktop functionality. I.e. and additional application will grab the mouse/keyboard input on one side and the rendered output on the other side and sends them to each other. This has many benefits both for the people not using it and the people using it while many of the drawbacks often practically do not make much of a difference anymore. The main issue is if there is a high quality open source for free program you can use and if it's installed on the system where you want to use it...
A server in a datacenter generally doesn’t have a GPU, certainly not enough to support thousands of clients (each of which does have a GPU plugged right into one user’s monitor). Software rendering is a regression that didn’t need to happen, and Javascript apps seem to be the way the industry is avoiding it (with the browser as a remote display server).
Qwertious|2 years ago
So Wayland++ can provide network transparency, but whenever a W++ feature has issues and those issues are criticized, Wayland advocates will just motte-and-bailey the issue by saying "but that's not part of Wayland!", which is technically true but irrelevant. "Wayland" can mean Wayland++ or just Wayland-core, depending on what's convenient.
dale_glass|2 years ago
The protocol uses shared memory buffers and file descriptors, so it can't be just transported through TCP as-is. You need something like waypipe, which parses part of the protocol, extracts things like file descriptors that won't make sense on the other end, and then reconstructs things on the destination.
waypipe turns out not to be that complicated, it's just 15K lines of code.
j16sdiz|2 years ago
dathinab|2 years ago
most software which did support network transparency in a way similar to what X11 started out with has giving up on it (like in the industry as a whole) and there seems to be a clear technical consensus that it's best to not to approach remote access this way, even in X11 it was kind of semi-abandoned long before X11 was semi abandoned (from developers not from people using it)
As far as I can tell from the POV of the discussion of weather Wayland (or any other hypothetical replacement) needs to support it the answer always had been a clear "no it doesn't need to, nor should it try to".
This doesn't mean that you can't have remote shared applications, desktops, screen sharing or similar just not using network transparency. I.e. not by pretending the things the application communicates with (compositor, GPU, etc.) are on the same computer and "transparently" routing (part of) them to a different computer. And if you consider the stark difference in latency, reliability and throughput between a Unix pipe/speaking to a GPU over PCIe and TCP over Ethernet it can feel surprising that it was ever considered to be a good idea (but then when X11 was build network transparency was just that big think people put into everything, from most of which it is removed by now).
So what replaces network transparency (and did replace it in many cases long before Wayland was relevant) is typical remote desktop functionality. I.e. and additional application will grab the mouse/keyboard input on one side and the rendered output on the other side and sends them to each other. This has many benefits both for the people not using it and the people using it while many of the drawbacks often practically do not make much of a difference anymore. The main issue is if there is a high quality open source for free program you can use and if it's installed on the system where you want to use it...
erik_seaberg|2 years ago