Considering how much works fine in Xvnc which kind of lacks half the extensions, and considering that all the bad hardware stuff now needs to be handled in each compositor, it is unclear how much worse it would actually be.
So OpenGL-first design sounds like the real reason for all the mess.
What do you mean by bad hardware stuff? Most hardware should be handled by KMS and libinput, shouldn't it?
I think there is somehow still some buffer-management code which is not fully indifferent to the GPU used, and apparently that goes beyond proprietary drivers. Has it been completely cleaned up for nouveau?
… unsurprisingly, as these are typically WM teams who are now deprived of what Xorg server did for everyone.
Only the ones that don't use wlroots, I think. wlroots has its own problems, but in large part those are the problems we're trying to mitigate here.
Yes, but it seems memory-unsafe even by the «careful C» standards, and it seems to crash noticeably often with reasonably well-behaved clients, so just a protocol compliance filter would not be enough.
My experience with wlroots has been that when it crashes, it's because of quirks with monitor state and stuff, not anything from the Wayland protocol. Have you had a different experience?
I still avoid Wayland because it would be too much of a drop in features compared to my X11 setup. I have just checked segmentation fault bugs in the tracker… Of course you do not get many crashes due to Wayland protocol quirks, if only because your applications are not going out of their way to crash wl_roots.
Another thing the proxy would be really cool for that I didn't mention before is debugging. Potentially you could even record and replay Wayland messages, which would help with any crash that was from Wayland.
Indeed. Then if we have a good proxy codebase, yet another proxy might even help some («good, clean») applications shrug off a compositor crash.
Aren't shared memory buffers usually handed out by the compositor, to the client? IIRC this was the reason virtio wayland can work when it only supports shared memory that was allocated by the host.
Looks like for wl_shm the client creates and shm object and sends FD to the server, then both sides mmap from there. Given that one could cook an FD with approximately arbitrary combination of properties, I guess some care should be taken about this, too.
Hmm, yes, looks like you're right. I wonder how virtio wayland can work the way it does, then... But yes, that is something we could validate.
Wait, I remember you explaining a pretty complicated dance to make some buffer host-allocated from the VM point of view but client-managed from the Wayland point of view. Am I misremembering?
no support in the Wayland protocol. It could even be used to modify surfaces, to implement things like Qubes-style unspoofable coloured window borders.
I am tempted to ask how close it will be to providing a socket for WM and window decorator implementation (with some suitably limited compositor as the backend behind the proxy).
(So basically, defining a scope will be hard, and defining a scope in a usefully extensible way might be even harder)
I don't understand this point. Can you rephrase / expand?
Well, you start describing a proxy that is basically «only valid messages pass» and that's it, then add that it could also implement some more functionality. Then you say plugins for policy-heavy functionality. (I guess at that point the natural next step is a socket so that safety-handling and user logic could be in different processes)
This sounds like a recipe for scope creep, although it might also be good as a single well-vetted Thing being safety-critical and a lot of policy decisions being pushed to restartable and functionality-restricted separate processes is actually better than the current recommended approach to Wayland compositors.
If you want to try pushing the project to freedesktop, I suspect it is a good idea to define how much scope you want to include into the pitch. Although apparently they don't have any objections to hosting software with heavy scope creep, when reaching for a high profile, it is a good idea to set internal expectations before having to manage external ones.
I actually think the scope is fairly limited?
1. Receive request 2. Validate request
This alone could become interesting really quickly.
3. Asynchronously run request through plugins (you're right that external processes are probably a better idea, although I worry about complexity and performance).
And then it all depends on what we want the plugins and external processes to do, as this functionality needs interfaces. (Re: performance — I guess «simple but high-volume» and «complicated but with small request and response» need to be separated, policy vs. mechanism, and all that)
4. Forward request to compositor
Re-serialise more than forward, I really hope.