@SpookySkeletons Thank you for the report - I have a few questions since we don't currently have a setup to test Monado specifically ... first off - do you know if there is a way to observe the persistent XR instance with SteamVR in some way that would be easier for us to reproduce for test? Any specific steps on how to repro would be greatly appreciated :)
Second - there is a major difference between experimental-10 and the 10.0-beta. Could you please test 10.0-beta and let us know if you see the problem there too or only on experimental-10?
Third (as a side-note) - Proton Hotfix is basically never interesting to test. As described here, Hotfix is a very "short-lived" branch and is almost always out of date by weeks or longer. Experimental-bleeding-edge will always have everything interesting that might be in a particular hotfix build, and it gets updated regularly and automatically (unlike hotfix).
I do not yet have a good answer to question 1 in steamvr as I don't use it myself but if you are aware of a way to enumerate connected clients on the steamvr IPC that would be a way to check.
We do have an orchestrator which can inform you of dependencies to install for monado in simulation mode to test without a headset connected and it also sets up an OpenVR translation layer to accompany, as well as patching pressure vessel so games just work while we wait on runtime OpenXR awareness: https://lvra.gitlab.io/docs/fossvr/envision/
All installed to home folder locally and built from source.
The video is slightly outdated for sure but most there should be accurate it's available in appimage format for you to snag.
I gave 10-GE a test and found the same result, stuck open client. I will try both stock 10 and 10 experimental and report back.
I will disregard hotfix then and will try experimental-bleeding-edge and report.
Have something a bit more substantive that a VR/XR client is spooling the whole time.
Looking at the monado log the final disconnect on proton 10 beta only occurs when the game is closed and on proton 9 stable it occurs as soon as the game launches. OpenComposite reports the VR interface closing quite quickly in logs so its likely the XR client here.
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client 12 connected
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_handler.c:ipc_handle_instance_describe_client]
Client info:
id: 12
application_name: 'OpenComposite_wine64-preloader'
pid: 11347
extensions:
ext_hand_tracking_enabled: true
ext_eye_gaze_interaction_enabled: false
ext_hand_interaction_enabled: false
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client 13 connected
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_handler.c:ipc_handle_instance_describe_client]
Client info:
id: 13
application_name: 'wineopenxr test instance'
pid: 11347
extensions:
ext_hand_tracking_enabled: false
ext_eye_gaze_interaction_enabled: false
ext_hand_interaction_enabled: false
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client disconnected.
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client disconnected.
Whereas proton 9 below will connect one client, disconnect, then connect the other, and disconnect before the game is allowed to execute and you can see a slight diff in the runtime logs.
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client 4 connected
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_handler.c:ipc_handle_instance_describe_client]
Client info:
id: 4
application_name: 'OpenComposite_wine64-preloader'
pid: 14438
extensions:
ext_hand_tracking_enabled: true
ext_eye_gaze_interaction_enabled: false
ext_hand_interaction_enabled: false
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/compositor/main/comp_target_swapchain.c:comp_target_swapchain_create_images]
Not using vblank event thread!
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client disconnected.
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client 5 connected
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_handler.c:ipc_handle_instance_describe_client]
Client info:
id: 5
application_name: 'wineopenxr test instance'
pid: 14438
extensions:
ext_hand_tracking_enabled: false
ext_eye_gaze_interaction_enabled: false
ext_hand_interaction_enabled: false
Info [/home/bones/.local/share/envision/4ba867ab-891a-4e5d-939c-ca49ab5f29c3/xrservice/src/xrt/ipc/server/ipc_server_per_client_thread.c:client_loop]
Client disconnected.
@SpookySkeletons Thank you!! This is hopefully going to be very helpful towards looking into the issue :). By the way - just to confirm -- did you ever get a chance to check Proton 10.0-1 Beta to see if this problem is unique to experimental or if there is the same behavior on 10.0-1 and experimental-10? I don't want to make assumptions about the Proton version you were testing here :)
10.0-1 Beta behaves the same, I was using it for testing just yesterday. Still presuming experimental-bleeding-edge is doing this as well but I have not tested directly yet FYI.
EDIT: Confirm bleeding-edge also replicates the XR client hanging on. Everything beyond stable 9 has this issue.
@SpookySkeletons Thank you for the confirmation - that helps narrow down some things :). I have another request for the next time you test this - could you please get a log by adding this launch option? PROTON_LOG=+vrclient,+openxr,+steam %command%
It would be ideal if you could get a log with Proton 10 Experimental and with Proton 9 so that we can compare them. We still don't have a full setup to test Monado locally, but some times things can be obvious enough from a log (fingers crossed).
@SpookySkeletons Thanks for the detailed info! I looked into that. I installed Monado and OpenComposite building from current git source, then I am running Monado serice from the command line, while Proton game with:
VR_OVERRIDE=/run/host/usr/local/OpenComposite XR_RUNTIME_JSON=/run/host/usr/local/share/openxr/1/openxr_monado.json PRESSURE_VESSEL_FILESYSTEMS_RW=$XDG_RUNTIME_DIR/monado_comp_ipc %command%
This way I got the thing working both with Simulated HMD (like in the log above) and real Valve Index HMD. And was reproducing the issue intermittently.
Most of the time the game was starting fine for me (I also tried with VRChat; "Faster Than Light" from the log is not a VR game so it is not apparent if anything is actually broken or not). And I could reproduce the issue intermittently, when disconnect message appearing late in Monado output, and (only once) actual failure to start VRChat in VR mode when OpenComposite complained about the VR instance already been created.
I didn't find any relevant differences in the instance creation / desstruction between Proton 9 and 10 (including Experimental). I think if the problem is reproducible more likely on Proton 10 that is maybe a matter of a bit different timing between the thread created by steam.exe helper process and starting the game process in parallel which timing could happen to change a bit between Proton 9 and 10.
What I think actually happens here looks like Monado bug to me. The socket which is created in Monado's XR client is inherited by child processes. So if our helper creates game process while the connection to Monado is open (either for VR instance through OpenComposite or XR instance directly) the socket gets inherited in the child process. While Monado service only seems to decide that client connection is closed (and reflects it in the log) when the client side socket connection is closed, which doesn't happen when we have a second fd for the socket in the child process. There is no way on Linux to only inherit specified fds on process creation (unlike explicit management of that for handles on Windows). On Linux that is the matter of creating file or socket in a way that is not inherited if that is not needed.
I think it is Monado bug, I sent MR to Monado https://gitlab.freedesktop.org/monado/monado/-/merge_requests/2470 .
That seems to help here and now I am not reproducing those connection getting stuck. If you are building Monado from source, could you please confirm if that helps if possible?
@gofman Confirm just tested this did the trick.
I can now launch any title under proton 10 and the runtime starts & stops as it should.
proton 10.0-1x1 2025-05proton hotfixx2 2025-05PROTON_LOG=+vrclient,+openxr,+steamx1 2025-05
Latest stable proton 9's winexrtestinstance XR client naturally exits after a second or two of operation to verify the functionality of the OpenXR runtime on Monado but proton hotfix and experimental and presumably (but yet to be tested) proton 10 will all just spool the XR client indefinitely so long as any Steam application is actively running.
This is quite a problem for socket activated and deactivated setups who rely on OpenXR apps to try to connect to a Monado socket to spawn the runtime and also rely on all of these disconnecting to terminate the runtime. What would normally very briefly spool up the VR gear instead becomes the VR gear powering up and running for the whole duration of gameplay game even if it's not a native VR title, the wineopenxr instance runs unconditionally and the VR gear will sit idle so long as one active client is connected.