Mesa needs kernel 5.15 for AMD

[kero990]

Sorry, I couldn't find a community channel (like Discord) to ask this, so I had to use issues. Apologies for taking up resources.

I'm using an arm64 device with the system locked to Debian 10, kernel 4.19. This project is the best option for me to run newer software on my machine, thank you for that.

The issue I'm facing now is that if I build an AppImage on Arch, because Arch uses Mesa 25, which is quite new, it throws an error on my system and falls back to software rendering, making the program extremely laggy.

amdgpu: DRM version is 3.27.0, but this driver is only compatible with 3.54.0 (kernel 6.6+) or later.

MESA: error: amdgpu: ac_query_gpu_info failed.

glx: failed to create dri3 screen

failed to load driver: radeonsi

I don't know how to solve this problem. Is there an option to not bundle Mesa and OpenGL, Vulkan, etc. drivers inside? Of course, I'm also not sure if it's possible to use the host's Mesa environment. Currently, if possible, I use Debian 12 for packaging, as its Mesa 22 is quite compatible with my system. But I'm not sure if packaging on a non-latest system will break forward compatibility—meaning that while it runs on Debian 10, it loses the ability to run on newer systems like Arch and Ubuntu 26.

Another issue is with GTK4. I've previously compiled GTK4 entirely on Debian 10, so I can also natively compile GTK4 applications for Debian 10. The only problem is that GTK4 is tightly bound to Fcitx5, while my machine only has Fcitx4, which GTK4 doesn't support. So, can using this project to package an AppImage solve the Fcitx issue?

Thanks for any possible answers, and thanks again for this project.

[Samueru-sama]

amdgpu: DRM version is 3.27.0, but this driver is only compatible with 3.54.0 (kernel 6.6+) or later.

Damn, looks like recent versions of Mesa bump the minimum kernel quite high.

Looks like we will have to start patching Mesa.

Is there an option to not bundle Mesa and OpenGL, Vulkan, etc. drivers inside?

For vulkan you can just export SHARUN_ALLOW_SYS_VKICD=1 which will let you use the opengl drivers of your machine. With OpenGL though there is no solution.

---

cc @fiftydinar do you have this problem with intel GPUs?

[Samueru-sama]

@kero990 Does forcing zink as your opengl driver work? in that case it will use your host vulkan driver when combined with SHARUN_ALLOW_SYS_VKICD=1

[Samueru-sama]

A while ago I had someone complain in the ghostty repo:

pkgforge-dev/ghostty-appimage#93 (comment)

In that case the minimum kernel was 5.15 so it wasn't much of a deal, now it is a huge deal lol.

Note that you will run into this issue if you try to spin an archlinux container from debian using distrobox or similar.

[Samueru-sama]

@kero990 Do you have still have the error in the demos? Check the vkcube+glxgears demo and also the GTK4 demo:

https://github.com/pkgforge-dev/Anylinux-AppImages/releases/tag/demo

[kero990]

With the help of AI, I am currently using the following parameters during the build stage:

DEPLOY_OPENGL=0
DEPLOY_VULKAN=0
ANYLINUX_DO_NOT_LOAD_LIBS='libGLX_mesa.so*:libEGL_mesa.so*:libgallium-*:libvulkan*'

The build result runs normally on my machine. Checking the included library content, the results are as follows:
1.It no longer contains any libvulkan* libraries.
2.It no longer contains mesa drivers under lib/dri.
3.It still contains libraries like libGLX_mesa*, but the mesa errors no longer appear.

Of course, the problem is also obvious: the mesa and vulkan on lower systems may not necessarily meet the program's requirements. For example, although glibc is sufficient for Blender on my machine, I must externally bundle mesa 22+ to use it; the built-in mesa 19 does not work. (Of course, for some applications, bundling mesa doesn't work either; for instance, xemu always prompts that the driver does not support OpenGL 4.0).

Regarding SHARUN_ALLOW_SYS_VKICD=1 and MESA_LOADER_DRIVER_OVERRIDE=zink mentioned in your reply, my test results are as follows:

1.Using SHARUN_ALLOW_SYS_VKICD=1 alone has no effect (after all, the error comes from mesa, not just vulkan).
2.Using SHARUN_ALLOW_SYS_VKICD=1 and MESA_LOADER_DRIVER_OVERRIDE=zink together results in the following default error:

$SHARUN_ALLOW_SYS_VKICD=1 MESA_LOADER_DRIVER_OVERRIDE=zink ./
  Play.-0.75.r36.g73cb9378c-1-anylinux-aarch64.AppImage

  self updates disabled by /home/inspur/.config/auto-updates-policy/org.purei.Play-update-setting
  [ALSOFT] (EE) Failed to connect PipeWire event context (errno: 112)
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 3.2, options
  QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1,
  alphaBufferSize 0, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 0,
  colorSpace QColorSpace(), profile  QSurfaceFormat::CoreProfile)
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 3.2, options
  QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1,
  alphaBufferSize 0, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 0,
  colorSpace QColorSpace(), profile  QSurfaceFormat::CoreProfile)
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 3.2, options
  QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1,
  alphaBufferSize 0, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 0,
  colorSpace QColorSpace(), profile  QSurfaceFormat::CoreProfile)
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  DRI3 not available
  Could not initialize GLX

Interestingly, for Qt applications, using QT_XCB_GL_INTEGRATION=xcb_egl results in no errors.

