Live data from Hacker News

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

gist.github.com

191–200 of 419 posts

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

#191
post #130

Earlier quoted context omitted.

We (desktop devs) eventually gave up on it and are enjoying our Windows/macOS/Android/ChromeOS setups instead.

It would be funny that at the point where it seems that Linux desktop hardware support is at its peak, the actual use of Linux desktop would be at its lowest. I don't think that's the case, though.

GNU/Linux gets used alright, on IoT, servers and VMs, where the desktop is irrelevant.

While Linux community can pat themselves on the back for having Linux kernel as part of ChromeOS and Android, they tend to forget it is hardly exposed to userspace frameworks used by app developers.

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

#192

Earlier quoted context omitted.

That's exactly how I'm assembling my Sway session. My Sway config ends with `exec systemctl --user start sway-session.target`, and that target links to all the services I want running in my session (redshift, notification daemon, etc.). If you don't like systemd, you can `exec my-session-startup-script.sh` in the exactly same way. The Sway devs maintain a list of common helper applications that work with Sway: https:…

User services only really make sense for user stuff that requires more complex set up and tear down than start foo and kill it when I log out. Creating a user service per single line exec foo is extra ceremony. I have nvidia hardware so sway makes no sense for me to use. Also it's developer is extremely abrasive. Furthermore a lot on that list isn't an even trade. ydotool is a poor unmaintained replacement, making yo…

> User services only really make sense for user stuff that requires more complex set up and tear down than start foo and kill it when I log out. > > Creating a user service per single line exec foo is extra ceremony.

Then go with the parent post's other suggestion: a simple startup script that ends with launching Sway.

> I have nvidia hardware so sway makes no sense for me to use.

I mean the fact that Nvidia refuses to play by the rules, making their hardware unusable with Wayland, is a well-established thing by now.

> Also it's developer is extremely abrasive.

Is he? He has strong opinions and doesn't beat around the bush, but does that really matter unless you yourself actually want to develop Sway?

> Is there anyway that sway does better than i3?

I actually haven't tried i3, but on the face of it I would say that it's an advantage of Sway that it can run without the gigantic and increasingly unmaintainable legacy system that is X. You can certainly run X without problems today, but isn't it widely agreed that X doesn't exactly have a bright future? Sway is not tied to X's future.

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

#193

I think Wayland is a nice way forward from X, right now it's still not a replacement because of how central X is and how much stuff interfaces with it specifically or make assumptions about X features. (and so indeed, Wayland kind of breaks "everything") But I also think that they (Wayland) took a way too heavy napalm approach to the solution, almost like they totally ignored how painful such a transition would have…

You can quite easily be using wayland right now and not even notice it. It’s even the default on some distros now. Basically the only things holding it back are proprietary screen capture tools and nvidia.

I'm not saying you cannot use it, in fact I use it (with minor hassles here and there)

But this last step is taking ages, what I don't understand is why it had to be such a painful process without a migration path (hence we are still talking about it and the transition still didn't happen)

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

#194
One of my main gripes unfortunately Wayland does not function very well with accessibility software. Areas include but not limited to :

-simulated keyboard/mouse input (some progress recently with some composers)

ability to inspect window attributes (e.g. window title, executable and handle)

ability to manipulate windows (e.g. maximise, close, etc)

So just as with automation software this has significant impact on accessibility. The current composers available provide very limited functionality. Not to mention there are many different composers that would have to be supported to make many different system configurations accessible.

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

#195
post #123

I wasn't even sure which of them I'm running even though I've been remote teaching for almost a year, i.e. frequently sharing my screen: > [user@laptop:~]$ echo $XDG_SESSION_TYPE > wayland Apparently it's not as bad as it seems! However, now that I think of it, I haven't been able to share the entire screen and must add one application at a time to OBS. Maybe I've gotten used to this. At least I won't accidentally sh…

If you're using a wlroots compositor, then a workaround for sharing the whole screen is to use wf-recorder [1], which supports capturing the whole screen, and feeding its output to a virtual V4L2 device using v4l2loopback [2]. Software that is able to capture from a V4L2-compatible webcam (i.e. most) can them capture from the virtual device without knowing anything about Wayland. It's not exactly the most CPU-efficient way of doing things, but if you can afford the cycles it works very well!

[1] https://github.com/ammen99/wf-recorder

[2] https://github.com/umlaeute/v4l2loopback

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

#196
post #93

Earlier quoted context omitted.

> But more to the point, that the problem is that moving away from Xorg as a display server really needs to happen eventually Yeah, to a "better Xorg". The problem is people don't believe Wayland is a "better Xorg".

And for me, this is the main Issue: belief People are flaming and screaming about their beliefs, demonizing systemd, Wayland and what-not with FUD, baseless arguments and non-arguments, because they "believe" these things are bad and must die. If I want to talk about what runs on my workstation as if it was religion, I install Temple OS. If I want a modern (and basically following sane/safe architecture decisions) di…

systemd adds a concrete and substantial set of features for me. I eagerly embraced systemd for that reason - there are things I don't like about it, but it gave me lots of new benefits that justified the effort.

Moving to Wayland would force a bunch of changes on me for the sake of no functionality I care about.

That's the big difference. Given it provides no benefits to me that I care about, I won't move until staying on Xorg is more effort than replicating my current setup on Wayland, and as it stands it seems that's likely still years away.

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

#198

Earlier quoted context omitted.

> Problem solved! Not so fast! Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol. How the compositors are supposed to handle that? If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years…

How are you going to change those decade old binaries to work with Wayland??? At least if you don't throw X11, those decade old binaries still work. If you throw X11, they will not! You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly). And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic s…

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.

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

#199
post #83
post #59

Earlier quoted context omitted.

> 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. I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons. Edit: Thanks for pointing out that Xorg is a…

> 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 tearing for me has been a thing of the past for years now - just switch on "Force Full Composition Pipeline" on your Nvidia card and hey presto, no more tearing.

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

#200
post #164

Earlier quoted context omitted.

> How can people accept to use a display manager with constant screen tearing is beside me. I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing. How often does it actually happen to you, and under which circumstances? Personally I've been using computers since 1995, (Windows and Linux) and I practically never encounter screen tearing. And this is on a wide…

> How often does it actually happen to you, and under which circumstances? Scrolling, moving windows, resizing windows, approximately constantly.

Then you haven't switched on Full Composition Pipeline on your nvidia card (if you're using nvidia that is).

I've been enjoying silky smooth Xorg and video for a very, very long time.

Post reply on HN