💾 Archived View for dioskouroi.xyz › thread › 24945538 captured on 2020-10-31 at 01:02:29. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
Maybe I have reading comprehension problems but this article sounds so conflicting and presumptuous. Is it a sales pitch or not? If it is, even when it says it isn't, I would start by looking at Arcan's bus factor, and what refactoring and architectural changes were necessary along the years.
Having no expertise in this field I have no patience for people who write in this style but never got involved in the process. But if they did then I would be more interested in reading why their proposal was better and what can be done _now_ in the living code. Also IIUC protocols are exactly that, places to experiment and learn from mistakes until they get stable and anyone can propose them.
There are many developers who could write a good technical solution but it's the ones who can deal with the ugly politics that make a real difference. There's a phrase about that there but as always if you don't send code your opinion won't do any good.
> _Maybe I have reading comprehension problems..._
I was feeling the same! I came away from this article even more confused as to what's been going on.
I used to be a maintainer on Xfce (though it's been a decade since I was active), and I've been worried (as a user) about the "upgrade path". Porting (if you can call it that) from X11 desktop environment to Wayland compositor (etc.) is a _huge_ step to take, it seems, and Xfce's current core team doesn't seem interested in going in that direction (I don't blame them).
As a user, I want to just keep using Xfce until the heat death of the universe. As someone who might get involved in Xfce development again, I worry that any work I'd be doing on the X11-based things might be wasted time in the long run.
I seem to recall there was some hacks to get a legacy X11 wm to manage windows for a wayland environment but they were unstable or not maintained.
Googling around: xweston and/or xwlnest ?
I wouldn't do that. Only move to Wayland when there is a real path for what you want and need. And it does it without hacks.
About porting I would look at what MATE is doing or at the code of Wayland shells, protocols or things like Waybar at GitHub. You don't have to write an entire compositor if you don't want to. Even better get in touch with the people who know what they are talking about, I think they have a wayland IRC channel.
There are a lot of unmaintained WMs that work well and are amusing for historical value or retro computing, and probably some of them have a small number of real world users too. I like the idea of a compatibilty layer for those.
Maybe not for a big project with ongoing development. But as a last resort to run some cool stuff.
It seems it would be difficult to do that without combining both protocols into one server. (This is not quite what xwayland, xweston, xwlnest do. They run the server X out of process and can't manage wayland windows because they don't know anything about the internal wayland state)
To that point, you would have to decide if it's more worth it to fork xwayland and merge with an existing wayland compositor, or to fork xfree86 and add wayland.
I bet you could achieve it with three layers. First, run a "top level" Wayland compositor. Then, use XWayland to run an X session (with your favorite window manager). Then, use Weston's X client mode to run Wayland applications inside the X session.
As silly as that sounds, it might actually be a good solution. Red Hat gets to push their shiny new display server protocol, and I still get to make screen recordings and use my favorite window manager. I wonder how well it works in practice...
That would sort of work too, but it comes with its own set of issues. Keep in mind that there is very little reason you would actually want to do it that way when either way you're dealing with the same impedance mismatch. In other words, you will have to solve the same issues in the display server you're running into now with screen recordings and strange window manager behavior. It's not something that you'll just get for free. If it was, the other Wayland implementations would have it fixed by now. There's no magic solutions to this without any brokenness or workarounds—the crux of the problem is that you have two protocols you're trying to match up that are compatible in some ways and incompatible in others.
Also I think it's a stretch to say the push behind Wayland is coming from Red Hat. Maybe within GNOME, but there are other implementations with no connection to Red Hat.
I don't think the impedance mismatch is the same either way. The Wayland protocol is much more restrictive than X's -- things like screen capture and window managers don't work because the APIs they need aren't present. Conversely, there are X APIs for everything a Wayland application is able to do, so a Wayland-app-in-X shim would probably work a lot better.
The outermost layer, where you run the X session inside a Wayland compositor, would probably work alright too because it just needs to send pixels to the screen and accept mouse/keyboard input. Wayland is able to do both of those things!
>Wayland protocol is much more restrictive than X's -- things like screen capture and window managers don't work because the APIs they need aren't present
This is not quite true. There are protocols for these things in some implementations. You'd want to keep compatibility with these because otherwise you'd have no reason to be supporting Wayland. Keep in mind either way you're talking about using a specific compositor—it doesn't matter if the APIs aren't present in the protocol. In this situation you'd re-use one from another implementation or add another private protocol extension. That's always been what individual compositors are encouraged to do. It's no different here.
> This is not quite true. There are protocols for these things but they live in multiple places.
Every Wayland window-manager-compositor-hybrid invents their _own_ protocols for these things. This basically means that you can't write a program that does these things -- you need three different versions of every API call you make, and that's just to support the popular desktop environments that people happen to be using this week. So no one has, so the only Wayland protocol features you need to support are the basic ones to open a window, draw into it, and get mouse and keyboard input.
> Keep in mind either way you're talking about using a custom compositor
No, I suspect the "top-level compositor" could be any off-the-shelf Wayland compositor that supports XWayland and can make a window full-screen.
Here's the thing about Xwayland: Xwayland _is_ Xorg. If you look in the xorg code base, you will find that it's separated into components called DDX and DIX. DIX (Device-Independent X) handles protocol and server state; DDX (Device-Dependent X) does the drawing. One of the back ends in the DDX code is for Wayland; when you compile Xorg with just this back end, you get Xwayland.
So if Xorg gets abandoned -- oops! There goes Xwayland as well. I do believe that this was the plan all along: keep Xwayland around as a solution for "legacy applications" for a while, then stop supporting X altogether to make it less attractive as a back end for new applications and toolkits.
Yes, I am familiar with the Xorg code base :) The point I was getting at is that if you want to keep using an old protocol far into the future, someone from the community has to step up and maintain something. That's true of any old technology faced with waning influence over time.
It is a compromise for how Xorg and Wayland can have a shared graphics backend that improves both sides and the part that the Xorg maintainer wants gone can go away.
Arcan has had its own fork of Xorg for many years, as well as a Wayland implementation. Nothing here will change that trajectory.
The library mentioned is about ~2kloc, decoupled from the rest of the project (100+kloc) and the relevant subset has not changed significantly for several years.
This is about X.org deprecation, which has come up a bit this week:
https://www.phoronix.com/scan.php?page=news_item&px=XServer-...
/
https://news.ycombinator.com/item?id=24884988
https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
/
https://news.ycombinator.com/item?id=24920183
Seems to be an oblique sales pitch for pushing bits of the author's window server architecture into Wayland.
Nothing wrong with that, but it didn't really tell me what problem it was trying to solve, nor directly pitch a solution for anything.
What is holding Wayland back? Was the core protocol just not created with many basic features in mind?
There's really only one appropriate response to nebulous and meandering proposals like this.
It's a great idea, now send us a patch.
Author misses the point.
There are strong differences that will not get smoothed over regardless of how many 'protocols' you define; Wayland is Policy over Mechanism, X11 is Mechanism over Policy.
Why yes, that's the whole point.
I don't know if you've noticed, but "policy over mechanism" has thoroughly won in the desktop space. The dominant desktop is Windows; even macOS has several times the mind/market share that Linux has.
This is pretty much the "Emacs modernization" debate for the desktop as a whole. There is a growing contingent of Emacs users who saw their chosen editor get its lunch eaten by Visual Studio Code, and now wish it was a bit more modern and a bit less... well, less Emacs. Similarly, Wayland was pushed by a large contingent of users who want to see the Linux desktop resemble a successful desktop used by millions to get their work done.
Back when GUIs were brand new and the Unix community was populated by neckbeards, creativity and experimentation in the desktop space was a good thing. Today, those neckbeards have grown older. Time for them is shorter. So even they don't want to experiment anymore; like everybody else _they just want to get their fucking work done_. Millions of people have gotten work done with the successful model of Windows and Mac, and Linux users want their desktop to resemble the most successful desktops of all time -- not something that is a large pile of hack upon hack with seams constantly showing.
Pushing back against the direction the ecosystem is going will only breed resentment and ill will, because you are committing time and brainpower to a dead end when you could have committed it to making Wayland better.