WIP: Draft: Document what I did on Asahi Linux #120
Assignees
MayaTheShy
Clear assignees
MayaTheShy
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: LinuxVR_Adventure/lvra.gitlab.io#120
Reference in New Issue
Block a user
Delete Branch "patch-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This... isn't really a true guide. I'm documenting what I did so
that it doesn't get lost elsewhere.
I did all my testing with this with a dummy monado profile,
but it would likely be much more useful to try this with
wivrn and a wireless headset, and I may try to arrange
circumstances where I can test it.
the file is in the wrong damn place. sigh i'll fix that later.
added 1 commit
e1d8b09d- Add information about WiVRn to Asahi Linux docCompare with previous version
Envision is useful as a quick and dirty setup but I am of the mind we should have a reproducible build guide here using cross compile instructions so everything can be built on the aarch64 machine itself.
We will likely end up costing users substantial headache with less straightforward instructions and this can be used by the Fedora maintainers to help upstream this as a binary setup.
Envision also paves the OpenXR and OpenVR manifests. Steam is not responsible for manifest resets back to steamvr after the version.txt was introduced to both XRizer and OpenComposite.
This will likely not need configuration much longer with pressure vessel getting support for runtime arch and manifest translation https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/813
That's worth raising an issue on the WiVRn git and asking what's up here.
Useful for PoC but I would like reproducible build and crossbuild guide all on the arrch64, too much can go wrong using Envision as a bodge.
That's the eventual plan, yes, but I want to do more investigation into why the commits are different first. It's probably some metadata somewhere.
Make sure to mention this requires suid on the home filesystem or wherever Monado resides to allow caps.
Worth investigating if after https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/813 is merged and distributed if XR_RUNTIME_JSON will need to be set as a launch option to the specific arch.
I guess the way to do it, then, is to build from inside a aarch64 debian docker container, so we can take advantage of debian multiarch to grab the dependencies & cross compile. Reason I was avoiding doing the x86_64 build on my macbook is because Fedora doesn't follow debian multiarch, which would've made installing the x86_64 versions of deps much more annoying.
Perhaps we should work with IMRSVJon to further the multiarch packages of opencomposite and wivrn which are already available in repo.
XR_RUNTIME_JSONmay not actually need to be set as it is -- I added it well before I actually finished troubleshooting the other things that were going wrong (i.e. the hackyXDG_RUNTIME_DIRworkaround) and then never removed it.https://github.com/WiVRn/WiVRn/pull/351 fixes the commit hash reproducibility issue.
changed this line in version 3 of the diff
changed this line in version 3 of the diff
changed this line in version 3 of the diff
changed this line in version 3 of the diff
changed this line in version 3 of the diff
added 1 commit
735f3524- Update 2 filesCompare with previous version
added 1 commit
07777855- Update file Asahi_Linux.mdCompare with previous version
added 1 commit
15e87e2a- Update file Asahi_Linux.mdCompare with previous version
The bulk of this section has been replaced with a pointer to https://gitlab.com/lvra/vr-multiarch-build and some basic instructions for its use.
That is a good question, since the PR doesn't touch anything to do with loading the runtime jsons, and when I re-checked it just now, it didn't work without it. (new question: does it check
active_runtime.jsonand notactive_runtime.<arch>.json? might indicate that an older version of the openxr loader that predates the addition ofactive_runtime.<arch>.json.)It'll just be replaced by
PRESSURE_VESSEL_IMPORT_OPENXR_1_RUNTIMES=1, since it looks like it's disabled by default.active_runtime.jsonworks, so valve needs to update the version of the openxr loader included with the steam runtime, most likely.I need to take a closer look at the load order and see if I can make
active_runtime.jsona symlink that matchesactive_runtime.x86_64.jsonwithout screwing up native aarch64 applications.Has been updated to mention the commit that fixes it, and using the ignore version override only as a last resort. Feel free to poke me if you think it shouldn't be mentioned at all.
oops, i missed that runtime.c was collapsed, which is where all the manifest handling is located.
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/813/diffs#ed2babf7392cb0d43172fc65e09dadc58f4df19f_4863_4904 acknowledges the issue at least. It might do the right thing, I can't quite tell. Perhaps I should try it and see ™️.
Current observations:
wivrn didn't work too well in my test with the PC client on my desktop. I got it working in Basis, but it was definitely choppy. There's many possible reasons for this (maybe my WiFi isn't good enough for this), but I know for sure that I'm lacking a driver for hardware video encoding, and that's probably not helping.
monado dummy driver seems to run quite nicely, though I haven't found a configuration where it's useful yet. Qwerty doesn't work, since the debug UI crashes when a game connects to monado (even if I run a nested weston instance under xwayland), but disabling Qwerty gets me a gentle swaying movement, and that has looked smooth as butter on the initial screens of Beat Saber, Basis, The Lab, Pistol Whip, and Droid Repair Bay. This doesn't say that much, but compared to my initial experience with wivrn, it's promising.
added 1 commit
861be0fa- fixup! typoCompare with previous version
added 1 commit
9dbba2c7- setcap'd wivrn-server needs dbus-launchCompare with previous version
Noticed that I didn't appear to have x264 installed for wivrn, so I grabbed it and re-checked. Didn't seem to help that much.
I've also been experiencing an issue where muvm/passt isn't consistently actually connecting forwarded ports, which is annoying/concerning. I don't have a good way to make this consistently work at the moment. Maybe it'd be worth doing the port forwarding through ssh tunneling or something instead of through passt, but I'll need to wait for it to start breaking again before I can confirm if that'd be a valid workaround.EDIT: I was running into https://github.com/AsahiLinux/muvm/issues/178 and I have a workaround for it that I'm adding into documentation.Last comment on this: Newer versions of the openxr loader check the arch specific json before the undecorated json. So you can set a provide all the arch specific paths, and then add a
ln -sfn ./active_runtime.x86_64.json ~/.config/openxr/1/active_runtime.jsonto, in theory, redirect older versions of the openxr loader to the architecture you expect it to need.I can't figure out a way to action on this for this PR, without adding a section on "here's how to replace the version of
pressure-vesselthat steam uses!" that I don't really feel like adding.IMO, This document should be updated once that PR is merged and released to the public, but it doesn't feel appropriate to do so before-hand, whether that happens before or after this is merged, unless we were specifically going to not merge this until that PR is merged and release.
Thoughts?
added 1 commit
b65bc23b- Refactor the monado and wivrn sectionsCompare with previous version
and right after I post this, I find a way to say "this will not be necessary in the future" in regard to the XDG_RUNTIME_DIR workarounds. shrug
added 1 commit
e4ccdb9b- fixup!Compare with previous version
added 1 commit
0269da71- Add Troubleshooting sectionCompare with previous version
added 1 commit
7db85cf0- Make wivrn a subsection of steam gamesCompare with previous version
Consider linking my NixOS apple-silicon config, as a known-working example for NixOS users.
The nixos-apple-silicon repo pulls in the latest version of asahi's mesa, which includes the necessary vulkan extensions for monado. Once that is configured using the existing guide in that repo, following the regular NixOS instructions for monado + wivrn was sufficient. I did have to pass
NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1to thenixos-rebuildcommand, because some subset of the software doesn't appear to be labeled as supported on aarch64-linux (xriser?). Even though its not labeled as supported, it all built and ran fine.I have only tested xrgears and a bevy_mod_openxr example application. I can confirm passthrough works, I did not test controllers or hand tracking. I did not test xriser, opencomposite, wlx-overlay, or any other games. I did not test x86 emulation.
added 1 commit
3aaaf07f- missing `/bin` for wivrn in launch scriptCompare with previous version
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.