[BUG] Room Setup crashes on startup on Fedora+Mesa

[rcannood]

Describe the bug
Room Setup crashes immediately on startup on an AMD GPU, so it never writes
chaperone_info.vrchap. Without that file no VR game will launch at all, which makes the
headset unusable rather than just inconvenient.

Digging into it, there turn out to be three separate problems, each only visible once the
previous one is worked around:

1. Room Setup asks vkCreateImage() for a 50x32 2D image with mipLevels = 7. The
   maximum for 50x32 is floor(log2(50)) + 1 = 6, so this violates
   VUID-VkImageCreateInfo-mipLevels-00958.
2. vrclient.so calls vkGetMemoryFdKHR without checking that it resolved. The Unity
   runtime Room Setup is built on never enables the external memory extensions, so
   vkGetDeviceProcAddr() correctly returns NULL, vrclient logs
   Failed to fetch KHR shared memory extension functions! and then calls the pointer
   anyway.
3. The same again for vkWaitSemaphores(). vrclient synchronises with the compositor over
   timeline semaphores, which the Unity runtime does not enable either.

Problem 1 only crashes on distributions that ship Mesa with its assertions enabled --
Fedora does, Arch and Debian do not -- but the image request is out of spec either way.
Problems 2 and 3 look like genuine bugs in vrclient.so, independent of any driver.

To Reproduce

1. On Fedora with an AMD GPU, start SteamVR.
2. Open SteamVR Settings and click Room Setup. Equivalently, run
   ~/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup.sh -popupwindow
3. See that the window never appears and the process dies immediately.

$ ./steamvr_room_setup.sh -popupwindow
...
Trace/breakpoint trap (core dumped)

~/.config/unity3d/Valve/SteamVR Room Setup/Player.log stops right after OpenVR comes up:

Vulkan renderer=[AMD Radeon RX 6900 XT (RADV NAVI21)]
InitializeOrResetSwapChain 1146x648 samples=1
OpenVR initialized!

Expected behavior

Room Setup opens, lets me trace a boundary, and writes
~/.local/share/Steam/config/chaperone_info.vrchap.

System Information:

• Steam client version (build number or date): 1785187029, built 25 July 2026. Branch is
  Stable Client rather than the beta -- the crash is in Room Setup's own Vulkan usage
  rather than anything client-side, but say the word and I will retest on the beta client.
  Steam API version SteamClient023.
• SteamVR version: 2.17.6 (beta)
• Distribution (e.g. Ubuntu): Fedora 44, kernel 7.1.5-201.fc44.x86_64

Also relevant:

• GPU: Radeon RX 6900 XT (Navi21), amdgpu
• Mesa: 26.1.5 (mesa-vulkan-drivers-26.1.5-1.fc44.x86_64), RADV
• Vulkan loader: 1.4.341
• Session: GNOME on Wayland. Direct mode itself is fine -- Mutter grants the DRM lease and
  the headset comes up at 120 Hz.

Screenshots:

Screencast of the crash, and of the same thing working once the workarounds are applied.
A full description of the investigation and the workaround fix is at https://github.com/rcannood/steamvr-room-setup-on-fedora

screencast.mp4

Additional context

Backtrace of the crash in step 3, on Mesa 26.1.5:

#3  Addr::V2::Lib::VerifyMipLevelInfo   ../src/amd/addrlib/src/core/addrlib2.h:864
#5  Addr::V2::Lib::ComputeSurfaceInfo   ../src/amd/addrlib/src/core/addrlib2.cpp:230
#7  gfx9_compute_miptree                ../src/amd/common/ac_surface.c:2257
#11 radv_image_create_layout            ../src/amd/vulkan/radv_image.c:1261
#13 radv_CreateImage                    ../src/amd/vulkan/radv_image.c:1797

The surface parameters, read out of the core dump:

width=50 height=32 numSlices=1 numMipLevels=7 numSamples=1
bpp=32 format=ADDR_FMT_32 swizzleMode=ADDR_SW_4KB_D_X resourceType=ADDR_RSRC_TEX_2D

For problem 2, the Unity player log shows the extensions were never enabled:

[Vulkan init] extensions: name=VK_KHR_external_memory_fd, enabled=0
[Vulkan init] extensions: name=VK_KHR_external_semaphore_fd, enabled=0
[Vulkan init] extensions: name=VK_EXT_external_memory_dma_buf, enabled=0

and the call goes to address 0 regardless:

#7  <signal handler called>
#8  0x0000000000000000 in ??? ()
#9  0x00007f2a34b49709 in ??? () from .../SteamVR/bin/linux64/vrclient.so

For problem 3, disassembling the faulting indirect call gives three arguments ending in a
nanosecond timeout, which is vkWaitSemaphores():

lea    -0x4a0(%rbp),%rsi     ; pWaitInfo
mov    $0x5f5e100,%edx       ; 100000000 ns = 100 ms
call   *%rax                 ; rax == 0

What I think the fixes are:

• Room Setup should not request 7 mip levels for a 50x32 image. A validation layer run
  would flag it.
• Room Setup should enable the extensions vrclient.so needs -- or vrclient.so should
  require them explicitly rather than assuming they are there.
• vrclient.so should NULL-check what vkGetDeviceProcAddr() returns and fail with a
  clear message instead of jumping to 0. This is the one I would prioritise: it turns
  three confusing segfaults into three actionable error messages, and it would protect any
  other old OpenVR title with the same habit. The existing
  Failed to fetch KHR shared memory extension functions! is logged at [Info] level,
  which rather undersells it.

I realise Room Setup is an old Unity build that is presumably awkward to rebuild. If that
is the blocker, the NULL checks in vrclient.so on their own would at least make this
diagnosable rather than a bare segfault.

Workarounds and the full write-up, in case they are useful to anyone hitting this in the
meantime: https://github.com/rcannood/steamvr-room-setup-on-fedora