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
