-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux VAAPI Doesn't Work With AppImage or Flatpak #2409
Comments
This report documents two independent(?) issues that I can both confirm for the latest nightly AppImage on Ubuntu 22.04 with Intel graphics. I can happily provide more logs if needed. Issue 1. Sunshine AppImage is indeed unable to load VA-API. The error messages for my Intel laptop are similar except that it fails loading Issue 2. KMS capture is not working due to missing capabilities. The AppImage is unable to set the capabilities. I'm not sure there's a workaround for this (see AppImage/AppImageKit#881), except to just run the AppImage as root e.g. using |
@gschintgen I'm trying to work around issue 2 in #2300. I haven't tested the code yet, but the idea is to actually copy the binaries out of the AppImage. This has likely been an issue forever, and the custom AppRun probably only ever worked when the AppImage was extracted. For issue 1, we probably need to manually add those libraries to the AppImage. Here's an example of how we did this in the past (for different libraries though). https://github.com/LizardByte/Sunshine/blame/974c4bd4a1d53a4ed09ba0d17add0845551d7c61/.github/workflows/CI.yml#L460 |
Hmm, I thought of such an approach too, but then it's even stranger than having an AppImage with an Since As for the other issue, bundling hardware drivers seemed slightly unusual at first, but apparently that's quite normal:
and
I don't have the slightest idea though how self-contained those libraries are... and also why the AppImage is unable to load the system libraries. What I can tell is that those drivers have a versioned Init function:
Sunshine.AppImage seems to look only for |
The VAAPI issue seems to be due to some incoherent library versions. It can be "fixed" by removing the bundled Here's what I tried (from memory):
It seems to be an all or nothing situation: either don't bundle |
I'd agree with this |
I'll file a PR for the AppImage part of the report:
|
@RickAndTired : Would you mind testing a build of PR #2429? The AppImage can be downloaded here: |
VAAPI didn't work with this build, here's the log: |
Thank you for testing and providing the log!
There are a number of very recent reports of Mesa breakage referring to that same symbol: https://www.google.com/search?q=%22amdgpu_va_get_start_addr%22 As I'm now noticing the PR is not working either on my own AMD system (RX6650XT), but with different errors. (While preparing the PR I was using an Intel iGPU-based laptop and it fixed the issue just fine, so I was cautiously optimistic about it.) The reason that I get past the I'll see how it goes if I'm adding the stable kisak mesa PPA instead of the "fresh"er variant. (I thought the more bleeding edge PPA might be advantageous for users with more recent hardware, i.e. RX7xxx.) For completeness, here's the output on my system:
If I have a build that's working on my AMD box I'll let you know. |
I downgraded the mesa PPA in the AppImage. Now it seems to be working fine on my AMD system. (Logs look good, basic desktop streaming as perfect as it should be.) (I tested it with the build in my own fork: https://github.com/gschintgen/Sunshine/actions/runs/8728427369/artifacts/1423643042 ) |
Bummer. |
Here's a new test build: This AppImage now includes the latest libva.so built from source. It should be newer than your system's *_drv_video.so files. That should make it work, in theory... |
Looks like it's working, thank you! |
The test build still isn't working on my Fedora 40 / AMD |
Thanks for the feedback. Without log output it is impossible to debug though. But anyway, in the meantime the base OS of the AppImage has been upgraded in the nightlies. The latest commit in my PR is rebased on that new Ubuntu base. Could you plesase test again with this AppImage: https://github.com/gschintgen/Sunshine/actions/runs/8945652081/artifacts/1472155303 I've just tested it myself in order to make sure that nothing obvious broke. AMD is still working fine for me. (But I'm on the same Ubuntu as the AppImage is built on so I wouldn't expect trouble anyway...) edit: https://github.com/LizardByte/Sunshine/actions/runs/8890299036/artifacts/1473103571 |
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks! |
This issue was closed because it has been stalled for 10 days with no activity. |
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the nightly release?
Describe the Bug
Encoder VAAPI fails when using AppImage or the official Flatpak (not from flathub)
Expected Behavior
No response
Additional Context
VAAPI works when using the Sunshine deb
Host Operating System
Linux
Operating System Version
Ubuntu 23.10
Architecture
64 bit
Sunshine commit or version
0.23.0
Package
Linux - AppImage
GPU Type
AMD
GPU Model
RX 6600XT
GPU Driver/Mesa Version
23.2.1
Capture Method (Linux Only)
X11
Config
Apps
No response
Relevant log output
The text was updated successfully, but these errors were encountered: