5.1 KiB
| 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:
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:
muvm -it -- bash
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:
muvm -it -p 9757/udp -p 9759 -- bash
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.