5 ms·
I thought this was specifically not part of Wayland, am I wrong?
by pluijzer 3y ago
I thought this was specifically not part of Wayland, am I wrong?
- Qwertious 3y agoSort 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.
- j16sdiz 3y agooutsourcing the responsibility that is.
- dathinab 3y agonot putting complexity into places it doesn't belong to leading to sub-par outcomes for everyone that is
- wing-_-nuts 3y agobah. the sub-par outcome is they broke compatibility with everyone and then claimed it was every man / DE for themselves.
- dathinab 3y agox11 was (development) dead long before wayland was relevant x11 had long time become unsustainable in multiple ways braking changes where inevitable all of the most relevant DE had somewhat already gutted out X11 leaving nothing behind then the interfaces so the replacement being defined by interfaces and "every DE for themself" was just natural, for the large DEs it was already the case anyway and for the other DEs you could say wlroot is now the common core they need because they don't have the will/time to implement everything by themself
- dale_glass 3y agoWayland 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.
- wing-_-nuts 3y ago>Wayland proper is a protocol specification. By it itself, it's completely inert and it's all up to an implementation. Wayland should have shipped with a default implementation that had screen sharing, recording, clipboard and everything else that x11 had by default. The fact that they've thrown all that responsibility on DEs without so much as a HOWTO on how to reach parity is ridiculous. I will never understand why anyone took their effort seriously.
- mariusor 3y ago> The fact that they've thrown all that responsibility on DEs without so much as a HOWTO on how to reach parity is ridiculous. Well, all DEs (excepting maybe Xfce?) have members in the work groups that design the wayland protocol extensions, so it can be assumed that people are well aware of what needs to be done. Wayland has a default implementation called Weston, but I'm not sure that any of its devs cared enough to implement the extensions which are responsible for all the other bits that you mentioned.
- somat 3y agoX11 is just a protocol specification. By it itself, it's completely inert and it's all up to an implementation.
- dathinab 3y agono, you are right 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 3y agoA 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).
- esarbe 3y agoI'm not sure about your use case here. Why would a server in a data center need to render the GUI for thousands of clients?