Wayland is not ready as a 1:1 compatible Xorg replacement just yet • Hacker News Board

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#221

Post by zbuf » Tue, Feb 02, 2021, 12:33 PM UTC

_abox wrote: post #30

I really miss the network transparency in Wayland. Just being able to start a program on another machine through an SSH session is so useful. You can use something like vnc but a "whole desktop in a window" is slower and not as handy. I'm on freebsd mostly anyway which isn't big on the Wayland train so I'm fine for now. But it would be great if X11 development would be continued.

> I'm on freebsd mostly anyway which isn't big on the Wayland train so I'm fine for now. But it would be great if X11 development would be continued.

It would be. If a group wishes to take up Xorg development then I would be supportive of that. I suspect it may come from the BSDs, too.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#222

Post by simion314 » Tue, Feb 02, 2021, 12:34 PM UTC

vetinari wrote: post #153

rob74 wrote: post #78

Earlier quoted context omitted.

As a complete outsider - ok, I'm a developer, but I haven't had the pleasure (?) of writing something that interfaces directly with Xorg yet - I have been reading for years about Wayland being the way forward and how Xorg is dragged down by a long history of dubious design decisions and features nobody needs anymore, and I was secretly wondering: if this is really the future of desktop Linux, why doesn't it gain more…

> This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility. And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then c…

>And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then considered as it works, we don't have to fix anything, Ubuntu will keep things broken for us. Due to this attitude, they have slowed down Linux desktop by years, by not switching to Wayland by default in the past LTS release.

How can you complain about Ubuntu LTS keeping Xorg as default in an LTS when RedHat itself had Xorg as default at that time. Isn't this hypocrisy or irony? (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.

IMO let RH use Wayland as default for a few years , then hopefully they can't ignore user bugs and fix them.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#223

Post by tsss » Tue, Feb 02, 2021, 12:34 PM UTC

elric wrote: post #43

jchw wrote: post #19

> Wayland solves no issues I have This is a common sentiment, but it is kind of funny. Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn. Wayland indeed “breaks a lot of shit” but it’s not an accident or done due to incompetence. Als…

> [...] reducing technical debt, improving security practices, etc Reducing technical debt by rewriting everything from scratch (almost?) never works. It's the baby and the bathwater. It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues. The new, conceptually beautiful system…

Let me tell you an anecdote: A big, old, crusty online retail company wants to bring their web shop up to par with the competitors. Due to many years of technical debt, feature development speed has come to a halt and it is determined that the web shop must be rewritten to remain competitive. Over a period of months, requirements are gathered from user focus groups and all the employees who maintained the content on the previous shop. Development starts and 3 years later, still not having implemented all the requested features, the project is deemed a failure. Another 3 years later, a new consulting company is brought in to attempt to realize the project. But this time, instead of trying to replace the old shop, a completely new shop is built iteratively and independently. Domain experts in the company complain: there is no way to review products, they can no longer put text wherever they want in the shop and users have to call the hotline to unsubscribe from newsletter because there is no settings menu. Still, the new shop is already outperforming the old one, despite having far less features. It turns out that many of those features weren't needed after all.

The lesson here is that writing a direct replacement system rarely succeeds because the new system will hardly be able to implement all the features in a reasonable time. Instead you should take a step back and develop a completely new system that follows actual user requirements and gets rid of all the dead code.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#224

Post by vetinari » Tue, Feb 02, 2021, 12:34 PM UTC

AshamedCaptain wrote: post #210

vetinari wrote: post #198

Earlier quoted context omitted.

With Xwayland. On hidpi display they will be upscaled and blurry, but at the right size and they will work in the first place. Even window grabbing will work, albeit only with other Xwayland clients.

Xwayland is the kludge I was talking about (and this article). No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs

X11 is the kludge. Xwayland is the symptom. If anything, Xwayland is too nice and too seamless; it should get Xquartz treatment.

The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything.

For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#225

Post by rpiguyshy » Tue, Feb 02, 2021, 12:34 PM UTC

DavidPiper wrote: post #35

There might be some good stuff here for Wayland devs, but otherwise seems to be mostly the usual dumpster fire (good for for roasting popcorn, though). Stopped reading at this gem from the OP a long way down: > For all the Wayland proponents here, why argue in places like this, wouldn't it be a better use of your time to send PRs to fix things like MaartenBaert/ssr#431 and vkohaupt/vokoscreenNG#51. Time perhaps to in…

