wayland: Bump required client version to 1.20 or newer #5429

flibitijibibo · 2022-03-21T05:06:14Z

This weeds out the older systems that have Wayland available, but don't have the required bits and pieces necessary to run the driver well. It roughly translates to...

Ubuntu 22.04 or newer
Debian 12 or newer (or Sid)
Fedora 34 or newer
Reasonably updated Arch, OpenSUSE Tumbleweed, etc.

This conveniently lines up perfectly with the exact list of distributions that have libdecor available, which is a hard requirement for GNOME setups.

Tested on Fedora with both autoconf and CMake; I happened to be on client version 1.19 and latest repo had 1.20 so I was able to test the full matrix. To stress-test the build requirement on older systems I also tested on CentOS 7 with libwayland 1.20 self-built.

Fixes #5416

Conan-Kudo · 2022-03-21T05:24:00Z

This should be in place for CentOS Stream 9 (and eventually RHEL 9.1): https://gitlab.com/redhat/centos-stream/rpms/wayland/-/merge_requests/3

cc: @wtay @nwnk

cgutman · 2022-03-21T05:42:33Z

Hmm, I'm not sure about going all the way up to 1.20.

That leaves out all stable versions of Debian (which has defaulted to Wayland since Debian 10) and there won't be a new stable release for quite a while. I also wonder whether it's a good idea to leave out Ubuntu 20.04, which is the base for many (most?) Snaps currently.

It might actually end up hurting our goal of more native Wayland application support, since these cases would actually regress from native Wayland in SDL 2.0.20 to using XWayland when updated to 2.0.22.

flibitijibibo · 2022-03-21T05:46:23Z

We could possibly roll back to 1.18 but only if distributions start packaging libdecor - right now the list is pretty sad and the more involved autodetection involves doing a lot of stuff that's in Wayland_InitVideo (and should probably stay there, unless we can do a global registry poll that's completely separate, but even that is still doing up to three full roundtrips just to get to the starting line).

flibitijibibo · 2022-03-21T06:05:43Z

Double checked... a brief list of high-profile distributions that have 1.18 but not libdecor:

Ubuntu 20.04
Debian 11
RHEL 8 (RIP CentOS)

Basically a lot of the LTS systems. Ubuntu 20.04 doesn't default to Wayland so that just leaves Debian/RHEL. Would be interested to know where Flatpak fits into that, similar to Snap.

Conan-Kudo · 2022-03-21T06:08:10Z

RHEL 8 (RIP CentOS)

I think it might be possible to get libdecor backported to RHEL 8. At least from what I can tell, it should build just fine there. @wtay, @jadahl, what do you think?

sezero · 2022-03-21T09:42:00Z

Fixes #5416 Fixes #5376 Fixes #4636

I usually don't like requirement bumps like this, but I'm happy with this
one with relation to the bug entries listed above.

slouken · 2022-03-21T17:04:39Z

I agree, I'd rather bump requirements in this case. Would it be possible to add a hint if someone really wants to try an earlier wayland?

slouken · 2022-03-21T17:05:17Z

Rather, default to X11 on earlier wayland, but allow the video driver environment variable to override this?

flibitijibibo · 2022-03-21T17:06:58Z

I think so - let me mess with the defines a bit.

By default we require 1.20, but if you force SDL_VIDEODRIVER we'll let you get away with 1.18. Hypothetically we could lower the default to 1.18 overall, but we found that distributions using 1.18 did not package libdecor, and without that the user experience is incomplete.

flibitijibibo · 2022-03-21T17:24:08Z

Pushed the override. The requirement is 1.18 but still falls back if 1.20 isn't there. This is more flexible, but unfortunately removes the fix for 2 of the 3 issues.

sezero · 2022-03-21T17:59:22Z

Ugh...

slouken · 2022-03-21T19:00:01Z

What are the two bugs that are fixed by Wayland 1.20?

sezero · 2022-03-21T22:51:52Z

