From the repo
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.
Mesa MR to add support for the ‘frog-fifo-v1’ protocol :(https://github.com/misyltoad/frog-protocols)
I like the approach here, but the requirements are a little vague and prone to bikeshedding. Stuff like “could this be used by multiple clients” might mean a protocol is held in limbo whilst it’s given extra scope for example.
It’ll need some strong moderation which might rub people the wrong way, but if this keeps Wayland’s cutting edge moving whilst the official solutions are found, I’m all for it.
Basically the Matrix Spec Change Proposal system, I like it. Opens the floor to more players, gives tool authors a list of protocols they could choose to build on, and hopefully compositors will choose to adopt or adapt one of these protocols before writing their own.
sounds great! I hope this gets some traction, because the official wayland protocols are so dead slow that its not even funny anymore. for example the wayland hdr protocol, open for 4 years now: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
Yay, another set of protocols that will just lead to more and more fragmentation.
You do acknowledge one issue with Wayland, probably the biggest issue with Wayland, but then fail to acknowledge the second biggest issue with Wayland being fragmentation.
Solve one issue by making another issue worse.
Wayland’s approach has always been to make 3rd party protocols easier to opt in and out of. Sway and Hyprland both used custom protocols whilst official solutions were being designed iirc. Nothing stopping anyone from switching from one protocol to another if they implement the same thing down the line.
At least this way, compositors may be able to use something like frog as a shared “experimental branch” which can be enabled for users who need them, but otherwise disabled whilst Wayland core isn’t pressured to work faster.
It’s up to Wayland to make these projects obsolete if it causes them or users a problem.
I can’t help but feel that they like Wayland the way it is, seeing as it’s certainly not changed course