doesnt teddy remind you of hugo chavez a little?

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#226

Post by adrusi » Tue, Feb 02, 2021, 12:34 PM UTC

sokoloff wrote: post #167

brmgb wrote: post #83

Earlier quoted context omitted.

> Xorg is 16 years old Xorg is a fork of Xfree86 which started in 1991 but feature parity minus the cruft has been reached years ago. Some people disagree about what is cruft however. For example, I view 90% of the list in the posted articles to be minor softwares relying on undesirable behaviour and unwilling to adapt (the remaining 10% being misrepresentation of actually solved issues listed in bad faith). The orig…

Screen sharing seems a critical feature to enough people to rise well above mere “minor feature” if the goal is to replace Xorg. That was probably true 12 months ago, but definitely true 8 months ago. If the goal is to have a different display protocol that a significant fraction of the possible user base can’t reasonably use as their root display because it provides yet another way in which “Linux isn’t ready for th…

Wayland definitely supports screen capture.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#227

Post by AshamedCaptain » Tue, Feb 02, 2021, 12:36 PM UTC

vetinari wrote: post #224

AshamedCaptain wrote: post #210

Earlier quoted context omitted.

Xwayland is the kludge I was talking about (and this article). No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs

X11 is the kludge. Xwayland is the symptom. If anything, Xwayland is too nice and too seamless ; it should get Xquartz treatment. The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, w…

> The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. I

Just make a new property, and make those DPI-aware clients set it!

You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence).

> For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years

Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#228

Post by adrusi » Tue, Feb 02, 2021, 12:36 PM UTC

nerdponx wrote: post #132

arp242 wrote: post #100

Earlier quoted context omitted.

> How can people accept to use a display manager with constant screen tearing is beside me. I never even noticed it, and I never quite understood what people are on about with this. I had to go to YouTube to watch a demo video to see what it really looks like. And if I try it, then yes, I suppose I see some tearing if I move a window and pay close attention to it. But I never even noticed on my own, and am not bother…

Same here on all points, including Youtube. I always envisioned some kind of critical graphics failure from the way people talk about it. Maybe my standards are too low.

Maybe it's overhyped, but tearing does make me feel like I'm using an amateur OS, especially when I'm using X for some weeks and then hop over to wayland or Mac or Windows, and the picture looks stable.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#229

Post by nly » Tue, Feb 02, 2021, 12:37 PM UTC

gggtt wrote: post #208

nly wrote: post #124

Earlier quoted context omitted.

Taking your example of screenshots... I don't think there's an 'official'/defacto Wayland protocol for that. Under GNOME Shell you can use the org.gnome.Shell.Screenshot dbus API, but under KDE you presumably have to use something else. It is pretty grim.

All major distros seem to have agreed on Flatpak/Freedesktop Portal dbus APIs. For eg, for screenshot : https://docs.flatpak.org/en/latest/portal-api-reference.html... There are still apps using legacy gnome/kde specific APIs, but, from what I understand, in the future Flatpak APIs are becoming the defacto standard

These are dbus APIs though, not wayland protocol specifications that you can call with libwayland's RPC mechanism.

On the one hand this means you can support both X11 and Wayland with a single API from a client perspective, on the other you have to use DBus, which is horrendous to use (especially from statically typed languages).

It also doesn't seem to work on my XFCE/X11 desktop, which shows what fragmentation we have now.

Re: Wayland is not ready as a 1:1 compatible Xorg replacement just yet

#230

Post by cycomanic » Tue, Feb 02, 2021, 12:38 PM UTC

vetinari wrote: post #142

enriquto wrote: post #58

Earlier quoted context omitted.

> The author obviously hasn’t tried plugging a high dpi monitor in to a laptop if they don’t understand what’s wrong with X This is the only actual, honest, problem that I've ever seen about X. Still, it does not seem a really fundamental problem, it must surely be solvable from within X? Do we really need a full-rewrite of X, unstable, with new bugs and less functionalities? (many of us don't use "desktop" applicati…

> Still, it does not seem a really fundamental problem, it must surely be solvable from within X? X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable. Or you can do, as the Xorg does: use multip…

I've never used xwit before, but just looking at the description, I believe at least under sway the same should be achievable using sway's ipc protocol (I wouldn't be surprised if other compositors have similar options).

I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.