What are the two bugs that are fixed by Wayland 1.20?

#5376 and #4636

smcv · 2022-03-22T20:17:26Z

I think defaulting to Wayland on newer systems and X11 on older systems is preferable to making users of slightly older LTS distributions disable Wayland completely, particularly since Debian 11 and Ubuntu 20.04 both have Wayland 1.18.

I'm fairly sure I can fix #5376 if there's interest: I applied a patch for this in Debian (at the time I thought it was a temporary workaround for Debian's Wayland maintainer not having packaged 1.20 yet, so I didn't upstream it). Bumping the requirement to 1.18 and applying that patch would probably also resolve #4636. Alternatively, people building SDL for older distributions could probably avoid those issues with --enable-wayland-shared (I don't do that in the official Debian packages because distro packaging benefits from more rigid dependencies that can prevent broken "half-upgraded" situations, but dynamically loading dependencies seems more forgiving for local or relocatable builds).

libdecor is not going to be added to Debian 11 (at the time Debian 11 was released, libdecor had never had a release), but I can add it to the optional bullseye-backports repository if that helps.

flibitijibibo · 2022-03-22T20:21:05Z

bullseye-backports would be enough, I think - people using Wayland on Bullseye will probably figure out what's going on pretty quickly. If that ends up going downstream to Ubuntu 20.04 that would wrap up the libdecor issue for me.

smcv · 2022-03-22T20:22:13Z

src/video/wayland/SDL_waylanddyn.c

