Some time ago I needed a virtual #ARM machine and while I’m not entirely sure any more why that was I did seem to have an inspirational moment and made a template of this. Here is what the #qemu config for #Proxmox _may_ look like:
It makes sense to install the package cloud-init to some stuff can be set from outside of the machine.
…and yes, it’s just as slow as expected from an ARM 🤓
I’m also not entirely sure if this is really officially featured by Proxmox (just like btrfs 🤷) but the machine was doing it’s job without an issue for years and I did just replay the template on VE 7.4 so I guess it’s fine 🤷
I was especially happy when I found the Paperless apps in the #fdroid store. That’s always a good sign 🤓
> #PaperlessNGX is a community-supported open-source document management system that transforms your physical documents into a searchable online archive so you can keep, well, less paper.
I didn’t use my Steam Link for some time and was kinda surprised by the new UI in Big Picture Mode. And also very unhappy because it was a stutter feast with buffer artefacts all over the place. Once I could get a game running it was butter though so something was up with the streaming mode of the UI. I’ve no really an idea what’s going on there but this was always a problematic thing with my AMD GPU under Gnome using Wayland when it comes to streaming and remote play. I ticked off the basics and disabled the blocklist for unknown GPUs, made sure that AMD hardware acceleration was enabled for the host in the Big Picture setting and even tried to launch it with the old big picture mode but no dice:
steam pipewire -pipewire-dmabuf -oldbigpicture
After reading around a lot on the bugtracker at https://github.com/ValveSoftware I eventually learned that the hardware acceleration for remote play is usually done with VAAPI and that there is debug information in ~/.local/share/Steam/logs/streaming_log.txt and sure enough here it was:
ffmpeg verbose: libva: VA-API version 1.16.0
ffmpeg verbose: libva: User environment variable requested driver 'radeonsi'
ffmpeg verbose: libva: Trying to open /usr/lib/dri/radeonsi_drv_video.so
ffmpeg verbose: libva: Found init function __vaDriverInit_1_16
ffmpeg verbose: libva: va_openDriver() returns 0
ffmpeg verbose: Initialised VAAPI connection: version 1.16
ffmpeg verbose: VAAPI driver: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6700 XT (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64).
ffmpeg verbose: Driver not found in known nonstandard list, using standard behaviour.
ffmpeg verbose: Input surface format is nv12.
ffmpeg verbose: Compatible profile VAProfileH264Main (6) is not supported by driver.
ffmpeg error: No usable encoding profile found.
So the profile was missing and a check with vainfo confirmed this:
This was the moment when my brain did pull off one of it’s tricks and remembered me about the story about Fedora _disabling_ hardware acceleration for H264 due to proprietary concerns some months ago and yes I did recently upgrade to Fedora 37 🤯
Thankfully the community stepped in already and fixed mesa drivers are only one dnf install away on rpmfusion, so there is no need to recompile this with h264 support (and some others) manually. There is a caveat though because the swap command would happily delete the needed 32bit versions for Steam and only install the 64bit version of the swapped package. Keeping this in mind the required commands are basically this (and if this breaks your system I do not want to hear about it – use your brain!):
And sure enough the Steam Link started working again. Somewhat. Now I have issues that some games don’t get captured or loose focus eventually but that I’ll debug another day 😩
Video: Starting Steamworld Dig 2 and showing system overview
Linux Gaming in 2023 is easy. Remote Play… not so much.
