One day, Wayland will truly take over the Linux world, but it's not quite there yet with plenty still using X11 due to various problems some of which the new Frog Protocols aim to solve.
Announced by misyl, who does various work for Valve (like Gamescope), it certainly sounds like a good idea to give Wayland Protocols a swift kick to get into gear to improve things for users. Writing on their social media post:
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.
You can learn more on the GitHub and see the open Mesa Merge Request to hopefully get the frog-fifo-v1 protocol into upstream Mesa drivers.
Looking at the Merge Request, it's explained that SteamOS (Steam Deck) and Gamescope are already "shipping essentially this functionality" since version 3.5 as it's a "serious and genuine problem".
There's already a little bit of push-back from one developer Simon Ser who mentioned:
I don't think adding support for protocols essentially bypassing the wayland-protocols consensus is a good idea. The bar in wayland-protocols is not that high, and adding support for third-party protocols not representative of the Wayland community isn't a good way forward.
Which had a reply from Valve developer Pierre-Loup Griffais to note:
There is value in rapid iteration that the current development model is missing out on. If this would be better as an ext hosted on the upstream wayland-protocols repo, that seems fine to me as well, but I'm not sure that there needs to be a bar at all for an ext protocol other than being available for whoever wants to use it. On the contrary, reducing friction there would provide invaluable experimental feedback to the upstream development effort, and serve users during those long development cycles.
Interesting times, but it's good that something is being done to hopefully kick things up a notch and improve things, especially when it comes to gaming, for the rest of us.
Article taken from GamingOnLinux.com.
fenglengshun about 5 hours ago
-Global hotkey support
-Copy-paste between wayland and xwayland that doesn't break
-Drag and drop between applications is finnicky and not always working
-Window management with positions, geometry etc are lacking features.
Just to name some. Hopefully things get better faster.
And lots of people use Wayland just fine already. It depends on the needs i guess.
Last edited by Xpander on 24 September 2024 at 9:18 am UTC
kaktuspalme about 4 hours ago
Quoting: Xpander-Global hotkey support
-Copy-paste between wayland and xwayland that doesn't break
-Drag and drop between applications is finnicky and not always working
-Window management with positions, geometry etc are lacking features.
I was thinking I'm the only one experiencing those. Especially drag and drop and copy and paste is one of the things not working reliably. Sometimes drag and drop even freezes the application and I have to kill it. It's hard to know wether it's an application specific problem a Wayland protocol implementation problem (I'm using Plasma) or a problem from the protocol itself.
All I know is, those things worked reliably on X11 and they don't work reliably now.
On my gaming system I don't encounter those problems, but while working I encounter them almost on a daily basis.
Due to scaling working way better on Plasma Wayland than Plasma X11 I kind of have to live with these problems.
pleasereadthemanual about 3 hours ago
KDE also maintains its own bespoke protocols and implemented some of the wlr unstable protocols.
I'm not sure how Frog Protocols is any different except in the way it's presented as protocols anyone can implement. In practice wlr protocols can be implemented by other compositors and KDE did implement them.
(from my perspective as a bystander)
Edit: clicking through some of the links, I can see the value in it. Individual compositor protocols are different than protocols intended for adoption in every compositor. The w-p repository really needs a kick in the ass. I can only hope Frog Protocols will provide that.
Or, as Xaver Hugl puts it:
Quoteone of the big reasons in MRs that have an (at least initially) active author is unresolved discussions about often theoretical issues, while at the same time some real world problems get missed. By experimenting in the real world before committing to a "stable" protocol, a lot of those problems can be avoided.
Last edited by pleasereadthemanual on 24 September 2024 at 10:04 am UTC
Patreon
PayPal
See more from me