Live data from Hacker News

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

gist.github.com

351–360 of 419 posts

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

#351
post #318

Earlier quoted context omitted.

Everything you said is correct. But, there are surely cases where even though rewriting everything from scratch almost never works, the status quo doesn't work either . I'm afraid that's where the Linux desktop is today. Linux as a platform actually sucks for running "untrusted" software. And "untrusted" doesn't just mean proprietary games. It also just means "can I please run the alpha version of this cool open sour…

Android does a thing where it has its own display stack and very strict sandboxing so X11 isn't really a thing :) And for the sandboxing it uses SELinux which is available on desktop as well. It's just a royal PITA to configure. This is why many people don't bother with it. But in a highly restricted environment like a smartphone it's a lot easier. I wouldn't call that a 'hacky' thing, it's just using it in a very di…

> And for the sandboxing it uses SELinux which is available on desktop as well

I used to think that, and then I started using Fedora. They have put a lot of effort into their SeLinux policies. I do all sorts of things with my workstation and very rarely have to care. In the last 6 months the only thing I have had to do is add ":z" to a bind mount running a podman container so that labelling happened correctly.

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

#352
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…

> Clipboard is weird.

Hopefully you are not referring to the fact that there are two clipboards in X, because I really like that "weirdness", and I'm really used to it.

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

#353
post #23

This is absurd. Author claims that "Wayland breaks automation software". They then use the "py37-autokey" tool as an example. Autokey uses Xorg APIs for key handling. Of course this is not going to work on Wayland since it's written for Xorg and not for Wayland. The author is probably the type of person that buys an AMD graphics card, and then complains that AMD "breaks" software that's based on CUDA...

I think you have a point, and I agree about this kind of complaint for screencapture where there are APIs on Wayland so you can't point at X-based software that didn't port and say "it's broken"!

However as far as I am aware there is no proper key-capture or key-inserting API in Wayland. There are hacks (IMHO) like bypassing the compositor and reading the events directly but we are still missing a well-defined API that is supported cross-compositor.

I am fine with GNOMEs very limited keyboard shortcut support but I definitely agree that this is a step down from what we had on X.

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

#354
post #278
post #23

This is absurd. Author claims that "Wayland breaks automation software". They then use the "py37-autokey" tool as an example. Autokey uses Xorg APIs for key handling. Of course this is not going to work on Wayland since it's written for Xorg and not for Wayland. The author is probably the type of person that buys an AMD graphics card, and then complains that AMD "breaks" software that's based on CUDA...

Automation software like that will never work on wayland (certainly not across different compositors) since it violates the security model.

That's not true. It bypasses the default security model but it is entirely possible (and to be honest I'm surprised there hasn't been progress) for the user (or the compositor automatically) to provide an API that provides the required access to whitelisted applications.

It is just like the web. By default websites don't get to access your camera, but that doesn't mean that camera access is impossible. They just added a way to request camera access with user permission.

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

#355
post #182

Earlier quoted context omitted.

My external monitor is 3440x1440. Equivalent HiDPI monitors didn't exist. Perhaps maybe they do now, but the pricing would be prohibitive.

My 3840x2160 external monitor has a pixel density of approx. 275 ppi. IIRC it cost approx. $300, not exactly prohibitive.

This sounds like an interesting screen. Which is it, if I may ask?

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

#356
post #43
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…

>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 Wayland developers are the same people who have been building all these workarounds for xorg for decades. This isn't a new thing coming out of nowhere. When the old guard is telling you that their own work needs to be replaced, I'd listen.

>Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.

Good thing nobody forces you to use it and it's just one click away on the login screen from switching to xorg. In the meantime people who want to hack on the project can do so and ship their changes to users to test them plus those who do suffer from xorg issues( because yes, xorg doesn't do well on a lot of things that aren't even that modern despite all the workarounds for the "real world" issues it has) can use wayland right away.

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

#357

Earlier quoted context omitted.

> How can people accept to use a display manager with constant screen tearing is beside me That's solved by using a compositing window manager such as Compton.

You don't even need a compositor. Just activate Force Full Composition Pipeline if you have an nvidia card. see: https://imgur.com/a/lDfObqw It's in the advanced settings. Silky smooth Xorg web browsing and video at no extra compositor cost.

Thank you so much for this! I've been looking for a solution in picom config for way, way too long.

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

#358
post #84

Earlier quoted context omitted.

They aren't though. And X is pretty deprecated by now.

X is not deprecated by the global community at all, only by the few who push Wayland.

... and those developing X.

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

#359
post #43
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…

> Reducing technical debt by rewriting everything from scratch (almost?) never works.

Agreed but this is one of those "almost" exceptions.

1. Is the code built to 40+ year old requirements, many of which are irrelevant today?

2. Is it hard to make it work for today's requirements without widespread fundamental changes?

3. Is the code a huge pile of foo that's damn near impossible to navigate, much less understand, much less debug?

4. Would a hypothetical program that solved today's requirements (with an architecture where the most important backwards compatibility features could be hooked in as needed) be smaller, simpler, and easier to maintain by newcomers?

If the answer to all of the above is "hell yes!", you might want to think about a wholesale rewrite.

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

#360
post #229
post #208

Earlier quoted context omitted.

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 h…

Yes exactly, it's always a big debate every time a new features is needed whereas it should be Wayland protocol or Dbus.

Gnome people push for everything Dbus, and many Wayland dev prefer to standardize over Wayland protocol.

It's kinda sad that the APIs are fragmented over two IPC solutions (unlike for eg on Android where everything goes through Binder IPC).

I think the overall the idea is : if it requires permission/sandbox -> Dbus, otherwise Wayland . But in practice there is a lot of disagreements.

Post reply on HN