Jasima/lvra.gitlab.io
1
0
Fork 0
mirror of https://gitlab.com/lvra/lvra.gitlab.io.git synced 2025-07-01 17:25:31 +02:00
Code Issues Projects Releases Packages Wiki Activity

Update file Asahi_Linux.md

Browse source
This commit is contained in:
Kitlith 2025-05-29 16:13:07 -07:00
parent 735f35246f
commit 07777855ff
1 changed files with 36 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

75
content/docs/distros/Asahi_Linux.md
View file

@ -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 <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
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 <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.
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.*
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.
[vr-multiarch-build]: https://gitlab.com/lvra/vr-multiarch-build