Differences between Wayland and X11

[email protected]

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 can't really understand the benefits.

[email protected]

I won't bother going into technical details about x11 and wayland since other people already explained it much better than i ever could, but basically wayland is supposed to be replacing x11, because the codebase is so old now that it has become very hard to maintain and implement new features without breaking things. A window manager pretty much only handles the placement of windows on the screen, and you have to use seperate applications for setting a wallpaper, getting notifications, application launcher, etc. Whereas a desktop environment is a fully fledged out of the box experience. I personally really like window managers because i like the workflow of tiling window managers in particular, which places the windows in a predefined layout for you. Something that might be a bit confusing is that window managers on wayland are called compositors, which is because in wayland the window manager also has to do it's own compositing. In x11 you could use something like picom, which is a seperate compositor program that you could use to add graphical effects to any window manager, but on wayland this doesn't exist and the window manager has to implement its own compositing.

[email protected]

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.

[email protected]

This reads like an AI response to me.

Mac OS has never used X11 as a primary display system. Apple had a version they supplied with older Mac OS X versions for people using older Unix applications (and half-arsed ports) but that’s been unsupported since 2012. You can still install the modern “XQuartz” open source equivalent.

[email protected]

A shorter take: x11 is old, and big, and didn't originally consider security much at all.

Wayland is newer, therefore lacking some bells and whistles of x11 that some x11 users may still care about, but also designed with more awareness of security issues - making it more extensible and maintainable into the future.

There was a time Wayland wasn't a great x11 replacement due to its level of development. When it will become the better choice all depends on what kind of user you are, but it seems inevitable to become the better choice for most users in the future.

[email protected]

Not AI.

My bad on the Apple part.

[email protected]

That looks like a great solution, will have to try it out.

[email protected]

Oddly I think the only cases I ever used it where I was connecting to my home computer from outside my house was when I needed to connect to my router's webpage. SSH to my home computer and then pull up the browser to open a port on my DMZ or other such nonsense.

When at home and just using LAN bandwidth it was to run lesser programs.

[email protected]

Why does Nvidia need to support night light?

They don't, but they needed to support the KMS API for applying lookup tables to the image sent to the screen - desktops relied on that functionality without a fallback, so when it wasn't available, you just didn't get the feature.

Can't someone from Wayland just write a simple shader in any shader language that does colour adjustments and apply it to the desktop?

There's no such thing as "someone from Wayland", just the developers of the DEs (well, the project is named after a town, but I'm sure that's not what you meant).

But, yes, you can use a shader. We implemented that in KWin and we're using it when the driver or hardware doesn't support the functionality we need... but that has a noticeable performance impact, so it's still necessary for the driver to support it natively.

[email protected]

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.

[email protected]

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 dbus is also installed.

[email protected]

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 !

agnos.is Forums

Differences between Wayland and X11