Hacker News Reader

Comment by corty | Hacker News Reader

It is actually one of the big, unfixable, conceptual problems of Wayland that all the effort is duplicated in each compositor. The Wayland concept pushes out most of the work to the DEs. That of course will result in tons of predictable inconsistency, incompatibility, bugs, delays, consolidations and general pain. Wayland devs are then generally in the lazy "worksforme, use sway (or whatever)" position while the user (of some other compositor) will be out there complaining to yet another maintainer duplicating yet another feature badly. Lather, rinse, repeat.

Wayland is bad design, and it shows in the users' and maintainers' attrition.

View on HN

I honestly think this complaint is completely bogus.

This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations.

The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] !

The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't.

[1]: https://github.com/swaywm/wlroots

Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places).

What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.

Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.

No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.

The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.

At least between-app DPI inconsistency was not a thing before this. Now its a thing, added to the stack of configuration problems.

If you support multiple DPIs then that will always be an issue, regardless of what display server you're using.

Not if the protocol allows the exchange of desired DPI/scaling.

Right, I agree that differences of opinions between implementations is probably not productive. I was responding to the notion that this situation is somehow directly attributable to Wayland's design, which is bogus.

The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.

Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling"

edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1

[1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

This is absolutely right, and wlroots is not a fix once you already have 2 implementations

Once that ship has sailed, what you want instead is a shared method of providing configuration. The goal is to have all 3 implementations read configuration (like DPI scaling etc) from one place. That way the user won't have to configure common things in 3 places to get any semblance of apps looking remotely close to eachother.

Wayland isn't bad design, at least not in the way you're describing it. I feel like there's some confusion about what Wayland actually is. It's a document that describes how surfaces ("windows") should talk to a compositor ("display sever"). That's it. In a parallel universe Kwin and Mutter would be X11 display servers and we would have all the same issues. Nothing is stopping the existence of a single extensible compositor to rule them all and be the base on which every DE/WM is based but it hasn't happened yet.

When people talk about "pushing stuff to the DE" what they mean is the Wayland project aggressively scoping the Wayland protocol to drawing surfaces and handling input events. They're not trying to become a generic desktop message bus for everything an application might want to do -- that's literally what dbus is.

But isn't this the point of wlroots?

> It is actually one of the big, unfixable, conceptual problems of Wayland

Why not have a shared implementation?

Because then you end up with something like X11, which we already have.

The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11."

Personally I think something like that is an inevitability.

> which we already have.

It'd still solve a lot of issues that X can't.

Because the Xorg mono-culture was bad. There was no ability to write other X11 display servers from the spec alone. You either did what Xorg did bug for bug or apps broke. By having many different implementations all speaking a common protocol you make it harder to calcify the behaviors of any one implementation and ensure that the spec is what apps code against.

People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.

That's fine, I know. But acting like Wayland is feature complete when it obviously isn't is pretty ridiculous. Instead of solving hard problems the Wayland maintainers are acting like you're stupid to want to have the features solving the hard problems enables.

I think Wayland is about as feature complete as it's gonna get at this point. Mutter, Kwin are still working on adding features to support workflows that relied on the loosey-goosey nature of Xorg. Like Xorg never had "support" for global hotkeys or screen sharing. It's just that programs were allowed access to all inputs and the screen buffer. Designing a system where only some programs are allowed to do that isn't trivial.

That's more or less why I sometimes log in under X instead of Wayland - I can't run Fontforge under Wayland (not sure why and I don't have the bandwidth do dig deeper). Luckily, the machine behaves the same way.

I don't understand why it's so important to have multiple broken implementations before having 1 working implementation. Especially in open source where there's no monopoly risk.

Diversity is great but equality in failure is not helpful.

> Because then you end up with something like X11, which we already have.

X11 is a protocol. What you mean is that we end up with something like Xorg, an implementation of X11. Which is still incorrect because a major design goal of Wayland is to move as much logic as possible from the server to the client.

> a major design goal of Wayland is to move as much logic as possible from the server to the client.

I wonder how long it'll take to have a Wayland server running on the AT&T Blit...

We do, wlroots. But it came _after_ mutter, and maybe even kwin, so right now there are basically three.

Reply on news.ycombinator.com