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

Sep 24, 2024 at 6:22amWeb
Show threadPekka PaalanenSep 24, 2024
@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.
Show threadPekka PaalanenSep 24, 2024
@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.
Show threadPekka PaalanenSep 24, 2024
@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.
Show threadPekka PaalanenSep 24, 2024
@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.
Show threadPekka PaalanenSep 24, 2024

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

Show threadPekka PaalanenSep 24, 2024
@frog @emersion @krh and that blessed ground was not supposed to be a cemetery. :-P
Show threadNeal Gompa (ニール・ゴンパ) Sep 24, 2024

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

Show threadNeal Gompa (ニール・ゴンパ) Sep 24, 2024

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

Show threadNeal Gompa (ニール・ゴンパ) Sep 24, 2024
@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.
Show threadLeandro (Cerberus1746)Sep 24, 2024

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

Show threadWolf480plSep 24, 2024

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

Show threadYuki LinuxSep 25, 2024

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

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 SimmonsSep 24, 2024
@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.