But there is no solution for non-Qt applications. If LIBGL_KOPPER_DRI2=1 is added, the error message changes to:

$SHARUN_ALLOW_SYS_VKICD=1 MESA_LOADER_DRIVER_OVERRIDE=zink LIBGL_KOPPER_DRI2=1 ./xemu_Nightly-0.8.135.r2.ge00c151-1-anylinux-aarch64.AppImage self updates disabled by /home/inspur/.config/auto-updates-policy/xemu-update-setting
xemu_version: 0.8.135-2-ge00c1511d1
xemu_commit: e00c1511d1db5ede3343f7a8404fe4b94864b357
xemu_date: Thu May 21 08:35:05 AM UTC 2026
xemu_settings_get_base_path: base path: /home/inspur/.local/share/xemu/xemu/
xemu_settings_get_path: config path: /home/inspur/.local/share/xemu/xemu/xemu.toml
WARNING: radv is not a conformant vulkan implementation, testing use only.
amdgpu: DRM version is 3.27.0, but this driver is only compatible with 3.42.0 (kernel 5.15+) or later.
glx: failed to create drisw screen
failed to load driver: zink
WARNING: radv is not a conformant vulkan implementation, testing use only.
amdgpu: DRM version is 3.27.0, but this driver is only compatible with 3.42.0 (kernel 5.15+) or later.
glx: failed to create drisw screen
failed to load driver: zink
WARNING: radv is not a conformant vulkan implementation, testing use only.
amdgpu: DRM version is 3.27.0, but this driver is only compatible with 3.42.0 (kernel 5.15+) or later.
glx: failed to create drisw screen
failed to load driver: zink
Failed to create main window: Couldn't find matching GLX visual

In summary, for my system, the options are either to use Arch but not bundle mesa inside, or to use a system with a suitable version for packaging (for my Debian 10, that's Debian 12 with mesa 22). However, this might require precisely selecting the build environment for each target system, and whether the resulting build can run on higher systems like Arch also needs testing.

[Samueru-sama]

@kero990 I really need you to do this

Use the demos for the tests.

---

Using SHARUN_ALLOW_SYS_VKICD=1 and MESA_LOADER_DRIVER_OVERRIDE=zink together results in the following default error:
DRI3 not available

Also add LIBGL_KOPPER_DRI2=1.

[Samueru-sama]

oh nvm, you tested LIBGL_KOPPER_DRI2=1 already.

[Samueru-sama]

But there is no solution for non-Qt applications. If LIBGL_KOPPER_DRI2=1 is added, the error message changes to:

amdgpu: DRM version is 3.27.0, but this driver is only compatible with 3.42.0 (kernel 5.15+) or later.

This is because it is still picking up the vulkan driver in the appimage, you have to use a vulkan layer that lets you select a specific vulkan driver. (the one from your system).

Also please do all these tests with the vkcube+glxgears demo.

[kero990]

Regarding the test results of the demo you mentioned, there are no obvious errors in the terminal. However, the rotating cube in vkcube stutters quite a bit, and I'm not sure if this is normal.

./gtk4-demo-aarch64.AppImage 
 [gtk-class-fix.so] Setting window class to 'fuck.gnome'

(fuck.gnome:798861): Gdk-WARNING **: 10:50:16.478: Cannot get portal org.freedesktop.host.portal.Registry version: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.host.portal.Registry”

(fuck.gnome:798861): Gtk-WARNING **: 10:50:17.243: No IM module matching GTK_IM_MODULE=fcitx found
** Message: 10:50:17.365: For syntax highlighting, install the “highlight” program
inspur@inspur-PC:~/Downloads/tmp/1/a/AnyLinux$ ./zink-vkcube+glxgears-demo-aarch64.AppImage 
Selected WSI platform: xcb
WARNING: radv is not a conformant vulkan implementation, testing use only.
Selected GPU 0: AMD RADV OLAND (LLVM 7.0.1), type: DiscreteGpu

Of course, as I mentioned at the beginning, gtk4 supports fcitx5 or falls back to ibus, but it does not support fcitx4 at all. So gtk itself is not the problem; the issue is that for fcitx4 users, they have no input method.

[Samueru-sama]

inspur@inspur-PC:~/Downloads/tmp/1/a/AnyLinux$ ./zink-vkcube+glxgears-demo-aarch64.AppImage
Selected WSI platform: xcb
WARNING: radv is not a conformant vulkan implementation, testing use only.
Selected GPU 0: AMD RADV OLAND (LLVM 7.0.1), type: DiscreteGpu

What happens if you use vkcube+glxgears demo? (The one without zink in its name).

iirc the zink one wasn't patched for older kernels.

[kero990]

The one without zink looks much more normal; zink has a sort of repeatedly stuttering feel. The terminal output is exactly the same.

./vkcube+glxgears-demo-aarch64.AppImage 
Selected WSI platform: xcb
WARNING: radv is not a conformant vulkan implementation, testing use only.
Selected GPU 0: AMD RADV OLAND (LLVM 7.0.1), type: DiscreteGpu

It's worth mentioning that your AppImages all experience a few to a dozen seconds of extreme lag when running for the first time on my machine—the kind where even the mouse can't move. I'm not sure what the reason is, because there is absolutely no relevant terminal output; it basically only happens when each AppImage is run for the first time.

The only difference is that vkcube lags for a dozen seconds after the interface appears, while other applications lag for a dozen seconds before the interface appears.

[Samueru-sama]

hold on second, your system is aarch64????