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

[Guido Günther]

Hi Simon,
On Tue, Feb 16, 2021 at 08:58:07AM +0000, Simon McVittie wrote:
> 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?

I rechecked the binary package from buster and it indeed has kmsdrm
disabled on at least arm64. Seems it got triggered on by a downstream
rebuild - so sorry for the false flag.

We have since then moved to 2.0.12 and i can say it works there when
enabled. I haven't yet checked if enabling kmsdrm in 2.0.9 works too
but i can do that if it has any additional value.

> 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.

I didn't mean to have you go hunting for downstream patches. I basically
wanted to check if a change this large is even worth
considering. I've moved things into a MR now:

   https://salsa.debian.org/sdl-team/libsdl2/-/merge_requests/11

> 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.

That's totally fair. My main use case currently is osk-sdl. I intend to
add a test mode that would work on x86 too so we could turn that into an
autopkgtest.

> 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

I think that's the best option with the freeze coming forward *and* SDL
2.0.15 having the fixes already *if* it's not in use and working for
others. I don't expect many users on bullseye running e.g. osk-sdl since
things are just coming into place.

> * 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)

Only going forward to 2.0.15 looks sensible here since we can then
cherry-pick fixes in case of problems rather inventing or own.

> * 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

kmsdrm got enable in d0bc7cb108c838e09ec7e14c1076f85ad8765a3a by
Kristof. Kristof is kmsdrm working for you in bullseye?  Which hardware
are you running on?

> Which of those is best for you?

I'd prefer 1. over 3. over 2. if we don't break existing working setups.

Cheers,
 -- Guido

> 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
>