Differences between Wayland and X11

[guy_threepwood@lemmy.world]

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.

[mangocats@feddit.it]

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.

[that_leaflet@lemmy.world]

Not AI.

My bad on the Apple part.

[jecxjo@midwest.social]

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

[jecxjo@midwest.social]

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.

[zamundaaa@discuss.tchncs.de]

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.

[wewbull@feddit.uk]

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.

[thingsiplay@beehaw.org]

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.

[kixik@lemmy.ml]

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 !

[matombo@feddit.org]

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.