Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Separating the Wayland compositor and window manager

isaacfreund.com

Post reply on HN
Print view View original

181–190 of 228 posts

Re: Separating the Wayland compositor and window manager

#181

Post by ACS_Solver »

GuB-42 wrote: post #160
hedgehog wrote: post #94

Earlier quoted context omitted.

Remote access on X11 is a mess and I won't miss it, at least on Wayland everyone is funneled through EGL or Vulkan and there's a reasonable path to layering remote access on top of that.

X11 remote access have worked really well for me. And the best part is that it worked even when the client machine has no graphical subsystem installed. I can launch GUI applications remotely with a non-privileged account and it shows on my machine as if it was native. Wayland can use RDP and some other remote desktop protocols, but it is not what I want, I want a window, not a desktop. There is Waypipe now, I heard…

This is also where I'm at. I don't care what protocol or whatever is running underneath but I just want things to work and Wayland doesn't do that. It has lately been better, previously I would try Wayland and run into problems within minutes, recent attempts have given me hours without running into a problem. And as an end user I don't want to care that the problems I get aren't with Wayland but rather a particular compositor/WM implementation or whatever. I want it to work but it's only in the last year or so that basic functionality like screenshots has become reliable.

What gets me is how old Wayland is. It's now older than Linux itself was when Wayland started. It started in the era of 2.6 kernel series, when most software was still 32-bit, systemd didn't exist, when Motora Razr was more common than iPhones, when native desktop applications were still the norm, Node.js didn't yet exist and Google Chrome was a completely new beta browser. Wayland is now reaching feature parity and some kind of "it works out of the box, usually" state when it's from a completely different era of computing.

The nearest point of comparison is perhaps systemd, another Linux project that is very large in scope, complicated, critical and must interface well with lots of pre-existing software. Four years after Poeterring's "Rethinking PID 1" post that introduced systemd, it was enabled and in use on many distros. The conservative Debian adopted it within five years. Now it's been clearly a major success, but Wayland has been perhaps the slowest serious software product to be in development.

Re: Separating the Wayland compositor and window manager

#182

Post by paulryanrogers »

stuaxo wrote: post #174
roenxi wrote: post #161

Earlier quoted context omitted.

> I don't get the frustration with wayland (the protocol) in the comments. They took a firm principled stance against screenshots to start with, which set them up for the COVID WFH wave. Then we've got this questionable design that seems hard to make accessible since accessibility is a security risk and we're heading right into Agentic AI which will be interesting. I've been avoiding the Wayland ecosystem for as long…

I'm not sure I get the link between being against screenshots and working from home during COVID ?

You need to screen share a lot more during remote work

Re: Separating the Wayland compositor and window manager

#183

Post by vidarh »

vidarh wrote: post #158
toast0 wrote: post #105

Earlier quoted context omitted.

X11 has some tricky, imposible to fix (within the confines of the existing protoco) issues because of the seperation between Xserver and window manager. Things like (IIRC) initial window placement and what nots, where ideally the window manager would make choices about things before the process continues, but the reality of distributed systems makes everything hard. Combining some things into an integrated process fi…

> imposible to fix (within the confines of the existing protoco) X11's extension mechanisms can - and has - been used to enable backwards incompatible protocol changes. E.g. BigRequest changes the length and format of every single protocol request . Very few client libraries are only capable of speaking "the existing" protocol if you take that to mean the original unextended X11 protocol. Adding an X11 extension that…

Too late to edit, but one minor self-correction: BigRequest changes the allowed length and format of every single protocol request. For small requests they are the same, but if length is set to 0, an extra 4 octets are inserted to allow encoding a larger packet length.

Re: Separating the Wayland compositor and window manager

#184

Post by pjmlp »

chriswarbo wrote: post #180
pjmlp wrote: post #163

Earlier quoted context omitted.

Basically something that us grey beards like in several window managers, it is not supported in GNOME since the version 3.0 reboot, and relates to minimizing a window to the title bar. You can move the title bar around, and depending on the window manager either double clik to drop down again its contents, or by leaving the mouse pointer for a few seconds hover it, it will temporarly reveal its contents. https://en.w…

Yeah, it took me a while to discover that it was removed from KWin. (I eventually ended up reading the sources). It didn't help that KWin also does 3D effects, so all of my Web searches for "shading" were returning results for "shader" :-(

Oh, gone from KWin as well? Yet another reason to stick to XFCE I guess.

Re: Separating the Wayland compositor and window manager

#185

Post by hedora »

ximm wrote: post #132

I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction. Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get…

First they said we couldn’t have screenshots because they were insecure. Then they added them back in.

Next, it was accessibility APIs and I guess copy paste is still flaky.

Now, it’s window managers.

What’s next, Remote Desktop?

The whole reason given for wayland’s replacement of x11 was that those things are all fundamentally bad ideas.

It’s been 15 years. Linux desktops are more fragmented than ever, and they’re still going forward with mass deletion of legacy x11 applications.

The only benefits to end users are things like HDR, or backporting a compositor feature or two, which X11 could easily be extended to support.

Instead we get two decades of the digital equivalent of book burning for reasons no one understands.

Re: Separating the Wayland compositor and window manager

#186

Post by pluc »

akagusu wrote: post #106

Well, it only took 15 years to someone to fix one of many Wayland design flaws and start to make it feel usable. Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers. Then, people who think they know better than everyone else will throw Way…

It's a shame because Wayland has made complicated what most contributed to the growth of Linux in the last few years: gaming. I still can't run most of my library on Wayland without the added latency of XWayland. It's great if it's one step back to take a big leap, but this feels like two steps back one step forward without much of a plan for parity.

As the sibling comment said, with WSL becoming better and better, it's a dangerous game to play.

Re: Separating the Wayland compositor and window manager

#187

Post by hedora »

throwthro0954 wrote: post #139

As a 25 year user of Linux I love wayland since cutting over to it about 5 years ago. No tearing ever, which I always had to battle with with X. Certain developers that must interact with the Wayland stack will have to do more work now, and some projects may not still be viable, I get it. I've been following the comments in Linux forums for years. But users exist too, and here is one data point for you.

I haven’t had problems with tearing in x11 for 20 years, with or without compositors, on nvidia, amd or intel.

Each driver spells the TearFree / vsync option differently in the config. They probably should have just enabled it by default, since there is no downside.

Re: Separating the Wayland compositor and window manager

#188

Post by hedora »

hparadiz wrote: post #85
charcircuit wrote: post #59

Earlier quoted context omitted.

Works fine for me with 144/120 with the second as 60.

What's happening is you are running both screens at 144/120 and your 60 is gonna have vsync and screen tearing issues.

How does wayland handle the hypothetical problem of playing a 24 fps movie split across a 48hz and 60hz display?

(Hint: It’s not possible to solve correctly.)

Re: Separating the Wayland compositor and window manager

#190

Post by prmoustache »

throw_a_grenade wrote: post #147
ximm wrote: post #132

I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction. Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get…

I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent commu…

Nonsense. Gnome is not Wayland.
Post reply on HN