Can anyone explain why Wayland exists or who cares about it? X has been around forever, it sucks but it works and everything supports it. Alternatives like NeWS came around that were radically better, but were too soon or relied too much on corporate support, so they faded. The GNU project originally intended to write its own thing, but settled for using X. Now there’s Wayland though, which seems like a slight improvement over X, but mostly kind of a lateral move.
If you’re going to replace X, why not do something a lot better? If not actual NeWS, then something that incorporates some of its ideas. I think Squeak was like that but I don’t know much about it.
I have been using X11 since 1996, and I never felt that it was very good. Sure, at the start it was better the then state-of-the-art desktop (Windows 95), mostly thanks to Linux, but that advantage went away in 2001 when OS/X was released. And even Windows went past it at some point, perhaps around Windows 7 or 8.
Wayland took a long time to get there, but it definitely is there today.
You answered your question of why Wayland exists right after asking it. X sucks. Wayland is a very significant improvement, I’m not sure why you think it’s a lateral move.
Also, X works for some cases, but not all, just lime Wayland. Using multiple refresh rates doesnt work well, HDR has no hope of ever working, and fractional scaling is horrible. Wayland has initial support for HDR and great support for the other two.
I don’t know how or why, but I get absolutely atrocious stuttering while playing games on X11 that simply doesn’t occur with Wayland, so X is just not an option for me.
That right there. X11 was released in the mid-80s and has become an unmaintainable patchwork of additions. Nobody wants to develop or maintain the code because changing one thing breaks five others.
But it wont, x had to accomodate every desktop’s needs, wayland is the way it is specifically so desktop can implement wat they need, and only the common stuff has to be part of the official protocols
I mean, the extension system means we could easily fix it, just deprecate the old paths, use the legacy xlib to set up extensions and write a lighter stack from there. A new input path too and you’re on your way.
It makes things a bit more complicated, but it’s also exactly how x86 managed to stay relevant all these decades, the old macro instructions are all slow microcode and you only use the safe stuff that’s hyper-optimized.
You mean I’ve been doing everything, from work through CGI to gaming (with 120 FPS mind you) on a display that doesn’t work?
Wayland has many issues, sure, but it’s not even close to the point where “it works” can be used to distinguish it from other display protocols. We (and by we I mean anyone willing to dedicate their life to it) could do a lot to bring X11 up to modern expectations, but it’s just not worth the effort. X11 will outlive the cockroaches, but claiming that Wayland is not a functional display protocol is incorrect and uninformed.
I installed a fresh copy of, I believe, Debian. Wayland, for some reason, couldn’t handle 4 monitors, with one above the other three.
Not the issue I expected on a fresh install. Oh, and the biggest issue I had with Windows was copied straight into Linux. I want my (single) taskbar on a monitor that isn’t my primary.
I’m currently back to Windows. It was already going to be a rough transition, and missing the ideas I was looking for while also adding complications just hasn’t made it worth it.
what desktop environment? what you described works perfectly on KDE. i have 3 monitors here and they work flawless in any arbitrary combination or orientation under wayland. side-by-side or on top of each other or even diagonal. with different resolutions and different refresh rates. with taskbars on any number of monitors and any orientation. maybe Debians KDE version is just very outdated. the 6+ versions work fantastic.
My setup is two screens side by side and one above. KDE Plasma 6.1 can handle it without issues, and you can make panels on any screen.
One of the most significant drawbacks of Wayland is feature fragmentation between compositors. Unlike the X11 stack of X.Org server + window manager + compositor, Wayland compositors have to implement all of Wayland in themselves. They have to serve as the display servers, plus manage window positioning, plus render the clients, and all of that within the confines of Wayland-protocols. Building a compositor is a massive task, which is why middleware like wlroots is such a big deal. It also means that WM-agnostic tools like xrandr and xdotool are more difficult, sometimes impossible to implement.
Consider that Wayland is still heavily under development, and that new protocols have to be implemented by every compositor separately, and that the development of wayland-protocols is an ongoing fucking trainwreck – fragmentation is inevitable, and some compositors will not have the same functionality as others (GNOME being a particularly nasty sandbag). Similarly, things that don’t work as expected in one compositor might work perfectly fine in another.
Right now I would consider KDE Plasma to be the most feature-complete compositor that is also beginner-friendly.
… is not something you should ever use on a desktop PC. Due to its eternally very outdated nature and not even shipping bugfix updates**** it is not a good fit for anything but servers.
Wayland, for some reason, couldn’t handle 4 monitors, with one above the other three.
“Wayland” doesn’t handle monitors at all. What (because of Debian, wildly outdated) desktop did you use?
Oh, and the biggest issue I had with Windows was copied straight into Linux. I want my (single) taskbar on a monitor that isn’t my primary.
Not a Linux issue, but a problem with the desktop environment you chose. KDE Plasma allows you to configure panels in any way you want.
I mean, the extension system means we could easily fix it
If that’s the case, then why not do it? Apparently the people who actually worked on X11 had a different idea, and so they decide not to do it themselves - but the code is right there for those who do think that that’s a good approach.
From what I can see it mostly does ease of development better; it’s a completely new and rather lean codebase, and it’s seen as an investment in compatibility with graphical applications.
Also, it has lock screens.
X cannot do lock screens; it can have an app being full screen and pray to some collection of deities that nothing will come in front of it or that the fake lock screen won’t draw far too small, but it cannot natively do secure lockscreens that are guaranteed to work.
So there, it does something much better: security.
Likewise, there are plenty of definitions of “better” that make Wayland a lot better. It’s just that it’s a lot of work to make something better, especially for some interpretations of “better”.
But Wayland is waaay better than X in basically everything? Performance and security are simply in another league entirely. And these 2 are the most important factors.
The rest of the “features” will be eventually there. In fact, mostly are there already. I’ve been using Wayland 2 years without issues. The important thing is that now the sofware is solid, the code is clean and the performance is amazing. Growing from there will be so much better than from X11.
The screen capture protocol was merged a month ago. Support will come soon. wayvnc, grim (and by extension grimshot) already have support for it. No compositors have implemented it afaik, but wlroots is very close to it.
The screen capture protocol was merged a month ago.
That’s part of my issue I have with Wayland protocols. It was added a month ago. After several years! During research I found discussions ~6 years old, this PR was 2 years old, and superseded a 4 years old other request.
In the meantime some environments implemented that on their own without waiting for the protocol. If I understand correctly: Gnome as well as KDE have implemented it outside the protocol. And Hyprland devs forked wlroots to advance development faster and also add that. (Correct me if I’m wrong.)
Since labwc uses wlroots (but is a bit slow with adapting to new versions) it will take quite some time before I can put a checkmark after my last usecase. I am optimistic that it will work. But I accepted that it may take several years to add new functionality and a few months before the functionality arrives in wlroots and at some point after that in labwc.
Yes. Wayland protocols take too long to get merged. Actually, a few days ago some people (mostly Valve guys) got tired of it and took action by proposing changes[1, 2, 3, 4]to the way new protocols are handled. Hopefully it gets better. Also, if your compositor is based on wlroots, then you might get support for the new protocol very soon.
Can anyone explain why Wayland exists or who cares about it? X has been around forever, it sucks but it works and everything supports it. Alternatives like NeWS came around that were radically better, but were too soon or relied too much on corporate support, so they faded. The GNU project originally intended to write its own thing, but settled for using X. Now there’s Wayland though, which seems like a slight improvement over X, but mostly kind of a lateral move.
If you’re going to replace X, why not do something a lot better? If not actual NeWS, then something that incorporates some of its ideas. I think Squeak was like that but I don’t know much about it.
I have been using X11 since 1996, and I never felt that it was very good. Sure, at the start it was better the then state-of-the-art desktop (Windows 95), mostly thanks to Linux, but that advantage went away in 2001 when OS/X was released. And even Windows went past it at some point, perhaps around Windows 7 or 8.
Wayland took a long time to get there, but it definitely is there today.
Wayland cuts out the need for a display server. It also has the benefit of being designed for hardware made in this century
You answered your question of why Wayland exists right after asking it. X sucks. Wayland is a very significant improvement, I’m not sure why you think it’s a lateral move.
Also, X works for some cases, but not all, just lime Wayland. Using multiple refresh rates doesnt work well, HDR has no hope of ever working, and fractional scaling is horrible. Wayland has initial support for HDR and great support for the other two.
I don’t know how or why, but I get absolutely atrocious stuttering while playing games on X11 that simply doesn’t occur with Wayland, so X is just not an option for me.
That right there. X11 was released in the mid-80s and has become an unmaintainable patchwork of additions. Nobody wants to develop or maintain the code because changing one thing breaks five others.
Wayland will be an unmaintainable patchwork of protocols, once it will have the same functionality as X11 has.
But it wont, x had to accomodate every desktop’s needs, wayland is the way it is specifically so desktop can implement wat they need, and only the common stuff has to be part of the official protocols
I mean, the extension system means we could easily fix it, just deprecate the old paths, use the legacy xlib to set up extensions and write a lighter stack from there. A new input path too and you’re on your way.
It makes things a bit more complicated, but it’s also exactly how x86 managed to stay relevant all these decades, the old macro instructions are all slow microcode and you only use the safe stuff that’s hyper-optimized.
Meanwhile you get the one thing X has: It works.
You mean I’ve been doing everything, from work through CGI to gaming (with 120 FPS mind you) on a display that doesn’t work?
Wayland has many issues, sure, but it’s not even close to the point where “it works” can be used to distinguish it from other display protocols. We (and by we I mean anyone willing to dedicate their life to it) could do a lot to bring X11 up to modern expectations, but it’s just not worth the effort. X11 will outlive the cockroaches, but claiming that Wayland is not a functional display protocol is incorrect and uninformed.
I installed a fresh copy of, I believe, Debian. Wayland, for some reason, couldn’t handle 4 monitors, with one above the other three.
Not the issue I expected on a fresh install. Oh, and the biggest issue I had with Windows was copied straight into Linux. I want my (single) taskbar on a monitor that isn’t my primary.
I’m currently back to Windows. It was already going to be a rough transition, and missing the ideas I was looking for while also adding complications just hasn’t made it worth it.
what desktop environment? what you described works perfectly on KDE. i have 3 monitors here and they work flawless in any arbitrary combination or orientation under wayland. side-by-side or on top of each other or even diagonal. with different resolutions and different refresh rates. with taskbars on any number of monitors and any orientation. maybe Debians KDE version is just very outdated. the 6+ versions work fantastic.
Ok but it’s not called Kdeland.
OK but Wayland is not responsible for arranging monitors
If Wayland is so fragile as to only work with KDE, and is not responsible for anything, how long until it’s relegated to a KDE internal subsystem?
My setup is two screens side by side and one above. KDE Plasma 6.1 can handle it without issues, and you can make panels on any screen.
One of the most significant drawbacks of Wayland is feature fragmentation between compositors. Unlike the X11 stack of X.Org server + window manager + compositor, Wayland compositors have to implement all of Wayland in themselves. They have to serve as the display servers, plus manage window positioning, plus render the clients, and all of that within the confines of Wayland-protocols. Building a compositor is a massive task, which is why middleware like wlroots is such a big deal. It also means that WM-agnostic tools like
xrandrandxdotoolare more difficult, sometimes impossible to implement.Consider that Wayland is still heavily under development, and that new protocols have to be implemented by every compositor separately, and that the development of wayland-protocols is an ongoing fucking trainwreck – fragmentation is inevitable, and some compositors will not have the same functionality as others (GNOME being a particularly nasty sandbag). Similarly, things that don’t work as expected in one compositor might work perfectly fine in another.
Right now I would consider KDE Plasma to be the most feature-complete compositor that is also beginner-friendly.
… is not something you should ever use on a desktop PC. Due to its eternally very outdated nature and not even shipping bugfix updates**** it is not a good fit for anything but servers.
“Wayland” doesn’t handle monitors at all. What (because of Debian, wildly outdated) desktop did you use?
Not a Linux issue, but a problem with the desktop environment you chose. KDE Plasma allows you to configure panels in any way you want.
Wayland works.
If that’s the case, then why not do it? Apparently the people who actually worked on X11 had a different idea, and so they decide not to do it themselves - but the code is right there for those who do think that that’s a good approach.
From what I can see it mostly does ease of development better; it’s a completely new and rather lean codebase, and it’s seen as an investment in compatibility with graphical applications.
Also, it has lock screens. X cannot do lock screens; it can have an app being full screen and pray to some collection of deities that nothing will come in front of it or that the fake lock screen won’t draw far too small, but it cannot natively do secure lockscreens that are guaranteed to work.
So there, it does something much better: security.
For some definitions of “works”
Likewise, there are plenty of definitions of “better” that make Wayland a lot better. It’s just that it’s a lot of work to make something better, especially for some interpretations of “better”.
I was responding to someone who saw no need for Wayland to exist, not advocating for everyone to use it
“it works for me!”
But Wayland is waaay better than X in basically everything? Performance and security are simply in another league entirely. And these 2 are the most important factors.
The rest of the “features” will be eventually there. In fact, mostly are there already. I’ve been using Wayland 2 years without issues. The important thing is that now the sofware is solid, the code is clean and the performance is amazing. Growing from there will be so much better than from X11.
You cannot even record single windows without having your DE patching that in for you.
The screen capture protocol was merged a month ago. Support will come soon. wayvnc, grim (and by extension grimshot) already have support for it. No compositors have implemented it afaik, but wlroots is very close to it.
That’s part of my issue I have with Wayland protocols. It was added a month ago. After several years! During research I found discussions ~6 years old, this PR was 2 years old, and superseded a 4 years old other request.
In the meantime some environments implemented that on their own without waiting for the protocol. If I understand correctly: Gnome as well as KDE have implemented it outside the protocol. And Hyprland devs forked wlroots to advance development faster and also add that. (Correct me if I’m wrong.)
Since labwc uses wlroots (but is a bit slow with adapting to new versions) it will take quite some time before I can put a checkmark after my last usecase. I am optimistic that it will work. But I accepted that it may take several years to add new functionality and a few months before the functionality arrives in wlroots and at some point after that in labwc.
Yes. Wayland protocols take too long to get merged. Actually, a few days ago some people (mostly Valve guys) got tired of it and took action by proposing changes[1, 2, 3, 4]to the way new protocols are handled. Hopefully it gets better. Also, if your compositor is based on wlroots, then you might get support for the new protocol very soon.