Bug#981722: libsdl2-2.0-0: KMSDRM backend segfaults on Etnaviv

[Simon McVittie]

On Wed, 03 Feb 2021 at 22:17:00 +1100, Matthew Harm Bekkema wrote:
> On 2/3/21 8:40 PM, Simon McVittie wrote:
> > With which backend? I didn't think we had KMSDRM enabled until August 2020?
> > (Unfortunately I can't find the bug report or merge request that asked for
> > it to be enabled.)
> 
> I asked for libdrm-dev to be added to the build deps in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971529 in order to
> consistently build with KMSDRM enabled. It's possible that buster has KMSDRM
> enabled if the build machine had libdrm-dev installed by chance.

The build logs on the three ARM architectures for the version that ended
up in buster
https://buildd.debian.org/status/fetch.php?pkg=libsdl2&arch=armel&ver=2.0.9%2Bdfsg1-1&stamp=1549131519&raw=0,
https://buildd.debian.org/status/fetch.php?pkg=libsdl2&arch=armhf&ver=2.0.9%2Bdfsg1-1&stamp=1549165828&raw=0,
https://buildd.debian.org/status/fetch.php?pkg=libsdl2&arch=arm64&ver=2.0.9%2Bdfsg1-1&stamp=1549127008&raw=0
all say "Video drivers   : dummy x11 opengl opengl_es2 vulkan wayland"
(no mention of kmsdrm.

Guido, when you say the buster version works, do you mean the buster
binaries work; or do you mean the buster source code, when recompiled
with the KMSDRM backend enabled, works?

On Tue, 09 Feb 2021 at 11:56:05 +0100, Guido Günther wrote:
> On Wed, Feb 03, 2021 at 09:40:20AM +0000, Simon McVittie wrote:
> > If you can prepare a tested patch, I'd consider it
> 
> It's isolated but pretty invasive:
> 
> https://source.puri.sm/guido.gunther/libsdl2/-/tree/kmsdrm/debian/patches/backport
> 
> I'll test that for a couple of days but I'm not sure this qualifies for
> bullseye?

If you would like me to consider applying this in Debian, please open a
merge request in https://salsa.debian.org/sdl-team/libsdl2, or otherwise
send a tested patch that encapsulates exactly the state you want to
achieve.

As I said, I'll consider patches. However, I have enough in my queue
that I can't go looking for Debian derivatives' patches and classifying
them into parts we should and shouldn't apply in Debian - partly out of
time/availability, and partly because if I try to second-guess what a
Debian derivative is doing, I expect that I'll choose the wrong subset
of patches and ship a version that does not make anyone happy.

Sorry, I'm not using KSMDRM myself (and I'm not clear on whether/how
it can be tested on the mostly x86 hardware I have), so I'm completely
reliant on people who do use it for information and testing. I can't speak
for libsdl2's other maintainers but I suspect they would say the same.

I think the options are:

* Disable the KMSDRM backend to avoid fooling people into thinking it's
  well-supported in the current package, and have another try for Debian 12

* Patch the KMSDRM backend into some different state, either going forward
  to what's in SDL git or rolling back to what was in 2.0.12; if you
  want this to happen for bullseye, it's not necessarily too late,
  but it should happen *now* if we are going to consider it, and preparing
  a suitable patch would need to be done by someone who is genuinely using
  this backend (i.e. not me)

* Leave it as-is; if it works for some people, it works, and if it doesn't
  work for other people, that's no worse than disabling it

Which of those is best for you?

If we don't do something about this now, then the last option wins by
default; so if you consider that to be the worst option, now is the time
to make something else happen.

Thanks,
    smcv