> The protocol makes wrong abstractions at the lowest level which causes problems everywhere else.
Can you point out any specifics? I think both the low-level operations (allocate some shared memory for a surface, agree on a pixel format, etc) and the high-level features (scaling!) are solid, the holes are mostly in the ecosystem fragmentation/extension support ("can you please draw some window borders for me, thanks?"). If you were designing a modern windowing system from scratch, what would you do differently?
How much time do you have? First of all it needs to be much simpler to do simple things. You are right that you need to "allocate some shared memory for a surface, agree on a pixel format, etc" but it shouldn't take 250 LOC just to put a simple window on the screen (look at https://wayland.app/protocols/wayland there is no reason to make bare essential things that complicated). A proper standardized client library should need 1 LOC for that. The whole polling/ping mechanism is completely flawed. Since you don't know how to solve the halting problem please let the user decide if an application is unresponsive or not and reliably kill the pid of the window when the user presses that "x". Until then assume the process to be working. This also means a hard requirement for server side window decorations since they need to be rendered by another process with higher priority (also because temporarily unresponsive windows might occasionally be moved or resized). Windows should also be able to obtain where they are on the screen in relation to other windows from other processes. There should also be processes that are allowed to read out and modify all window positions (e.g. for window managing and automation). Also processes should be able to read image data from screen or other windows (e.g. for screen sharing). Standardized interfaces and proper access control for all latter things should be baked into the protocol from day one and not rely on non-standardized external infrastructure (like dbus/portals). And those interfaces should be as simple as possible. Latency is generally bad on Wayland. The mouse pointer should be rendered by a separate thread on its own hardware layer which requires no vsync. Keyboard input events should be able to immediately update dirty rectangles disregarding vsync for those pixels to make typing as smooth as possible. Generally allow tearing for windows by choice of the user/program and be able to have windows that don't allow tearing next to tearing windows at the same time. (I have more but nobody reads that shit anyways.)
> If you were designing a modern windowing system from scratch, what would you do differently?
Personally I would recreate something like MGR with a modern spin. But this is obviously a very opinionated design.
ya most of this i think people don't understand because they don't code. and even then a lot of people will defend it. the real problems show up even before any of the flow, design or logic though. if you were to spend millions on a house, you wouldn't cheap out on the foundation would you? yet the xml generation and shit horrible names like 'globals' and 'shell' liter wayland nomenclature. i would rather have 'window' namestepped on again like X did. the source of most wayland woes seem to be 'security' ideas and epoll being used to funnel everything. as for the amount of code that's define 'struct thing thing' extralongnametosetawhole3funcpointers is just astounding.
i don't think it would be 'that hard' to redo with the above sane types of considerations, avoid everyone reinventing the wheel and writing the same code for every project, and something that has a core protocol ACL configurable at the system level. it certainly shouldn't take a decade. but the main problem is then everyone would have to switch display server stacks, again.
i still haven't switched because i'm too lazy to rewrite anything just to get nothing from wayland.
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.
Can you point out any specifics? I think both the low-level operations (allocate some shared memory for a surface, agree on a pixel format, etc) and the high-level features (scaling!) are solid, the holes are mostly in the ecosystem fragmentation/extension support ("can you please draw some window borders for me, thanks?"). If you were designing a modern windowing system from scratch, what would you do differently?