On 6/5/26 9:07 AM, Akihiko Odaki wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender
and know the content is safe.
On 2026/06/05 21:52, Alexander Kanavin wrote:
On Fri, 5 Jun 2026 at 10:10, Daniel P. Berrangé <[email protected]>
wrote:
It's the same issue, I assure you. Qemu 10.x prints nothing and
simply
starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
(even though there's no wayland running on the build hosts), and then
finally crashes, with the traceback that RP provided.
I don't think it's a race condition, as the failure is deterministic,
but I agree that something has changed in qemu's GL initialization
sequence.
Cc'ing Marc-André & Akihiko
Context:
https://lore.kernel.org/openembedded-core/7da33301e8a0bae93a33695b4fd41f67a08e1b9f.ca...@linuxfoundation.org/
If it is an suspected regression between 10.2 and 11.0, then
I'd suggest someone who is able to reproduce the issue reliably
should do a 'git bisect' to narrow it down precisely.
I've done additional testing, and I can confirm:
1. Reverting the following commit fixes the issue:
commit 52053b7e0a0e285ce3448b830053b05fb0a9b1a8
Author: Pierre-Eric Pelloux-Prayer <[email protected]>
Date: Wed Mar 4 16:50:30 2026 +0000
ui/sdl2: Implement dpy dmabuf functions
2. Updating to 11.0.1 does not fix the issue. It includes a fix for a
different, but related problem:
674221887f ui/sdl2: Fix assumption of EGL presence at runtime
Note that the environment we run in is X11 without wayland, e.g. a
XTigervnc server that provides a X11 display.
Cc'ing Pierre-Eric Pelloux-Prayer
My best bet is that SDL_HINT_VIDEO_X11_FORCE_EGL triggered the host
issue, but the stack trace cited above contradicts with that. I don't
exclude the possibility of a QEMU bug either.
Can you confirm the stack trace is from a run with X11? If so, the next
step would be to symbolize the stack trace. Otherwise, re-generating the
stack trace with X11 may help.
Regards,
Akihiko Odaki
Hi Odaki,
I think I mentioned also in another email that this commit 52053b7e0a
("ui/sdl2: Implement dpy dmabuf functions") may have caused the issue,
which added the sdl2_set_hint_x11_force_egl() function:
static void sdl2_set_hint_x11_force_egl(void)
{
Display *x_disp = XOpenDisplay(NULL);
EGLDisplay egl_display;
if (!x_disp) {
return;
}
egl_display = eglGetDisplay((EGLNativeDisplayType)x_disp);
if (egl_display != EGL_NO_DISPLAY) {
SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
eglTerminate(egl_display);
}
XCloseDisplay(x_disp);
}
The above function probes whether EGL is available on the X display. If
eglGetDisplay() returns EGL_NO_DISPLAY (which can happen with llvmpipe on
certain VNC configurations, for example), the hint is never set, and SDL
falls back to GLX.
GLX then tries DRI3, finds only the vgem driver (no real GPU), and crashes.
In QEMU 10.2.0, this function didn't exist — SDL would use whatever GL
backend
was available (GLX with software rendering via llvmpipe worked fine because
it didn't attempt DRI3).
Possible Fixes could be: Setting the EGL hint unconditionally when on
X11 (remove the probe):
static void sdl2_set_hint_x11_force_egl(void)
{
#if defined(SDL_HINT_VIDEO_X11_FORCE_EGL) && defined(CONFIG_OPENGL) &&
defined(CONFIG_X11)
SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
#endif
}
Thanks,
Quan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#238178):
https://lists.openembedded.org/g/openembedded-core/message/238178
Mute This Topic: https://lists.openembedded.org/mt/119658594/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
