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/

@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

@frog happy birthday fifo protocol

@frog Arch has packaged this as well:

https://archlinux.org/packages/extra/any/frog-protocols

@frog i like frogs

@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 path for doing this sort of iteration in that model; nor a path for me to fix it as an "outsider."

@emersion @frog I don't see frog-protocols as competition for wayland-protocols. I see it as a staging repository. If a protocol lands in frog-protocols with its much lower barrier to entry, then it has a better chance to gain enough adoption to gain the support and acks required to land in wayland-protocols.

That said, I really do wish such a staging repo weren't necessary, and I want to see w-p improve. I'll be happy if it does.

@serebit @emersion @frog How exactly would you improve wayland-protocols, such that a trivial protocol without any significant controversy (e.g. fifo) would ship in say, 1 to 2 months, instead of > 12 months?

cc @mia Maybe this could of interest to you. I do remember to see you posting about wayland-stuff here and there

ps: I did make this post as answer before. But thought that maybe quoting is the better sorry mia for the double mention.

RE: https://idtech.space/objects/f5221e5a-b025-4aaf-ba92-4563f21f2046

@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 Cool!! :D

@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

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

@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", but I don't think that's something we should be concerning ourselves. 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.

@emersion @frog I wrote up a slightly longer post that came out kind of annoyed, so I wanted to reword this: can you please like, suggest what you actually would like to see? Because this isn't actionable. This just greatly complicates the situation and I don't think this helps anywhere as much as you think it does.

@Lyude @emersion the governance model is totally broken, and needs to be just removed and should be replaced with controlled anarchy like Mesa.

the fact that the repository is anything more than a collection of XML files that compositors and clients handshake on is a huge mistake. w-p should not be set up like a standards body. it doesn't deal with ip or legal frameworks like Khronos does; and the current w-p governance represents but a tiny selection of clients and compositors.

whenever something new is proposed, the immediate reaction is typically "this goes against my ideology for what i think is pure and right for Wayland," which is totally messed up and not conducive to actually fixing any problems. take the window icons protocol, 95% of that whole thing was just utterly useless noise and what-about-ism.

it is not just a "technical" problem, the way people treat others with differing opinions and schools of thought about how something should or could be done is really bad, and even if certain people are not directly members, they are associated/affiliated to projects who are, and act incredibly hostile.

in my experience, wayland-protocols is just a lot of power-tripping and useless arguing, and not much actually solving problems.

as mentioned by me and others, the bar for entry for a protocol to land even in 'staging' is ludicrously high, which leads to features taking literally half a decade to land at some times.

having a path for experimental protocols in w-p -- ie. something that can be rapidly iterated on and implemented by clients and compositors, and shipped to users is a total must.

experimental protocols can follow the basic iteration groundrules of what I defined in frog-protocols to avoid there being an immense amount of churn there.

but I think all of this is incompatible with the current governance model.

@frog thank you for writing this up! Honestly I completely agree with you, and it's almost kind of weird that this is what has been happening with w-p at least from my perspective of having worked on it a number of years ago. Previously when I worked on the drawing tablet protocol as a GSoC student it was really emphasized to me that it's difficult to simply write a perfect protocol, you need to be able to actually test it out in the real world to see what needs to be changed

@frog it makes me think that this has sort of also stemmed from the issues we had getting protocols into core Wayland, because the overarching opinion was that the core Wayland protocol should remain as small as possible - which was one of the reasons w-p was started in the first place. It feels like now though w-p isn't being treated as staging anymore because of how many protocols are actually in there, which itself is a problem because yeah - this stuff needs to get shipped to perfect it

@frog also FWIW I didn't assume this would be a "technical" problem. Honestly I kind of hate that term. Open source communities have their own politics and it's kind of naive to pretend that those politics don't directly affect actual development - the reality is they're just as much of a "technical issue" as actual code is.

@Lyude @frog I think people like to pretend that it's possible to be "just about the tech", but technology is aimed to serve people and solve their problems, so naturally the relationships among the folks working on the tech matter just as much, if not more so.

@Conan_Kudo @frog I will say though - I still don't think we can treat stuff like frogs as a permanent solution. it would be really helpful if y'all would at least put something along the lines (maybe you have already, I'll admit I haven't checked) of these protocols not being finalized.
I've actually been seeing a lot of good conversation with people today about how we could make the bars for getting protocols into w-p less of an issue. but basically everyone, myself included, is incredibly worried about the possibility of another repository like this just sort of side-stepping actual consensus from communities.

@Lyude @Conan_Kudo i would argue that consensus is already sidestepped in much worse way by virtue of the majority of the wider community being not being represented by the current governance situation in any way.

@Conan_Kudo @frog It would both help to actually push other projects to consider using these protocols, and come across in good faith to communities. Because I have to be honest, I completely understand why people are upset by this. If we just pushed every single protocol into the hands of users immediately without a second thought we will be stuck with literally ever decision we ever make until we have to fork something and start over.
It's really tempting to look at actual working PoC implementations we have and say to ourselves "well sure, that can't happen". But that's like, literally exactly 100% how this always starts. we can't just put off trying to fix things as being impossible.

@Conan_Kudo @Lyude @frog over the year's I've come to realize that "It's just about the tech" is a dog whistle for shitty behavior that people don't want to change. I've but up with so much BS because of that.

