---
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 <https://gitlab.com/znixian/OpenOVR/-/merge_requests/179>,
or an xrizer commit that pre-dates <https://github.com/Supreeeme/xrizer/pull/106>,
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:

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
```

Launch Steam.

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.

Launch a game.

## wivrn

Due to <https://github.com/AsahiLinux/muvm/issues/177>, 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.

Here's what I did that worked:

```sh
muvm -it -p 9757/udp -p 9759 -- 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/ ./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.*