From 07777855ffd5637c3d4e99e6967f080aa3517890 Mon Sep 17 00:00:00 2001 From: Kitlith Date: Thu, 29 May 2025 16:13:07 -0700 Subject: [PATCH] Update file Asahi_Linux.md --- content/docs/distros/Asahi_Linux.md | 75 ++++++++++++++--------------- 1 file changed, 36 insertions(+), 39 deletions(-) diff --git a/content/docs/distros/Asahi_Linux.md b/content/docs/distros/Asahi_Linux.md index 2ba3fb3..180a69a 100644 --- a/content/docs/distros/Asahi_Linux.md +++ b/content/docs/distros/Asahi_Linux.md @@ -14,48 +14,37 @@ This *will not* be the most up-to-date with upstream envision, but seeing as Env ## Multiarch Depending on what openxr applications you are planning on running, you may need multiple builds of the same component, but for different architectures. -I will refer to the components as monado and opencomposite going forward, but the same information holds for wivrn and xrizer. +You can acquire these builds in multiple ways, such as cross-compiling, or gathering builds from multiple machines. -Here's how I created an environment that can run both aarch64 openxr/openvr applications, and x86_64 openxr/openvr applications: +A repo ([vr-multiarch-build]) for cross-compiling these components has been thrown together to make things easy. +Some sample usage: -I started by using envision on an aarch64 machine and an x86_64 machine, building the same profile on the same commits. -Each prefix (containing monado) was copied from `~/.local/share/envision/prefixes/{profile id}/` to a directory on my Asahi Linux install. -(In my case, `~/multiarch_monado/monado-x86_64-prefix/` and `~/multiarch_monado/monado-aarch64-prefix/`.) -The two instances of OpenComposite (located at `~/.local/share/envision/{profile id}/OpenComposite/build`) should be merged into a single directory. -(In my case, `~/multiarch_monado/opencomposite`.) -The x86_64 build of OpenComposite should contribute `bin/linux64/vrclient.so`, while the aarch64 build of OpenComposite should contribute `bin/linuxarm64/vrclient.so`. -(If you are following along using an OpenComposite commit that pre-dates , -or an xrizer commit that pre-dates , -you should rename the `bin/linux64` folder from the aarch64 build to `bin/linuxarm64`. -Or you can choose to ignore the aarch64 build entirely, since Steam games don't currently require it.) - -Runtimes that have been copied from another machine should probably be setcap'd: `sudo setcap CAP_SYS_NICE=eip monado-service` - -To be able to run openxr applications, we need to create the symlinks `active_runtime.x86_64.json` and `active_runtime.aarch64.json` in `~/.config/openxr/1/`. -On my machine, this looks like: ```sh -ln -s ~/multiarch_monado/monado-aarch64-prefix/share/openxr/1/openxr_monado.json ~/.config/openxr/1/active_runtime.aarch64.json -ln -s ~/multiarch_monado/monado-x86_64-prefix/share/openxr/1/openxr_monado.json ~/.config/openxr/1/active_runtime.x86_64.json +git clone https://gitlab.com/lvra/vr-multiarch-build +cd vr-multiarch-build +# `./setup_wivrn.sh` and `./setup_xrizer.sh` also exist, depending on what you need. +./setup_monado.sh && ./setup_opencomposite.sh +sudo ./setcap.sh + +# you can now start monado by running prefixes/monado-aarch64/bin/monado-service ``` -To be able to run openvr applications, we need to create `~/.config/openvr/openvrpaths.vrpath`. -This is overridden when you start steam in some cases, so make sure you keep an extra copy handy to re-override it. -On my machine, the contents of `openvrpaths.vrpath` is as follows: -``` -{ - "jsonid": "vrpathreg", - "runtime": [ - "/home/kitlith/multiarch_monado/opencomposite" - ], - "version": 1 -} +When you want to update a component, you should manually pull the git repos, then rerun the setup scripts. For example: + +```sh +cd vr-multiarch-build +git pull # update the build repository +git -C monado pull +git -C OpenComposite pull +./setup_monado.sh && ./setup_opencomposite.sh +sudo ./setcap.sh ``` ## Steam Games under muvm 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 launch arguments look like: `PRESSURE_VESSEL_FILESYSTEMS_RW=/run/user/1000/monado_comp_ipc XR_RUNTIME_JSON=~/.config/openxr/1/active_runtime.x86_64.json %command%` -There is some extra complication caused my muvm putting its `XDG_RUNTIME_DIR` in a weird spot interfering with monado's ability to connect to itself. +On my machine, the 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: @@ -66,15 +55,18 @@ muvm -it -- bash ```sh mkdir -p /run/user/1000/ 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. -XDG_RUNTIME_DIR=/run/user/1000/ ./monado-service +./monado-service ``` 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. Optionally, `tail -f ~/.steam/steam/logs/console-linux.txt` so you can see errors when a game fails to do the correct thing. -Ensure that `openvrpaths.vrpath` has the correct contents and hasn't been overwritten by steam. +Ensure that `openvrpaths.vrpath` has the correct contents. Launch a game. @@ -83,7 +75,8 @@ Launch a game. Due to , the terminal that you're running WiVRn within *must* be the one that's starting the VM. Therefore, you should start wivrn before you start steam. -There are also some extra considerations, such as the avahi daemon not being visible within the VM. +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] Here's what I did that worked: @@ -92,11 +85,15 @@ muvm -it -p 9757/udp -p 9759 -- bash ``` ```sh -mkdir -p /run/user/1000/ +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. -XDG_RUNTIME_DIR=/run/user/1000/ ./wivrn-server --no-publish-service --no-manage-active-runtime +./wivrn-server --no-publish-service --no-manage-active-runtime ``` -On my machines, for some reason, WiVRn produced different commit hashes when applying patches, even though the base monado commit and wivrn commit were the same. -If this happens to you, you can workaround it by adding `IPC_IGNORE_VERSION=1` to your steam launch arguments, *but you should verify that everything was built off of the same commit first.* \ No newline at end of file +If you are using a commit of WiVRn before , 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. + +[vr-multiarch-build]: https://gitlab.com/lvra/vr-multiarch-build \ No newline at end of file