upvote

points

by dralley3 hours ago |
comments
upvoteby wing-_-nuts3 hours ago|
next
[-]
>Wayland is not a "display server", it's a display protocol.

I, as an end user, do NOT care.

>A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.

I also don't care about ivory tower ideals of what is within the dominion of 'display' and what is not. The fact of the matter is their changes broke a ton of functionality, and instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.

I have no idea why the community didn't take one look at their proposal and flatly ignore them.

reply
upvoteby setopt2 hours ago|
parent|
next
[-]
> instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.

In other words, the Wayland people should perhaps have defined official protocol extensions early on to cover most of what X did, thus preventing all the initial interop issues when Gnome and KDE and Sway tried to reinvent them independently.

reply
upvoteby yjftsjthsd-h1 hours ago|
parent|
[-]
In hindsight, it's my opinion that wayland, if it had to exist at all, should have been implemented like this:

1. Add GBM to graphics drivers and start working it up the stack from the bottom, stopping at Xorg. That is, make rootful XWayland the standard Xorg before standalone even is a thing. This reduces maintenance work up front rather than belatedly.

2.a. Implement weston as a standalone compositor.

2.b. Actually make weston fully functional. Figure out everything needed to provide an actual working desktop environment with the features that users expect out of the box. Standardize all the protocols needed for at least a basic XFCE-ish environment rather than hoping someone else will do it.

3. Then, only after these things are done and working, announce to the world that wayland, a quiet project that has until now explicitly suggested nobody use it, is now the future of linux graphical systems and everyone should plan to migrate.

reply
upvoteby Anonyneko2 hours ago|
parent|
prev|
next
[-]
The community doesn't really have a say because Xorg is effectively on life support and the Xorg devs are now working on Wayland. There aren't many people in this world who could keep Xorg going. Some distros are sticking to Xorg, but it will become more and more difficult in the coming years.
reply
upvoteby toast01 hours ago|
parent|
[-]
People keep saying Xorg will stop working, but it has yet to turn into a pumpkin, so I dunno man.

Can it do new things? Eh, probably not. Do I need it to do new things? Not really.

reply
upvoteby Anonyneko1 hours ago|
parent|
[-]
Not in the short-term, for sure, and probably not even in the mid-term. But hardware keeps changing, and at some point nobody will care enough (or be able) to implement proper support for it in X (or proper support of X in that hardware). Hopefully we still have at least a decade of X though.
reply
upvoteby cschep2 hours ago|
parent|
prev|
next
[-]
If nothing else this is a very strong commentary on just how challenging landing positive changes in Xorg felt to the community.
reply
upvoteby skydhash2 hours ago|
parent|
prev|
[-]
This pretty much. Xorg got almost everything that I care about to have a functionning GUI. You only startx and the only thing you may need are utils programs like a wm, a compositor, a bar… now you have conflicting implementation from gnome, kde, wlroots,… each with its own set of features.
reply
upvoteby wing-_-nuts2 hours ago|
parent|
[-]
Yeah, instead of the wayland folks leading the effort to fix issues, it's often some individual DE / WM going off, fixing it the way they prefer, and wayland grudgingly adopting it as official because they know the ecosystem is fragmenting bad enough as it is.
reply
upvoteby drmr2 hours ago|
prev|
next
[-]
And this transition is nowhere near done. Just look at Kicad and pretty much any DAW that loads audio plugins (to name two major usecases where Wayland simply doesn't cut it).

Sure Xwayland exists and mostly (not entirely) works, but that's a band-aid for what is essentially a "we broke it and don't care" approach.

reply
upvoteby Blackthorn1 hours ago|
parent|
next
[-]
The daw problem is really really bad too. We've got a de facto standard forming right now where you link libwayland.so and hope the structs never ever ever change in the next 30 years.
reply
upvoteby wing-_-nuts2 hours ago|
parent|
prev|
[-]
Also, as benchmarks show, xwayland introduces pretty bad latency..
reply
upvoteby dralley2 hours ago|
parent|
[-]
The latency isn't that bad, it's reasonable for a compatibility shim.
reply
upvoteby mzajc1 hours ago|
prev|
[-]
> Wayland is not a "display server", it's a display protocol.

This is a huge part of what "user/dev hostile" means in my book; with Wayland, getting a working desktop always someone else's responsibility, all features have to be reimplemented across DEs endlessly (with often-incompatible variations, of course), and they all blame each other and program authors for bugs while the Wayland project refuses to even acknowledge basic features like desktop automation or screen recording.

> But sure, the transition was difficult and took a long time.

And this irks me too, people are convinced they're done but I still don't have xmacro. And flameshot is broken, while the alternatives suck. And support for everything depends on the DE now. And java.awt.Robot is broken with no replacement. And the clipboard randomly misses copies. And OBS screen recording is broken for me. And there's no support for display resolution scaling. And ssh -X is gone, while waypipe doesn't work all programs.

But hey, at least there's HDR now or something! It was definitely worth replacing a functioning stack for this. I'm so glad that Plasma 6.8 removes X support!

reply