<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [regression] weston-simple-egl not running anymore inside qemu" href="https://bugs.freedesktop.org/show_bug.cgi?id=86701#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [regression] weston-simple-egl not running anymore inside qemu" href="https://bugs.freedesktop.org/show_bug.cgi?id=86701">bug 86701</a> from <a class="email" href="mailto:daniel@fooishbar.org" title="Daniel Stone <daniel@fooishbar.org>"> Daniel Stone</a> <pre>(In reply to Marek Olšák from <a href="show_bug.cgi?id=86701#c11">comment #11</a>) > Is it the EGL_WL_bind_wayland_display extension that you'd like to have or > something else? I'd like to understand exactly what is missing. Client-side support for swrast in src/egl/drivers/dri2/platform_wayland.c. platform_x11.c has a whole section (see dri2_initialize_x11_swrast) with alternate codepaths to support swrast. platform_wayland totally lacks this, so not only does $LIBGL_ALWAYS_SOFTWARE do nothing, but on Wayland servers lacking hardware GL support (e.g. EGL_WL_bind_wayland_display), there is no fallback to the wl_shm interface. Implementing this is the minimum requirement. Supporting swrast-on-VGEM (EGL_WL_bind_wayland_display support when running on swrast; client-side support for allocating VGEM backing buffers for swrast) would also allow us to cut down on alternate codepaths a little, but probably doesn't buy us too much.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>