surface-suspension wayland protcool development status?
Hey all, Is there a reason why the development of the surface-suspension protocol[1] has completely stalled out? It's been in the 30 day discussion period for a few months now and it's a pretty critical protocol for games (it's the main blocker for SDL to switch to Wayland by default[2]). >From a purely downstream perspective, I'd like to have Fedora Linux switch to Wayland by default for SDL-based applications (which we are able to do relatively quickly and easily since all SDL applications now use SDL2 since Fedora Linux 35[3]). Thanks in advance and best regards, Neal [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99 [2]: https://github.com/libsdl-org/SDL/pull/4306#issuecomment-963513540 [3]: https://fedoraproject.org/wiki/Changes/SDL12onSDL2 -- 真実はいつも一つ！/ Always, there's only one truth!
Re: surface-suspension wayland protcool development status?
On Thu, Nov 11, 2021 at 5:56 PM Emmanuel Gil Peyrot wrote: > > On Thu, Nov 11, 2021 at 10:00:33AM -0500, Neal Gompa wrote: > […] > > >From a purely downstream perspective, I'd like to have Fedora Linux > > switch to Wayland by default for SDL-based applications (which we are > > able to do relatively quickly and easily since all SDL applications > > now use SDL2 since Fedora Linux 35[3]). > > Hi, that’s very nice! > > I wrote a similar library[1] for running applications using the GLFW 2 > API on top of GLFW 3, and thus natively on Wayland, it’s been tested > with Crypt of the Necrodancer so far but should apply to all other > GLFW 2 applications, if you have any in Fedora. > > [1] https://linkmauve.fr/dev/glfw2to3/ Apparently we haven't had GLFW 2 in Fedora since Fedora Linux 15, so it's not an issue right now. But I'll keep it in my back pocket for the future. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Are the stable/staging/unstable protocol distinctions useful?
Hey everyone, There's something I've been ruminating on for a few years now: the state of wayland-protocols. I've noticed that over the course of the existence of wayland-protocols, only three have made it into "stable": presentation-time, viewporter, and xdg-shell. But basically no useful Wayland environment relies only on those three protocols, and many protocols have been broadly adopted in staging and unstable. For example: everyone implements relative-pointer (unstable) and almost everyone implements xdg-activation (staging). There are many "unstable" wayland protocols that are so broadly adopted that they basically aren't going to change anymore. A good chunk of the "staging" protocols have no implementers (per wayland.app). So what I'm wondering now is: are the distinctions useful? And if so, how are they useful? If they aren't useful, can we get rid of them? Now, that may seem nuts, but here me out! Every wayland protocol that has been merged is already versioned. Every wayland protocol proposed is supposed to already have at least two implementers (which as noted earlier, a number of existing protocols lack). Between the versioned protocols and the requirement for implementers, I don't see where the distinction helps anything. If anything, I've seen examples of the distinction used as a deterrent by particular compositor implementers despite the obvious need for them. Could we consider getting rid of the distinction? If we need to have structural sorting in the repository, perhaps folders representing the versions instead? Or maybe some other categorization that doesn't imply that something shouldn't be implemented. Thanks in advance and best regards, Neal -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Are the stable/staging/unstable protocol distinctions useful?
On Fri, Jul 7, 2023 at 6:32 AM Pekka Paalanen wrote: > > On Thu, 6 Jul 2023 18:44:16 -0400 > Neal Gompa wrote: > > > Hey everyone, > > > > There's something I've been ruminating on for a few years now: the > > state of wayland-protocols. > > > > I've noticed that over the course of the existence of > > wayland-protocols, only three have made it into "stable": > > presentation-time, viewporter, and xdg-shell. > > > > But basically no useful Wayland environment relies only on those three > > protocols, and many protocols have been broadly adopted in staging and > > unstable. For example: everyone implements relative-pointer (unstable) > > and almost everyone implements xdg-activation (staging). > > > > There are many "unstable" wayland protocols that are so broadly > > adopted that they basically aren't going to change anymore. A good > > chunk of the "staging" protocols have no implementers (per > > wayland.app). > > Right. See e.g. > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/223 > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/221#note_1985498 > > > So what I'm wondering now is: are the distinctions useful? And if so, > > how are they useful? If they aren't useful, can we get rid of them? > > The distinction they make is: > > - unstable/staging are kind of incubating, meaning they have higher > chance to need a new backward-incompatible revision than stable > > - unstable/staging have a higher chance to lose support after being > implemented than stable > > "Higher chance" also implies that suggestions to do so are more > acceptable than in stable. That means that the incentive to bend over > backwards to work around any design warts is much lower. > > The difference between unstable and staging was just the process on how > an extension shall be declared stable. Unstable mandated a final > world-breaking change while staging does not. Today, I think both are > equal in that we would always use the staging process. > > Our failure here is that there is no clear criteria when an extension > needs to move to stable, so they have mostly been forgotten since stuff > works already. > Maybe consider an automatic promotion process instead? There's no harm in promoting standards that aren't changing. Ultimately, even "unstable" protocols don't get incompatibly changed without a version bump, so I don't really feel like the current classification model is meaningful. Promoting after two wayland-protocols releases of no significant changes would hopefully be a decent indicator of "stability". > > Now, that may seem nuts, but here me out! Every wayland protocol that > > has been merged is already versioned. Every wayland protocol proposed > > is supposed to already have at least two implementers (which as noted > > earlier, a number of existing protocols lack). > > > > Between the versioned protocols and the requirement for implementers, > > I don't see where the distinction helps anything. If anything, I've > > seen examples of the distinction used as a deterrent by particular > > compositor implementers despite the obvious need for them. > > > > Could we consider getting rid of the distinction? If we need to have > > structural sorting in the repository, perhaps folders representing the > > versions instead? Or maybe some other categorization that doesn't > > imply that something shouldn't be implemented. > > A good question. If staging prevents an extension from seeing interest, > it will never prove the design either. > > OTOH, I suspect a concern was that people would jump to implementing > something assuming it's final, and when upstream decides it doesn't > work right and needs a breaking change, people could be upset. > > There are few extensions that probably shouldn't be newly implemented > by anyone. Fullscreen-shell comes to mind. > > Nothing can be deleted, because it would break builds, so the > directories will live on anyway, but it would be possible to realize > the old directory structure at install time, like Sebastian recently > suggested. > But we could stem the bleeding and do an artificial version bump to eliminate the unneeded labels, couldn't we? The number of protocol implementers are small enough right now that it is potentially possible to fix this, though arguably it should have been fixed long ago... > I suppose a much more useful distinction than staging/stable would be > a database indicating which software implements what
Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients
On Wed, Nov 29, 2023 at 5:27 AM Olivier Fourdan wrote: > > Hi all, > > In Fedora and Red Hat Enterprise Linux, we ship a small shell script called > "xvfb-run" originating from Debian to launch an X11 client within Xvfb. > > With the future removal of Xorg and all related Xservers in RHEL [1], except > Xwayland, there was a need for a replacement utility that would work like > xvfb-run, but without Xvfb :) > > The idea is to run Xwayland rootful within a Wayland compositor headless as a > replacement for Xvfb. The problem though is that I didn't want to be tight to > a specific Wayland compositor and of course every Wayland compositor uses > different options to run headless. > > At the same time, I was also working on improving Xwayland rootful support > ([2], and identified the need for a convenient utility to run an X11 client > within its own Xwayland rootful instance (useful to run a legacy game for > example. as with [3]). > > So, long story short, what started as a replacement utility for xvfb-run > ended as 3 different (yet related) utilities: > > * xwayland-run, to spawn an X11 client within its own dedicated Xwayland > rootful instance, > * wlheadless-run to run a Wayland client on a set of supported Wayland > headless compositors, > * xwfb-run, a combination of the two other tools above to be used as a > direct replacement for xvfb-run specifically. > > Right now, it supports 4 different Wayland compositors (weston, cage, mutter, > gnome-kiosk) but adding more should just be a matter of adding a relevant > module. > > So my question is, if there is any interest for such a project [4], should > this be moved to the wayland namespace in gitlab (we could even change the > name of the project), should that be added to the existing "wayland-utility" > project that we have already, or if there's no interest it's fine to stay in > my own gitlab namespace for now? > Thank you for writing this, this is great! I would love to see this in the wayland namespace somehow. As an aside, it would be nice to see a collection of nice wayland utilities to be in the wayland fdo gitlab namespace to make it easier to discover. For example, as part of the discussion around Wayland-only Plasma, I was surprised that people didn't know about things like waypipe[1], which has existed for a long time. And another recent creation, waycheck[2], is not easily discoverable either. [1]: https://gitlab.freedesktop.org/mstoeckl/waypipe [2]: https://gitlab.freedesktop.org/serebit/waycheck -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Right mailing list for mutter/gnome-remote-desktop question?
On Wed, Jan 17, 2024 at 12:17 PM Matt Hoosier wrote: > > Hi, > > Does anybody know whether there’s a dedicated mailing list suitable for > asking questions about the hardware acceleration in the remote desktop > use-case for those two? > > I did a quick look through both repos’ README and CONTRIBUTING files, but > didn’t find anything. The GNOME project no longer maintains mailing lists. You will need to ask on their Discourse instance: https://discourse.gnome.org/ Good luck. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Proposal: no more alphas/betas for Wayland releases
On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote: > > Hi all, > > With years passing by, development in the main Wayland repository has > slowed down quite a bit, activity has moved over to wayland-protocols > and compositors. However, cutting a new Wayland release is still a > heavyweight process: it takes at least one and a half months with at > least 3 pre-releases. I'm also not sure about the value of all of these > pre-releases: historically they've been used to push the last features > over the fence before the RCs, but it's easy enough to talk and > coordinate over the bits that we want to wait on for the release. > > I would suggest to drop the alphas/betas from the release process, ie. > go straight to RC1. The process would then continue as usual, with > weekly RCs. As a release manager this would help reduce the load. This > is also what I've been doing for Sway and wlroots for a very long time. > > Would this make sense? Are there other reasons why alphas/betas were > valuable? > Funnily enough, I think wlroots should probably have them since wlroots releases are so highly disruptive for basically every consumer... That said, going straight to RCs for libwayland itself seems reasonable. But, do we even need those? Could we go straight to release since the churn is so low? -- 真実はいつも一つ！/ Always, there's only one truth!
