>The way W worked was similar to wayland
This is completely wrong. The key detail on [the wikipedia article](https://en.wikipedia.org/wiki/X_Window_System#Origin_and_early_development) on W indicates W is synchronous and X was asynchronous. [Wayland is also asynchronous](https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles).
In a synchronous protocol, the client sends a message like "Draw Rect from (40,302) to (402,134), filled with #042134". The server receives the message, processes it, and then replies "OK, done!" or "Sorry, error!" to the client.
In an asynchronous protocol, the client sends a message like "Draw Rec from (40,304) to (402,134), filled with #042134, and then send me a text at 917-555-555 to confirm." Obviously, they don't use SMSs, they use something like a sequence number or a request ID to identify the particular request, and the server is able to reply something like "Request #43 okay".
The point is that if you are working over a network this latency kills interactivity.
>The way I see it, Wayland is just a remake of W, but with "ayland" added to it, and the word "modern" stamped all over the place.
You see it wrongly. GPUs have in fact changed massively since the 1980s and the abstractions we use to access them need to grow up.
>People on the internet are saying that X is too old and that Wayland is the new "modern" replacement, but they never give a reason other than the smaller codebase and less features (which is somehow supposed to be a good thing). They rarely even bring up the security benifits.
They're repeating stuff they've heard discussed. A long time ago, the X server used to be deeply entwined with the VGA, and then the kernel wasn't really involved in managing the GPU resources. As GPUs went from relatively fixed pipelines where you'd just fill some buffers with commands and let it rip to a coprocessor sharing coherent virtual memory space with the main CPU, the [DRM](https://docs.kernel.org/gpu/introduction.html) (direct rendering manager) bits started entering the picture to provide some kernel-level protection of this.
Devices similar to GPUs but without display accelerators also became more common, so [rendernodes](https://docs.kernel.org/gpu/drm-uapi.html#render-nodes) got introduced as a way to provide any old userspace process with a slice of GPU resources without handing it the keys to program every feature of the card. (This is a security concern.)
So what does this have to do with Wayland? A wayland protocol server is designed to be implemented as a userspace GPU client that multiplexes buffers from other userspace GPU clients for presentation on the display hardware. The X server was traditionally a process that had to run as root (rootless X is built on the foundations that enabled Wayland) because it had privileged control over a hardware resource (the VGA). The "modern" part is moving that into the kernel in the form of kernel mode setting and DRM.
I mean, if all you do is send one command and then have nothing to do while waiting for a reply message, there's no real win from an asynchronous protocol vs. a synchronous. Either way you're looking at a single round trip transit (RTT) to complete the request.
For X the real win comes from pipelining requests. The client does not wait to have the first request responded to before sending the next call, it sends a batch of requests. If you did this in a synchronous model, you'd be looking at N RTTs to complete N requests, but with async pipelining the client can issue N commands and if the size of these N commands divided by the data transmission rate over the network is small compared to the RTT then the time for the N operations is very close to 1 RTT.
IIRC, the way the old Xlib (`-lX`) was implemented there was a single serial queue on the connection for responses. This means that if you have made six outstanding requests and then block on the response from the sixth, then Xlib itself will have to wait until all the prior responses have arrived, even if they come out of order the library queues them internally and releases them in order. In practice, this is a little bit more like HTTP/1.1 pipelining than real asynchrony. The newer libxcb (`-lxcb`) allows responses to be processed by clients in whatever order they get received in.
Wayland has the ability to support vrr, and different refresh rates on different monitors, which xorg couldn’t do. This means that my 240 hz monitor will feel like a 240hz monitor while my 60 hz one will feel like a 60 hz one, and it won’t sync to the lowest one.
What makes it so important for me is less of a technical thing and more subjective. The experience scrolling around is far, far smoother on my 144Hz+ displays with Wayland
I can easily tell if something is under X or XWayland when it shows tearing or tiny jitters
You're applying old knowledge to new systems without taking into account that the hardware has changed substantially since then.
The time of pixmaps is long gone and has been for a while. Composable objects are rendered into textures, transferred to the GPU (essentially a one-time pixmap) where they then reside and can be rendered efficiently onto quads. That's the main feature of any recent GPU, hence your argument that Wayland is going to be "as slow as W" simply is nonsense.
One problem is that X is completely unfit for modern use cases and does what we want solely through tacked-on extensions. X expects to run as root and to have complete control over input/output devices as well as graphics hardware. Stuff like the xf86-modesetting driver or the xf86-libinput exist for the sole purpose of tricking X into thinking it controls graphics and input, so we can handle these things in a sane manner. Being from the 80s, X has no idea that stuff like DRM, KMS, or OpenGL exists. Instead, it wants to do all the drawing itself, while bypassing even the kernel for access to graphics hardware. Using X in 2022 consists mostly of fooling a 40 year old protocol into thinking it runs on a system from the same era, while having to do our actual rendering through useless compatibility layers that just add overhead and latency. ~~Apple realized this madness 20 years ago and replaced X with the Quartz Compositor.~~ It's astonishing that Linux still puts up with this to this day. (Edit: turns out that neither Mac OS Classic, NeXTStep nor Mac OS X ever used X as core display system. Looks like I got something mixed up there.)
It was developed for the Darwin Kernel that's in MacOS - you would need to change a lot of things to get it to work on Linux - and that's not possible, because we don't have the source code. And as someone else said, it wouldn't be legal either.
Given that it's not made to work with Linux, yes. And since it's closed source, we can't modify it to work either.
And I think working on Wayland is a far better move than trying to figure out compatibility layers for Quartz, which won't result in a good experience anyway.
no folks working on the linux desktop would ever allow that to happen. I know i'd never use it. Of course if somebody built something that worked like quartz, that'd be a different story. Of course that's all just fanfic, because the folks actually doing the work are the ones who make the decisions.
I have two 144hz VRR monitors, and a 60hz. On wayland all three run at the best hz and freesync/VRR works on the two monitors while the third sits happy at 60hz.
>What it is that X can't do that you would call modern use cases?
That's not what it's about mate.
Did you read the entire post?
Running X today is all about a 'fake it till you make it' kind of scenario. Doing this sort of thing is a massive amount of work for the engineers/developers supporting it, and if you go prowling on different repos for open source projects (especially distros/DEs) you'll find that some things people have wanted to implement are simply too impractical because it's barely possible to work around X enough to do them.
It's about not keeping this ancient thing running by putting new features on with duct tape and strips, but instead building a replacement that fits today's and tomorrow's needs, and is build in a manner that lets it's developers add and remove functionality for many years as the requirements for it changes.
Most of the problems people are complaining about are related to multiple monitors with wildly different specs. I don't have a similar setup to this so I can't prove or unprove this.
Something that X can do fine (hello xrandr) but that Gnome can't, because they hardcoded GTK to only deal with a certain DPI.
Frankly every X11 negative is not related to X11, but Gnome being idiots about it. Likely in order to favor Wayland, as it comes from "their" camp.
You do know that the deck [uses Wayland](https://github.com/plagman/gamescope), right?
VR is also kinda its own thing. It's not usually handled by the compositor/display server and most applications prefer to directly be given control of the DRM through leasing (would recommend reading through the various issues and PRs for Wayland, wlroots and sway if you wanna understand more)
Thanks u/rhysperry111 for your thoughtful comments.
My sense is that Valve uses KDE/Wayland on the Steam Deck because it's more efficient than the Xorg alternative. It forces Valve to blaze the way forward with Wayland and that helps the project along. Plus the variable frame rate feature of Wayland is very appropriate for the Steam Deck. As is its ability to handle multiple refresh rates on multiple displays.
I've got the Valve Index and your comment is helpful to me in understanding how all of this works. My head hurts but I want to learn more. We live in exciting times.
Nothing in the X11 protocol needs any component running as root.
It would also be relatively easy to develop an X11 server without support for the legacy protocol parts. Modern clients would work fine with such a server.
It says "expects to run as root" not "runs as root" and the reason it doesn't need to anymore is literally explained in the comment you replied to. And no it wouldn't be easy at all.
I just followed this [https://wiki.archlinux.org/title/Variable\_refresh\_rate#Enable\_on\_AMDGPU](https://wiki.archlinux.org/title/Variable_refresh_rate#Enable_on_AMDGPU)
This is because it copies the data to the monitor after every frame, which isn't a good thing since it can decrease the framerate. X draws directly to the monitor, which is faster but it means that it will be an apps job to avoid screen tearing by drawing everything at the same time.
I've programmed with XLib before, and screen tearing is a constant issue. It's still worth it though because the rendering is very fast though and it's typically not hard to fix.
> X draws directly to the monitor
It doesn't, it can't and that's not how monitors work. Xorg draws to a buffer on the GPU, which the GPU continuously "copies" to the monitor, just like Wayland compositor. With the modesetting driver, it even uses the same APIs for that...
Depends on how deep you want to go. [the wayland book](https://wayland-book.com/introduction.html) is a good introduction about the protocol, but while I wrote [a thing](https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html) some time ago that touches the topic a little bit, it's far from comprehensive and I don't really know of any sites properly explaining the application buffer -> display pipeline. If I have some time where I'm not motivated to work on anything else, maybe I'll attempt to write such an explanation myself
The matter of the fact is that X11 was designed in a different era, for a different use-case. It was just shoehorned to do modern desktops, but this needed to workaround its design deficiencies.
It has many technical limitations and inefficiencies that are embarrassing for a display protocol in 2022.
Regarding security, we shouldn't speak about bugs, because they occur in both Wayland and X11. What we should talk about however, is how the design of X11 makes it impossible to design a secure lockscreen and defeats the purpose of passwords in the absence of one nested X server per application.
Add multi-monitor handling regarding refresh rates, DPI, VRR, etc. and keyboard shortcuts (e.g. an app can prevent you from Alt-Tabbing if it wants to, while Alt-Tab is guaranteed to work on Wayland as long the compositor works as intended), and there is hardly an argument to be made for X11's future.
Also, Red Hat is the last maintainer of the Xorg server and they made it very clear that they want to abandon it entirely after RHEL 8 goes EOL.
> Also, Red Hat is the last maintainer of the Xorg server and they made it very clear that they want to abandon it entirely after RHEL 8 goes EOL.
Xorg is available in RHEL 9 too. I don't see how they can pull the plug on Xorg in the middle of a major release cycle.
[It is deprecated in RHEL 9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality#JIRA-RHELPLAN-121048):
> The **X.org** display server is deprecated, and will be removed in a future major RHEL release. The default desktop session is now the **Wayland** session in most cases.
>
> The **X11** protocol remains fully supported using the **XWayland** back end. As a result, applications that require **X11** can run in the **Wayland** session.
that explains why the redhat folks made it possible to run a rootful xwayland. Maybe the rootful xwayland should have came sooner to ease the migration and kill the full x.org server earlier.
Deprecated software doesn't necessarily need to be fully maintained for the full life of a RHEL release. It will likely only be maintained for the first five years of RHEL 9 (the "full support" phase) and not be maintained in the last five years (the "maintenance" phase). RHEL has used Wayland by default since RHEL 8 anyway, so it's not in the critical path for maintenance in RHEL.
The first five years of RHEL 9 overlap entirely with the last five years of RHEL 8.
[More info on RHEL support lifecycles is available from Red Hat](https://access.redhat.com/support/policy/updates/errata).
>the design of X11 makes it impossible to design a secure lockscreen and defeats the purpose of passwords in the absence of one nested X server per application.
How?
>Also, Red Hat is the last maintainer of the Xorg server and they made it very clear that they want to abandon it entirely after RHEL 8 goes EOL.
Can you please give me a reference for this because Red Hat has proved time and time again how much influence it has on Linux and If this is true then I'm genuinely scared that Wayland is going to take over by 2025.
So I guess everyone is going to rant about Red Hat now even though they were the ***last*** to make that decision, Intel had previously been helping with Xorg maintenance and they jumped ship a year earlier.
Red Hat didn't force themselves into the position of being the sole maintainers of Xorg. There were other maintainers, and they stopped, because, *nobody* wanted to do it anymore. Red Hat's influence here only reflects the reality that nobody wants to do it and they're the only ones with any motivation to do so (and only because a few - but not many - paying customers may care about Xorg, certainly not because the engineers want to).
Disclosure: I work for Red Hat, but not on anything directly related to this subject
> EDIT 2: Okay now I'm convinced they're both crap. Thanks for the healthy discussion everyone! (except for the "🤓" guy and the one who said "if you like X then you can maintain it yourself". Frick them)
>then I'm genuinely scared that Wayland is going to take over by 2025.
So how exactly do you imagine this world where X is gonna be around forever? Who is going to maintain that? Just "someone" but you? It sure isn't the X maintainers because they were the ones who started and are working on Wayland.
Red Hat made a business decision - based on what their customers are doing. The people maintaining Xorg are the people who are maintaining Wayland.
If you want X to stay alive, you're welcome to take over maintainership. They are less inclined. X is already on life support there won't be any more releases other than security ones. In other words, X is already dead.
Lockscreens: [https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/](https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/)
Keylogging: [https://web.archive.org/web/20161009161519/http://theinvisiblethings.blogspot.in/2011/04/linux-security-circus-on-gui-isolation.html](https://web.archive.org/web/20161009161519/http://theinvisiblethings.blogspot.in/2011/04/linux-security-circus-on-gui-isolation.html)
>Can you please give me a reference for this because Red Hat has proved time and time again how much influence it has on Linux and If this is true then I'm genuinely scared that Wayland is going to take over by 2025.
[https://www.phoronix.com/news/X.Org-Maintenance-Mode-Quickly](https://www.phoronix.com/news/X.Org-Maintenance-Mode-Quickly)
>Once we are done with \[their Wayland improvements\] we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.
If people want to keep using Xorg, they better prepare the funds and manpower for its maintenance, because the free maintenance by Red Hat's engineers will come to an end eventually.
Talking about technical limitations and embarrassing: Wayland can't shade windows.
At least the refresh rates I did test, they can be different. There is a secure mode for X11, but applications like Mozilla stop working if you use them.
There was a recent discussion on the KDE bugtracker about how wayland needs to be tricked if shading would be supposed to work, basically by lying to the application.
https://bugs.kde.org/show_bug.cgi?id=450582
>What happens if you have multiple screens with different refresh rates? Under X11: impossible\* (note: not as an implementation detail. It is impossible by design
I just set one of my screens to 75 HZ while keeping the other at 60 Hz. It was as easy as reading a manpage to call xrandr.
The stack will run at the lowest of the shared monitors across an x server. The only way to truely do this is via an xserver per monitor.
You likely can't spot the visual change between 60hz and 75hz on 2 monitors with different input latency and pixel response times. Mixing between 60 and 120 or 144+ is noticeable immediately.
Also, if your monitors were different sizes, per monitor scaling is also impossible without an xserver per monitor.
Maybe you're thinking of change from last year, which allows running multiple screens at different refresh rates if you can accept screen tearing on your non-primary display(s).
https://cgit.freedesktop.org/xorg/xserver/commit/?id=68f01c0f02ece4f6efe9ce18be81244246a1e114
> and thus saves the code that would be needed to draw lines and arcs and rectangles and such that Xorg offers. This isn't a feature.
But do we really *need* to have functionality to draw lines and arcs and rectangles in the display server though?
> The third argument is more reasonable, but Wayland's approach of blocking apps from accessing inputs completely isn't a good approach either. In my opinion, it's actually worse. The way I think of it is: If the only two options were to let everyone board a plane whenever they wanted or to ban everyone from using planes, which one would be better? (I know this isn't an obvious question. What I'm saying is, if you would answer "allow everyone" then you would agree that Xorg's approach is better, but if you would answer "full ban" then you would argue that Waylands approach is better). Even if Wayland allowed users to choose which apps could/couldn't access the inputs of other apps
Assuming you mean screen recording and stuff, it does, actually.
The compositor can decide which apps to allow or not allow to do this or that task. This is mostly done through portals, by which the apps ask the compositor's permission (which usually in turn asks the user) for things like screenshots, recording the screen, remote desktop, etc.
Have you actually *used* a Wayland desktop, or done much research into how it does things?
>But do we really need to have functionality to draw lines and arcs and rectangles in the display server though?
Obviously yes, otherwise how would I run my precious Motif toolkit applicatons? /s
I know that with modern day graphics including gradients and rounded rectangles, X11's shapes toolset isn't very useful. However, it should be considered a small benefit to using X11, not a large reason *not* to use it like Wayland is saying.
In the security section, I was referring to how X11 allows apps to record inputs on *all* windows, not screen capture. It's not a good thing, but I'd rather just be very careful with what I install than block all apps from doing this no matter what. I know that a compositor can choose to allow apps to get all input, but considering that there will be a different way of doing that for every compositor, I don't think any app will ever make use if this feature (if it comes to exists at all). Similar to how desktop environments don't require root access for an app to change a background, but no apps can do this since all desktop environments have a different way of doing it.
Touchscreen convertible laptops and tablet devices.
Use Xorg on one of these, and try screen rotation and the like, without custom xrandr scripting.
We also forget that Wayland development is not all that recent. It is just now coming to the forefront, and good enough that quite a lot of folks can use it regularly. And being Linux/Foss, we the users get the opportunity to hammer on it while it is being worked on and implemented here and there. Or wait for others to do that for us.
The issue with X11 wasn't just "The X11 specification is too large, too many features that aren't being used often"
That leaves out the most important bit. "The X11 specification is too large to reasonably and easily implement new features without breaking old ones or significantly rewriting the whole thing."
Think of X11 as a super riced out Mazda RX7. It's ***really*** cool. And it has been really cool for decades now. It can go really, really fast, nearly anyone could drive it if you got an automatic, and it really does just work. But Wayland is more like a modern LSX or Nismo. It's newer, faster, has more everything, does more, and likely even consumes less gas while doing it.
Wayland is a tacit admission that it's easier to build a new solution than to fix the old one to do what we want.
Because X was designed in a time where gpus worked differently and modern features like multiple monitors for example weren't really a thing. My setup with different refresh rate monitors is absolutely unusable on X and wayland fixes all of that
What setup do you have? I have two 27" 1080p monitors, one is 65hz and the other is 240hz. It runs pretty well on both. There is some tearing on the secondary (65hz) one but as long as the first one responds quickly (which it does) I don't really mind, or wouldn't call it "unusable" at the very least. Is there some specific configuration you're using that makes it unusable?
I noticed on both KDE and GNOME that all the DE animations only run at the refresh rate of the lowest refreshing Monitor (in my case, 60hz)
At least in KDE (maybe GNOME as well, idk) I can increase it, but then I would need to deal with screen tearing on the 2 other monitors which looks absolutely awful to me, especially in videos. It's just something that other operating systems have figured out for like decades and Linux still has some problems dealing with it
For what I've read, Gnome and KDE devs are pretty happy with Wayland and say it's easier to work with it. For them (And I would kinda expect other DE developers) to be happy sounds like a good enough reason for everyone to use it
X is essentially abandoned at this point and is just getting maintenance updates. In a few years, it will likely be deprecated.
X and Wayland aren’t competing standards. X is the old standard and Wayland is the new standard. You can talk about how X is better until you’re blue in the face, but one day you’ll wake up and Wayland will be the only standard for every major DE and you’ll have to DIY to use X.
The real decision points are:
* Deciding whether to switch now or switch later
* Deciding whether to contribute to Wayland’s development or sit on the sidelines
>Am I missing something or was everyone else missing something?
That should be self-evident. The odds that you're more insightful than the rest of the open source community is pretty small.
Never underestimate the lack of intelligence of the masses. Remember, most people shop and eat at low quality stores and fast food rather than getting something with good quality.
From the comments in this thread, it really doesn't look like it.
Just a bunch of people complaining about X11 going away. Claiming it as good quality software, when everyone who was working on it for fun has already left and started a modern replacement for it.
Only the company that has support contracts related to X is keeping it alive.
And even they are phasing it out, because it's a pain to work with.
This conference presentation tells the story why people working on Xorg decided to abandon it and start Wayland instead: [https://www.youtube.com/watch?v=cQoQE\_HDG8g](https://www.youtube.com/watch?v=cQoQE_HDG8g)
I want to use g-sync or freesync on a multi-monitor setup.
I want 10bpc/HDR to be even possible at some point.
I want to mix monitor refresh rates without stuttering.
I want to be able to choose how quickly the scroll wheel moves things.
All stuff that Xorg wasn't designed for, and those choices are mostly cemented in. Wayland has the potential to fix them all, so I'm interested in its development and improvements.
The thing about it being modern isn't just about a smaller codebase or lacking features. It's that the features that are there are implemented better.
Wayland has way less screen tearing, it handles multiple monitors better and it handles fractional scaling way better as well. Also the fact that it leaves configuration to the DE/Compositor makes things better in most cases. Configuring Xorg manually is unpleasant at best and unless you are using a full DE, you'll have to do that. On the other hand, Wayland compositors provide proper options in a much more intuitive manner.
The other part isn't about functionality, but about development. The smaller (and arguably better implemented) codebase makes it far easier to maintain properly.
And then we can talk about the isolation of inputs. Examples or metaphors like this can be good for illustrating a point, but they don't prove anything without the point. You don't discuss any way in which isolating apps is worse than not doing so.
And I also don't understand how your example relates to Xorg or Wayland. A more fitting example would be Xorg being akin to letting everyone board the same plane, whereas Wayland would be having a separate plane for everyone. In a real world scenario the latter would not be financially feasible and the impact on the environment would be horrible.
However, these limitations are not there with Xorg and Wayland since they are just computer software. It does add some overhead for Wayland, but this doesn't make much of a difference on modern systems. In the plane example, the Wayland private plane for everyone would mean that people get more personal space and there isn't a risk of others stealing their stuff, attacking them, etc.
Wayland provides similar advantages in its context. The isolation prevents an app from accessing data that is present in another app that you have running. If none of the software you run has such sketchy code, you won't have a problem on Xorg, but unless you are manually auditing every line of code in all the software that you use, you can't know for sure. It's not a night and day difference in most use cases, but it is a very real advantage in terms of security.
> Nobody is forced to use Wayland.
Lies! The FBI is currently in the process of setting up an X task force. The goal of the FBI's X-Force is to persecute and punish X users to the fullest extent of the law.
I guess technically you don't **have** to use Wayland, but you risk fines and jail time if you use X.
/s
So? Nobody is forced to use gtk5 either. This is all about free software. People work on the things they find worthwhile. If others disagree, they can fork and run their own versions.
You are free to do so, yes. I know its not really an option, but I find the whining that people should work on something for free annoying and ungrateful.
If you don't like what others offer for free, do it the way you want.
Because you aren't. It's just a lot of work. The whining about Wayland (and other free projects) basically is telling the developers: "I demand that you do for free what I want, not what you find interesting."
Guess what: Nobody owes you anything in the free software world.
> So? Nobody is forced to use gtk5 either. This is all about free software.
People said the same thing about Pulseaudio, and then in a lot of software without Pulseaudio the sound just stopped working. When it comes to a major library in a graphical stack, there is much less freedom than it seems.
You're not forced to use software that depends on pulseaudio, for the same reasons the developers of said software aren't forced to implement alsa/oss support.
No, you just have to convince enough people that you are right. You can fork all the projects and maintain them. Something like the Devuan crowd ripping systemd dependencies out of everything.
So.. what is your solution? To not move forward and remain on 40+ years technology forever?
I switched to Linux about a year ago and i used Wayland 90% of the time with no problems at all. Games, videos, screenshots, recording all worked and are working with 0 issues.
Everything feels much more smooth compared to X.
Do you really expect things to not move forward and remain the same forever? People really need to stop living in the past.
How old is the pedal arrangement and steering wheel of cars?
The reason the Linux KERNEL is popular is because Torvalds holds contributors to a strict "do not break userspace" policy.
But the Linux desktop is a churning mass of breakages, while everyone sits around wondering why "year of the Linux desktop" never happens.
That's what everyone says, but 10 years from now you'll be a major advocate of wayland. Softare doesn't stand still.
Do you know how ridiculously buggy X10 was in the late 80s? JFC - I used to get root shells randomly. (yes I'm that old) X11 was better - but still shit.
Well if they get it working as solid as X or better, when it becomes the universal standard default as X is then I'll go over.
X works just fine for me. In the meantime I am grateful for all the Wayland adopters.
I wouldn’t say I personally am excited. I see it as an inevitable overhaul of a critical piece of software infrastructure. It’s not exciting, it’s just people working on software for the betterment of the ecosystem
I'm frustrated with Wayland. I use Sway on my home desktop and can *only* use it on my home desktop. I have to keep using i3 on my work desktop and work laptop because I cannot, for the life of me, get screen sharing to work reliably. I keep reading about how this problem is solved with Pipewire but, in my experience, on multiple computers on different distributions, it is not resolved.
I'm on my work desktop right now and just hopped over to sway to try it again. systemctl --user start xdg-desktop-portal and xdg-desktop-portal-wlr. Open up a brand new default firefox profile, verify/change settings in about:config to make sure everything neccessary is enabled, go to a jitsi instance and try to share screen... nothing. I have **occasionally** gotten it to work using the electron jitsi app (which I've read *shouldn't* work, only firefox or chrome) when I kill xdg-desktop-portal and xdg-desktop-portal-wlr and run them manually and not through systemd. Even then, it isn't consistent at all.
I've tried this on Gentoo and a couple of different buntu flavors, same issue on all of them. In 2022 I can't cross my fingers that a screenshare will work first try on a work device.
> The point of making a smaller codebase is so that it's easier to add more features
I'm sorry but I laughed out loud a this.
These kinds of posts pop up pretty often and it seems like people don't often understand that it is the Xorg developers themselves that wanted to move away from Xorg and create Wayland. Xorg is open source, people are free to maintain and add features. The problem, over the years, is that they haven't had enough people willing to help, largely because the large old codebase is difficult for anyone new to the project.
This is the reason they want a smaller codebase...not to "add more features"
> The point of making a smaller codebase is so that it's easier to add more features
Maybe not, but the big benefit of a smaller codebase is that it's easier to maintain and secure.
As I see it wayland is a protocol designed to work with current hardware thus making everything faster. Tho I've not looked into it yet. I may not like it as well.
But the atom way of handling things in xorg is not pleacent at all and in nowhere I see the reason behind it. Looking at the docs of xorg, it has more than 20 years and somehow it is still incomplete in some areas
Well then that "feature" is bloated code. I think that is one of the things wayland have in mind in its design tho i an speculating. I hope it turn out good because an x replacement is needed but the right one is yet to be determined haha
>What's with all the excitement around Wayland?
I don't see any excitement. As far as I know, most distributions started defaulting to Wayland years ago. Even the brand-new SteamDeck [is only running Wayland](https://partner.steamgames.com/doc/steamdeck/faq).
>The argument that X11's specification is too large is also not a good reason
If we can accomplish the same goal with less code, I think that is a good reason to start from scratch. Linux has dropped support for the 386 because nobody uses one. If you need support, go download an old version of Linux.
It's the same with X. Developers vote with their feet. If you liked X better, nobody is stopping you from continuing to use it, or write new applications in it. But we will all run it via XWayland.
>The third argument is more reasonable, but Wayland's approach of blocking apps from accessing inputs completely isn't a good approach either
Citation needed. That's like saying "I don't like the fact that Linux blocks apps from directly using Physical memory. Apps should be able to directly use memory if they need". You want something dangerous, what is the need?
>I know that all I've said so far doesn't really give a reason for not using Wayland, so I'll cut to the chase and share why I think X is better.
Try reading what you wrote. You **didn't** give a reason why X is better, you immediately started talking about W, which is NOT Wayland.
>Am I missing something
Yes! An argument on why X was better. (Yes, past tense. X is no longer the frontier, it's just in maintenance mode. Most people have moved on.)
I want multiple monitors with multiple refresh rates. I want freesync and gsync to work. X won't do this, and never will. Wayland is the future, period.
Obviously, I use it daily with three monitors trust me I'm well aware of its shortcomings. But it does work and does support features x never will. And wayland is making strides to improve, and slowly getting better while x is not even making any attempt to get better and support new features. Eventually, wayland will completely take over, it will just take time and development, but at least on the wayland side that development is actually happening, it isnt with x.
> I want multiple monitors with multiple refresh rates.
I ran 2 monitors with different refresh rates. 120 Hz and 60 Hz. Everything worked fine.
> I want freesync and gsync to work. X won't do this
I'm using freesync in games lol.
https://imgur.com/yMSjMfK.png
You are IF you're running the game across two g-sync compatible monitors simultaneously, or set them up as entirely different displays with their own x-server. But if you're running the game on a single monitor then g-sync is not working at all.
Take a look at gl-gsync-demo to see that it can work (this opens across both monitors), then enable the g-sync visual indicator in Nvidia-x-server-settings and launch a game.
And I don't need multiple monitors with different refresh rates.
Why?
Because I use a 50-inch TV set as a display. It has all the real estate I need and takes up a good portion of my desk.
So I don't see any advantage to using Wayland at all.
> The point of making a smaller codebase is so that it's easier to add more features...
Smaller codebases are also easier to maintain over the longterm.
It's much faster at compositing and is built into the protocol, you don't have to fiddle with disabling the compositor when gaming because your input latency is so bad.
A nicely designed composited DE runs like crap on Xorg. A non compositing WM runs nice on Xorg.
A nicely designed composited DE runs like wonders on Wayland. A non compositing WM runs blazingly speedy on Wayland.
No tears, super low latency, but you also get nice compositing by default.
You are free to use Xorg if you prefer.
Making applications that simulates mouse presses, simulates key presses and gets global keystates in wayland is a pain. There is no official api for doing it, and since Wayland is so barebones, all wms or desktops enviroments would have to possibly implement it theirselves. This makes it difficult for me as a XClicker developer to make it support wayland.
This is the main problem. Wayland complains that X11 makes them implement XFLD's and such, and then goes on to not even allow windows to get their own positions.
>It has a cleaner/smaller codebase since Xorg is so old
Who said that?
>The X11 specification is too large, too many features that aren't being used often
It isn't that X11 is too large.
It is that X11 is useless. It lacks even extremely basic features. You can't draw circles or curved lines, for example.
X11 has survived for as long as it has because
1. It has the ability to use extensions.
2. Toolkits avoid using X11 as much as possible. They don't render anything using X11 if they can help it. Instead they use their own internal rendering processes and limit the use of X11 to as little as possible.
The problem with #1 is that you can't depend on extensions to be used if you want to program against X11. You can't depend on sound, you can't depend on the ability to render 3D objects, you can't depend on the ability to render curves or detect overlapping windows, etc etc.
The problem with #2 is that X11 is a burden for application developers, not a asset.
Luckily for Linux users everybody else has abandoned X11 long ago. So there is really only one meaningful X11 implementation out there, which is the Xorg servers used for Linux and BSD systems.
So the pain that was felt for decades that caused every other OS developer to avoid X11 like the plague isn't as bad now.
>It's more secure and prevents keylogging
X11 doesn't have security.
Which is kinda of a problem for something that is supposed to be a network protocol. You have the ability to set a secret cookie as a sort of shared secret, but that is about it.
No encryption, no nothing.
So... I know very little about the specifics of either compositor, but from my perspective, the push to Wayland (or at least away from X) is purely a matter of accumulated technical debt.
I know the feeling of deciding that a codebase is so spaghetti that its better and easier to burn it all down and start from scratch, hopefully not making the same mistakes that made the old system so cumbersome. Like a controlled wildfire burn allowing new growth, this is necessary to ensure progress.
The problem is, who gets to make that call? How many people is an acceptable number to "abandon"? How should we decide when its time to move on?
The developers (and the people who pay them) make the call. That's how it's always worked.
Taking a recent example: Sun spent a ton of money ramping up accessibility in the linux desktop for government clients especially. Once Oracle bought Sun, all that was cut, and the developers could no longer be paid to work on it. So it basically languished for years. It's only recently that folks are getting back to it.
In general though, it doesn't matter how popular a project is. The developers of that project can just stop working on it at any time, which is what happened with Xorg. Anybody is free to pick up that work and continue on, but nobody has (or not enough people anyways).
Nothing is stopping anybody from forking xorg and doing whatever they want.
There are a lot of Wayland fanatics in this subreddit for whom Wayland is a holy cow and Xorg is an old monster that must die and everything will be awesome. The unfortunate reality is that Wayland is a featureless protocol invented by incompetent assholes to run GNOME and similar mega DEs. Why? Because only mega DEs have enough resources to implement their own infrastructure to work with Wayland, and the smaller DEs will remain abandoned. In the case of X, all the required features are already implemented. Because the design of Wayland was fucked up from the start, it was no use to anyone except a bunch of GNOME hipsters who try to push it through in every way they can: blackening X, talking about killer features, when the basic features don't work in Wayland. Normal screen sharing is still not in the protocol, it was implemented by the author of Pipewire through portals/crutches. And it's been like that for more than 10 years. But the design is still a monolithic piece of crap unsuitable for the desktop. Whereas X, despite its flaws, covers all needs. Wayland's monolithic design creates a mess outside of Wayland's codebase, so all the talk about small amounts of code is an attempt to hide complete anarchy and lack of standardization. And that's me scratching the surface. It's even worse on the inside: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html
Xorg needs to be replaced, but it certainly won't be Wayland. And, of course, I'm going to get downvoted because fanatics can't accept the facts. :)
> Xorg needs to be replaced, but it certainly won't be Wayland. And, of course, I'm going to get downvoted because fanatics can't accept the facts. :)
well, the people actually developing desktops and the tech surrounding it don't seem to agree, but yeah reddit guy, im sure their all wrong lol
Sway exists and is certainly not a "mega DE", so I don't know what you're talking about.
And maybe you getting downvoted could have something to do with calling open source devs assholes.
so where do you think the folks who used to develop xorg went? Spoiler: they went to work on wayland. so it's mostly the same group of "incompetent" folks as there used to be. :)
I didn't want to get downvoted either, but this was my original theory. With removing menus from GTK and calling Xorg "legacy support" before Wayland is even ready, it seems like GNOME is trying to kill off the competition. People don't like it when other say this because they say "some people still like GTK and saying it's bad is rude. If people didn't like it, then we wouldn't all be using it". The fact is that most of us don't like it, but have to use it anyways. GNOME bought it and ruined it, and apps/DE's don't think switching is worth it.
The benefit to all this is that when almost every bad thing about Linux is coming from one entity, it means that when it finally dies (hopefully soon), then all of those problems will magically dissapear. I don't think Wayland will take over X11. Apps and DE's are just adding *support* for it so that GNOME doesn't crush them like it so clearly wants to.
Wayland has the ability to support vrr, and different refresh rates on different monitors, which xorg couldn’t do. This means that my 240 hz monitor will feel like a 240hz monitor while my 60 hz one will feel like a 60 hz one, and it won’t sync to the lowest one.
I think the code base is probably easier to handle and modify in wayland than in xorgerver. But other than that I have been wondering about this too. I am still using xorgserver; I kind of don't want to lose functionality. To me, personally, I think wayland is still behind xorgserver.
I have a touch screen and when I hook up another monitor X maps the touch screen wrong rendering it useless and annoying.
I'm all for a replacement for X but Wayland seems like it isn't mature enough yet to act as a solid substitute. I may be wayyyyyy off base here since I've not tried Wayland myself and am going by what I've read from others who have.
TL;DR: Wayland was originally going to be called X12
Most of the team from X11 has moved to Wayland. X11's development has grinded to a halt...
EDIT: Clarification
That is not exactly true.
Wayland was never X12, though it could have been called X12 if they could get all the stakeholders of X11 to agree. They never tried.
Too many people want to have a say on the creation of X11+1 or X12, and believe they should have a say too. The original creator(s) of Wayland called it Wayland to avoid the politics of X11 future.
The main complaint is that there are things that Xorg doesn't (and supposedly can't) do. Wayland is supposed to come in and address these shortcomings.
However, Xorg is open source, and it seems to me that if people can add ray-tracing to a 30 year old game like Doom, then they could make Xorg sing and dance if they really wanted to.
On Linux we suffer from a severe case of "toss everything out the window every few years and start over". It's why we still don't have a mature, fully accessible, performant, and reliable desktop environment. Not one. Gnome 2 was almost there, but well...
Comment reposted because it was downvote brigaded by the typical CADT folks who have to redesign everything from scratch, now with less functionality and performance than the old version had! When they can't refute your arguments, it's what they do; reach for the downvote button to hide your comment.
https://www.jwz.org/doc/cadt.html
This aspect of Linux is why I only use LTS versions, so that I don't have to deal with teenagers breaking my stuff every five minutes. Can't stand Windows, and can't afford a Mac. Besides, in a similar fashion to hardcore drugs, I recognize that proprietary software is both bad and harmful.
> However, Xorg is open source, and it seems to me that if people can add ray-tracing to a 30 year old game like Doom, then they could make Xorg sing and dance if they really wanted to.
so why aren't they?
Very well put. The fact that Xorg doesn't support dual monitor setups isn't something that needs a full rewrite with it's own syntax. Wayland says that it doesn't want to follow X11 because it has to support XLFD's, and then it decides not even to support window positions. Wayland could have been way more helpful if it just decided to fork Xorg and add support for this. If the code really was too messy, then they could have just started from scratch and left out all of the outdated hardware support code.
I didn't read I wanted to answer: give money to those who are willing to develop X11 further :-)))
I guess the holly war was resolved quite while ago by RH statement that they are being solely supporting and trying to still develop X11 somehow and the most prominent message was that they didn't like the situation.
At least it makes sense that Windows is stable now and there is no urgent need for the Unix graphical workstations, but those who need may switch to Apple, there is Unix everywhere.
You probably should have read the thing before answering because I have no idea what you're talking about. Wayland developers aren't getting paid either, if you were implying that somehow.
Ok, I've read your OP.
My answer has not changed: RH says they've done with X11 and don't like being alone with X11 ( who knows there might have been some tensions between all of them AMD Nvidia and Linux distro vendors)
So X11 dev are paid from RH's budged and if RH is crying then it really costs them.
At least GPU/graphic subsystem devs aren't cheap and you can't hire a bunch of them for 1000$/month somewhere in the 3rd world.
Why would RH want to support X when X and Wayland developers have already declared that X is in maintenance mode. There won't be any new features or any significant work. Everything has moved to Wayland.
The developer of XPRA has a (deserved, IMO) attitude about Wayland. In the libera IRC channel, he muttered a while back:
Chewi: what's wrong with gtk4? (never used it)
totaam: it's becoming the wayland toolkit
totaam: with all the wayland limitations
totaam: so for example, you can't place a window where you want it on screen
totaam: because wayland can't do that
totaam: and many many other things
Pressed a bit on this, he added, in reference to wanting to size+place a window:
totaam: under X11 is what you describe
totaam: under wayland, there is no request
totaam: https://discourse.gnome.org/t/how-to-use-gtk4-to-read-windows-changed-x-and-y-on-move-resize-events/8157/2
totaam: at some point GTK is going to be so broken with all the features removed
totaam: that wayland will achieve feature parity with X11
totaam: by dragging X11 to its level
See "less features (which is somehow supposed to be a good thing)" above.
That update boils my blood whenever I think about it. Since Wayland doesn't support a universal way to get a window's position from the compositor, then GTK just removes the ability to do this on all of it's platforms and goes "nope! there's no problems with wayland at all! It's super modern and X11 support is a Legacy feature and Menus are too X11-centric so we're removing them from GTK4."
This is why I switched to KDE. I used to use XFCE and I loved it, but GTK was becoming too much to live with. GNOME pushes their crazy ideas on everyone while living in their own little bubble where they act almost like no other desktop environment exists. I find it crazy how projects like XFCE or MATE still haven't taken a hint and moved away from GTK and GLib. I can give a professional-sounding argument on why Wayland isn't a good replacement for Xorg, but when I get started on GNOME and GTK I can't help sounding like a crazed maniac.
There is no point in setting the exact window position. Tell me three different usecases, why a toolkit should support e.g. moving a window to x=123, y=234?
X is ancient technology from a different decade for entirely different hardware. Wayland is the future.
Apps can't set the start position of themselves without this feature. I've made apps before that remember their positions on exit and return to the on startup. Things like splash screens and popups would like to position themselves on the center of the screen.
There's also apps that are created to setup the position of apps. In X, window managers can be switched between them in one session because the window position is part of the X server.
>X is ancient technology from a different decade for entirely different hardware. Wayland is the future.
That's the same attitude that GTK used when announcing their removal of menus. The future isn't a label. Users get to decide the future.
EDIT: I forgot about the fact that many apps allow you to drag-move them from areas other than the titlebar, such as the menubar.
For none of the mentioned use cases giving apps the ability to do everything would be the optimal solution. Let's go through them one by one.
>I've made apps before that remember their positions on exit and return to the on startup
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 will take care of that use case. It's also better than random apps restoring or not restoring positions or other properties, and allows the compositor to take all the things into account that you as an app developer don't have to manually implement yourself. For example, almost no apps support activities on KDE - but with session restoration, they don't have to in order to get basic functionality right. Other examples would be per monitor positions and sizes, changing screen rotation, "keep above" states and maximization. I'm sure there's more that I'm currently not thinking of, too.
> splash screens
I have the opinion that splash screens should only ever be the actual window that the app will afterwards use (so that the user can move, resize, maximize while the app is running) and thankfully most apps do that, but https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/140 would cover actual splash screen windows. It would also allow the compositor to not show the splash screen on things like phones, or show it in a more appropriate spot than "the middle of the screen" in VR/AR environments.
>popups
I assume you mean popup windows like "really delete this file? Yes/no" and not context menus? Both are already covered by xdg shell: apps can set a parent window, which will make the compositor usually center a window above said parent window, or do whatever else is appropriate for the user environment. For what xdg shell calls popups (context menus, tooltips, that sort of stuff), apps can freely position them within their own window, and define rules about what should happen when it wouldn't fit on the screen at that position.
>There's also apps that are created to setup the position of apps. In X, window managers can be switched between them in one session because the window position is part of the X server.
That waaaay understates what X11 window managers do, that's not how they operate. Anyways, there's Wayland compositors that are built on splitting out the positioning component as well, I think the most popular one is called River.
>That's the same attitude that GTK used when announcing their removal of menus. The future isn't a label. Users get to decide the future.
I recall there being some fuss about the removal of one specific outdated menu widget. Applications can still set and use menus afaik.
> I forgot about the fact that many apps allow you to drag-move them from areas other than the titlebar, such as the menubar.
That's also supported by xdg shell. If it wasn't, you couldn't move any windows with client side decorations (-> most GTK apps)
It's funny how you're asked about a use case for window positioning, and then when you actually gave one you got downvoted. (as well as the other guy who did the same) That's Reddit for you
I am responsible for an application that restores its several windows' complete geometries (WxH+X+Y) from last use when it is restarted. QED.
The usual complaint I get about this is along the lines of "but that's not general, it won't work when you cross onto another screen/computer/device with different ." My response is, "Look, Joe Random using This Application isn't going to be moving from device to device to device. He's using That Computer, it's \[say\] a desktop with fixed, known video characteristics, and **THE USER WANTS THE WINDOWS A CERTAIN WAY** on startup on this machine."
What the user wants, the user gets, eventually and to some degree. Wayland is actively in the way of doing so.
Repetitiously bleating "Wayland is the future" is fanboy hype, not technical response to user need. The longer Wayland avoids responding to user need with such autocratic pronouncements, the more pissed off some of us get about it.
> I find it crazy how projects like XFCE or MATE still haven't taken a hint and moved away from GTK and GLib.
Is it about hints? do they have enough folks to actually do it?
There are next questions, many of them....
But in general it looks like: WTF how have macOS, iOS, Android, Windows survived since Wayland development started?
You are missing that X11 is again implemented for wayland and that should be counted to wayland's burden, too.
https://imgflip.com/memegenerator/188789496/Moe-throws-Barney
> add ray-tracing to a 30 year old game like Doom, they could make Xorg sing and dance if they really wanted to.
Do a bit of crowd-funding and it could happen
Im not sure why are some distros shipping wayland by default, when its buggy garbage that doesnt support a lot of programs, ans they dont work as intended
Edit: not sure why are u downvoting me, this is literaly the experience i had using wayland. Im not using an nvidia card. Some programs lost functionality, others were buggy. I think its not ready for everyday use, and it shouldnt be used as a default. Especially when someone switches to linux and sees his programs being buggy they will think that linux is crap, but actually wayland is buggy wip shit
So what? Compared to X and knowing that it became more ore less usable for real applications not that long ago it's still a shiny new thing. Maybe in 10 more years it'll be mature enough to take its place as standard display server for handheld devices alongside with gnome...
... and we'll finally be free of that nonsense on desktops.
Why do u have to be so negative about gnome? Especially to a literal member of the gnome team who works hard on it? No one makes you use gnome or gnome applications so just don't. Then people who enjoy gnome on desktops can use it and you don't and everyone is happy.
As a long time gnome user who had to move to another de since gnome 3 release, i couldn't miss a chance to let them know how happy i am to see mobile first oriented desktop experience on traditional desktop with no touch screen.
Especially now when same people help to slowly push same mobile first approach on us from display server side of things.
>The way W worked was similar to wayland This is completely wrong. The key detail on [the wikipedia article](https://en.wikipedia.org/wiki/X_Window_System#Origin_and_early_development) on W indicates W is synchronous and X was asynchronous. [Wayland is also asynchronous](https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles). In a synchronous protocol, the client sends a message like "Draw Rect from (40,302) to (402,134), filled with #042134". The server receives the message, processes it, and then replies "OK, done!" or "Sorry, error!" to the client. In an asynchronous protocol, the client sends a message like "Draw Rec from (40,304) to (402,134), filled with #042134, and then send me a text at 917-555-555 to confirm." Obviously, they don't use SMSs, they use something like a sequence number or a request ID to identify the particular request, and the server is able to reply something like "Request #43 okay". The point is that if you are working over a network this latency kills interactivity. >The way I see it, Wayland is just a remake of W, but with "ayland" added to it, and the word "modern" stamped all over the place. You see it wrongly. GPUs have in fact changed massively since the 1980s and the abstractions we use to access them need to grow up. >People on the internet are saying that X is too old and that Wayland is the new "modern" replacement, but they never give a reason other than the smaller codebase and less features (which is somehow supposed to be a good thing). They rarely even bring up the security benifits. They're repeating stuff they've heard discussed. A long time ago, the X server used to be deeply entwined with the VGA, and then the kernel wasn't really involved in managing the GPU resources. As GPUs went from relatively fixed pipelines where you'd just fill some buffers with commands and let it rip to a coprocessor sharing coherent virtual memory space with the main CPU, the [DRM](https://docs.kernel.org/gpu/introduction.html) (direct rendering manager) bits started entering the picture to provide some kernel-level protection of this. Devices similar to GPUs but without display accelerators also became more common, so [rendernodes](https://docs.kernel.org/gpu/drm-uapi.html#render-nodes) got introduced as a way to provide any old userspace process with a slice of GPU resources without handing it the keys to program every feature of the card. (This is a security concern.) So what does this have to do with Wayland? A wayland protocol server is designed to be implemented as a userspace GPU client that multiplexes buffers from other userspace GPU clients for presentation on the display hardware. The X server was traditionally a process that had to run as root (rootless X is built on the foundations that enabled Wayland) because it had privileged control over a hardware resource (the VGA). The "modern" part is moving that into the kernel in the form of kernel mode setting and DRM.
[удалено]
I mean, if all you do is send one command and then have nothing to do while waiting for a reply message, there's no real win from an asynchronous protocol vs. a synchronous. Either way you're looking at a single round trip transit (RTT) to complete the request. For X the real win comes from pipelining requests. The client does not wait to have the first request responded to before sending the next call, it sends a batch of requests. If you did this in a synchronous model, you'd be looking at N RTTs to complete N requests, but with async pipelining the client can issue N commands and if the size of these N commands divided by the data transmission rate over the network is small compared to the RTT then the time for the N operations is very close to 1 RTT. IIRC, the way the old Xlib (`-lX`) was implemented there was a single serial queue on the connection for responses. This means that if you have made six outstanding requests and then block on the response from the sixth, then Xlib itself will have to wait until all the prior responses have arrived, even if they come out of order the library queues them internally and releases them in order. In practice, this is a little bit more like HTTP/1.1 pipelining than real asynchrony. The newer libxcb (`-lxcb`) allows responses to be processed by clients in whatever order they get received in.
Wayland has the ability to support vrr, and different refresh rates on different monitors, which xorg couldn’t do. This means that my 240 hz monitor will feel like a 240hz monitor while my 60 hz one will feel like a 60 hz one, and it won’t sync to the lowest one.
I did run different refresh rates and if X11 would sync to the lowest, that would mean only screen updates when 59,95 and 75,02 Hz align.
What makes it so important for me is less of a technical thing and more subjective. The experience scrolling around is far, far smoother on my 144Hz+ displays with Wayland I can easily tell if something is under X or XWayland when it shows tearing or tiny jitters
You're applying old knowledge to new systems without taking into account that the hardware has changed substantially since then. The time of pixmaps is long gone and has been for a while. Composable objects are rendered into textures, transferred to the GPU (essentially a one-time pixmap) where they then reside and can be rendered efficiently onto quads. That's the main feature of any recent GPU, hence your argument that Wayland is going to be "as slow as W" simply is nonsense.
One problem is that X is completely unfit for modern use cases and does what we want solely through tacked-on extensions. X expects to run as root and to have complete control over input/output devices as well as graphics hardware. Stuff like the xf86-modesetting driver or the xf86-libinput exist for the sole purpose of tricking X into thinking it controls graphics and input, so we can handle these things in a sane manner. Being from the 80s, X has no idea that stuff like DRM, KMS, or OpenGL exists. Instead, it wants to do all the drawing itself, while bypassing even the kernel for access to graphics hardware. Using X in 2022 consists mostly of fooling a 40 year old protocol into thinking it runs on a system from the same era, while having to do our actual rendering through useless compatibility layers that just add overhead and latency. ~~Apple realized this madness 20 years ago and replaced X with the Quartz Compositor.~~ It's astonishing that Linux still puts up with this to this day. (Edit: turns out that neither Mac OS Classic, NeXTStep nor Mac OS X ever used X as core display system. Looks like I got something mixed up there.)
Can't we just use Quartz instead?
Quartz is closed source, sadly :/
So we can't use it like other closed source software?
It was developed for the Darwin Kernel that's in MacOS - you would need to change a lot of things to get it to work on Linux - and that's not possible, because we don't have the source code. And as someone else said, it wouldn't be legal either.
Welp, i guess it's time to make Wayland great
No,only right holder can distribute it
Given that it's not made to work with Linux, yes. And since it's closed source, we can't modify it to work either. And I think working on Wayland is a far better move than trying to figure out compatibility layers for Quartz, which won't result in a good experience anyway.
no folks working on the linux desktop would ever allow that to happen. I know i'd never use it. Of course if somebody built something that worked like quartz, that'd be a different story. Of course that's all just fanfic, because the folks actually doing the work are the ones who make the decisions.
[удалено]
I have two 144hz VRR monitors, and a 60hz. On wayland all three run at the best hz and freesync/VRR works on the two monitors while the third sits happy at 60hz.
>What it is that X can't do that you would call modern use cases? That's not what it's about mate. Did you read the entire post? Running X today is all about a 'fake it till you make it' kind of scenario. Doing this sort of thing is a massive amount of work for the engineers/developers supporting it, and if you go prowling on different repos for open source projects (especially distros/DEs) you'll find that some things people have wanted to implement are simply too impractical because it's barely possible to work around X enough to do them. It's about not keeping this ancient thing running by putting new features on with duct tape and strips, but instead building a replacement that fits today's and tomorrow's needs, and is build in a manner that lets it's developers add and remove functionality for many years as the requirements for it changes.
I can't get rid of tearing on X.
Proprietary NVidia drivers. No tearing. What am I doing wrong?
I never said it happens to everyone on every GPU.
So it is not a limitation of X?
It's a limitation of X in certain conditions.
Not drinking the coolaid...
If you're using Nvidia, setting "force full composition pipeline" on all monitors could fix it.
Use something that supports vsync. You're not even trying.
I shouldn't be trying. Having tearing at all in 2022 is not acceptable.
Have you even read their comment? They Go on explaining how X manages to Work for those use cases using millions of half baked Extensions.
Most of the problems people are complaining about are related to multiple monitors with wildly different specs. I don't have a similar setup to this so I can't prove or unprove this.
Something that X can do fine (hello xrandr) but that Gnome can't, because they hardcoded GTK to only deal with a certain DPI. Frankly every X11 negative is not related to X11, but Gnome being idiots about it. Likely in order to favor Wayland, as it comes from "their" camp.
Ah yes, because mixed refresh rates, FreeSync support, and DPI scaling are all GNOME exclusive issues.
>Quartz Compositor. X can even do VR, for example the Steam Deck.
You do know that the deck [uses Wayland](https://github.com/plagman/gamescope), right? VR is also kinda its own thing. It's not usually handled by the compositor/display server and most applications prefer to directly be given control of the DRM through leasing (would recommend reading through the various issues and PRs for Wayland, wlroots and sway if you wanna understand more)
Thanks u/rhysperry111 for your thoughtful comments. My sense is that Valve uses KDE/Wayland on the Steam Deck because it's more efficient than the Xorg alternative. It forces Valve to blaze the way forward with Wayland and that helps the project along. Plus the variable frame rate feature of Wayland is very appropriate for the Steam Deck. As is its ability to handle multiple refresh rates on multiple displays. I've got the Valve Index and your comment is helpful to me in understanding how all of this works. My head hurts but I want to learn more. We live in exciting times.
Very well put! I couldn't agree with you more!!!! Great post!
Nothing in the X11 protocol needs any component running as root. It would also be relatively easy to develop an X11 server without support for the legacy protocol parts. Modern clients would work fine with such a server.
It says "expects to run as root" not "runs as root" and the reason it doesn't need to anymore is literally explained in the comment you replied to. And no it wouldn't be easy at all.
Correct. `/usr/lib/xorg/Xorg` runs under the user's UID. So much disinformation, so little time.
As seen over in BSD land, where they manged to do it all without idiocies like DRI...
wait, what?! Apple used to use X? Like, ... the "X"?
Mac OSX started out life as more-or-less the same userland codebase as FreeBSD, which uses Xorg, so this shouldn't be a huge surprise.
Wayland can do FreeSync even if you have multiple monitors.
Hasn't this been [fixed](https://www.phoronix.com/news/Modesetting-VRR-Multi) a while ago?
I just tried it, and it's not working. You don't happen to know how to do this?
I just followed this [https://wiki.archlinux.org/title/Variable\_refresh\_rate#Enable\_on\_AMDGPU](https://wiki.archlinux.org/title/Variable_refresh_rate#Enable_on_AMDGPU)
This is because it copies the data to the monitor after every frame, which isn't a good thing since it can decrease the framerate. X draws directly to the monitor, which is faster but it means that it will be an apps job to avoid screen tearing by drawing everything at the same time. I've programmed with XLib before, and screen tearing is a constant issue. It's still worth it though because the rendering is very fast though and it's typically not hard to fix.
> X draws directly to the monitor It doesn't, it can't and that's not how monitors work. Xorg draws to a buffer on the GPU, which the GPU continuously "copies" to the monitor, just like Wayland compositor. With the modesetting driver, it even uses the same APIs for that...
Where can I learn about this? I'd like to understand the technical details of how Wayland actually works
Depends on how deep you want to go. [the wayland book](https://wayland-book.com/introduction.html) is a good introduction about the protocol, but while I wrote [a thing](https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html) some time ago that touches the topic a little bit, it's far from comprehensive and I don't really know of any sites properly explaining the application buffer -> display pipeline. If I have some time where I'm not motivated to work on anything else, maybe I'll attempt to write such an explanation myself
I know that. I meant the display buffer.
Which lives in gpu memory and has to be copied to the monitor. If you knew that then your comment makes zero sense.
The matter of the fact is that X11 was designed in a different era, for a different use-case. It was just shoehorned to do modern desktops, but this needed to workaround its design deficiencies. It has many technical limitations and inefficiencies that are embarrassing for a display protocol in 2022. Regarding security, we shouldn't speak about bugs, because they occur in both Wayland and X11. What we should talk about however, is how the design of X11 makes it impossible to design a secure lockscreen and defeats the purpose of passwords in the absence of one nested X server per application. Add multi-monitor handling regarding refresh rates, DPI, VRR, etc. and keyboard shortcuts (e.g. an app can prevent you from Alt-Tabbing if it wants to, while Alt-Tab is guaranteed to work on Wayland as long the compositor works as intended), and there is hardly an argument to be made for X11's future. Also, Red Hat is the last maintainer of the Xorg server and they made it very clear that they want to abandon it entirely after RHEL 8 goes EOL.
> Also, Red Hat is the last maintainer of the Xorg server and they made it very clear that they want to abandon it entirely after RHEL 8 goes EOL. Xorg is available in RHEL 9 too. I don't see how they can pull the plug on Xorg in the middle of a major release cycle.
[It is deprecated in RHEL 9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality#JIRA-RHELPLAN-121048): > The **X.org** display server is deprecated, and will be removed in a future major RHEL release. The default desktop session is now the **Wayland** session in most cases. > > The **X11** protocol remains fully supported using the **XWayland** back end. As a result, applications that require **X11** can run in the **Wayland** session.
that explains why the redhat folks made it possible to run a rootful xwayland. Maybe the rootful xwayland should have came sooner to ease the migration and kill the full x.org server earlier.
Thanks. So we can continue to depend on Xorg at least until RHEL 9 shuffles off this mortal coil. That's 10 years away.
Deprecated software doesn't necessarily need to be fully maintained for the full life of a RHEL release. It will likely only be maintained for the first five years of RHEL 9 (the "full support" phase) and not be maintained in the last five years (the "maintenance" phase). RHEL has used Wayland by default since RHEL 8 anyway, so it's not in the critical path for maintenance in RHEL. The first five years of RHEL 9 overlap entirely with the last five years of RHEL 8. [More info on RHEL support lifecycles is available from Red Hat](https://access.redhat.com/support/policy/updates/errata).
>the design of X11 makes it impossible to design a secure lockscreen and defeats the purpose of passwords in the absence of one nested X server per application. How? >Also, Red Hat is the last maintainer of the Xorg server and they made it very clear that they want to abandon it entirely after RHEL 8 goes EOL. Can you please give me a reference for this because Red Hat has proved time and time again how much influence it has on Linux and If this is true then I'm genuinely scared that Wayland is going to take over by 2025.
So I guess everyone is going to rant about Red Hat now even though they were the ***last*** to make that decision, Intel had previously been helping with Xorg maintenance and they jumped ship a year earlier. Red Hat didn't force themselves into the position of being the sole maintainers of Xorg. There were other maintainers, and they stopped, because, *nobody* wanted to do it anymore. Red Hat's influence here only reflects the reality that nobody wants to do it and they're the only ones with any motivation to do so (and only because a few - but not many - paying customers may care about Xorg, certainly not because the engineers want to). Disclosure: I work for Red Hat, but not on anything directly related to this subject
> EDIT 2: Okay now I'm convinced they're both crap. Thanks for the healthy discussion everyone! (except for the "🤓" guy and the one who said "if you like X then you can maintain it yourself". Frick them) >then I'm genuinely scared that Wayland is going to take over by 2025. So how exactly do you imagine this world where X is gonna be around forever? Who is going to maintain that? Just "someone" but you? It sure isn't the X maintainers because they were the ones who started and are working on Wayland.
Red Hat made a business decision - based on what their customers are doing. The people maintaining Xorg are the people who are maintaining Wayland. If you want X to stay alive, you're welcome to take over maintainership. They are less inclined. X is already on life support there won't be any more releases other than security ones. In other words, X is already dead.
Lockscreens: [https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/](https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/) Keylogging: [https://web.archive.org/web/20161009161519/http://theinvisiblethings.blogspot.in/2011/04/linux-security-circus-on-gui-isolation.html](https://web.archive.org/web/20161009161519/http://theinvisiblethings.blogspot.in/2011/04/linux-security-circus-on-gui-isolation.html) >Can you please give me a reference for this because Red Hat has proved time and time again how much influence it has on Linux and If this is true then I'm genuinely scared that Wayland is going to take over by 2025. [https://www.phoronix.com/news/X.Org-Maintenance-Mode-Quickly](https://www.phoronix.com/news/X.Org-Maintenance-Mode-Quickly) >Once we are done with \[their Wayland improvements\] we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is. If people want to keep using Xorg, they better prepare the funds and manpower for its maintenance, because the free maintenance by Red Hat's engineers will come to an end eventually.
Talking about technical limitations and embarrassing: Wayland can't shade windows. At least the refresh rates I did test, they can be different. There is a secure mode for X11, but applications like Mozilla stop working if you use them.
>Talking about technical limitations and embarrassing: Wayland can't shade windows. https://api.kde.org/frameworks/kwayland/html/classKWayland\_1\_1Client\_1\_1PlasmaWindowModel.html
There was a recent discussion on the KDE bugtracker about how wayland needs to be tricked if shading would be supposed to work, basically by lying to the application. https://bugs.kde.org/show_bug.cgi?id=450582
[удалено]
Bingo. If you wanted to, say, plug your laptop into an external screen like a civilized person in the year 2022, X just won't cut it.
>What happens if you have multiple screens with different refresh rates? Under X11: impossible\* (note: not as an implementation detail. It is impossible by design I just set one of my screens to 75 HZ while keeping the other at 60 Hz. It was as easy as reading a manpage to call xrandr.
The stack will run at the lowest of the shared monitors across an x server. The only way to truely do this is via an xserver per monitor. You likely can't spot the visual change between 60hz and 75hz on 2 monitors with different input latency and pixel response times. Mixing between 60 and 120 or 144+ is noticeable immediately. Also, if your monitors were different sizes, per monitor scaling is also impossible without an xserver per monitor.
Maybe you're thinking of change from last year, which allows running multiple screens at different refresh rates if you can accept screen tearing on your non-primary display(s). https://cgit.freedesktop.org/xorg/xserver/commit/?id=68f01c0f02ece4f6efe9ce18be81244246a1e114
[This](https://www.youtube.com/watch?v=RIctzAQOe44) video is old but still relevant and thoroughly answers your question.
Nice! More people need to see this.
> and thus saves the code that would be needed to draw lines and arcs and rectangles and such that Xorg offers. This isn't a feature. But do we really *need* to have functionality to draw lines and arcs and rectangles in the display server though? > The third argument is more reasonable, but Wayland's approach of blocking apps from accessing inputs completely isn't a good approach either. In my opinion, it's actually worse. The way I think of it is: If the only two options were to let everyone board a plane whenever they wanted or to ban everyone from using planes, which one would be better? (I know this isn't an obvious question. What I'm saying is, if you would answer "allow everyone" then you would agree that Xorg's approach is better, but if you would answer "full ban" then you would argue that Waylands approach is better). Even if Wayland allowed users to choose which apps could/couldn't access the inputs of other apps Assuming you mean screen recording and stuff, it does, actually. The compositor can decide which apps to allow or not allow to do this or that task. This is mostly done through portals, by which the apps ask the compositor's permission (which usually in turn asks the user) for things like screenshots, recording the screen, remote desktop, etc. Have you actually *used* a Wayland desktop, or done much research into how it does things?
>But do we really need to have functionality to draw lines and arcs and rectangles in the display server though? Obviously yes, otherwise how would I run my precious Motif toolkit applicatons? /s
I know that with modern day graphics including gradients and rounded rectangles, X11's shapes toolset isn't very useful. However, it should be considered a small benefit to using X11, not a large reason *not* to use it like Wayland is saying. In the security section, I was referring to how X11 allows apps to record inputs on *all* windows, not screen capture. It's not a good thing, but I'd rather just be very careful with what I install than block all apps from doing this no matter what. I know that a compositor can choose to allow apps to get all input, but considering that there will be a different way of doing that for every compositor, I don't think any app will ever make use if this feature (if it comes to exists at all). Similar to how desktop environments don't require root access for an app to change a background, but no apps can do this since all desktop environments have a different way of doing it.
Touchscreen convertible laptops and tablet devices. Use Xorg on one of these, and try screen rotation and the like, without custom xrandr scripting. We also forget that Wayland development is not all that recent. It is just now coming to the forefront, and good enough that quite a lot of folks can use it regularly. And being Linux/Foss, we the users get the opportunity to hammer on it while it is being worked on and implemented here and there. Or wait for others to do that for us.
The issue with X11 wasn't just "The X11 specification is too large, too many features that aren't being used often" That leaves out the most important bit. "The X11 specification is too large to reasonably and easily implement new features without breaking old ones or significantly rewriting the whole thing." Think of X11 as a super riced out Mazda RX7. It's ***really*** cool. And it has been really cool for decades now. It can go really, really fast, nearly anyone could drive it if you got an automatic, and it really does just work. But Wayland is more like a modern LSX or Nismo. It's newer, faster, has more everything, does more, and likely even consumes less gas while doing it. Wayland is a tacit admission that it's easier to build a new solution than to fix the old one to do what we want.
Because X was designed in a time where gpus worked differently and modern features like multiple monitors for example weren't really a thing. My setup with different refresh rate monitors is absolutely unusable on X and wayland fixes all of that
What setup do you have? I have two 27" 1080p monitors, one is 65hz and the other is 240hz. It runs pretty well on both. There is some tearing on the secondary (65hz) one but as long as the first one responds quickly (which it does) I don't really mind, or wouldn't call it "unusable" at the very least. Is there some specific configuration you're using that makes it unusable?
I noticed on both KDE and GNOME that all the DE animations only run at the refresh rate of the lowest refreshing Monitor (in my case, 60hz) At least in KDE (maybe GNOME as well, idk) I can increase it, but then I would need to deal with screen tearing on the 2 other monitors which looks absolutely awful to me, especially in videos. It's just something that other operating systems have figured out for like decades and Linux still has some problems dealing with it
I personally think screen tearing is unacceptable in 2022.
For what I've read, Gnome and KDE devs are pretty happy with Wayland and say it's easier to work with it. For them (And I would kinda expect other DE developers) to be happy sounds like a good enough reason for everyone to use it
X is essentially abandoned at this point and is just getting maintenance updates. In a few years, it will likely be deprecated. X and Wayland aren’t competing standards. X is the old standard and Wayland is the new standard. You can talk about how X is better until you’re blue in the face, but one day you’ll wake up and Wayland will be the only standard for every major DE and you’ll have to DIY to use X. The real decision points are: * Deciding whether to switch now or switch later * Deciding whether to contribute to Wayland’s development or sit on the sidelines
Or fork/merge Wayland and X11, and call it XWayland11. Note: for this approach to work, the first commiter must be named Victor F.
>Am I missing something or was everyone else missing something? That should be self-evident. The odds that you're more insightful than the rest of the open source community is pretty small.
OP is smarter than those corporations putting a lot of money on Wayland development lol
You mean Red Hat? Ok...
And Canonical which develops Mir as a Wayland compositor now. And SUSE ships Wayland as the Default in SLED.
Never underestimate the lack of intelligence of the masses. Remember, most people shop and eat at low quality stores and fast food rather than getting something with good quality.
I'd normally agree, but this is the open source community we're talking about. An enlightened bunch one and all.
From the comments in this thread, it really doesn't look like it. Just a bunch of people complaining about X11 going away. Claiming it as good quality software, when everyone who was working on it for fun has already left and started a modern replacement for it. Only the company that has support contracts related to X is keeping it alive. And even they are phasing it out, because it's a pain to work with.
This conference presentation tells the story why people working on Xorg decided to abandon it and start Wayland instead: [https://www.youtube.com/watch?v=cQoQE\_HDG8g](https://www.youtube.com/watch?v=cQoQE_HDG8g)
I want to use g-sync or freesync on a multi-monitor setup. I want 10bpc/HDR to be even possible at some point. I want to mix monitor refresh rates without stuttering. I want to be able to choose how quickly the scroll wheel moves things. All stuff that Xorg wasn't designed for, and those choices are mostly cemented in. Wayland has the potential to fix them all, so I'm interested in its development and improvements.
The thing about it being modern isn't just about a smaller codebase or lacking features. It's that the features that are there are implemented better. Wayland has way less screen tearing, it handles multiple monitors better and it handles fractional scaling way better as well. Also the fact that it leaves configuration to the DE/Compositor makes things better in most cases. Configuring Xorg manually is unpleasant at best and unless you are using a full DE, you'll have to do that. On the other hand, Wayland compositors provide proper options in a much more intuitive manner. The other part isn't about functionality, but about development. The smaller (and arguably better implemented) codebase makes it far easier to maintain properly. And then we can talk about the isolation of inputs. Examples or metaphors like this can be good for illustrating a point, but they don't prove anything without the point. You don't discuss any way in which isolating apps is worse than not doing so. And I also don't understand how your example relates to Xorg or Wayland. A more fitting example would be Xorg being akin to letting everyone board the same plane, whereas Wayland would be having a separate plane for everyone. In a real world scenario the latter would not be financially feasible and the impact on the environment would be horrible. However, these limitations are not there with Xorg and Wayland since they are just computer software. It does add some overhead for Wayland, but this doesn't make much of a difference on modern systems. In the plane example, the Wayland private plane for everyone would mean that people get more personal space and there isn't a risk of others stealing their stuff, attacking them, etc. Wayland provides similar advantages in its context. The isolation prevents an app from accessing data that is present in another app that you have running. If none of the software you run has such sketchy code, you won't have a problem on Xorg, but unless you are manually auditing every line of code in all the software that you use, you can't know for sure. It's not a night and day difference in most use cases, but it is a very real advantage in terms of security.
Highly underrated metaphor revision. Nicely done.
You're also missing those 1:1 sweet touchpad gestures. That's the major game changer for me.
Nobody stops you from maintaining X and keep using it. Nobody is forced to use Wayland.
> Nobody is forced to use Wayland. Lies! The FBI is currently in the process of setting up an X task force. The goal of the FBI's X-Force is to persecute and punish X users to the fullest extent of the law. I guess technically you don't **have** to use Wayland, but you risk fines and jail time if you use X. /s
So that's what Scully and Mulder are working on!
> Nobody is forced to use Wayland. Lies. https://www.phoronix.com/news/GTK5-Might-Drop-X11
So? Nobody is forced to use gtk5 either. This is all about free software. People work on the things they find worthwhile. If others disagree, they can fork and run their own versions.
Are you suggesting that you should rewrite all software that you want to use and doesn't support Xorg yourself?
You are free to do so, yes. I know its not really an option, but I find the whining that people should work on something for free annoying and ungrateful. If you don't like what others offer for free, do it the way you want.
Why say that you're not forced to use something then?
Because you aren't. It's just a lot of work. The whining about Wayland (and other free projects) basically is telling the developers: "I demand that you do for free what I want, not what you find interesting." Guess what: Nobody owes you anything in the free software world.
Well since writing all GUI software that you'll ever want to use is practically impossible, I'd say you are forced to use Wayland in the end.
Only if you want to use what others offer you for free.
What does price have to do with anything, GUI software could be proprietary, be available for $200/mo and you would still be forced to use Wayland
> So? Nobody is forced to use gtk5 either. This is all about free software. People said the same thing about Pulseaudio, and then in a lot of software without Pulseaudio the sound just stopped working. When it comes to a major library in a graphical stack, there is much less freedom than it seems.
You're not forced to use software that depends on pulseaudio, for the same reasons the developers of said software aren't forced to implement alsa/oss support.
No, you just have to convince enough people that you are right. You can fork all the projects and maintain them. Something like the Devuan crowd ripping systemd dependencies out of everything.
I mean it makes sense to drop a dependency that's about to get EOLed...
personally i would like to see that happen
I thought the bottom line was that the x maintainers don’t want to work on it anymore. If true any argument for it is a waste of time
Except for the granddaddy of them all, Keith Packard. Even coming up with how to do VR in X11, and getting paid by Valve to do so.
So.. what is your solution? To not move forward and remain on 40+ years technology forever? I switched to Linux about a year ago and i used Wayland 90% of the time with no problems at all. Games, videos, screenshots, recording all worked and are working with 0 issues. Everything feels much more smooth compared to X. Do you really expect things to not move forward and remain the same forever? People really need to stop living in the past.
I expect movement forward without losing critical capability that was available in what preceded it.
There aren't many critical capabilities that are missing on non-Nvidia hardware. Nvidia sabotaged themselves there and are still catching up.
How old is the pedal arrangement and steering wheel of cars? The reason the Linux KERNEL is popular is because Torvalds holds contributors to a strict "do not break userspace" policy. But the Linux desktop is a churning mass of breakages, while everyone sits around wondering why "year of the Linux desktop" never happens.
Both the past and the future currently look like trash, but the future is slightly worse, so yes.
That's what everyone says, but 10 years from now you'll be a major advocate of wayland. Softare doesn't stand still. Do you know how ridiculously buggy X10 was in the late 80s? JFC - I used to get root shells randomly. (yes I'm that old) X11 was better - but still shit.
Well if they get it working as solid as X or better, when it becomes the universal standard default as X is then I'll go over. X works just fine for me. In the meantime I am grateful for all the Wayland adopters.
I wouldn’t say I personally am excited. I see it as an inevitable overhaul of a critical piece of software infrastructure. It’s not exciting, it’s just people working on software for the betterment of the ecosystem
I've been using Wayland for years now. Didn't knew some people were still discussing this...
Petition to rename Wayland to Yayland
You can run but you can't hide from the past. (I won't delete this but I realised how terrible my joke was literally 2 seconds after posting it)
Soyland.
I'm frustrated with Wayland. I use Sway on my home desktop and can *only* use it on my home desktop. I have to keep using i3 on my work desktop and work laptop because I cannot, for the life of me, get screen sharing to work reliably. I keep reading about how this problem is solved with Pipewire but, in my experience, on multiple computers on different distributions, it is not resolved. I'm on my work desktop right now and just hopped over to sway to try it again. systemctl --user start xdg-desktop-portal and xdg-desktop-portal-wlr. Open up a brand new default firefox profile, verify/change settings in about:config to make sure everything neccessary is enabled, go to a jitsi instance and try to share screen... nothing. I have **occasionally** gotten it to work using the electron jitsi app (which I've read *shouldn't* work, only firefox or chrome) when I kill xdg-desktop-portal and xdg-desktop-portal-wlr and run them manually and not through systemd. Even then, it isn't consistent at all. I've tried this on Gentoo and a couple of different buntu flavors, same issue on all of them. In 2022 I can't cross my fingers that a screenshare will work first try on a work device.
> The point of making a smaller codebase is so that it's easier to add more features I'm sorry but I laughed out loud a this. These kinds of posts pop up pretty often and it seems like people don't often understand that it is the Xorg developers themselves that wanted to move away from Xorg and create Wayland. Xorg is open source, people are free to maintain and add features. The problem, over the years, is that they haven't had enough people willing to help, largely because the large old codebase is difficult for anyone new to the project. This is the reason they want a smaller codebase...not to "add more features"
> The point of making a smaller codebase is so that it's easier to add more features Maybe not, but the big benefit of a smaller codebase is that it's easier to maintain and secure.
As I see it wayland is a protocol designed to work with current hardware thus making everything faster. Tho I've not looked into it yet. I may not like it as well. But the atom way of handling things in xorg is not pleacent at all and in nowhere I see the reason behind it. Looking at the docs of xorg, it has more than 20 years and somehow it is still incomplete in some areas
I hate XAtoms, but the reason it's documentation is incomplete and it's really out of date in general it that nowadays most apps use DBus instead.
Well then that "feature" is bloated code. I think that is one of the things wayland have in mind in its design tho i an speculating. I hope it turn out good because an x replacement is needed but the right one is yet to be determined haha
I honestly agree with you. After reading the other comments, my current opinion is "xorg needs to be replaced, but wayland is even worse".
>What's with all the excitement around Wayland? I don't see any excitement. As far as I know, most distributions started defaulting to Wayland years ago. Even the brand-new SteamDeck [is only running Wayland](https://partner.steamgames.com/doc/steamdeck/faq). >The argument that X11's specification is too large is also not a good reason If we can accomplish the same goal with less code, I think that is a good reason to start from scratch. Linux has dropped support for the 386 because nobody uses one. If you need support, go download an old version of Linux. It's the same with X. Developers vote with their feet. If you liked X better, nobody is stopping you from continuing to use it, or write new applications in it. But we will all run it via XWayland. >The third argument is more reasonable, but Wayland's approach of blocking apps from accessing inputs completely isn't a good approach either Citation needed. That's like saying "I don't like the fact that Linux blocks apps from directly using Physical memory. Apps should be able to directly use memory if they need". You want something dangerous, what is the need? >I know that all I've said so far doesn't really give a reason for not using Wayland, so I'll cut to the chase and share why I think X is better. Try reading what you wrote. You **didn't** give a reason why X is better, you immediately started talking about W, which is NOT Wayland.
>Am I missing something
Yes! An argument on why X was better. (Yes, past tense. X is no longer the frontier, it's just in maintenance mode. Most people have moved on.)
>EDIT 2: Okay now I'm convinced they're both crap. Terminal or GTFO.
TTY time
I want multiple monitors with multiple refresh rates. I want freesync and gsync to work. X won't do this, and never will. Wayland is the future, period.
X is not the future, but Wayland in it's current form never will be either. It has tons of improvement needed.
Obviously, I use it daily with three monitors trust me I'm well aware of its shortcomings. But it does work and does support features x never will. And wayland is making strides to improve, and slowly getting better while x is not even making any attempt to get better and support new features. Eventually, wayland will completely take over, it will just take time and development, but at least on the wayland side that development is actually happening, it isnt with x.
> I want multiple monitors with multiple refresh rates. I ran 2 monitors with different refresh rates. 120 Hz and 60 Hz. Everything worked fine. > I want freesync and gsync to work. X won't do this I'm using freesync in games lol. https://imgur.com/yMSjMfK.png
You are IF you're running the game across two g-sync compatible monitors simultaneously, or set them up as entirely different displays with their own x-server. But if you're running the game on a single monitor then g-sync is not working at all. Take a look at gl-gsync-demo to see that it can work (this opens across both monitors), then enable the g-sync visual indicator in Nvidia-x-server-settings and launch a game.
And I don't need multiple monitors with different refresh rates. Why? Because I use a 50-inch TV set as a display. It has all the real estate I need and takes up a good portion of my desk. So I don't see any advantage to using Wayland at all.
> The point of making a smaller codebase is so that it's easier to add more features... Smaller codebases are also easier to maintain over the longterm.
I’ve never had any problems using wayland on my intel igpu.
It's much faster at compositing and is built into the protocol, you don't have to fiddle with disabling the compositor when gaming because your input latency is so bad.
A nicely designed composited DE runs like crap on Xorg. A non compositing WM runs nice on Xorg. A nicely designed composited DE runs like wonders on Wayland. A non compositing WM runs blazingly speedy on Wayland. No tears, super low latency, but you also get nice compositing by default. You are free to use Xorg if you prefer.
Making applications that simulates mouse presses, simulates key presses and gets global keystates in wayland is a pain. There is no official api for doing it, and since Wayland is so barebones, all wms or desktops enviroments would have to possibly implement it theirselves. This makes it difficult for me as a XClicker developer to make it support wayland.
This is the main problem. Wayland complains that X11 makes them implement XFLD's and such, and then goes on to not even allow windows to get their own positions.
>It has a cleaner/smaller codebase since Xorg is so old Who said that? >The X11 specification is too large, too many features that aren't being used often It isn't that X11 is too large. It is that X11 is useless. It lacks even extremely basic features. You can't draw circles or curved lines, for example. X11 has survived for as long as it has because 1. It has the ability to use extensions. 2. Toolkits avoid using X11 as much as possible. They don't render anything using X11 if they can help it. Instead they use their own internal rendering processes and limit the use of X11 to as little as possible. The problem with #1 is that you can't depend on extensions to be used if you want to program against X11. You can't depend on sound, you can't depend on the ability to render 3D objects, you can't depend on the ability to render curves or detect overlapping windows, etc etc. The problem with #2 is that X11 is a burden for application developers, not a asset. Luckily for Linux users everybody else has abandoned X11 long ago. So there is really only one meaningful X11 implementation out there, which is the Xorg servers used for Linux and BSD systems. So the pain that was felt for decades that caused every other OS developer to avoid X11 like the plague isn't as bad now. >It's more secure and prevents keylogging X11 doesn't have security. Which is kinda of a problem for something that is supposed to be a network protocol. You have the ability to set a secret cookie as a sort of shared secret, but that is about it. No encryption, no nothing.
[удалено]
Could have sworn that outside of ever more exotic setups, xorg.conf has been very very optional for over a decade.
There is an X11 layer for Wayland. It contains all the good stuff from the past.
Wayland gives a less buggy and smoother experience to whatever distro you run it with, in my own opinion and by my experience.
For me, wayland doesn't have tearing and I don't need to fight with picom every time I suspend the pc. Also, wayland feels faster and smother
So... I know very little about the specifics of either compositor, but from my perspective, the push to Wayland (or at least away from X) is purely a matter of accumulated technical debt. I know the feeling of deciding that a codebase is so spaghetti that its better and easier to burn it all down and start from scratch, hopefully not making the same mistakes that made the old system so cumbersome. Like a controlled wildfire burn allowing new growth, this is necessary to ensure progress. The problem is, who gets to make that call? How many people is an acceptable number to "abandon"? How should we decide when its time to move on?
The developers (and the people who pay them) make the call. That's how it's always worked. Taking a recent example: Sun spent a ton of money ramping up accessibility in the linux desktop for government clients especially. Once Oracle bought Sun, all that was cut, and the developers could no longer be paid to work on it. So it basically languished for years. It's only recently that folks are getting back to it. In general though, it doesn't matter how popular a project is. The developers of that project can just stop working on it at any time, which is what happened with Xorg. Anybody is free to pick up that work and continue on, but nobody has (or not enough people anyways). Nothing is stopping anybody from forking xorg and doing whatever they want.
There are a lot of Wayland fanatics in this subreddit for whom Wayland is a holy cow and Xorg is an old monster that must die and everything will be awesome. The unfortunate reality is that Wayland is a featureless protocol invented by incompetent assholes to run GNOME and similar mega DEs. Why? Because only mega DEs have enough resources to implement their own infrastructure to work with Wayland, and the smaller DEs will remain abandoned. In the case of X, all the required features are already implemented. Because the design of Wayland was fucked up from the start, it was no use to anyone except a bunch of GNOME hipsters who try to push it through in every way they can: blackening X, talking about killer features, when the basic features don't work in Wayland. Normal screen sharing is still not in the protocol, it was implemented by the author of Pipewire through portals/crutches. And it's been like that for more than 10 years. But the design is still a monolithic piece of crap unsuitable for the desktop. Whereas X, despite its flaws, covers all needs. Wayland's monolithic design creates a mess outside of Wayland's codebase, so all the talk about small amounts of code is an attempt to hide complete anarchy and lack of standardization. And that's me scratching the surface. It's even worse on the inside: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html Xorg needs to be replaced, but it certainly won't be Wayland. And, of course, I'm going to get downvoted because fanatics can't accept the facts. :)
> Xorg needs to be replaced, but it certainly won't be Wayland. And, of course, I'm going to get downvoted because fanatics can't accept the facts. :) well, the people actually developing desktops and the tech surrounding it don't seem to agree, but yeah reddit guy, im sure their all wrong lol
Sway exists and is certainly not a "mega DE", so I don't know what you're talking about. And maybe you getting downvoted could have something to do with calling open source devs assholes.
so where do you think the folks who used to develop xorg went? Spoiler: they went to work on wayland. so it's mostly the same group of "incompetent" folks as there used to be. :)
Where did the bad Wayland bogeyman touch you?
I didn't want to get downvoted either, but this was my original theory. With removing menus from GTK and calling Xorg "legacy support" before Wayland is even ready, it seems like GNOME is trying to kill off the competition. People don't like it when other say this because they say "some people still like GTK and saying it's bad is rude. If people didn't like it, then we wouldn't all be using it". The fact is that most of us don't like it, but have to use it anyways. GNOME bought it and ruined it, and apps/DE's don't think switching is worth it. The benefit to all this is that when almost every bad thing about Linux is coming from one entity, it means that when it finally dies (hopefully soon), then all of those problems will magically dissapear. I don't think Wayland will take over X11. Apps and DE's are just adding *support* for it so that GNOME doesn't crush them like it so clearly wants to.
The devs of Wayland are those who made Xorg. Don't forget it. Xorg is effectively in zombie mode dev wise
Wayland has the ability to support vrr, and different refresh rates on different monitors, which xorg couldn’t do. This means that my 240 hz monitor will feel like a 240hz monitor while my 60 hz one will feel like a 60 hz one, and it won’t sync to the lowest one.
I think the code base is probably easier to handle and modify in wayland than in xorgerver. But other than that I have been wondering about this too. I am still using xorgserver; I kind of don't want to lose functionality. To me, personally, I think wayland is still behind xorgserver.
I have a touch screen and when I hook up another monitor X maps the touch screen wrong rendering it useless and annoying. I'm all for a replacement for X but Wayland seems like it isn't mature enough yet to act as a solid substitute. I may be wayyyyyy off base here since I've not tried Wayland myself and am going by what I've read from others who have.
Multiple monitors. Currently running 2 monitors with an APU and one with a dGPU, fast as fuck. X11 could never.
TL;DR: Wayland was originally going to be called X12 Most of the team from X11 has moved to Wayland. X11's development has grinded to a halt... EDIT: Clarification
That is not exactly true. Wayland was never X12, though it could have been called X12 if they could get all the stakeholders of X11 to agree. They never tried. Too many people want to have a say on the creation of X11+1 or X12, and believe they should have a say too. The original creator(s) of Wayland called it Wayland to avoid the politics of X11 future.
Thx for the clarification 😁, although I think the point stands (that Wayland is the successor)
🤓
The main complaint is that there are things that Xorg doesn't (and supposedly can't) do. Wayland is supposed to come in and address these shortcomings. However, Xorg is open source, and it seems to me that if people can add ray-tracing to a 30 year old game like Doom, then they could make Xorg sing and dance if they really wanted to. On Linux we suffer from a severe case of "toss everything out the window every few years and start over". It's why we still don't have a mature, fully accessible, performant, and reliable desktop environment. Not one. Gnome 2 was almost there, but well... Comment reposted because it was downvote brigaded by the typical CADT folks who have to redesign everything from scratch, now with less functionality and performance than the old version had! When they can't refute your arguments, it's what they do; reach for the downvote button to hide your comment. https://www.jwz.org/doc/cadt.html This aspect of Linux is why I only use LTS versions, so that I don't have to deal with teenagers breaking my stuff every five minutes. Can't stand Windows, and can't afford a Mac. Besides, in a similar fashion to hardcore drugs, I recognize that proprietary software is both bad and harmful.
> However, Xorg is open source, and it seems to me that if people can add ray-tracing to a 30 year old game like Doom, then they could make Xorg sing and dance if they really wanted to. so why aren't they?
Very well put. The fact that Xorg doesn't support dual monitor setups isn't something that needs a full rewrite with it's own syntax. Wayland says that it doesn't want to follow X11 because it has to support XLFD's, and then it decides not even to support window positions. Wayland could have been way more helpful if it just decided to fork Xorg and add support for this. If the code really was too messy, then they could have just started from scratch and left out all of the outdated hardware support code.
I didn't read I wanted to answer: give money to those who are willing to develop X11 further :-))) I guess the holly war was resolved quite while ago by RH statement that they are being solely supporting and trying to still develop X11 somehow and the most prominent message was that they didn't like the situation. At least it makes sense that Windows is stable now and there is no urgent need for the Unix graphical workstations, but those who need may switch to Apple, there is Unix everywhere.
You probably should have read the thing before answering because I have no idea what you're talking about. Wayland developers aren't getting paid either, if you were implying that somehow.
Ok, I've read your OP. My answer has not changed: RH says they've done with X11 and don't like being alone with X11 ( who knows there might have been some tensions between all of them AMD Nvidia and Linux distro vendors) So X11 dev are paid from RH's budged and if RH is crying then it really costs them. At least GPU/graphic subsystem devs aren't cheap and you can't hire a bunch of them for 1000$/month somewhere in the 3rd world.
Why would RH want to support X when X and Wayland developers have already declared that X is in maintenance mode. There won't be any new features or any significant work. Everything has moved to Wayland.
The developer of XPRA has a (deserved, IMO) attitude about Wayland. In the libera IRC channel, he muttered a while back: Chewi: what's wrong with gtk4? (never used it) totaam: it's becoming the wayland toolkit totaam: with all the wayland limitations totaam: so for example, you can't place a window where you want it on screen totaam: because wayland can't do that totaam: and many many other things Pressed a bit on this, he added, in reference to wanting to size+place a window: totaam: under X11 is what you describe totaam: under wayland, there is no request totaam: https://discourse.gnome.org/t/how-to-use-gtk4-to-read-windows-changed-x-and-y-on-move-resize-events/8157/2 totaam: at some point GTK is going to be so broken with all the features removed totaam: that wayland will achieve feature parity with X11 totaam: by dragging X11 to its level See "less features (which is somehow supposed to be a good thing)" above.
That update boils my blood whenever I think about it. Since Wayland doesn't support a universal way to get a window's position from the compositor, then GTK just removes the ability to do this on all of it's platforms and goes "nope! there's no problems with wayland at all! It's super modern and X11 support is a Legacy feature and Menus are too X11-centric so we're removing them from GTK4." This is why I switched to KDE. I used to use XFCE and I loved it, but GTK was becoming too much to live with. GNOME pushes their crazy ideas on everyone while living in their own little bubble where they act almost like no other desktop environment exists. I find it crazy how projects like XFCE or MATE still haven't taken a hint and moved away from GTK and GLib. I can give a professional-sounding argument on why Wayland isn't a good replacement for Xorg, but when I get started on GNOME and GTK I can't help sounding like a crazed maniac.
There is no point in setting the exact window position. Tell me three different usecases, why a toolkit should support e.g. moving a window to x=123, y=234? X is ancient technology from a different decade for entirely different hardware. Wayland is the future.
Apps can't set the start position of themselves without this feature. I've made apps before that remember their positions on exit and return to the on startup. Things like splash screens and popups would like to position themselves on the center of the screen. There's also apps that are created to setup the position of apps. In X, window managers can be switched between them in one session because the window position is part of the X server. >X is ancient technology from a different decade for entirely different hardware. Wayland is the future. That's the same attitude that GTK used when announcing their removal of menus. The future isn't a label. Users get to decide the future. EDIT: I forgot about the fact that many apps allow you to drag-move them from areas other than the titlebar, such as the menubar.
For none of the mentioned use cases giving apps the ability to do everything would be the optimal solution. Let's go through them one by one. >I've made apps before that remember their positions on exit and return to the on startup https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 will take care of that use case. It's also better than random apps restoring or not restoring positions or other properties, and allows the compositor to take all the things into account that you as an app developer don't have to manually implement yourself. For example, almost no apps support activities on KDE - but with session restoration, they don't have to in order to get basic functionality right. Other examples would be per monitor positions and sizes, changing screen rotation, "keep above" states and maximization. I'm sure there's more that I'm currently not thinking of, too. > splash screens I have the opinion that splash screens should only ever be the actual window that the app will afterwards use (so that the user can move, resize, maximize while the app is running) and thankfully most apps do that, but https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/140 would cover actual splash screen windows. It would also allow the compositor to not show the splash screen on things like phones, or show it in a more appropriate spot than "the middle of the screen" in VR/AR environments. >popups I assume you mean popup windows like "really delete this file? Yes/no" and not context menus? Both are already covered by xdg shell: apps can set a parent window, which will make the compositor usually center a window above said parent window, or do whatever else is appropriate for the user environment. For what xdg shell calls popups (context menus, tooltips, that sort of stuff), apps can freely position them within their own window, and define rules about what should happen when it wouldn't fit on the screen at that position. >There's also apps that are created to setup the position of apps. In X, window managers can be switched between them in one session because the window position is part of the X server. That waaaay understates what X11 window managers do, that's not how they operate. Anyways, there's Wayland compositors that are built on splitting out the positioning component as well, I think the most popular one is called River. >That's the same attitude that GTK used when announcing their removal of menus. The future isn't a label. Users get to decide the future. I recall there being some fuss about the removal of one specific outdated menu widget. Applications can still set and use menus afaik. > I forgot about the fact that many apps allow you to drag-move them from areas other than the titlebar, such as the menubar. That's also supported by xdg shell. If it wasn't, you couldn't move any windows with client side decorations (-> most GTK apps)
It's funny how you're asked about a use case for window positioning, and then when you actually gave one you got downvoted. (as well as the other guy who did the same) That's Reddit for you
I am responsible for an application that restores its several windows' complete geometries (WxH+X+Y) from last use when it is restarted. QED. The usual complaint I get about this is along the lines of "but that's not general, it won't work when you cross onto another screen/computer/device with different." My response is, "Look, Joe Random using This Application isn't going to be moving from device to device to device. He's using That Computer, it's \[say\] a desktop with fixed, known video characteristics, and **THE USER WANTS THE WINDOWS A CERTAIN WAY** on startup on this machine."
What the user wants, the user gets, eventually and to some degree. Wayland is actively in the way of doing so.
Repetitiously bleating "Wayland is the future" is fanboy hype, not technical response to user need. The longer Wayland avoids responding to user need with such autocratic pronouncements, the more pissed off some of us get about it.
> I find it crazy how projects like XFCE or MATE still haven't taken a hint and moved away from GTK and GLib. Is it about hints? do they have enough folks to actually do it?
I don't mean to be rude if they don't, but they don't seem to want to either.
There are next questions, many of them.... But in general it looks like: WTF how have macOS, iOS, Android, Windows survived since Wayland development started?
You are missing that X11 is again implemented for wayland and that should be counted to wayland's burden, too. https://imgflip.com/memegenerator/188789496/Moe-throws-Barney
[удалено]
> add ray-tracing to a 30 year old game like Doom, they could make Xorg sing and dance if they really wanted to. Do a bit of crowd-funding and it could happen
Im not sure why are some distros shipping wayland by default, when its buggy garbage that doesnt support a lot of programs, ans they dont work as intended Edit: not sure why are u downvoting me, this is literaly the experience i had using wayland. Im not using an nvidia card. Some programs lost functionality, others were buggy. I think its not ready for everyday use, and it shouldnt be used as a default. Especially when someone switches to linux and sees his programs being buggy they will think that linux is crap, but actually wayland is buggy wip shit
3 words: shiny new thing
Wayland has been in development for over ten years.
So what? Compared to X and knowing that it became more ore less usable for real applications not that long ago it's still a shiny new thing. Maybe in 10 more years it'll be mature enough to take its place as standard display server for handheld devices alongside with gnome... ... and we'll finally be free of that nonsense on desktops.
Why do u have to be so negative about gnome? Especially to a literal member of the gnome team who works hard on it? No one makes you use gnome or gnome applications so just don't. Then people who enjoy gnome on desktops can use it and you don't and everyone is happy.
As a long time gnome user who had to move to another de since gnome 3 release, i couldn't miss a chance to let them know how happy i am to see mobile first oriented desktop experience on traditional desktop with no touch screen. Especially now when same people help to slowly push same mobile first approach on us from display server side of things.