I stumbled upon this post regarding an earlier rant about wayland, but now it seems fine, according to the author.
After using Linux for nearly 5 years, using both depending on distros defaults, I have to admit that I never got the core/main/game changing differences between wayland and x11.
To be said, that I also dont do fancy linux things other than basic sysadmin stuff and from time to time repair the mess my curiosity left behind.
Could somebody explain the differences between those two and afterwards maybe also say some words about what this has to do with the difference between window managers and desktop environments?
I am also happy about links to good blog posts or stuff, that target this very questions (as long as the questions make sence of course). Thanks beforehand :)
Humorously, X11 is like driving a 1990 Honda Accord. It was built ages ago, but with enough care, it still runs just fine.
The good news? Over time, you’ve bolted on all sorts of modern conveniences: GPS, Bluetooth, maybe even a backup camera—but at the end of the day, it’s all just stuff you crammed in. Underneath, it’s still the same old car. It’s reliable, it gets great gas mileage despite the half a million miles on the odometer, and it’ll start even when it’s buried under a foot of snow. Sure, it takes some effort to pass emissions, but at least every mechanic knows how to fix it, and parts are cheap.
Now for the bad news. Anyone with a flathead screwdriver can take it for a joyride whenever they feel like it. You keep finding it parked in weird places, but hey, at least they always bring it back. The airbags? They might work, but there’s only one way to find out. And let’s be honest—most modern cars have surpassed it in every possible way.
The best part? It’s been paid off for decades. No one is just going to hand you a brand-new car because that would take a ton of money and effort. No matter how much you tinker with it, it’s still a 1990 Honda Accord. You can throw on some new tires, upgrade the suspension, and maybe swap out the brakes, but at the end of the day, it’s never going to have that brand new car feel.
Every mechanic does not know how to fix x11, and cannot fix it without extensive knowledge.
it’s never going to have that brand new car feel.
Worse excuse to write new code, but Wayland does seem to be a good example of rewritting.
One thing to note with X11’s design, having a server and client, there was nothing requiring both to be on the same machine. You could run an X11 client on your local machine, ssh into a remote machine and use its X11 server.
Lets say you are home and can ssh into a work server. You could run Firefox on the work machine, using it’s network and have the visual parts show up on your home computer.
This was very much a Unix, shared resource style design. Servers and thin clients. Put all your horse power in the big machine and connect using your crappy low power system to it.
I realize not using this model was intentional with Wayland, but I wish it had something similar.
I’ve never tried it, but there’s Waypipe.
That looks like a great solution, will have to try it out.
Back than I tried this. The performance was horrible, even on a good connection. It was barely tolerable on LAN, but over the Internet … no. Just no. There were and are better solution for accessing a remote machine.
It was fine when rendering (esp. text) was server side and not client side like it is now. At least LAN (10MB ethernet) was basically transparent. Internet was shit mainly because everyone was on 56k modems.
GTK and Qt do all their rendering client side and transfer bitmaps to the server requiring much more bandwidth.
Ca. 20 years ago I worked for a company that used X forwarding for their backup management system (a Java application running on one of the servers) which somewhat worked on their wired LAN (at least
mostsome of the time).This was just unreliable and slow and had issues left and right.
In short, X11 is a bit unsecure in its concept (like every program can read keyboard inputs you are doing right now). The multi monitor configuration possibilities and mixing different setups is basically impossible (I mean stuff like mixing 4k@120 Hz with G-Sync and another one with 1080p@60 Hz with just V-Sync). X11 or XOrg has a long history since the 80s with many versions, the code base is spaghetti code and its not a pleasure for developers to work on.
Wayland is new, with a fresh and modern code base. It eliminates the security and monitor issues. Programs not written for Wayland does not work, but luckily there is XWayland, which allows running X11 games on Wayland. You can think of like Proton for X11, but without the benefits of Wayland, just a compatibility mode. In Wayland there are sub protocols, meaning standard definitions, that are developed and added after some time passes. I personally think protocols being like an addon that allows doing more stuff in a standardized way across all systems that support it. Developers in Wayland have a much better time working with its modern code base.
Have a look at https://wayland.freedesktop.org/docs/html/ch03.html .
Hey, sorry to take adantage of your answer, perhaps you can help me out though.
Is dbus actually necessary for xdg-desktop-portal? I understand from this flatpak post that xdg-desktop-portal is actually a bunch of d-bus interconnections, which of course make d-bus fundamental for xdg-desktop-portal, but wanted to confirm. xdg-desktop-portal is a must on wayland if one wants to share screen through webrtc, or electron apps like slack or teams-for-linux (probably zoom which is Qt as well). But I’ve read some people (this for example) start sway from console without d-bus, without logind/systemd, just seatd on the background (wlroots and sway support seatd). So perhaps those people are not interested on sharing screen, I don’t know. Or perhaps such d-bus plumbing is only required for flatpaks apps, which are sandboxed, thus requiring all that interconnection to access resources and such, and then I’m not sure about a thing…
Thanks !
Looks like XDG Desktop Portal is using dbus and expects it: https://flatpak.github.io/xdg-desktop-portal/docs/common-conventions.html
XDG Desktop Portal uses D-Bus in a slightly uncommon way, due to the potentially long-running nature of some of its requests.
And for the one user in your link https://snoo.habedieeh.re/r/voidlinux/comments/1471jbk/why_do_i_need_to_start_sway_with_dbusrunsession/jnxpxz7/?context=3#jnxpxz7 stating instead using d-bus, would use
seatd, I assume it has compatibility with d-bus. He recommends to uninstall d-bus in that case. I have no idea what seatd can do and if this is applicable to other distributions than Void Linux. So unfortunately I don’t know more than you. It makes sense that some sort of messaging is required in sandboxed environments.Funny enough I just looked in my Archlinux based system and look what we have, seatd is installed already. And
dbusis also installed.If you have installed wlroots, that’s why. Wlroots has a hard dependency on libseatd, which is provided by seatd. Labwc also directly depends on it. Sway as well can use seatd as both documented by sway itself, and its arch wiki, but for some reason it doesn’t directly depend on it, though it depends on wlroots, :). This is not a problem on arch since the seatd service can co-exist with logind/systemd, and on arch you can use the seatd service combined with libseatd for software build on top of libseatd, and users on arch can then choose between seatd or policy kit on that software. On other non systemd distros like artix, the seatd daemon is in conflict with logind (on artix it’s extracted from systemd), precisely because you can get away without logind as long as you use acpid to provide some of the functionality logind also provides besides session administration. Not sure if besides wlroots on archthere’s additional software depending on seatd. Several wayland compositors are based on wlroots, which attempts to somehow offer a standard for compositor and applications developers.
So it might be xdg-desktop-portal behaves differently for sandboxed apps such as flatpak ones than regular apps, hmm. So I’d still like to know how required d-bus is…
Thanks a lot !
You can’t use xscreensaver on wayland.
and you can’t use a shortcut for gnome-pie on wayland :( the workaround is a command line and opens a fullscreen window
Wayland is a from scratch redesign on how to display things on Linux to get rid of a huge amount of technical debt of x11.
As always with such a huge undertaking, there are a lot of speedbumps on the read that you can’t see beforehand. And at every speedbump people cried that wayland was a mistake and we just should go back to x11 because it worked good enough.
We now reached the point where wayland has (almost?) feature parity with x11, that’s why now more and more distro deprecate x11 to be unsupported some undetermined point in the future.
Don’t forget that at this point X11 doesn’t have feature parity with Wayland more than the other way around. Mixed DPIs, refresh rates, multi-display VRR, virtual screen resolutions, nested compositing, direct scan-out, GPU hot plugging, DRM leasing, HDR are all exclusive or at least better on Wayland.
aside from the obvious, wayland being the default choice on all relevant distros and DEs and being continously worked on, evermore projects switching to it (WINE most recently) whilst X11 is in maintenance-mode, the main thing for me and my deployed fleet is if you’re running a modern laptop, say with a 1080p or better screen, wayland is a must. primarily because of the output (UI scaling, effortless multi-monitor dock/undock) and the input (touchpad gestures, touch screens).
if your world is a desktop with a mouse and, say, XFCE, then you have very few of these things intruding on you and you don’t really
understand the benefitsbenefit from it.X11 or xorg is old and dated and uses a “x server” to work which is what it manages what you see and stuff. Wayland is new and updated removes the need for a server causing lower latency and faster composting but less compatible.
deleted by creator
