Enable support for wlshell

[phcoder]

Description

Sailfish still uses old wlshell and hasno support for modern xdg-shell. Thispatch allows SDL to work on Sailfish.

Uplifted from github.com:savegame/SDL.git which in turn comes from https://github.com/sailfishos/libsdl/blob/master/rpm/0001-wayland-Bring-back-wl_shell-support.patch

Existing Issue(s)

libSDL shows empty window on SailfishOS

[sezero]

IIRC, wl_shell was dropped between 2.0.14 and 2.0.16. If this gets accepted, should the wayland version requirements, e.g. in cmake scripts, be lowered?

[phcoder]

IIRC, wl_shell was dropped between 2.0.14 and 2.0.16. If this gets accepted, should the wayland version requirements, e.g. in cmake scripts, be lowered?

Not necessarily. Cmake was happy with my mer (Sailfish) SDK: it has wayland 1.21.0. But the problem is that Sailfish has its own compositor that implements wlshell but not xdg-shell

[Kontrabant]

wl_shell has been deprecated for many (10+) years due to being broken, and support was removed from every library and compositor years ago (except from Sailfish apparently). This would be bitrotted going in, and be a completely untested and unsupported code path.

[sezero]

Close, then ?

[phcoder]

Close, then ?

LibSDL is probably the best library for porting to Sailfish. And apparently despite generally the system being updated they are not going to fix wlshell issue. I'm aware of at least quake3 and Doom3 port. Right now official libSDL supplied with Sailfish suffers from touch-cancel bug which makes it unusable if accidentally triggering any gesture. Sailfish is still being sold, so I ask you to accept this patch even if it's marked as "exotic" or "limited support", or even "no support" similar to Linux handheld emu consoles

[flibitijibibo]

I honestly wonder if it would be better to make a completely separate sailfish backend, given that this isn't really a Wayland protocol anymore and is now essentially the OS userspace for Sailfish exclusively. That way it's not ruining the Wayland backend and Sailfish maintainers can still keep their port until the proper standards are supported.

[phcoder]

This would be bitrotted going in, and be a completely untested and unsupported code path.

It's true that it will not receive testing outside Sailfish. However on non-sailfish this code will not even be triggered. And Sailfish tests it after pulling new version of upstream. For me I'll have to apply this patch to ScummVM Sailfish build one way or another and test it when releasing ScummVM for Sailfish. This patch has been unchanged in Sailfish repo for years, si maintenance overhead for upstream is tiny.

[Kontrabant]

I honestly wonder if it would be better to make a completely separate sailfish backend, given that this isn't really a Wayland protocol anymore and is now essentially the OS userspace for Sailfish exclusively. That way it's not ruining the Wayland backend and Sailfish maintainers can still keep their port until the proper standards are supported.

Adding a separate Sailfish target is probably the way to go if upstream support is desired, and would make supporting it in SDL3 feasible as well. It could pull in the core Wayland code where possible, and just provide its own windowing code, or any other legacy bits that might be required, without polluting the core Wayland code with deprecated bits for one niche platform.

[Kontrabant]

Alternatively, Sailfish could also maintain their own patched fork of SDL with whatever legacy support they require, as they seem to do with most other libraries they use: https://github.com/sailfishos/

e: Actually, they already do have their own patched version of SDL: https://github.com/sailfishos/libsdl