Wayland is a sports car - modern, tailor made for performance. X is like a '99 Civic that’s had the seatbelts stripped out and the airbags replaced with cameras that let all the other cars on the road see you naked.
It’s fine to prefer X, but the older it gets the more people are going to roll their eyes at you. XWayland is fine for random old stuff, but there is zero reason X should be running your whole display these days.
Inb4 someone mentions network transparency that gimps the rest of the system or some 5000 year old app that needs to sniff events sent to every other program.
And the network transparency argument is long gone. While you can indeed network windows over the wire, most toolkits use client side rendering/decorations. So you’re just sending bloated pixmaps across the wire when things like RDP , VNC, etc deal better with compression, damage to the window, etc. And anything relying or accelerated with DRI3 is just NOT network transparent.
Most modern toolkits have moved past X11 because the X protocol was severely lacking, and there wasn’t a good way as a committee to modify the protocol in an unified manner. I mean look at the entire moving Earth that it took for XFixes and Damage extensions. Toolkits wanted deep access to the underlying hardware and so they would go out of their way to work around X, because it just could not keep up.
Agreed. I was an early Wayland convert because once upon a time I started writing a WM and taking an interest in X internals… And then my face melted off like I’d opened the Ark of the Covenant.
Tell me you never deployed remote linux desktop in an enterprise environment without telling me you never deployed remote desktop linux in an enterprise environment.
After these decades of Wayland prosperity, I still can’t get a commercially supported remote desktop solution that works properly for a few hundred users. Why? Because on X, you could highjack the display server itself and feed that into your nice TigerVNC-server, regardless of desktop environment. Nowadays, you need to implement this in each separate compositor to do it correctly (i.e. damage tracking). Also, unlike X, Wayland generally expects a GPU in your remote desktop servers, and have you seen the prices for those lately?
How does that change what I said? Remote X is massively more bandwidth hungry than all the others. I mean things like TeamViewer Tensor exist and from what I’ve done, is massively stable. RHEL works perfectly for it. So I don’t want to hear this can’t get a commercially supported… There’s tons of vendors that will thin client for you.
X is a terrible protocol for modern widgets because modern widgets do their best to work around X, that’s literally in the code. Look at GTK or Qt, both are actively trying to avoid working with X when it can and just render directly, because in every metric, it’s better to work directly with the hardware than to go through some slow middle layer that just spins and wastes cycles.
Heck, even the X developers have left X, because it’s done. It’s a dead technology. It doesn’t matter how many people are deploying in enterprise environments, or how well they are deploying those things. There’s no devs on the project and GPUs keep changing. There’s only so many ways you can keep band-aiding a GPU into thinking it’s a giant frame buffer, at some point, there’s going to be a break in the underlying architecture of GPUs, that thinking it’s just VRAM to dump data to, will no longer work. The amount of space on die for the backwards VGA and SHM methods is minuscule these days on cards.
Heck, Using MIT-SHM on X11 for a Pi is something that’s terrible. You usually get worse results because the underlying hardware is woefully optimized for you to treat it like how old video cards worked. You actually do better using hardware acceleration. The usual mantra for X11 apps on Pi is, if you get good results with shared memory, use that and never upgrade your underlying Pi, otherwise always use hardware where possible.
Also, unlike X, Wayland generally expects a GPU in your remote desktop servers, and have you seen the prices for those lately?
You don’t even need a good one in today’s standards. At most, most compositors just need to convert pixmap into texture. Anything that supports GLX_EXT_texture_from_pixmap will be enough and at low resolutions, just give it to your CPU, we’re not talking intense operations. But literally anything from the last fifteen years of GPUs has enough power to complete these operations reasonably. Shoot, if you’re thin client on a Pi, the Pi itself has vastly more resources. You can literally have a cluster of Pis if you wanted, labwc is a completely fine compositor for basic thin clients and is basically the replacement of X on Pi. Because X11 was just so terrible because it was so misaligned to how modern GPUs actually work.
What I am saying is X can be whatever in “enterprise deployment”, but X has stopped matching how modern machines look like. Video cards have become more than a bunch of bits dumped into VRAM. No matter how many deployments you’ve done, that doesn’t change that fact. X barely resembles what modern systems of the last twenty-five years looks like. Nobody is working on it. You can have 100 deployments under your belt, nobody is still working on it. No matter how you slice the attributes of X, nobody is actively coding for X any longer. And as for damage and what not, lots of implementations of wl_surface_damage_buffer are using underlying hardware EGL/DMABUF because GPUs are smart enough for the last fifteen years to do that on their own, most compositors utilize that.
Again, it doesn’t matter how many deployments you might have, the hardware does it better than X will ever do it, it’s impossible for X to do it better, there’s nobody there to write better. And it will always be this way, until the heat death of the universe unless someone(s) picks up this massive task of taking care of Xorg. There’s nothing that changes any of this reality.
Does this mean you need to drop X11 tomorrow. No. That’s the entire point of why Xorg was open. So that you can keep it until someone rips it from your cold dead hands. But your stubbornness does not change the fact X is absolutely garbage on the network, is massive inefficient, and most things these days actively try to avoid using X directly and if they have to, they just stuff uncompress bits into a massive packet with zero optimization. You can totally mill grain with a stone wheel today, no one stops you. But you’re not going to convince many people that, that is the best way to mill grain. I don’t know what else to say. I don’t want you to stop using X, but your usage of it doesn’t change any fact that I’ve stated. It’s a very fat, very unoptimized, very slow protocol and there are indeed commercial solutions that are better. I’ve just named one, but there are many. That is just reality, the world has moved past dual channel RAM and buffers. I’ve built VGA video cards, I know how to build a RAMDAC form logic gates, all of that is gone in today’s hardware, and X still has these silly assumptions of hardware that doesn’t even exist anymore.
An anti-DEI fork by a wingnut and a project that isn’t even half way ready to use starting from scratch in a niche language. Neither of which are capable of dealing with the fundamental problem of X, the protocol itself, without becoming something entirely different.
If you deal with the fundamental problems of the protocol itself and also provide backwards compatibility… Congrats, you’ve just reinvented Wayland and XWayland.
Dealing with X11’s problems while still being X11, when X11 is the problem? Yeah, I wouldn’t hold my breath either.
The fundamental architectural issue with Wayland is expecting everyone to implement a compositor for a half baked, changing, protocol instead of implementing a common platform to develop on. Wayland doesn’t really exist, it’s just a few distinct developer teams playing catch-up, pretending to be compatible with each other.
Implementing the hard part once and allowing someone to write a window manager in 100 lines of C is what X did right. Plenty of other things that are bad with X, but not that.
I use KDE Connect remote input on Wayland all the time…
KMag is broken (simply has not been updated, not like it couldn’t work) but you can zoom the entire screen in KDE with super +/- is that not good enough?
Wayland is a sports car - modern, tailor made for performance. X is like a '99 Civic that’s had the seatbelts stripped out and the airbags replaced with cameras that let all the other cars on the road see you naked.
It’s fine to prefer X, but the older it gets the more people are going to roll their eyes at you. XWayland is fine for random old stuff, but there is zero reason X should be running your whole display these days.
Inb4 someone mentions network transparency that gimps the rest of the system or some 5000 year old app that needs to sniff events sent to every other program.
And the network transparency argument is long gone. While you can indeed network windows over the wire, most toolkits use client side rendering/decorations. So you’re just sending bloated pixmaps across the wire when things like RDP , VNC, etc deal better with compression, damage to the window, etc. And anything relying or accelerated with DRI3 is just NOT network transparent.
Most modern toolkits have moved past X11 because the X protocol was severely lacking, and there wasn’t a good way as a committee to modify the protocol in an unified manner. I mean look at the entire moving Earth that it took for XFixes and Damage extensions. Toolkits wanted deep access to the underlying hardware and so they would go out of their way to work around X, because it just could not keep up.
Agreed. I was an early Wayland convert because once upon a time I started writing a WM and taking an interest in X internals… And then my face melted off like I’d opened the Ark of the Covenant.
Things are so much simpler now.
Tell me you never deployed remote linux desktop in an enterprise environment without telling me you never deployed remote desktop linux in an enterprise environment.
After these decades of Wayland prosperity, I still can’t get a commercially supported remote desktop solution that works properly for a few hundred users. Why? Because on X, you could highjack the display server itself and feed that into your nice TigerVNC-server, regardless of desktop environment. Nowadays, you need to implement this in each separate compositor to do it correctly (i.e. damage tracking). Also, unlike X, Wayland generally expects a GPU in your remote desktop servers, and have you seen the prices for those lately?
How does that change what I said? Remote X is massively more bandwidth hungry than all the others. I mean things like TeamViewer Tensor exist and from what I’ve done, is massively stable. RHEL works perfectly for it. So I don’t want to hear this can’t get a commercially supported… There’s tons of vendors that will thin client for you.
X is a terrible protocol for modern widgets because modern widgets do their best to work around X, that’s literally in the code. Look at GTK or Qt, both are actively trying to avoid working with X when it can and just render directly, because in every metric, it’s better to work directly with the hardware than to go through some slow middle layer that just spins and wastes cycles.
Heck, even the X developers have left X, because it’s done. It’s a dead technology. It doesn’t matter how many people are deploying in enterprise environments, or how well they are deploying those things. There’s no devs on the project and GPUs keep changing. There’s only so many ways you can keep band-aiding a GPU into thinking it’s a giant frame buffer, at some point, there’s going to be a break in the underlying architecture of GPUs, that thinking it’s just VRAM to dump data to, will no longer work. The amount of space on die for the backwards VGA and SHM methods is minuscule these days on cards.
Heck, Using MIT-SHM on X11 for a Pi is something that’s terrible. You usually get worse results because the underlying hardware is woefully optimized for you to treat it like how old video cards worked. You actually do better using hardware acceleration. The usual mantra for X11 apps on Pi is, if you get good results with shared memory, use that and never upgrade your underlying Pi, otherwise always use hardware where possible.
You don’t even need a good one in today’s standards. At most, most compositors just need to convert pixmap into texture. Anything that supports
GLX_EXT_texture_from_pixmapwill be enough and at low resolutions, just give it to your CPU, we’re not talking intense operations. But literally anything from the last fifteen years of GPUs has enough power to complete these operations reasonably. Shoot, if you’re thin client on a Pi, the Pi itself has vastly more resources. You can literally have a cluster of Pis if you wanted, labwc is a completely fine compositor for basic thin clients and is basically the replacement of X on Pi. Because X11 was just so terrible because it was so misaligned to how modern GPUs actually work.What I am saying is X can be whatever in “enterprise deployment”, but X has stopped matching how modern machines look like. Video cards have become more than a bunch of bits dumped into VRAM. No matter how many deployments you’ve done, that doesn’t change that fact. X barely resembles what modern systems of the last twenty-five years looks like. Nobody is working on it. You can have 100 deployments under your belt, nobody is still working on it. No matter how you slice the attributes of X, nobody is actively coding for X any longer. And as for damage and what not, lots of implementations of
wl_surface_damage_bufferare using underlying hardware EGL/DMABUF because GPUs are smart enough for the last fifteen years to do that on their own, most compositors utilize that.Again, it doesn’t matter how many deployments you might have, the hardware does it better than X will ever do it, it’s impossible for X to do it better, there’s nobody there to write better. And it will always be this way, until the heat death of the universe unless someone(s) picks up this massive task of taking care of Xorg. There’s nothing that changes any of this reality.
Does this mean you need to drop X11 tomorrow. No. That’s the entire point of why Xorg was open. So that you can keep it until someone rips it from your cold dead hands. But your stubbornness does not change the fact X is absolutely garbage on the network, is massive inefficient, and most things these days actively try to avoid using X directly and if they have to, they just stuff uncompress bits into a massive packet with zero optimization. You can totally mill grain with a stone wheel today, no one stops you. But you’re not going to convince many people that, that is the best way to mill grain. I don’t know what else to say. I don’t want you to stop using X, but your usage of it doesn’t change any fact that I’ve stated. It’s a very fat, very unoptimized, very slow protocol and there are indeed commercial solutions that are better. I’ve just named one, but there are many. That is just reality, the world has moved past dual channel RAM and buffers. I’ve built VGA video cards, I know how to build a RAMDAC form logic gates, all of that is gone in today’s hardware, and X still has these silly assumptions of hardware that doesn’t even exist anymore.
Plenty life in X11 yet.
Xlibre running around.
Pheonix on the horizon. (Zig!)
An anti-DEI fork by a wingnut and a project that isn’t even half way ready to use starting from scratch in a niche language. Neither of which are capable of dealing with the fundamental problem of X, the protocol itself, without becoming something entirely different.
… I’m not holding my breath.
If you deal with the fundamental problems of the protocol itself and also provide backwards compatibility… Congrats, you’ve just reinvented Wayland and XWayland.
Dealing with X11’s problems while still being X11, when X11 is the problem? Yeah, I wouldn’t hold my breath either.
The fundamental architectural issue with Wayland is expecting everyone to implement a compositor for a half baked, changing, protocol instead of implementing a common platform to develop on. Wayland doesn’t really exist, it’s just a few distinct developer teams playing catch-up, pretending to be compatible with each other.
Implementing the hard part once and allowing someone to write a window manager in 100 lines of C is what X did right. Plenty of other things that are bad with X, but not that.
xlibre is xorg with some half baked commits that had to be removed from xorg for breaking too much and a guy who is kind of a nutcase.
No KMag + KDE Connect remote input, no Wayland.
I use KDE Connect remote input on Wayland all the time…
KMag is broken (simply has not been updated, not like it couldn’t work) but you can zoom the entire screen in KDE with super +/- is that not good enough?