@@ -150,8 +151,20 @@ SDL_WAYLAND_LoadSymbols(void)
 #include "SDL_waylandsym.h"

        if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT) {
-            /* all required symbols loaded. */
-            SDL_ClearError();
+            if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20) {


If you consider libdecor to be very important, then perhaps

Suggested change

if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20) {

if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20 && SDL_WAYLAND_HAVE_WAYLAND_LIBDECOR) {

or more directly

Suggested change

if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20) {

if (SDL_WAYLAND_HAVE_WAYLAND_LIBDECOR) {

so that the default is Wayland if libdecor is available, or X11 otherwise?

I'm hesitant - hypothetically a user running on sway or Plasma wouldn't need libdecor at all, so 1.18 + xdg-decoration qualifies as well.

Hmm, yes. Maybe SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20 || SDL_WAYLAND_HAVE_WAYLAND_LIBDECOR then?

Note that #5436 will make SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20 not exist in some build configurations (--disable-wayland-shared + older Wayland at build-time), so this and/or #5436 will likely need some adjustment.

Note that #5436 will make SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20 not exist in some build configurations (--disable-wayland-shared + older Wayland at build-time), so this and/or #5436 will likely need some adjustment.

Actually, no, that shouldn't be a problem, because this part is #ifdef SDL_VIDEO_DRIVER_WAYLAND_DYNAMIC anyway.

smcv · 2022-03-22T20:27:48Z

Regarding libdecor, it seems to me that it's important for windowed games (and non-game applications), but non-essential for fullscreen games? Is that correct?

I don't think it necessarily makes sense to make the default depend on libwayland 1.20 if you're only using libwayland 1.20 as a proxy for "has libdecor, a version of GNOME/KDE with a competent Wayland compositor, and so on".

bullseye-backports would be enough, I think - people using Wayland on Bullseye will probably figure out what's going on pretty quickly.

OK, I'll add this to my pile of things to backport. I already know from my Steam Runtime work that it backports easily, and it's not exactly fast-moving.

As a newly-backported package, expect this to take a few days or weeks for one of the people who run -backports to get round to pressing the accept button.

If that ends up going downstream to Ubuntu 20.04 that would wrap up the libdecor issue for me.

Ubuntu generally doesn't backport things unless they're considered strategically important by someone inside Ubuntu, as far as I can tell: libseccomp gets updated (for everyone, not just people who have opted-in to backports), but the focal-backports repository is basically unused, and in particular things like Flatpak don't get official backports.

However, Ubuntu 22.04 LTS is due in about 1 month, at which point 20.04 becomes a lot less interesting.

Conan-Kudo · 2022-03-23T11:47:39Z

I'm not sure we're going to get wayland-1.20 in RHEL 9 at this time because of this issue (which is not resolved for GNOME yet): https://gitlab.freedesktop.org/xorg/xserver/-/issues/1283

flibitijibibo · 2022-03-23T17:16:24Z

Going to close this for now... there's a big mess we have to clean up regarding the difference between 1.18 and 1.20, but there's definitely a consensus that 1.18 should be the minimum version in place, so I'll just integrate the bare minimum to enforce that. The rest I think will take care of itself via #5436 (or at least a variant of it).

This was referenced Mar 21, 2022

no window with wayland on an old wayland client #5416

Closed

wayland: Fall back to X on old wl_shell-only systems #5423

Closed

flibitijibibo self-assigned this Mar 21, 2022

flibitijibibo force-pushed the wl-120 branch from e21e2ec to 546175c Compare March 21, 2022 17:22

flibitijibibo force-pushed the wl-120 branch from 546175c to 60de61f Compare March 21, 2022 17:22

smcv reviewed Mar 22, 2022

View reviewed changes

smcv mentioned this pull request Mar 22, 2022

Avoid depending on libwayland 1.20 unnecessarily #5436

Merged

flibitijibibo closed this Mar 23, 2022

flibitijibibo deleted the wl-120 branch March 25, 2022 06:54

bdach mentioned this pull request May 15, 2022

SDL Wayland backend no longer working since 2022.515.0 ppy/osu#18273

Closed

rugk mentioned this pull request May 16, 2022

Replace --socket=x11 permission with --socket=fallback-x11 flathub/sh.ppy.osu#36

Closed

	if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20) {
	if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20 && SDL_WAYLAND_HAVE_WAYLAND_LIBDECOR) {

	if (SDL_WAYLAND_HAVE_WAYLAND_CLIENT_1_20) {
	if (SDL_WAYLAND_HAVE_WAYLAND_LIBDECOR) {

wayland: Bump required client version to 1.20 or newer #5429

wayland: Bump required client version to 1.20 or newer #5429

Uh oh!

Conversation

flibitijibibo commented Mar 21, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Conan-Kudo commented Mar 21, 2022

Uh oh!

cgutman commented Mar 21, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

flibitijibibo commented Mar 21, 2022

Uh oh!

flibitijibibo commented Mar 21, 2022

Uh oh!

Conan-Kudo commented Mar 21, 2022

Uh oh!

sezero commented Mar 21, 2022

Uh oh!

slouken commented Mar 21, 2022

Uh oh!

slouken commented Mar 21, 2022

Uh oh!

flibitijibibo commented Mar 21, 2022

Uh oh!

flibitijibibo commented Mar 21, 2022

Uh oh!

sezero commented Mar 21, 2022

Uh oh!

slouken commented Mar 21, 2022

Uh oh!

sezero commented Mar 21, 2022

Uh oh!

smcv commented Mar 22, 2022

Uh oh!

flibitijibibo commented Mar 22, 2022

Uh oh!

smcv Mar 22, 2022

Choose a reason for hiding this comment

Uh oh!

flibitijibibo Mar 22, 2022

Choose a reason for hiding this comment

Uh oh!

smcv Mar 22, 2022

Choose a reason for hiding this comment

Uh oh!

smcv Mar 22, 2022

Choose a reason for hiding this comment

Uh oh!

smcv Mar 23, 2022

Choose a reason for hiding this comment

Uh oh!

smcv commented Mar 22, 2022

Uh oh!

Conan-Kudo commented Mar 23, 2022

Uh oh!

flibitijibibo commented Mar 23, 2022

Uh oh!

Uh oh!

flibitijibibo commented Mar 21, 2022 •

edited

Loading

cgutman commented Mar 21, 2022 •

edited

Loading