2016-09-20 14:02 GMT+02:00 Simon McVittie <s...@debian.org>:
> Package: libsdl2-2.0-0
> Version: 2.0.4+dfsg2-1
> Severity: normal
> Tags: patch
> Games that rely on locking the mouse pointer, such as quake3 and openarena,
> don't work in a Wayland session (for example see
> <https://bugs.debian.org/820304>). There are two main failure modes,
> assuming the usual first-person-shooter control scheme where moving the
> mouse controls yaw (look left/right) and pitch (look up/down):
> A. players cannot turn all the way around, because the pointer stops at the
> edge of the screen
> B. players look straight down and spin uncontrollably, because the
> game's input subsystem thinks it has enabled pointer-locking but
> in fact has not
> ioquake3 currently exhibits symptom A when forcing native Wayland
> (e.g. `SDL_VIDEODRIVER=wayland openarena`) and symptom B when using the X11
> protocol via XWayland (run `openarena` with SDL_VIDEODRIVER unset), both
> under a GNOME Shell Wayland session.
> The attached patch 0003 corrects symptom A when forcing native
> Wayland, by pulling in some patches from SDL hg master which are expected
> to be released in 2.0.5. Fixing the XWayland case will require changes
> to src:xorg-server
> <https://lists.x.org/archives/xorg-devel/2016-September/050975.html>), which
> should be released in about a month, and unfortunately are an ABI break
> (hence difficult to backport); hopefully SDL X11 changes shouldn't be
> needed for that code path.
I asked upstream to release 2.0.5, as I've been doing for a while now,
the delta is too big alreay. They said that they will release soon,
to be included in Debian and also Fedora, let's see.
So I'd prefer to wait until this is done upstream, which hopefully is
soon enough (weeks before the freeze).
> While checking whether the defined(__FREEBSD__) conditionals were right
> (they should probably be defined(__FREEBSD__) || defined(__FreeBSD_kernel__))
> I noticed that the checks for kFreeBSD and Hurd in debian/rules are
> a bit broken. Patches 0001 and 0002 address that.
I will look into this for the next upload, thanks -- or if somebody
else goes ahead, hopefully they'll take them into account.
> I also wonder whether it would be better for SDL2 to default to native
> Wayland/Mir when available, by moving the Wayland/Mir blocks in the
> bootstrap array above the X11 block. The advantage of this would be
> that support isn't constrained by X11 and XWayland (or Mir equivalent)
> and SDL2 can use any protocol supported by both SDL2 and the Wayland/Mir
> compositor; the disadvantage would be that if a developer runs Weston
> inside X11 (a Xephyr-like setup), games and other SDL2 apps would default
> to using Wayland and appearing inside the Weston window, which might be
> unexpected. This change hasn't happened upstream, and I haven't provided
> a patch here either (although it's easy to do); comments on that welcome.
In general I prefer to not have different defaults than upstream,
unless they are proper bugs/problems, otherwise they create special
conditions for Debian and it's a mess for developers and users trying
to debug problems.
In the past, Debian included patches for years that diverged from
upstream (they're still in libsdl1.2 packages, IIRC), and then they
were never merged, so they caused different bugs and weirdness in
different packages compared to other distros or using the upstream
project directly. We've been trying to avoid this in SDLv2.
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>