I have exactly the Same issue on Fedora 42 Any ideas / Solutions yet?
No, I bypassed room setup altogether by doing the room setup in a windows boot and copying the files over, then manually setting room setup as complete in steamvr.vrsettings. It's pretty broken, but I can at least boot into SteamVR proper
Have you had a look what is in those (config-)files?
If there is only some coords one could surely write this without using the software of Valve.
It would be cool to have a workaround for this without the need of installing a windows machine somewhere.
The file is at ~/.local/share/Steam/config/chaperone_info.vrchap. I've successfully~ish set up my Index manually and put together some steps:
cd ~/.local/share/Steam/config/
cp chaperone_info.vrchap chaperone_info.vrchap~
You could edit your existing file directly, but I found it much easier to start from scratch and build up the configuration I needed.
The following file places the center of your play space at the world origin, which should be one of your base stations. It also sets a 1m x 1m x 1m boundary area with one corner at the origin.
Replace your chaperone_info.vrchap with this:
{
"jsonid" : "chaperone_info",
"universes" : [
{
"collision_bounds" : [
[
[ 0, 0, 0 ],
[ 0, 1, 0 ],
[ 0, 1, 1 ],
[ 0, 0, 1 ]
],
[
[ 0, 0, 1 ],
[ 0, 1, 1 ],
[ 1, 1, 1 ],
[ 1, 0, 1 ]
],
[
[ 1, 0, 1 ],
[ 1, 1, 1 ],
[ 1, 1, 0 ],
[ 1, 0, 0 ]
],
[
[ 1, 0, 0 ],
[ 1, 1, 0 ],
[ 0, 1, 0 ],
[ 0, 0, 0 ]
]
],
"play_area" : [ 1, 1 ],
"seated" : {
"translation" : [ 0, 0, 0 ],
"yaw" : 0
},
"standing" : {
"translation" : [ 0, 0, 0 ],
"yaw" : 0
},
"time" : "Sun Apr 13 21:57:00 2025",
"universeID" : "9999999999"
}
],
"version" : 5
}
Start SteamVR and look around the play area. (Not SteamVR Home. If SteamVR Home launched, exit it.) The play area's floor grid should be centered on one of your base stations, possibly over your head. Take note of which one.
Exit SteamVR. Measure the height from the floor to the center of the base station you noted, in meters.
Edit your chaperone_info.vrchap and enter the distance you measured as the Y position in both "translation" fields. Since my test setup has this base station 38cm from the floor, I entered 0.38:
"seated" : {
"translation" : [ 0, 0.38, 0 ],
"yaw" : 0
},
"standing" : {
"translation" : [ 0, 0.38, 0 ],
"yaw" : 0
},
Start SteamVR again. The play area's floor grid should now be at the same height as your physical floor.
Stand upright in the center of your play area, facing forward. Trigger a recenter by holding either system button or pressing the Recenter button in the SteamVR menu bar. If it worked, the floor grid's center should snap to where you're standing, and the triangle should point in the direction you're facing.
Exit SteamVR. Your chaperone_info.vrchap will have been updated; refresh your editor if you don't see the changes.
Your "seated" configuration will now have the new position and orientation, but your "standing" configuration will be unchanged. Here's what mine looked like:
"seated" : {
"translation" : [ 0.536378562, -1.33758354, 1.94879889 ],
"yaw" : 2.84820986
},
"standing" : {
"translation" : [ 0, 0.38, 0 ],
"yaw" : 0
},
If your setup works like mine, there's a couple problems with this:
"standing" configuration is the one that's actually loaded. If you start SteamVR again your changes won't be remembered.Copy all the values except the height from "seated" to "standing":
"seated" : {
"translation" : [ 0.536378562, -1.33758354, 1.94879889 ],
"yaw" : 2.84820986
},
"standing" : {
"translation" : [ 0.536378562, 0.38, 1.94879889 ],
"yaw" : 2.84820986
},
(You may also want to copy your measured height back to "seated". I haven't seen this have any effect but it may be important for some room setups.)
The "collision_bounds" array contains a series of 3D quads which describe the boundaries of your play space. Each corner of each quad is an array of 3 numbers [ x, y, z ] in meters. y is the vertical component, but I don't think it makes a difference what you set it to. My template file sets the walls to 1 meter high but the boundary visualization is much taller.
Type in the coordinates of your collision bounds. You're on your own for this one. It'll probably take a lot of approximate measurement and trial-and-error, but I don't use collision bounds and can't give any useful tips.
To skip this step and use your play space without collision bounds, enter "collision_bounds" : [].
However, triggering a recenter with empty bounds replaces the [] with null, which SteamVR fails to read properly on subsequent starts. If your config isn't being read and the origin is stuck to one of your base stations, make sure you don't have "collision_bounds" : null.
I've also run into this issue but sadly SteamVR would refuse to load any manually created chaperone_info.vrchap
My fix ended up being going to SteamVR settings->developer->Quick calibration.
You can pick any room size here, I chose medium.
This generates a chaperone_info.vrchap file and sets the room setup flag to completed.
From there I did step 4 of the above post to get my room size correct.
Having the same issue on Debian 12. Running steamvr_room_setup.sh manually I can see it open a window, which eventually segfaults:
steamvr_room_setup.sh[7279]: Relaunch under scout LDLP runtime.
steamvr_room_setup.sh[7279]: exec /home/dreamer/.steam/bin/steam-runtime/run.sh ./tools/steamvr_room_setup/linux64/steamvr_room_setup.sh
steamvr_room_setup.sh[7279]: Detected scout LDLP runtime.
steamvr_room_setup.sh[7279]: Relaunch under vrenv
steamvr_room_setup.sh[7279]: exec /home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/../../../bin/vrenv.sh /home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup.sh
vrenv.sh[7279]: VRCOMPOSITOR_LD_LIBRARY_PATH=/home/dreamer/.steam/steam/steamapps/common/SteamVR:/home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/qt/lib:/home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64:/home/dreamer/.steam/bin/steam-runtime/pinned_libs_32:/home/dreamer/.steam/bin/steam-runtime/pinned_libs_64:/lib/aarch64-linux-gnu:/usr/local/cuda-10.1/targets/x86_64-linux/lib:/usr/lib/x86_64-linux-gnu/fakechroot:/usr/lib/x86_64-linux-gnu/libfakeroot:/lib/i386-linux-gnu:/usr/local/lib:/home/dreamer/Downloads/huygens-fokker-scales/scala-22-pc64-linux:/usr/local/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu:/lib32:/libx32:/lib:/lib/i386-linux-gnu/i686:/lib/i386-linux-gnu/sse2:/lib/i386-linux-gnu/i686/sse2:/home/dreamer/.steam/bin/steam-runtime/lib/i386-linux-gnu:/home/dreamer/.steam/bin/steam-runtime/usr/lib/i386-linux-gnu:/home/dreamer/.steam/bin/steam-runtime/lib/x86_64-linux-gnu:/home/dreamer/.steam/bin/steam-runtime/usr/lib/x86_64-linux-gnu:/home/dreamer/.steam/bin/steam-runtime/lib:/home/dreamer/.steam/bin/steam-runtime/usr/lib
vrenv.sh[7279]: exec /home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup.sh
steamvr_room_setup.sh[7279]: Detected scout LDLP runtime.
steamvr_room_setup.sh[7279]: exec /home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup
Found path: /home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup
Mono path[0] = '/home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Managed'
Mono path[1] = '/home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono'
Mono config path = '/home/dreamer/.steam/steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/etc'
Preloaded 'ScreenSelector.so'
Preloaded 'libopenvr_api.so'
Segmentation fault
Using steam beta version 1761786974.
Steamvr beta 2.13.6
Even though we don't have any debug symbols, tried running the room setup through gdb:
(gdb) run
Starting program: /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff62156c0 (LWP 255449)]
Found path: /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup
Mono path[0] = '/home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Managed'
Mono path[1] = '/home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono'
Mono config path = '/home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/etc'
[New Thread 0x7ffff541f6c0 (LWP 255454)]
[New Thread 0x7fffee4166c0 (LWP 255455)]
Preloaded 'ScreenSelector.so'
Preloaded 'libopenvr_api.so'
[New Thread 0x7fffecdff6c0 (LWP 255456)]
[New Thread 0x7fffd61ff6c0 (LWP 255457)]
[New Thread 0x7fffd59fe6c0 (LWP 255458)]
[New Thread 0x7fffd51fd6c0 (LWP 255459)]
[New Thread 0x7fffd49fc6c0 (LWP 255460)]
[New Thread 0x7fffc77ff6c0 (LWP 255461)]
[New Thread 0x7fffc6ffe6c0 (LWP 255462)]
[New Thread 0x7fffc67fd6c0 (LWP 255463)]
[New Thread 0x7fffc5ffc6c0 (LWP 255464)]
[New Thread 0x7fffc57fb6c0 (LWP 255465)]
[New Thread 0x7fffc4ffa6c0 (LWP 255466)]
[New Thread 0x7fffabfff6c0 (LWP 255467)]
[New Thread 0x7fffab7fe6c0 (LWP 255468)]
[New Thread 0x7fffaaffd6c0 (LWP 255469)]
[New Thread 0x7fffaa7fc6c0 (LWP 255470)]
[New Thread 0x7fffa9ffb6c0 (LWP 255471)]
[New Thread 0x7fffa97fa6c0 (LWP 255472)]
[New Thread 0x7fffa8ff96c0 (LWP 255473)]
[New Thread 0x7fff83fff6c0 (LWP 255474)]
[New Thread 0x7fff837fe6c0 (LWP 255475)]
[New Thread 0x7fff7bfff6c0 (LWP 255476)]
[New Thread 0x7fff82ffd6c0 (LWP 255477)]
[New Thread 0x7fff827fc6c0 (LWP 255478)]
[New Thread 0x7fff81ffb6c0 (LWP 255479)]
[New Thread 0x7fff817fa6c0 (LWP 255480)]
[New Thread 0x7fff80ff96c0 (LWP 255481)]
[New Thread 0x7fff7b7fe6c0 (LWP 255482)]
[New Thread 0x7fff7affd6c0 (LWP 255483)]
[New Thread 0x7fff7a7fc6c0 (LWP 255484)]
[New Thread 0x7fff79ffb6c0 (LWP 255485)]
[New Thread 0x7fff797fa6c0 (LWP 255486)]
[New Thread 0x7fff78ff96c0 (LWP 255487)]
[New Thread 0x7fff4bfff6c0 (LWP 255488)]
[New Thread 0x7fff4b7fe6c0 (LWP 255489)]
[New Thread 0x7fff4affd6c0 (LWP 255490)]
[New Thread 0x7fff4a7fc6c0 (LWP 255491)]
[New Thread 0x7fff49ffb6c0 (LWP 255492)]
[New Thread 0x7fff497fa6c0 (LWP 255493)]
[New Thread 0x7fff48ff96c0 (LWP 255494)]
[New Thread 0x7fff3ffff6c0 (LWP 255495)]
[New Thread 0x7fff3f7fe6c0 (LWP 255496)]
[New Thread 0x7fff3effd6c0 (LWP 255497)]
[New Thread 0x7fff3e7fc6c0 (LWP 255498)]
[New Thread 0x7fff3dffb6c0 (LWP 255499)]
[New Thread 0x7fff3d7fa6c0 (LWP 255500)]
[New Thread 0x7fff3cff96c0 (LWP 255501)]
[Thread 0x7fff3cff96c0 (LWP 255501) exited]
[New Thread 0x7fff3cff96c0 (LWP 255502)]
[New Thread 0x7fffd84ff6c0 (LWP 255503)]
[New Thread 0x7fffd84f26c0 (LWP 255504)]
Thread 4 "steamvr_room_se" received signal SIGPWR, Power fail/restart.
[Switching to Thread 0x7fffee4166c0 (LWP 255455)]
__futex_abstimed_wait_common64 (private=<optimized out>, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7fffef0ad070) at ./nptl/futex-internal.c:57
57 ./nptl/futex-internal.c: No such file or directory.
(gdb) bt
#0 __futex_abstimed_wait_common64 (private=<optimized out>, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7fffef0ad070) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common
(futex_word=futex_word@entry=0x7fffef0ad070, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>, cancel=cancel@entry=true)
at ./nptl/futex-internal.c:87
#2 0x00007ffff7aa3f7b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x7fffef0ad070, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>) at ./nptl/futex-internal.c:139
#3 0x00007ffff7aaecff in do_futex_wait (sem=sem@entry=0x7fffef0ad070, abstime=0x0, clockid=0) at ./nptl/sem_waitcommon.c:111
#4 0x00007ffff7aaed90 in __new_sem_wait_slow64 (sem=0x7fffef0ad070, abstime=0x0, clockid=0) at ./nptl/sem_waitcommon.c:183
#5 0x00007fffeed8c903 in mono_sem_wait ()
at /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/x86_64/libmono.so
#6 0x00007fffeecf6f89 in () at /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/x86_64/libmono.so
#7 0x00007fffeed5ec6c in () at /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/x86_64/libmono.so
#8 0x00007fffeed8481b in () at /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/x86_64/libmono.so
#9 0x00007fffeeda5366 in () at /home/dreamer/.steam/debian-installation/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/x86_64/libmono.so
[#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x00007ffff7aa71f5 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
[#11](/issue/ValveSoftware/SteamVR-for-Linux/11) 0x00007ffff7b278dc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Realizing this ticket is probably a duplicate of https://github.com/ValveSoftware/SteamVR-for-Linux/issues/458
There are so many room setup tickets it's kind of ridiculous.
This is the fix that helped me launch and run it: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/663
Room Setup worked with steam-native back in January of 2025 but it broke somewhere around this summer/June (might be earlier as it happened directly after updating Arch Linux)
Workaround was to run the regular Steam Runtime
I've tracked it down to mesa. Works with 24.3.4, doesn't work with 25.2.6. I might be able to narrow it down further tomorrow.
Hi!
I'm on Nobara (Fedora) also, just took 42->43 update. I haven't been able to use room setup for a while also with my Index.
I'm building my own mesa (32 and 64 bit) and using export script method to run steam (and thusly steamvr) using this method, because of mesa 25.3.0 (43 lowest repo version) breaking VR as reported here and here.
Since I was already changing versions and it only takes a few min to compile and test, I was going to figure out what version this breaks on for bisecting, but when using the mesa version built myself following the linked guide, room setup launches just fine all the way up to 25.3.0 (though the headset doesn't work with 25.3.0).
But if I start steam without the export specifying my built drivers (so using system's 25.3.0) room setup crashes with segfault.
if anyone still following could please try building mesa, and report back if this fixes room setup (or not) + what distro you're using!
Could you try the old and new version by only setting
VK_ICD_FILENAMES=$MESA/share/vulkan/icd.d/radeon_icd.x86_64.json:$MESA/share/vulkan/icd.d/radeon_icd.x86.json
Please also do clean builds of mesa, just to be sure.
If newer mesa does work when compiled "differently", it probably isn't a mesa bug tbh. Might be something along the lines of a glibc incompat or something like that? You could try and find the difference between the build env that produced the non-working new mesa vs. your build env.
Bisecting using Nixpkgs will get us the full picture; will have to do that at some point.
Setting the single envvar works. Room Setup works fine if I use it to start steam.
I'm not sure what you mean by "clean build", if you want to see how they were built it's literally exactly as shown in the guide I linked to, using:
meson setup build32 --cross-file gcc-i686 --libdir lib --prefix $HOME/mesa -Dgallium-drivers=radeonsi,llvmpipe,softpipe,iris,zink -Dvulkan-drivers=intel,amd -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec -Dbuildtype=release
and
meson setup build64 --libdir lib64 --prefix $HOME/mesa -Dgallium-drivers=radeonsi,llvmpipe,softpipe,iris,zink -Dvulkan-drivers=intel,amd -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec -Dbuildtype=release
Also, the plot thickens, as I manually pulled the 25.2.7 rpms from fedora repo directly (https://dl.fedoraproject.org/pub/fedora/linux/updates/43/Everything/x86_64/Packages/) to downgrade the system packages, and the system copies installed this way still cause the segfault in Room Setup.
I'm just looking at this in gdb...
First it hits this assert a couple of times:
│ 862 // Client pass wrong number of MipLevels to addrlib and result will be bad. │
│ 863 // Not sure if we should fail this calling instead of putting an assertion here. │
│ > 864 ADDR_ASSERT(actualMipLevels >= pIn->numMipLevels); │
in
#0 0x00007ffff789caac in __pthread_kill_implementation () from /lib/libc.so.6
#1 0x00007ffff784190e in raise () from /lib/libc.so.6
#2 0x00007fffb66eedc4 in Addr::V2::Lib::VerifyMipLevelInfo (this=0x2849840, pIn=0x7fffaf7fda40) at ../src/amd/addrlib/src/core/addrlib2.h:864
#3 0x00007fffb66ef1f3 in Addr::V2::Lib::ComputeSurfaceInfo (this=0x2849840, pIn=0x7fffaf7fda40, pOut=0x7fffaf7fd580) at ../src/amd/addrlib/src/core/addrlib2.cpp:230
#4 0x00007fffb66e7f5f in Addr2ComputeSurfaceInfo (hLib=0x2849840, pIn=0x7fffaf7fda40, pOut=0x7fffaf7fd580) at ../src/amd/addrlib/src/addrinterface.cpp:1203
#5 0x00007fffb636670c in gfx9_compute_miptree (addrlib=0x283e8e0, info=0x2871480, config=0x7fffaf7fdb20, surf=0x7fffa9341ce0, compressed=false, in=0x7fffaf7fda40) at ../src/amd/common/ac_surface.c:2244
#6 0x00007fffb6368c65 in gfx9_compute_surface (addrlib=0x283e8e0, info=0x2871480, config=0x7fffaf7fdb20, mode=RADEON_SURF_MODE_2D, surf=0x7fffa9341ce0) at ../src/amd/common/ac_surface.c:2864
#7 0x00007fffb636ba90 in ac_compute_surface (addrlib=0x283e8e0, info=0x2871480, config=0x7fffaf7fdb20, mode=RADEON_SURF_MODE_2D, surf=0x7fffa9341ce0) at ../src/amd/common/ac_surface.c:3831
#8 0x00007fffb61b00c7 in radv_surface_init (pdev=0x2870010, surf_info=0x7fffaf7fdb90, surf=0x7fffa9341ce0) at ../src/amd/vulkan/radv_image.c:1128
#9 0x00007fffb61b073f in radv_image_create_layout (device=0x29dd620, create_info=..., mod_info=0x0, profile_list=0x0, image=0x7fffa9341b90) at ../src/amd/vulkan/radv_image.c:1267
[#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x00007fffb61b1799 in radv_image_create (_device=0x29dd620, create_info=0x7fffaf7fdd30, alloc=0x0, pImage=0x7ffec81d7640, is_internal=false) at ../src/amd/vulkan/radv_image.c:1505
[#11](/issue/ValveSoftware/SteamVR-for-Linux/11) 0x00007fffb61b2170 in radv_CreateImage (_device=0x29dd620, pCreateInfo=0x7fffaf7fdda0, pAllocator=0x0, pImage=0x7ffec81d7640) at ../src/amd/vulkan/radv_image.c:1789
[#12](/issue/ValveSoftware/SteamVR-for-Linux/12) 0x00007fffb4b3f989 in vvl::dispatch::Device::CreateImage(VkDevice_T*, VkImageCreateInfo const*, VkAllocationCallbacks const*, VkImage_T**) ()
from /nix/store/w71jnksfjghwf295nfpla8i0spjhmxff-vulkan-validation-layers-1.4.328.0/lib/libVkLayer_khronos_validation.so
[#13](/issue/ValveSoftware/SteamVR-for-Linux/13) 0x00007fffb49ea3fb in vulkan_layer_chassis::CreateImage(VkDevice_T*, VkImageCreateInfo const*, VkAllocationCallbacks const*, VkImage_T**) ()
from /nix/store/w71jnksfjghwf295nfpla8i0spjhmxff-vulkan-validation-layers-1.4.328.0/lib/libVkLayer_khronos_validation.so
[#14](/issue/ValveSoftware/SteamVR-for-Linux/14) 0x00000000012cb39e in ?? ()
That may be harmless, but then it crashes here:
Thread 20 "steamvr_room_se" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffee942a40e in CSharedSemaphoreLinux::ImportVulkanSemaphore(VkDevice_T*, unsigned long) () from /home/david/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#2 0x00007ffee921c527 in CVRCompositorSharedTextures::CreateVulkanCompositorSyncObjects(VkDevice_T*) () from /home/david/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#3 0x00007ffee921f0cd in CVRCompositorSharedTextures::UpdateTextureSet(CVRCompositorSharedTextures::Params const*, VRCompositorState_TextureSet_t*) ()
from /home/david/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#4 0x00007ffee9212ab5 in CVRCompositorClient::SubmitWithArrayIndexAndTime(vr::EVREye, vr::Texture_t const*, unsigned int, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags, unsigned long, int, vr::Texture_t*) ()
from /home/david/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#5 0x00007ffee921329e in CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags) ()
from /home/david/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#6 0x00000000011145ed in ?? ()
#7 0x00000000010f6cc6 in ?? ()
#8 0x00000000012227b6 in ?? ()
#9 0x000000000122b32b in ?? ()
[#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x00000000012206d7 in ?? ()
[#11](/issue/ValveSoftware/SteamVR-for-Linux/11) 0x00000000008d8c78 in ?? ()
[#12](/issue/ValveSoftware/SteamVR-for-Linux/12) 0x00007ffff789a97a in start_thread () from /lib/libc.so.6
[#13](/issue/ValveSoftware/SteamVR-for-Linux/13) 0x00007ffff7922d2c in __clone3 () from /lib/libc.so.6
This is on a debug build of mesa (main)
Also from the room setup log with validation enabled:
Validation Error: [ VUID-VkSemaphoreTypeCreateInfo-timelineSemaphore-03252 ] | MessageID = 0x396b5439
vkCreateSemaphore(): pCreateInfo->semaphoreType is VK_SEMAPHORE_TYPE_TIMELINE, but timelineSemaphore feature was not enabled.
The Vulkan spec states: If the timelineSemaphore feature is not enabled, semaphoreType must not equal VK_SEMAPHORE_TYPE_TIMELINE (https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VUID-VkSemaphoreTypeCreateInfo-timelineSemaphore-03252)
Okay, I managed to get it to stop crashing.
The problem is the VkInstance/Device are being created from steamvr_room_setup (Unity?) with only a few extensions enabled. The handles are then passed to vrclient.so which uses things that require certain other extensions to be enabled, e.g. VK_KHR_external_memory_fd. It calls vkGetDeviceProcAddr(instance, "vkGetMemoryFdKHR"), which returns null, and then crashes trying to call it.
I've tracked it down to mesa. Works with 24.3.4
@Atemu For me it doesn't work even with 24.3.4. I think if it ever worked it must have been because the GetProcAddr checks were more relaxed?
e.g.
/** Return true if the core version or extension in which the given entrypoint
* is defined is enabled.
*
* If device is NULL, all device extensions are considered enabled.
*/
static bool
vk_device_entrypoint_is_enabled(int index, uint32_t core_version,
const struct vk_instance_extension_table *instance,
const struct vk_device_extension_table *device)
[...]
case 173:
/* GetMemoryFdKHR */
if (!device || device->KHR_external_memory_fd) return true;
return false;
As a hack I looked up the extension strings in vrclient.so, and built radv with:
diff --git a/src/vulkan/runtime/vk_device.c b/src/vulkan/runtime/vk_device.c
index 60af69b1faf..a90e188778a 100644
--- a/src/vulkan/runtime/vk_device.c
+++ b/src/vulkan/runtime/vk_device.c
@@ -109,6 +109,18 @@ vk_device_init(struct vk_device *device,
&device->dispatch_table, &vk_common_device_entrypoints, false);
}
+ device->enabled_extensions.KHR_external_memory = true;
+ device->enabled_extensions.KHR_external_semaphore = true;
+ device->enabled_extensions.KHR_timeline_semaphore = true;
+ device->enabled_extensions.KHR_dedicated_allocation = true;
+ device->enabled_extensions.KHR_external_memory_fd = true;
+ device->enabled_extensions.KHR_external_semaphore_fd = true;
+ device->enabled_extensions.KHR_image_format_list = true;
+ device->enabled_extensions.KHR_present_id = true;
+ device->enabled_extensions.KHR_present_wait = true;
+ device->enabled_extensions.KHR_swapchain = true;
+ device->enabled_extensions.KHR_get_memory_requirements2 = true;
+
for (uint32_t i = 0; i < pCreateInfo->enabledExtensionCount; i++) {
int idx;
for (idx = 0; idx < VK_DEVICE_EXTENSION_COUNT; idx++) {
diff --git a/src/vulkan/runtime/vk_instance.c b/src/vulkan/runtime/vk_instance.c
index 186452d16a4..a1458fed129 100644
--- a/src/vulkan/runtime/vk_instance.c
+++ b/src/vulkan/runtime/vk_instance.c
@@ -145,6 +145,12 @@ vk_instance_init(struct vk_instance *instance,
instance->supported_extensions = supported_extensions;
+ instance->enabled_extensions.KHR_surface = true;
+ instance->enabled_extensions.KHR_external_memory_capabilities = true;
+ instance->enabled_extensions.KHR_get_physical_device_properties2 = true;
+ instance->enabled_extensions.KHR_external_fence_capabilities = true;
+ instance->enabled_extensions.KHR_external_semaphore_capabilities = true;
+
for (uint32_t i = 0; i < pCreateInfo->enabledExtensionCount; i++) {
int idx;
for (idx = 0; idx < VK_INSTANCE_EXTENSION_COUNT; idx++) {
It should be possible to write a layer that does this, instead of hacking the driver.
Also I think think might fix 'Display VR View', which was only showing a black screen for me before this change.
After another year I wanted to try SteamVR again under linux, still not working well out of the box, at least now I can get further than the display detection bug.
Now running into the Room setup doesnt start issue in like this thread.. Which I thought was first related to using the new SteamRT3 (64 bit steam on linux) But not fully, disabling SteamRT3 made it to Steam Home could launch and and therefor I could finally try to Launch Room setup (before it just said "could not start, because other app was already starting")
But a lot, also getting the stack dump:
./steamvr_room_setup.sh
steamvr_room_setup.sh[2120256]: Detected scout LDLP runtime.
steamvr_room_setup.sh[2120256]: Relaunch under vrenv
steamvr_room_setup.sh[2120256]: exec /home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/../../../bin/vrenv.sh ./steamvr_room_setup.sh
vrenv.sh[2120256]: VRCOMPOSITOR_LD_LIBRARY_PATH=/home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64:/home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/qt/lib:/home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/bin/linux64:
vrenv.sh[2120256]: exec ./steamvr_room_setup.sh
steamvr_room_setup.sh[2120256]: Detected scout LDLP runtime.
steamvr_room_setup.sh[2120256]: exec /home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup
Found path: /home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup
Mono path[0] = '/home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Managed'
Mono path[1] = '/home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono'
Mono config path = '/home/duckbuster/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_room_setup/linux64/steamvr_room_setup_Data/Mono/etc'
Preloaded 'ScreenSelector.so'
Preloaded 'libopenvr_api.so'
Trace/breakpoint trap (core dumped) ./steamvr_room_setup.sh
The quick room setup and tips to manually edit play area in this thread does make it so I can get VR to work.. but its not a good experience with SteamVR on linux so far.
Anyway.
Running Nobara Linux 43
Mesa 26.0.5
AMD Radeon RX 7900 XTX
Kernel 7.0.1
Nothing extracted yet.
Describe the bug
While clicking on the Room Setup button, the window appears for a brief moment, all black, and closes itself after a moment.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Room Setup launching
System Information (please complete the following information):
Please use the latest Steam beta client and SteamVR beta for your bug reports!
Additional context
Checking other related issues, I have been lead towards problems with the bash script
steamvr_room_setup.sh. Running this in the console, gives following output: