Package: libdxvk-native-dev Version: 2.6.1-1 Severity: normal Tags: patch upstream fixed-upstream
I added a libsdl3-dev build-dependency to src:dxvk in the hope that this would enable the SDL3 WSI, but my first attempt failed, as we can see in the buildd logs: > Get:329 https://deb.debian.org/debian sid/main arm64 libsdl3-0 arm64 > 3.2.10+ds-1 [835 kB] ... > Get:351 https://deb.debian.org/debian sid/main arm64 libsdl3-dev arm64 > 3.2.10+ds-1 [1473 kB] ... > Run-time dependency sdl3 found: NO (tried pkgconfig and cmake) > Run-time dependency sdl2 found: YES 2.32.54 > Run-time dependency glfw found: NO (tried pkgconfig and cmake) This is because upstream's dependency check for SDL3 was wrong, and only works (as a result of compensating errors) if cmake happens to be installed too. This led to my initial test-builds in the Steam Runtime succeeding, but silently disabling SDL3 because the dependency check for it was broken, resulting in some confusion while trying to test against a SDL3 game supplied by the FNA maintainer. Please consider applying my MR https://salsa.debian.org/aviau/dxvk/-/merge_requests/8 which incorporates an upstream-approved change to fix this. Also please consider the follow-up MR https://salsa.debian.org/aviau/dxvk/-/merge_requests/9 which incorporates and uses an upstream-approved change turning each of the three possible WSIs into a "feature" build option with three possible states (explicitly enabled, FTBFS if not found; explicitly disabled, do not enable; or automagic), to prevent the SDL2 and SDL3 WSIs accidentally getting disabled due to bugs, while also preventing the GLFW WSI from accidentally getting enabled. With those changes included in Steam Runtime 3's backport of DXVK 2.6.1 (which should be included in its next public beta, hopefully in the next few days), I was able to run both SDL2 and SDL3 code using DXVK. Thanks, smcv