@frog @Conan_Kudo So how does forking and adding two different protocol repositories actually fix this issue outside of the compositors currently using one or the other? How do you know that not only the compositors participating in this repository will actually get a say in these protocols when actual software is going to rely on them? Are you going to be open to projects like GNOME and sway actually contributing? what are the actual genuine plans for pushing any of this back upstream?

@Lyude @Conan_Kudo anyone can contribute to this repository, but i obviously cannot force them -- if they do not wish to participate in the project and ship protocols from this repo, that is their choice.

pretty much everything else is an unknown and a bridge to cross someday if this project continues.

one of the big problems with wayland stuff is putting the cart before the horse, and i have no intention of doing that right now. i don't plan much in my life :-)

@frog @Conan_Kudo And if wayland-protocols does get its shit together, what then?

@Lyude @Conan_Kudo the project will have been a success

@Lyude @Conan_Kudo @frog and the even scarier problem is that "a multitude of rushed and incompatible protocols" is one of the reasons X turned so messy and broken but couldn't be fundamentally fixed (according to my understanding of people that were there explaining it, i might be wrong)

My hot take here is that... just because you shipped it earlier doesn't mean that much for its quality.

Some kind of early testing of protocols is useful but it would require some tight integration of the stack so that deprecation definitely happens. So for example proton using gamescope-specific protols, or a similar thing on KDE and GTK.

@ada_magicat @Lyude @Conan_Kudo the good thing about Wayland is you can just not support any protocol, and protocols are entirely 'decentralized' which avoids this in the long term.

@frog @emersion @Lyude I think it's important to note that this is partly why we see all the incompatible approaches to integration done by the different desktops.

GNOME uses a couple of private protocols, but mostly D-Bus interfaces. KDE uses a pile of private protocols and third-party protocols, and most of the other desktops are following similar approaches.

The brand new COSMIC desktop is doing something similar, and I think that illustrates the point that something needs to change here.

@frog @emersion @Lyude To make my point clearer: we already have fragmentation and incoherence for Wayland integration because the central integration effort appears to be too hard for most desktop and application developers to want to do it.

@Conan_Kudo @frog @emersion @Lyude I'm actually not really aware of the purpose of these private protocols (especially the dbus ones). Do you have some examples on hand and why they are even needed?

@ada_magicat @Conan_Kudo @emersion @Lyude eg. gamescope uses this protocol to talk to it's layer: https://github.com/ValveSoftware/gamescope/blob/master/protocol/gamescope-swapchain.xml

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

@ada_magicat @Lyude @Conan_Kudo @frog people really really really overestimate how bad fragmentation caused by making the wrong thing is. It's understandable as a platform developer to be worried about long term maintenance, but it's really a problem that is entirely constricted to that area. As a consumer of these APIs fragmentation can be annoying, but building something out of multiple extensions already fundamentally fragments things, so +- some for an extra protocol is a small worry.

@ada_magicat @Lyude @Conan_Kudo @frog far more of an issue is when you try to figure out how to implement something and there's 3 in-progress protocols which have all stalled for multiple years and contain 300+ messages of aimless arguments about nothing. That is far worse than needing to do a v2 of a protocol, or needing to deprecate some protocol and have compositors support it long term.

@serebit @frog We've already been experimenting new protocols in w-p with the xx prefix (with the color management protocol for instance)

@emersion @serebit would you have objection to those being merged into Mesa?

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

@emersion if Gamescope applied to be a member, do you believe it would be NACK'ed? (genuine question)

@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

From an outsider's perspective watching some of those protocols being proposed and discussed - it seems like the biggest problem is how easy it is to stall all the work.

It feels like there's a pattern of "sharing concerns" that the original author doesn't agree with, often by a non-member. This acts almost as a NACK without being an official one. It's hard to move past that point as "someone is unhappy". Especially when most of the members don't really have an option and don't push for inclusion of those protocols.

FWIW I really appreciate that folks been actively reminding people that they don't have NACK powers and they should stop acting as such, but that doesn't fully solve the problem.

Looking at the governance document:

1.1.2 Members represent general-purpose projects with a stake in multiple Wayland protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose applications with a stake in only one or two.

This makes it sound like a lot of projects don't qualify. I would assume that gamescope is too narrow to be included. Mesa as well. If that's not the case rewording it would be great.

I would love to see some gaming / 3D representation with the likes of mesa, gamescope, and maybe, in a distant future, winewayland.drv.

With that it would be possible to get some of the game- / presentation-oriented protocols into ext- quicker as you have more invested parties.

1.2.1 New members who meet the criteria outlined in 1.1 are established by invitation from an existing member. Projects hoping to join should reach out to an existing member asking for this invitation.

Maybe inviting projects in a more proactive way would help with the outsider vs insider issue? If you see people working on protocols for a known project extending an invitation would be nice.

@ivyl @emersion I think that first requirement, as stated, would apply to any compositor (or GUI toolkit), which pretty fundamentally has an interest in more than a couple protocols. At least.

I guess it does exclude things like input method engines and accessibility tools, which may be only interested in a protocol or two. (Getting those kinds of projects more involved in Wayland and getting the necessary protocols right and implemented is another major issue with Wayland currently.)

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

@serebit @frog And packaged on Solus now as well: https://github.com/getsolus/packages/tree/main/packages/f/frog-protocols

@frog@idtech.space i like frogs 🐸