Refactor the monado and wivrn sections

Additionally, add a workaround for a bug present somewhere in the muvm stack.
This commit is contained in:
Kitlith 2025-06-01 18:50:00 -07:00
parent 9dbba2c7ae
commit b65bc23b7d

View file

@ -46,31 +46,46 @@ sudo ./setcap.sh
What worked for me was running `monado-service` manually, with all the environment variables that envision uses, and manually setting up environment variables for steam launch arguments.
On my machine, the steam launch arguments look like: `XR_RUNTIME_JSON=~/.config/openxr/1/active_runtime.x86_64.json PRESSURE_VESSEL_FILESYSTEMS_RW=/run/user/1000/wivrn/comp_ipc:/run/user/1000/monado_comp_ipc %command%`
There are some extra complications caused by muvm putting its `XDG_RUNTIME_DIR` in a weird spot interfering with monado's ability to connect to itself.
Therefore, my reccomended launch order is as follows:
Lanuch monado-service:
There are some extra complications caused by interactions between muvm and pressure-vessel, you may wish to put the following inside of a script somewhere for now:
```sh
muvm -it -- bash
```
#!/usr/bin/env bash
```sh
mkdir -p /run/user/1000/
# I couldn't find a way to make PRESSURE_VESSEL_FILESYSTEMS_RW map one file/directory to another,
# so let's create pressure-vessel's view of XDG_RUNTIME_DIR instead.
# This won't be necessary once pressure-vessel supports passing through openxr runtimes.
mkdir -p /run/user/1000/wivrn/
chmod 700 /run/user/1000/
ln -s $XDG_RUNTIME_DIR/monado_comp_ipc /run/user/1000/
# setup the rest of the environment variables, ensuring XRT_DEBUG_UI is *not* enabled.
./monado-service
ln -s $XDG_RUNTIME_DIR/wivrn/comp_ipc /run/user/1000/wivrn/
# wivrn: Work around https://github.com/AsahiLinux/muvm/issues/178
ping -c1 8.8.8.8
# setup the environment variables for monado or wivrn
# launch monado or wivrn
# path/to/vr-multiarch-build/prefixes/monado-aarch64/bin/monado-service
# dbus-launch path/to/vr-multiarch-build/prefixes/wivrn-aarch64/wivrn-server --no-publish-service --no-manage-active-runtime
```
Launch Steam.
Due to a [bug](https://pagure.io/fedora-asahi/steam/issue/18) in the steam launcher wrapper on asahi, the "Launching Steam" window will not stick around, but Steam *is* still launching.
If you get a message from OpenComposite complaining that it doesn't support VR Applications of type 6, then you should attempt to re-launch steam, as that will cause Steam to fail to launch.
For ease, going forward, I will assume that this script is located within the home directory, named `launch_monado.sh`, and has the executable bit set.
Therefore, my reccomended launch order is as follows:
Optionally, `tail -f ~/.steam/steam/logs/console-linux.txt` so you can see errors when a game fails to do the correct thing.
1. Lanuch monado:
```sh
muvm -it -- ~/launch_monado.sh
```
Ensure that `openvrpaths.vrpath` has the correct contents.
2. Launch Steam.
- Due to a [bug](https://pagure.io/fedora-asahi/steam/issue/18) in the steam launcher wrapper on asahi, the "Launching Steam" window will not stick around, but Steam *is* still launching.
- If you get a message from OpenComposite complaining that it doesn't support VR Applications of type 6, then you should attempt to re-launch steam, as that will cause Steam to fail to launch.
Launch a game.
3. Optionally, `tail -f ~/.steam/steam/logs/console-linux.txt` so you can tell what's going on if a game fails to find the openvr/openxr runtimes.
4. Ensure that `openvrpaths.vrpath` has the correct contents.
5. Launch a game.
## wivrn
@ -78,24 +93,25 @@ Due to <https://github.com/AsahiLinux/muvm/issues/177>, the terminal that you're
Therefore, you should start wivrn before you start steam.
The avahi daemon is not available inside of muvm, so you should use `--no-publish-service`.
Since I'm managing my active runtimes through [vr-multiarch-build]
Since I'm managing my active runtimes through [vr-multiarch-build], I'm using `--no-manage-active-runtime`.
Here's what I did that worked:
If you are using a commit of WiVRn before <https://github.com/WiVRn/WiVRn/commit/38b64fe09c27757109f126d91b9a5f4244e01f78>, the build system *will* produce inconsistent commit hashes for its build of monado across architectures.
```sh
muvm -it -p 9757/udp -p 9757 -- bash
```
To work around this, you can:
- `git cherry-pick 38b64fe09c27757109f126d91b9a5f4244e01f78` onto your wivrn branch
- use a newer commit of wivrn that includes that commit
- add `IPC_IGNORE_VERSION=1` to your steam launch arguments
```sh
mkdir -p /run/user/1000/wivrn/
chmod 700 /run/user/1000/
ln -s $XDG_RUNTIME_DIR/wivrn/comp_ipc /run/user/1000/wivrn/comp_ipc
# setup the rest of the environment variables, ensuring XRT_DEBUG_UI is *not* enabled.
dbus-launch ./wivrn-server --no-publish-service --no-manage-active-runtime
```
If you are using a commit of WiVRn before <https://github.com/WiVRn/WiVRn/commit/5130bdeda51c52137f11e0536273f3bfbb2f7f71>, the build system *will* produce inconsistent commit hashes for its build of monado.
To work-around this, you can either `git cherry-pick 5130bdeda51c52137f11e0536273f3bfbb2f7f71` onto your wivrn branch, use a newer commit of wivrn, or add `IPC_IGNORE_VERSION=1` to your steam launch arguments.
If you pick the last option, you need to be *extra careful* that you are actually building things off of the same commit of wivrn/monado.
Assuming a similar script to the one described above, named `launch_wivrn.sh`, my reccomended launch order is as follows:
1. Launch wivrn:
```sh
muvm -it -p 9757/udp -p 9757 -- ~/launch_wivrn.sh
```
2. Connect your headset to wivrn.
3. Start steam.
4. etc.
[vr-multiarch-build]: https://gitlab.com/lvra/vr-multiarch-build