Live data from Hacker News

Separating the Wayland compositor and window manager

isaacfreund.com

31–40 of 228 posts

Re: Separating the Wayland compositor and window manager

#31

Earlier quoted context omitted.

[flagged]

Yes, and I am praising them for tackling the idea. I don't know how you managed to misread me like that. I also read the article before commenting.

Sorry, I didn't address that at you but rather the other replies in this thread.

Re: Separating the Wayland compositor and window manager

#32
post #13
post #8

Earlier quoted context omitted.

>i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as w…

The Xorg codebase still includes some of those old drivers and is structured to allow them to exist.

Just to be clear the hardware abstraction layer used by wayland and any current Xserver is exactly the same.

Re: Separating the Wayland compositor and window manager

#33
Insightful article. I don't recall ever viewing an easy-to-follow lesson, tutorial or book for that matter that clearly explained the various components of a Linux Desktop environment. Always had to follow complicated and obscure guides to do this and that, when solving issues, but seldom did any explain their functions clearly.

Re: Separating the Wayland compositor and window manager

#34

I've never used a system with Wayland (been on i3 for ~15 years) but every time a project like this comes up, I have to wonder why Wayland is even a thing. So many hoops to jump through for things that should be simple. Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.

> I can make it do basically anything I want X11 can't do high refresh rates every time that I've tried to do so.

It runs just fine at 165 hz for me. Given that xrandr and CRTs have been around for a while, and both have supported high refresh rates for a long while, something seems fishy here. Something is probably at fault, but it's not X11.

Re: Separating the Wayland compositor and window manager

#35
post #13

Earlier quoted context omitted.

The Xorg codebase still includes some of those old drivers and is structured to allow them to exist.

Yes exactly. DRM exists, but there's still what I called the X "kernel", all of it's heavyweight abstractions. To the previous a-hole, frak you: not an AI. That's rude as frak. Also, you manage to be incredibly wrong. Even an AI wouldn't overlook such an obvious error; maybe it'd be better to have it replace you. So rude dude! Behave!

I am sorry if I mistaken you for a bot but the model you are describing have not been implenented by any graphic driver in decades.

Re: Separating the Wayland compositor and window manager

#36
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

[flagged]

The Wayland standard does not prescribe it (unlike X), and the reference implementations were monolithic for a very long time.

Wayland in general had a rather cavalier approach to doing away with things that X users take for granted, like, well, making screenshots. Eventually, under pressure, those in charge agreed that these features are actually very important for real users, so implementations appeared. It's an understandable way to discover the minimal usable subset of features, but the process of it is a bit frustrating for the early adopters.

Re: Separating the Wayland compositor and window manager

#38
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

[flagged]

"Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""

https://news.ycombinator.com/newsguidelines.html

Re: Separating the Wayland compositor and window manager

#39
post #14
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

You only need a single implementation that exposes an API for running a WM as an extension. I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.

We need a compositor that exposes everything as an extension. Preferably in a hot-reloadable, tweakable way, say, using Lua (with JIT). And also exposing its APIs in a way that allows having an analog of xdotool.
Post reply on HN