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
@frog sad to see this instead of efforts to improve wayland-protocols
@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."
@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.
@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)

@frog @emersion A big problem with Wayland extension is that their stability requirements are greater than those of a library ABI. If a library breaks ABI, one can at least vendor an old copy of the library with an app. That is not possible with Wayland. Protocol fragmentation hurts interoperability, which is why wide agreement on extension is very desirable. Getting wide agreement is also the hard part of design, as everyone knows.
@frog @emersion Some Wayland extensions should get wide agreement, while others are fundamentally enabling something that will never get that wide agreement. A good example are the protocol extensions that make wlroots the modular base for anyone to build a custom environment by choosing and picking helper programs. That design is inherently against the fully integrated product design used by e.g. GNOME. Both have good reasons to exist.
@frog @emersion I think in the past at least some people have seen the acceptance to wayland-protocols as means to force everyone to support the extension. It does not work like that. Some extensions should get wide adoption, others do not need to. That is how the wayland-protocols namespaces wp, xdg, and ext came about. It is possible for an ext extension to become widely supported, too, but there is usually not as wide agreement initially that it would have made it into wp.
@frog @emersion What are the concerns of easily accepting new extensions into wayland-protocols? Fragmentation, causing interoperability problems between apps and compositors. Some fragmentation is unavoidable, but I think it is still good to at least try to minimize it by looking for wide acceptance. Doing major revisions to extensions is a breaking change too, increasing fragmentation.

@frog @emersion But anyone can just make extensions and ship them outside of wayland-protocols. This was even a goal in the early days when @krh was still developing Wayland. Let downstreams mature extensions, and then let them grow their support organically.

I think that idea still carries, but we need to think how to deal with the fragmentation.

wayland-protocols partly came about from the desire to have "blessed ground" for known-good extensions.

@pq @frog @emersion @krh
maybe it should be mesa-fifo-v1 instead of frog-fifo-v1?

(and live in mesa repo instead of frog repo)