> How much time do you have?

Exactly one lifetime ;)

> A proper standardized client library should need 1 LOC for that.

Agree. See my sibling comment: https://news.ycombinator.com/item?id=43016206

Something like wlroots (with a high-level API) should've been the go to thing for all downstream compositors and/or client apps, unless you have very particular needs. The "wire" protocol underneath however? Meet the present and near-future needs, and make it as complex as it needs to be to match the state of the art on other platforms (OS X managed this over 25 years ago dammit!)

Graphics are complex though, even before you touch e.g. color science, and maybe you don't feel any pressure to meet the demands of the professional market, but it's like the curb effect... I do enjoy the heck out of my Zoom UAC-232, 32-bit float ADC may sound like overkill for an enthusiast setup but I just don't ever have to worry about gain levels, it's just one less thing that gets in the way of having fun with a guitar and/or mic. I don't work with picture as much, but I do understand why sRGB can feel limiting, and I recognise that I don't understand enough to make the call, whether Wayland is too complex for its task or not.

> Windows should also be able to obtain where they are on the screen in relation to other windows from other processes.

Wasn't this kind of poking and probing the root of all security evil under X11? You have to draw the line somewhere, and I think it was the right call to start conservative - you can always relax the restrictions later.

> There should also be processes that are allowed to read out and modify all window positions (e.g. for window managing and automation).

This is a much bigger topic that touches accessibility in general. I use Shortcat on macOS; I can press Cmd-Shift-space, and every interactive element on the screen gets a tiny popup with a two-letter keyboard shortcut - no need to reach for the mouse, unless some app insists on pushing its own pixels. The ability to only move windows around pales in comparison.

It's possible because stuff on macOS uses a standard set of libraries and APIs; the problem lies not with the display server (I think it's the wrong layer of abstraction), but in the layer in between that and the applications, which with the Qt/KDE/GTK2/3/4/5/whatever-tk-of-the-year was always a shitshow.

> Latency is generally bad on Wayland.

Isn't gamescope also a Wayland compositor? Or does it just isolate games?

> The mouse pointer should be rendered by a separate thread on its own hardware layer which requires no vsync.

I always thought this was the general/default case, with only the insane attempting software cursors. Darn I despise laggy cursors (StarCraft player checking in).

> Keyboard input events should be able to immediately update dirty rectangles disregarding vsync for those pixels to make typing as smooth as possible.

Noted and noted. It makes a lot of sense in general, vsync mostly matters for dynamic scenes and typing text isn't one. But you either need tight coupling (bleh), or a sane way to cut thru the layers.

> (I have more but nobody reads that shit anyways.)

I appreciate when people share different perspectives.

I'm actually interested in this topic, as I've embarked on a journey to write an entire NIH from-scratch Linux userland in pure Go - no cgo, therefore no Mesa/OpenGL/etc, likely gonna go thru fbdev unless I can understand if and how can I use DRI/DRM. Still aiming for a kinda late 90s vibe, it's amazing what Windows 2000 or E16 could do with software-only rendering.

I do think Wayland is too complex to tackle in a NIH/hobby project, but a very rough outline of how it does things is generally appealing.

> Personally I would recreate something like MGR with a modern spin. But this is obviously a very opinionated design.

I had to look it up. In my opinion, terminals/PTYs, network transparency, drawing primitives, tight coupling between display and widgets, are all waaay overrated. The sole use case for network transparent windowing died with the rise of the WWW, and you won't find a computer made in the last 30 years that can't draw its own windows. Remote access is solved by protocols such as VNC. A REPL shell does not need a terminal, it needs an input widget where you can edit text - where Ctrl-C means copy, and a scrollable output that supports automatic bookmarks for easy navigation (the stock macOS terminal is my hero). TUIs are just the lowest-common-denominator GUIs, with all the quirks of emulating a VT100 thrown in, including in-band sign^Q^Salling. Serial consoles are for rescue access, not for playing nethack, and modern servers have BMCs anyway. IMHO drawing belongs in a library like Cairo, it has no business in a display server, unless you're planning to make it talk to a printer.

Widgets are a tough nut though; consistency between window frame and its contents is essential, so either the display server has to understand widgets to draw correct frames, or throw the towel and delegate that to the higher-level toolkit and/or the application. Add another layer (like a separate WM) and it's starting to feel like too much indirection. It's an interesting dilemma though.

Overall maybe I just can't see why ManaGeR is appealing, at a glance it stinks of everything that held X11 back.