[cycloptic]

There's no political process. In GNOME if you want to do strange things with moving and reparenting windows from other processes then you write a GNOME extension. Same with KDE and kwin scripts. No touching of Wayland necessary. Fundamentally it doesn't seem that different from writing Arcan WMs. If all that's not enough then you write a new Wayland compositor with the policy you want, maybe using wlroots to save time. Overall that really hasn't changed much from writing X WMs, I don't get what the concern here is. At worst, it is a change that can be adapted to just like those changes you describe in DWM.

>you are much more locked down

Is this not what a policy is? The window manager locking down clients and enforcing that they can only do certain things? I'm aware that Arcan got wayland support recently and that actually gives me more hope that we're not headed towards an apocalypse of protocol incompatibilities.

[crazyloglad]

Need some shuteye (9am 'into the night'), but I think we are running into a similar misunderstanding that I spotted you having in the other Xorg thread.

https://github.com/wayland-project/wayland-protocols/blob/ma...

Is what I mean with political process. Patching the compositor is the wrong side of the equation, it doesn't work with networked clients and it's the client that needs most of the features. It's the client that needs to have a more expressive surface to work with. You can do these things safely and securely without the overbearing constraints and complexity of the policies that we are practically stuck with. See the trayicon/stream-deck articles.

> I'm aware that Arcan got wayland support recently and that actually gives me more hope that we're not headed towards an apocalypse of protocol incompatibilities.

I don't know if 4 years is recently in that span (see the dating my X post), but Xwayland support was initially decided as off limits. That was added recently because, as it turns out, those clients are still the ones that behave the most predictably and are the most robust. Even for applications that should handle both and I need to choose explicitly (arcan-wayland -exec-x11 the_thing or arcan-wayland -exec the_thing) I really only use the x11 side. Even for gtk and Qt. That's the real tragedy.

I would say the babel-split is practically here because of all the sidebands and ad-hoc protocols that have been introduced specifically as a reaction to the strictness and limitations of the initial designs and the poor underlying primitives (as in the wire format and its de facto implementation).

[cycloptic]

The wire format and the initial implementation are definitely flawed, but if you fix them you end up in the same situation again where you break everything every release and you go through all this politics trying to get everyone to use yet another new protocol and implementation. I see various complaints about that and it always comes back to the same thing. We have alternative implementations of the protocol but nobody uses them because of this. Consequently this is the same reason that it took so long to fix issues in X.

I see what you mean with that document, but if you have been watching then none of that stuff is new or unique to Wayland. What you may have missed is that this document is a reaction to the politics that already were around in the X days. (I was alluding to this earlier when I was talking about WM atoms, the popular desktops already have their own sets of policies there that are necessary and incompatible and in some ways do limit the expressive power of clients)

Not working with networked clients is a minor detail. It's trivial to have a user upload a compositor script to a different machine. If it becomes annoying to do it manually then a client that needs more features simply needs an automated way to do this. Still no need to touch the Wayland portions there either. I actually do appreciate the efforts to fix these issues with the whole shmif setup and I sympathize, but it's the same uphill political battle if you want to push that out to the rest of the ecosystem.

[crazyloglad]

Part of it is that you either go to extreme lengths (like arcan-wayland) or it embeds itself so deep in the code base that it will be hard to get anywhere. If it doesn't get fixed, well, you don't have to be a reliability expert to be worried about this one:

https://gitlab.freedesktop.org/wayland/wayland/-/issues/159

I have probably chased ghosts deep inside GTK from this one alone for multiple full time weeks, to no avail. There will eventually appear a rather harsh teardown post of some of the major mistakes in the implementation (and that alone, no xml business), wayland-server might not improve, but future designers should be able to stumble upon it.

I think to get further with the discussion we need a sort of list of what mechanisms we consider mechanisms, and how policies project over them. Not to be disrespectful, but my budget for engagement is thin, pandemics, sorry :-/

The politics stuff - so I have some logs that precedes the formation that are quite incendiary and outright vile, but there is enough shit flinging to suffice to stop at there being good reason why I wouldn't consider getting closer than bayonet range, and why the post was obtuse enough to discourage most #metoo and discard me as an idiot who knows nothing. The tech stuff matters though and that's only what I want to see. A protocol and not marriage as if from 'the war of the roses'(1989).

There is a fourth option that might materialise, but that's for then.

[entropy1111]

X was really bad for me and Wayland has been very reliable. Good enough for my work. Your posts are very political stuff too. If you want to be strictly technical just skip all the meta/drama and the boogeyman talk. In the post and in the comment section. It doesn't put you in a good light even if your statements turn out to be true. Your projects look very interesting. A suggestion for your next blog post would be talk about what you want to achieve, your real intentions, and how you plan to do that. If it's just a showcase make that clear. It's unfortunate that you don't want to work with what they have now but I hope you can find a compromise. It would be great if your contributions could make Wayland even better.

[crazyloglad]

"Good enough for your work" until issues like the one mentioned appears; You plug in a kvm, close the lid or something at the wrong time, come back and see your work gone. You then blame the client, the gpu or hardware, then the toolkit, then the compositor and everyone says "can't reproduce" because the infrastructure guys went EWONTFIX because 'difficult'. It is a design blog, it is inherently political. There's a high number of tech posts on the main site. The roadmap, the intentions, everything has been spelled out, and visible for half a decade.

[cycloptic]

I hear what you're saying and I also can't stand the namecalling and political infighting that tends to happen in some open source communities. Unfortunately I doubt a display protocol is ever going to fix that.

On that bug, that problem seems to go deeper than Wayland and I don't know if there is any way to fix that in all cases on Linux due to the nature of SIGSTOP. I know you may not answer this, but wouldn't that also affect X too? Or does it have some other way it deals with it?

[crazyloglad]

Xorg is better, but not by much. On write-fail they setup an internal buffer ~16k and if that one is saturated it is closed (that + whatever the kernel has). The protocol/packing is not that busy in the server to client direction so it lasts for quite a while.

The way the disconnect happens is interesting though, I am not certain enough about the threaded-IO implementation in regards to hotplug but a quick glance looks like if a hotplug occurs at the same time a client is disconnected the sparse allocation requirement of open() could get an input device confused as a client as it is cleaned up. The odds of that happening though :D

In the wayland code it looks like they tried to have a buffer strategy at some point, but then got too clever for their own good (epoll designs + asynch-OO projected over C is... yeah) and somewhere in 'closure/write/buffering to lower #syscalls/callbacks' landed in a long chain of error propagation and immediate kill.

The best way I found (hence using it) is to have memory mapped ring buffers and just have an atomic head-tail indicator. This makes file-descriptor transfers (DuplicateHandle from win32 fame is just so much prettier) messier, but it means that you can have a recovery strategy and see the backpressure buildup and rate-limit. Since it is mostly input events or 'drag-resize' (and those can be merged) in that direction, silently dropping them and have mouse cursor 'jank' is better than losing your work. If all else fails, the watchdog handle is pulled and the client is set to migrate to a fallback server (if set).