Commit Graph
14 Commits
Author SHA1 Message Date
Cameron Gutman 54f8fed51d Don't try fallback driver paths with the host libva 2026-09-05 14:30:28 -05:00
Cameron Gutman 3516591b99 Fix bad APPDIR when running an extracted AppImage 2026-09-03 00:10:27 -05:00
luanweslley77 526bde5586 Stop bundling libva in the AppImage so VAAPI works on modern hosts
The AppImage bundles libva from the build environment (Ubuntu 22.04,
VA-API 1.20). VA-API driver modules (e.g. Mesa's radeonsi_drv_video.so)
are dlopen()ed by libva and export an entrypoint named after the libva
minor version they were built against (e.g. __vaDriverInit_1_23). An
older libva cannot load newer drivers, so on any host more recent than
the build container va_openDriver() fails:

    Trying .../radeonsi_drv_video.so
    libva error: has no function __vaDriverInit_1_0
    va_openDriver() returns -1

and Moonlight silently falls back to software decoding (reproduced on
Fedora 44 / Mesa 26.1 / RX 6500 XT; overriding the bundled libva with
LD_PRELOAD of the host libva immediately yields HW decode). Refreshing
the bundled libva at each release only postpones the breakage: the host
drivers always eventually outrun it (see #1398).

Exclude libva and its backends from linuxdeploy so Moonlight and the
bundled FFmpeg resolve them through the loader's normal search path and
pick up the host libva, which the distro's package manager keeps in step
with the host drivers. This mirrors how Mesa/GL/EGL are already
host-provided.

Hosts without a usable libva (e.g. bare NVIDIA systems) must still not
fail to launch, since libva.so.2 is a direct DT_NEEDED of Moonlight and
the bundled FFmpeg. Stage the build-environment libva in
opt/libva-fallback (outside every loader search path) together with
libva-probe, a tiny program whose only job is to carry the same
DT_NEEDED entries and VA_API_* versioned symbol references as the
binaries shipped in the AppImage. The generated AppRun runs the probe
first: if the dynamic loader can start it against the host, the host
libva is used (probe passing is, by construction, exactly Moonlight
being loadable); if not, it prepends the fallback directory and launches
with the bundled libva, matching pre-existing behavior. The build script
verifies that the probe references every version node required by the
shipped binaries, so the two cannot silently drift apart.
2026-09-02 23:45:07 -05:00
Cameron Gutman e6da6fa11f Enable LTO for AppImage builds 2026-05-26 21:55:58 -05:00
Cameron Gutman c21affd15a Switch to linuxdeploy for AppImages 2026-05-10 16:56:34 -05:00
Cameron Gutman e1bbf8144e Switch AppImage to SDL3+SDL2-compat 2026-01-27 22:22:20 -06:00
Cameron Gutman 68aa04926e Switch to GitHub Actions for Windows and macOS builds 2025-10-26 15:09:57 -05:00
Cameron Gutman b4dc7ca7cb Build AppImage with Qt 6 2025-10-20 20:51:51 -05:00
Cameron Gutman e6e91ca88b Disable CUDA by default in favor of Vulkan and VDPAU
All of our official releases (Flatpak and AppImage) already do this, so this just makes it official.

This can be overridden by running qmake with CONFIG+=enable-cuda.
2025-10-19 21:24:29 -05:00
Cameron Gutman 3aaa09bb7d Disable CUDA/NVDEC in AppImage builds
These are only really useful for Wayland scenarios, but:
- Wayland is explicitly disabled for AppImage due to EGL issues
- VDPAU now works under XWayland with 545 and later drivers
- Moonlight now has a Vulkan Video backend which works with 535 and later drivers

Fixes #1314
2024-06-19 10:29:03 -05:00
Cameron Gutman b1c8005d1a Disable libdrm in AppImage build 2023-11-01 21:44:44 -05:00
Cameron Gutman 6f710faa8e Fix EGL loading in the AppImage 2023-10-05 23:05:07 -05:00
Cameron Gutman d5a26b1d70 Enable auto-update for AppImages 2020-04-03 17:03:12 -07:00
Cameron Gutman caca491943 Add build script to generate AppImage 2020-02-01 15:46:53 -08:00