Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0
Hi!
On Sun, 2021-03-21 at 14:03:32 +0100, Stephen Kitt wrote:
> Control: retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0
> Control: owner -1 !
>
> On Sun, 21 Mar 2021 11:17:32 +0000, Simon McVittie <smcv@debian.org> wrote:
> > On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> > > I've recently retried switching to Wayland and I think I'm sticking
> > > with it. But while checking for toolkits support, noticed that SDL 1.2
> > > does not have native Wayland support, but SDL 2.0 does.
> >
> > Note that SDL 2.0 currently defaults to using X11 if available, and will
> > currently only use Wayland if X11 is unavailable, so in environments where
> > Xwayland is either always run (such as GNOME 3.38) or started automatically
> > on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
> > I think typical desktop environments like GNOME and KDE Plasma are
> > likely to want Xwayland available by default for quite a long time,
> > even if it's only started on-demand.
Sure, in my case sway, but all the same. My goal is to be able to
disable Xwayland completely though. :)
> > You can override this with with environment variable
> > SDL_VIDEODRIVER=wayland.
Yes, the problem though is that this cannot be set unconditionally in
one's environment, as any SDL-1 program will then fail to start
completely (some might even segfault if they are not checking the SDL
initialization function return codes, as I found out with hex-a-hop,
which should now be fixed upstream :).
> Right, I’ll make sure to document this in the package.
Please, document that setting this unconditionally is currently not a
good idea.
> > On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> > > As seen in [1] regarding the headers, sdl12-compat isn't a full
> > > replacement yet.
> > >
> > > It could work for pure binary-compatibility but you can't build anything
> > > against it yet so it should be a Provide+Replace rather than something
> > > like a newer version.
> > >
> > > 1: https://github.com/libsdl-org/sdl12-compat/issues/34
> >
> > Yes, I'd come to that conclusion too.
>
> Yup, for the time being it’s really only a runtime replacement, it’s not
> ready as a build-time SDL2 shim for SDL1.2 projects.
Right, sorry should have made this more clear in the RFP.
There was also <https://github.com/MrAlert/sdlcl>, which seems might
have been more complete, but given that it does not seem to be active
anymore and not maintained by upstream SDL, it was not worth pursuing.
Thanks,
Guillem
Reply to: