You may have seen the news that Red Hat Enterprise Linux 10 plans to remove Xorg. But Xwayland will stay around, and given the name overloading and them sharing a git repository there’s some confusion over what is Xorg. So here’s a very simple “picture”.
↫ Peter Hutterer
A more useful visualisation than I expected.
I hear that a lot, but I never hear what those issues are other than “X11 has become too big”.
You cannot have different screens with different refresh rates on Xorg ( I think you can workaround this with nvidia)
You don’t have HDR support on Xorg
You don’t have VRR on Xorg
Any app running on Xorg can listen to *ANYTHING* being typed (that’s a security nightmare)
On Xorg, if you open a “modal” window (like a notification area) it blocks other things (like locking the screen).
On Xorg you always have screen tearing (albeit there are workarounds to reduce this, it’s still there and very noticeable to some people like me)
When running locally, wayland has better hardware acceleration
When running locally, wayland likely consumes less energy
When running locally, wayland is smoother
(not sure about this) Xorg doesn’t support Freesync/Gsync
Regardless of all that… after a few hours using Wayland trying Xorg is…. horrendous. Everything feels slow, clunky, screen tearing… not a nice experience. Is one of those things that you don’t understand how you could withstand that after trying the better option.
But some of those issues are because nobody is working on them, they are not an inherent problem of the protocol.
There is VRR in Xorg. AsyncFlipSecondaries.
jgfenix
“But some of those issues are because nobody is working on them, they are not an inherent problem of the protocol.
There is VRR in Xorg. AsyncFlipSecondaries.”
How to get things very wrong.
That AsyncFlipSecondaries. is a hack. By X11 protocol design yes by protocol design there is no such thing as Multi monitor. All monitors are glued into one huge monitor. Yes AsyncFlipSecondaries. who cares about tearing on secondary monitors we will flip when ever the primary monitor requires it who cares if the secondaries look like a total disaster zone..
The correct thing you want is every monitor handled individually this is just something X11 protocol cannot do. Yes X11 server per monitor then have issue of not allowing applications halfway between screens or transferring between screens is the old school solution.
One of the things about Wayland and why it lacks global absolute position system is that it does not glue monitors into one single virtual monitor the way X11 does so avoiding stack of problems in exchange for a set of different problems to solve..
Well, obviously all of those problems will go away when someone rewrites X in Rust as a systemd process.
jgfenix protocol design problem is not fixed by rewriting in another language.
Existing X11 protocol means your existing X11 applicaiton since it a single monitor output only expect a single vsync covering all output.
https://wayland.app/protocols/presentation-time
Wayland presentation time (Wayland vsync info to application) is different its response is per output surface of the application. Yes this does git a bit messy when a surface is displayed on two output screens.
I was being sarcastic.
That’s the thing… *YES*, they are a problem with the protocol. Perhaps some of the things could be implemented but in such horrible ways that nobody wants to do that.
And even if you were right, there’s a reason nobody is implementing those things: the Xorg code is so hard that nobody *wants* to work on it.
The problem here some of the X11 protocol problems to correct require protocol breaking changes this is where older X11 applications are going to not work when you fix the problem. This is why Wayland started in the first place. Dealing with some of the known issues of X11 protocol leads to some of the issues with the Wayland protocol design. Basically fix X now you have to deal with Y issue you did not have to deal with before.
Yes to fix X11 protocol you would have need xepher to work with everything and for years Nvidia made sure that would not have accelerated support.
Damnshock,
As usual, when it comes to wayland, I have to retest because things might have changed. But when I tested it last wayland was actually less performant.
That’s obviously not a universal experience. It’s been the opposite for me, and not subjectively so but actually timing the frames. Wayland was somewhat slower but not enough to be noticeable. The real problem though has been broken functionality under wayland. And that is extremely noticeable if it happens to affect you.
This is what I get suckered into doing, it’s like a fake it until we make it strategy!
May I ask which Wayland _implementation_ you tried?
Because it makes a lot of a difference if you tried Weston or Sway or Mutter(Gnome) or Kwin or KwinFT or Enlightment…
There’s essentially only one implementation of the X11 protocol: Xorg
There’s multiple implementation of the Wayland protocol
Something that you say is true though: if something that you were used to in Xorg is not yet implemented in Wayland then it doesn’t matter how much “better” wayland is 😉
(would you mind sharing what is that functionality that you are missing?)
Damnshock,
Yes, it’s extremely frustrating that wayland feature support has become fragmented across desktop environments/compositors like this. It is what it is, but IMHO wayland is significantly worse than x was for continuity.
My primary desktop uses KDE and for me it’s remote access.
Another showstopper, although it’s less important than the first is that I haven’t figured out how to create virtual monitors under wayland. Under x you could create a virtual monitor and then project it to a display on a different computer using your tool of choice regardless of the desktop you were running.
https://superuser.com/questions/1375448/using-windows-laptop-as-2nd-screen-for-ubuntu-desktop-possible
https://wiki.archlinux.org/title/Xrandr
This is useful if you’ve got multiple computers that you want to use as extended monitors. In my case a remotely controlled linux SBC connected to a projector.
I think there may be a gnome solution, but in my case I need Xcfe.
https://superuser.com/questions/1434779/using-a-tablet-as-a-second-monitor-with-wayland
Have I said that I absolutely hate that these kinds of features are desktop/compositor specific under wayland!!!
Thanks for that info, I hadn’t really taken note of which version was being implemented by the various distros I’d tried, actually in my ignorance about Wayland I wasn’t expecting so much variation, it’s not something I’m use to under Xorg. It makes me wonder why Wayland isn’t more unified, if it wants to progress that would seem to be the best path!
My desire is to get an OOB experience with one of Debian, openSUSE or eventually Linux Mint which is my MS conversion default, I hopes LM catches up quickly. The ageing hardware path for new Linux users is critical, firstly because that is most often the way Linux gets introduced to new users, secondly because ageing MS Win hardware is more than capable of running most Linux distros beautifully for many years to come, although I concede modern devices are not built to the same standards as just a few years ago I don’t expect that to change.
Alfman this one gets into a tooling problem. You have vkms in the Linux kernel people over look this. vkms allows you to create a virtual headless monitor at kernel level. You can use a direct from kms vnc/rdp server of some form on that. Yes having the virtual monitor not be part of the Wayland compositor..
“””Under x you could create a virtual monitor and then project it to a display on a different computer using your tool of choice regardless of the desktop you were running.”””
From the Linux kernel you can create a virtual monitor. Or you can have what gnome/wlroots compositors allow creating a virtual monitor from the Wayland compositor.
kscreen-doctor is the KDE xrandr replacement thing. I wish there was a nice shared command would use what ever is the right tool for the compositor for screen mode changes.
Also I wish there was better tooling to use vkms. Remember vkms the virtual monitor appears to the X11 server, Wayland compositor and Text based terminal like every other normal monitor.
Basically functional vkms solution you could basically deleted your create headless instructions under X11 as well.
Yes the vkms based solution would be I want to build a headless output to another computer that does not care if I am running X11/Wayland or TTY.
Think about KDE where the wayland compositor could crash and restart do you want your headless to remote computer to have a connection disruption…. vkms with KMS based VNC/RDP starts making lots of sense as vkms and the part sending VNC/RDP over network are independent to the Wayland compositor.
This is one of these things where there is questions if the sway/gnome way is right or wrong or is the do from kernel right or wrong.
Yes there is a tooling problem with your use case as well as what is the correct way.
oiaohm,
I wish that too. With X instructions worked regardless of desktop. With wayland, the features and instructions become more dependent on the user’s choice of desktop.
I really think it’s too bad these features weren’t unified under wayland. Anyway, I’m waiting to find a wayland solution that works for me.
Yea. Regardless of the underpinnings, I really wish xwayland were feature complete. The wayland migration could have gone a lot smoother that way and we’d be less dependent on X.
This is absolutely not true if your WM/DE uses a true compositor. KDE’s compositor seems to be the best of the bunch in my experience, but I can say as someone who is indeed sensitive to refresh rates and supposedly “invisible” tearing (the telltale for me with fake compositing is dragging a small Terminator window with a transparent background and seeing the titlebar struggle to stay lined up with the rest of the window), there is no tearing when using a proper compositor. These days even Xfce’s built in compositor finally gets rid of tearing completely, though Picom is still a bit better as far as added features.
I am sorry but the one at error here is you: https://www.x.org/wiki/Development/Documentation/Performance/#index4h2
In Xorg there’s a difference between the compositor (what you mention) and the entity in charge of rendering which is the X server.
I understand why you feel that way because in most situations you won’t ever see the tearing at all but it *can* happen. I know, I’ve suffered it for many years on external displays with long HDMI cables. And in wayland it cannot happen( unless you *allow* it to happen via a protocol which, for example, kwin implements)
Damnshock,
FWIW I don’t see tearing on X either, but some people might. I don’t know what combination of hardware & drivers do. I would guess that VESA drivers probably do, I’m not sure if any modern accelerated drivers do? Someone let me know.
Your point about long HDMI cable tearing doesn’t make much sense to me. Tearing doesn’t happen in transit, it happens at the source. If the signal quality degrades enough that there is data loss, that’s possible but then your problems would be worse than tearing – you could get data corruption and loose sync entirely. But if there is no data loss along the cable, then what mechanism are you suggesting causes “tearing” in long HDMI cables? How would wayland solve this cable length induced tearing?
Your link is broken so I can’t comment on what it says, but I stand behind what I said: With a proper compositor, tearing simply doesn’t happen on X. I never said that the X server itself eliminates tearing as you seem to be implying that I said.
And I’m with Alfman, how the hell does the length of an HDMI cable affect tearing, and if it does, why would it be any different for Wayland? I believe you are sorely misinformed about how digital video signals work. You could be referring to the fact that a poor connection over HDMI would downgrade the connection to 30hz, which I’ve seen with my 4Kp60 television and a cheap HDMI cable. In that case what you are seeing is simply a lower framerate, not tearing. I am sensitive to low framerates (movies at 24fps seem to stutter to my eyes), but I also can tell the difference between low framerates and tearing at any framerate. I suspect you are conflating the two.
> On Xorg you always have screen tearing (albeit there are workarounds to reduce this, it’s still there and very noticeable to some people like me)
Not seen on any of my NVIDIA, Intel and AMD systems in over a decade.
> When running locally, wayland has better hardware acceleration
Wayland is orthogonal to HW acceleration.
> When running locally, wayland likely consumes less energy
Not in my or anyone’s testing.
> When running locally, wayland is smoother
Smoother while having a much higher [input] latency which makes it unusable for fast paced online gaming until the tearing protocol is implemented.
> (not sure about this) Xorg doesn’t support Freesync/Gsync
FreeSync/GSync is supported by NVIDIA. Can’t say about AMD.
> Regardless of all that… after a few hours using Xorg trying Wayland is…. horrendous.
FTFY unless you’re a Gnome user.
> Everything feels slow, clunky, screen tearing… not a nice experience. Is one of those things that you don’t understand how you could withstand that after trying the better option.
Please do me a favour. Get a high framerate camer and record your experience because I don’t believe a single word you say. I’m now on Fedora 39/AMDgpu/Xorg and everything is silky smooth without any tearing.
Wayland feels like a nice extra option with a ton of limitations and placebo improvements because there’s no HDR in Wayland either and most people don’t have VRR monitors or dual monitor setups.
Ignoring the technical debates because I’m not qualified to discuss stuff and that leads the intent of my post going off the rails, so a selfish perspective. I keep being stung by promises Wayland is now better, by better I mean working OOB on older / legacy hardware, but I end up wasting half a day giving it a run. Maybe it’s my fault because I’m not installing on the latest and greatest hardware, but on the same legacy hardware I can go Xorg and it’s an OOB experience.
In my small corner of the world, the most common way Linux finds itself growing in headcount is rejuvenation of old hardware, that means lots of legacy Nvidia or AMD hardware. I regularly, every 3 months or so give a Wayland OOB experience a run, and so far I haven’t been able to get it to run as is. It’s not that I can’t get Wayland to run, but the problem is the time it would take me system by system to get Wayland adopted just isn’t worth it for the small performance benefits I’ll gain. Unless MS changes it’s Win 11 upgrade requirements, another round of older hardware migration to Linux is coming as Win 10 falls out of support. Hopefully by then Wayland Devs will take support for older hardware seriously, until then Wayland Devs complaining about the lack of uptake are just p@#$ing in their own pockets!
As debian user, mostly running inside virtual machines, i am very happy with xorg and xfce4. It may change over time but at the moment xorg is still my no brainer goto gui backend. Also use xrdp on headless freebsd installations. Maybe one day wayland alternative will be ready but it is not as mature yet for users looking for long term stable solutions.
Happy to hear wayland is progressing and looking forward to the day it becomes drop in replacement for my use cases.
Thank you all for sharing your experiences.
For an early Linux adopter I was quite late to Debian, but working remotely I can now see how you have come to the Debian conclusion because I have to agree that the xrdp experience under Debian seems so seamless and stable, and if anything it seems to be getting stronger in that area.
This isn’t TOO crazy. RHEL 10 is years away and even in RHEL 10 we’ll still have Xwayland for X11 compatibility. We’re still probably anywhere from 2-4 years away from RHEL 10 release and that will be supported for 10 years. So we will have X11 compatibility around in RHEL until probably sometime after 2035.
TLDR: RedHat/IBM workstation customers and software vendors are getting nervous and RedHat is now in damage control. Too little and too late, I am afraid. Everyone I know is now coming up with solutions that were unthinkable 5 years ago, when all commercial Linux software explicitly required RHELx. It is not just X11, NFS is another part of the platform people built their software and datacentres on that got neglected and then deprecated.
One of the big unsung problems of pushing the new at the expense of the old that refuses to go away is the spreading thin of resources. In effect both options suffer, one can’t attract enough people while the other can’t retain them, simply because they usually come from the same pool. It’s not like Wayland and Xorg Devs are distinct groups, they are more like different factions of the same group.
One area that I think is being overlooked is software for people with disabilities. While I understand that its a security risk to allow one application to “listen” to other apps, this is how a lot of software works to provide text to voice and screen readers and such,
I am all for Wayland, but its development process is a giant mess. Instead of coming up with a list of features and moving forward in a ordered way, development is happening all over the place. I think this is going to just turn into a giant waste. And while I am an IT professional who spends most of my time working on the CLI or web browser, gaming is an absolute requirement. If I have to drop fedora to keep a decent X environment then so be it.
TechGeek,
That’s just it. The vast majority of software doesn’t need access to foreign application data and it’s fine to block access to unprivileged applications. However the notion that no legitimate applications need this is false. Screen sharing and accessibility applications explicitly need access and by passing the buck to compositors wayland have done a disservice to users who expect the features to work across desktop environments instead of unifying them.