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

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

Control: tags -1 + pending

Both were applied in the packaging git repo as part of
<https://salsa.debian.org/aviau/dxvk/-/merge_requests/11>.

Thanks,
     smcv

Version: 2.6.2-1
...

Subsequently fixed in experimental.

Thanks,
    smcv