--- title: Asahi Linux --- # Asahi Linux *AKA: Fedora on aarch64 with extra steps* ## Envision Fedora has the `envision` package, as well as the `envision-monado` and `envision-wivrn` metapackages which grab the necessary dependencies for building monado and wivrn, respectively. This *will not* be the most up-to-date with upstream envision, but seeing as Envision doesn't currently build aarch64 AppImages, this is the easiest way to build custom commits of monado/wivrn/opencomposite/xrizer. ## 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. Here's how I created an environment that can run both aarch64 openxr/openvr applications, and x86_64 openxr/openvr applications: 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 ``` 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 } ``` ## 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. Therefore, my reccomended launch order is as follows: Launch steam from inside a terminal (so that you can see logs when things inevitably work incorrectly): ```sh steam ``` Lanuch monado-service: ```sh muvm -it -- bash ``` ```sh mkdir -p /run/user/1000/ chmod 700 /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 ``` Ensure that `openvrpaths.vrpath` has the correct contents and hasn't been overwritten by steam. Launch a game.