Some notes for UTM/QEMU
vancluever opened this issue · comments
Been working with trying to get bootstrapped off of this setup, thanks @mitchellh!
Couple of things I've noticed as I've been messing with this on UTM:
- We need the userspace
spice-vdagent(notvdagentd) running in the user's X session, e.g. launched out of.xprofile. - UTM prior to 4.4.0 does not handle accessibility resizing properly which might drive you wild trying to figure out what is going on when troubleshooting dynamic resolution while doing things like snapping to edges in Rectangle.
LIBGL_ALWAYS_SOFTWAREmay be unnecessary now, unless I haven't stumbled on issues yet. 😉 I was building from scratch and didn't include this option, and things seemed to be working okay.
I'll add a PR once I get more settled in with my config!
I might also take a stab at adding some automation for dynamic resolution too so that I don't necessarily need to run xrandr-auto super quick after I resize. I noticed the note about udev rules, I'll see if I can find a way to get this tidy so that it's localized to the UTM setup!
All sounds great to me. Thanks @vancluever!
Adding a note on the LIBGL_ALWAYS_SOFTWARE env var - looks like this is needed due to NixOS/nixpkgs#239977 and similar issues. There seem to be a lot of these... apparently there are problems trying to find the right OpenGL driver to use? Continuing to look into this though... I'm seeing the recommendation to use https://github.com/guibou/nixGL, but that seems to be for non-nix host targets.
So I think this is the core of the issue with UTM: utmapp/UTM#4285. It seems like the bottleneck here is ANGLE limiting the OpenGL implementations actually available to the guest. As a result, the available versions of OpenGL given to a guest are rather old.
There likely is no way around this on QEMU until this is corrected.
Incidentally, using the native Apple hypervisor framework on UTM works just fine using the same NixOS flake. 🙂 (I've built myself a minimal flake in the meantime to work through some of these issues).
Just a comparison of glxinfo on both VMs:
QEMU
Apple Virtualization
Looks like this is due to SW rendering on the Apple virtualization side - so yeah, likely software is our only hope for now.