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 happy birthday fifo protocol

@frog `frog-protocols` is already packaged for @fedora 40+ and EPEL for @centos 10.

For Fedora Linux 40 and 41, the package has been submitted and will land as updates once the conditions are met:

- F41: https://bodhi.fedoraproject.org/updates/FEDORA-2024-45c8df31f8
- F40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d69c3ec44

FEDORA-2024-45c8df31f8 β€” newpackage update for frog-protocols β€” Fedora Updates System

management of Fedora Project updates

@frog I guess I still need to get around to figuring out what is require to implement the fifo protocol.

If Mesa merges this, it should be reasonable to add Rust bindings for frog-protocols to wayland-rs, and use this in Smithay. It will be nice to see fifo presentation finally working.

@ids1024 not much really, just changes how you deal with commit queueing.

gamescope has its own private protocol that does the same thing, and it was only a few lines change, bar the protocol boilerplate
@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 What makes you feel like an outsider? What would it take to let you feel like an insider?
@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.

@frog @emersion @krh and that blessed ground was not supposed to be a cemetery. :-P

@pq @frog @emersion @krh I think you've kind of hit the nail on the head as to why we have a problem now and why frog-protocols now exists.

When I talk to folks who develop compositors, the majority of them don't support this idea that protocols need to be perfect before they land. On the contrary, it seems to be burning people out to try to deal with that expectation. Also, I think that the "principles" had little influence on adoption of Wayland, but rather desperation to replace X11.

@pq @frog @emersion @krh In practice, it does not seem to be as hard as it looks to get wide agreement, it's just much harder to get *universal* agreement. It often seems like the latter is necessary to get anything done, and that's something we need to put more effort into squashing.

There also seems to be a fear of "dead batteries", which I don't think is something we should fear. Things tend to naturally work themselves out over time anyway.

@pq @frog @emersion @krh Wayland, as used today, is already not functional without things that aren't in wayland-protocols. On the GNOME side, there's both private protocols and a mixture of private and public D-Bus interfaces. On the KDE side, they use private protocols and third-party protocols. Most other Wayland environments follow the KDE approach too. A lot of them are the same third-party protocols. That says to me we're not doing a good job of integrating things that are commonly needed.

@Conan_Kudo @pq @frog @emersion @krh
The main problem it seems is the speed of decision making.

People need one month minimum to merge changes. That's too long in a tech space.

Also, it seems that even with implementations and acks there seem to be discussions around something, why?

@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)

@pq @frog @emersion

Please just please get screen readers working. I have a friend that is completely blind. Wayland is not an option right now.

I also don’t see this getting fixed within the next 3 to 6 years that means Linux off the table for these users. Since I highly doubt distributions will inform users that when they are going to drop X11 that they will. οΏΌ

@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.

@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.

@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.
@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.

@frog Everybody can suggest improvements. Everybody can apply to be an "insider". All "insiders" are reasonable people and will listen to you if you throw ideas around.

But really, I don't think there is a high barrier between "insiders" and "outsiders". Many "outsiders" are super active in w-p and have a high impact.

@frog Replacing a formal governance designed to give everybody a voice and avoid gatekeeping (yes, that's why the governance exists in the first place), with the wild west without clear rules of who can do what when, is a regression in my eyes. Not saying w-p is perfect in any means.
@emersion if Gamescope applied to be a member, do you believe it would be NACK'ed? (genuine question)

@frog @emersion I would welcome gamescope, especially if it represented also Steam and Valve.

I would welcome Mesa too, if someone is willing to be the representative.

@emersion @frog you mean all insiders are reasonable people, including the one who tried to get me fired from my job... (which thankfully, wasn't even my job) Yeah, it's a great and welcoming community to be sure.
@emersion @frog But more related to the topic at hand, I think this exact kind of "no that's actually not a problem" response to people talking about issues they have, is a pretty common theme with w-p. It's also the case when you read through responses to some of the MR's and issues, including in comments from insiders (by whatever definition you use). Disagreement is expected to a degree, but the condescension isn't necessary.
@emersion @frog In my own personal experience, I really lost all hope when I saw people being condescending and generally just rude to icculus, of all people, on w-p. If their contributions don't allow them the benefit of even vague politeness when their input is dismissed out-of-hand I don't know what hope anybody else has.
@emersion @frog while i do agree that wayland-protocols moves, too slowly most of the time, i think going with a completely separate project will end up just causing more fragmentation, improving the wayland-protocols process would indeed be a lot better for the ecosystem

@frog If nothing else it seems like this has opened up the discussion around Wayland protocols being a mess of stalled protocols, bikeshedding, this is the kind of disruption that Wayland needs to experience to get things actually working like they should be.

Yes it's going to get a lot of push back and it probably should but it actually gets the ball moving on this very long standing issue.

@frog Very interesting! For those who think this detracts from wp, what do we say about wlr protocols that are already almost ubiquitous anyways? I think it's okay to have protocols come from other places, and then when proven to be solid they often get proposed into wp anyways.
@ryanabx @frog The `wlr` namespace has been closed for many years in an effort to shift protocol development to w-p.
@Conan_Kudo @frog I didn’t know it was closed. Even still, a lot of them have basically become standard, likely years before they’ll actually enter wp. I see frog protocols as being similar
@frog
This is probably fine.
I predict most be exclusively implemented in gamescope and kwin.
Then hopefully lead to a few fleshed out protocols landing in wp sooner than otherwise.
@frog love to see it, was wondering if something like this was even viable and possible. cant wait to get off x11 in the next half decade
@frog is there a "stabilization path" for getting protocols in the main protocols repo or is this a full alternative?