Migrated to @[email protected]Sep 23, 2024

Announcing: Frog Protocols for Wayland 🐸

Let's create Wayland Protocols but much more iterative.

Wayland Protocols has long had a problem with new protocols sitting for months, to years at a time for even basic functionality.

This is hugely problematic when some protocols implement very primitive and basic functionality such as frog-fifo-v1, which is needed for VSync to not cause GPU starvation under Wayland and also fix the dreaded application freezing when windows are occluded with FIFO/VSync enabled.

We need to get protocols into end-users hands quicker! The main reason many users are still using X11 is because of missing functionality that we can be shipping today, but is blocked for one reason or another.

Check out the repo here! https://github.com/misyltoad/frog-protocols

and the Mesa MR that adds support for frog-fifo-v1 to fix these issues and goes into much more detail: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/

GitHub - misyltoad/frog-protocols

Contribute to misyltoad/frog-protocols development by creating an account on GitHub.

GitHub
Show threadSimon SerSep 23, 2024
@frog sad to see this instead of efforts to improve wayland-protocols
Show threadMigrated to @[email protected]Sep 23, 2024
@emersion the governance model of wayland-protocols is set up in such a way that encourages and sustains all of these problems. there isn't really a realistic path for doing this sort of iteration in that model; nor a path for me to fix any of the other issues as an "outsider."
Show threadPekka PaalanenSep 24, 2024
@frog @emersion The wayland-protocols governance model was created in the early days. People wanted lots of features in, we feared that many of them are designed like X11 and violate the Wayland design principles, and so there was more disagreement than agreement on how to design things in order to get the features end users need. We always wanted downstream projects to develop extensions first for themselves, then see if they work for others as well.
Show threadPekka PaalanenSep 24, 2024
@frog @emersion I have tried to explain the Wayland design principles here: https://lists.freedesktop.org/archives/wayland-devel/2024-April/043583.html
Wayland design principles (Re: wayland and gambas)

Show threadJosh SimmonsSep 24, 2024
@pq @frog @emersion trying to enforce nebulous "design principles" is one of the major reasons that work stalls. anyone can argue that it's not "waylandy enough" and voila, protocol stalled forever. so one part of fixing this would be getting that entire idea out of the process and replacing it with minimal concrete requirements.
Show threadPekka PaalanenSep 24, 2024

@dotstdy @frog @emersion See my link to the design principles write-up. The goal was not to reinvent X11 but change the big paradigm and see if people follow that or go elsewhere.

Just like the Linux kernel has the policy of keeping policy out of the kernel, we want to keep policy in compositors.

Show threadJosh SimmonsSep 24, 2024
@pq @frog @emersion Right I'm not trying to make a value judgement on it, I'm just saying that's a core reason there's friction here. Because many people don't really care about those policies. So the idea that you can just fix wayland protocols to enable fast iteration, when like you say, there's an ideological component which is opposed to that... I don't know how that's supposed to happen.
Show threadJosh Simmons
@pq @frog @emersion For the goal of "fast iteration" to be achieved, either the ideological part of wayland-protocols has to bend to become more permissive and less bureaucratic, or those protocols need to exist somewhere outside of wayland protocols. I don't really see a third option which keeps everybody happy. For you, stalling of undesirable protocols is a feature. For others it is not. Regardless of who is "right" that disagreement needs to be at least acknowledged for progress to be made.
Sep 24, 2024 at 12:09pmPhanpy