egl_gallium.so was able to use llvmpipe and direct that rendering to wl_shm based buffers, and therefore does not need any EGL support from the compositor.

egl_dri2 does not implement that.

Could egl_dri2 be worked to implement it? What other options there are?

If someone suggests VGEM, then that will require special support in the compositor, and I will ask how compositors are supposed to support that and what do you do on systems with kernels that don't support VGEM.

This removal prevents any application from using llvmpipe on wayland, even with LIBGL_ALWAYS_SOFTWARE.

It still works fine on Xwayland and egl_dri2, but this isn’t a suitable fallback.

Imo the best fix would be to wire llvmpipe to egl_dri2 on wayland too.

Actually we seem to have an even older report of a similar thing: bug #64045

That other report seems to be when there was a bug in software rendering that ended up being fixed, as software rendering was working mostly until it was dropped. Without software rendering, many clients don't work well on VirtualBox and fbdev. (weston-desktop-shell appears to be limited to 16 bit color even) I don't know if the --use-gl option for Weston's fbdev backend is meant to work withou libhybris? 

Unfortunantly, VirtualBox probably isn't going to support running drm-backend properly for a long time, plus a software fallback would be nice for fallback some hardware platforms

(In reply to nerdopolis1 from comment #4)
> I don't know if the --use-gl option for Weston's fbdev backend
> is meant to work withou libhybris? 

No, I don't think that will ever work on a FOSS driver stack. It's just for proprietary stacks that do not bother with proper DRM drivers, hybris or not.

Weston's compositing on a software rendered GLESv2 would be fairly useless since Pixman renderer exists. Besides, even if Weston used sw GL, it still wouldn't improve the situation for apps at all.

Any updates on this one?

Today I fetched the Mesa master branch and grepped for wl_shm. The only hits are in src/gallium/state_trackers/egl/wayland/native_shm.c.

Therefore there is no implementation for egl_dri2 yet, and the issue persists.

Seems that there is still no way for running weston-simple-egl or weston-gears on software rendering?

SW rastering for EGL is really an important feature for us. We have an embedded device with no GPU and no display. We are planning on using Wayland/Weston with RDP protocol to display OpenGl graphics over network connection. Current MESA doesn't seem to support this functionality.

This is a very important feature for us, too. Reading the upstream thread, it seems there were legitimate reasons to remove egl-gallium, but bringing egl_dri2 to feature parity before doing that was ignored.

This needs insight from a proficient developer. Will try to help but have few experience personally. Distro-side, we will probably stick to an older Mesa until a solution is found.

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.

(In reply to Marek Olšák from comment #11)
> 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.

Two reasons why VGEM is less helpful on Wayland than X11:
  - MIT-SHM on X forces you to allocate out of POSIX/SysV (forget which) SHM regions, i.e. shmat() and friends; this is not true of wl_shm, which lets you specify an arbitrary fd, as long as it's mmap()able
  - MIT-SHM requires you to schedule a server-side copy out of the SHM Image to a Drawable (Pixmap or Window), whereas DRI2 adds the notion of flips and exchanging storage; this is not true of wl_shm, as the wl_surface/wl_buffer model natively supports buffer exchange

So I think just the relatively obvious wl_shm approach - which is less divergent from the existing platform_wayland.c code than platform_x11's, given that it shares the same buffer<->surface relationship, only diverging at buffer allocation - will do just fine.

Patch series posted by Axel Davy:
http://lists.freedesktop.org/archives/mesa-dev/2015-May/083254.html
Reviews combined from Daniel Stone and Dave Airlie cover it all.

The patch series has landed in Mesa, particularly:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cdcfe48fb0431184fabb40aa5a244d086f551df5

Feel free to test how the software GL on Wayland with Mesa master branch works.

Created attachment 115713 [details]
backtrace of weston-desktop-shell

backtrace of weston-desktop-shell on qemu with Weston running under the Framebuffer backend. Unfortunately weston-desktop-shell hangs

Adding Axel Davy to CC.

Hi. I realized that the hang happens when I hover over an icon on the desktop shell, and it tries to show a tooltip

Output of weston running with WAYLAND_DEBUG=server
http://pastebin.com/0aQGBLFH

Only weston-desktop-shell hangs. If I get another client to run before weston-desktop-shell hangs, that client stays running.

As suggested as a test, before running Weston, I exported 
vblank_mode=0

And this prevents the hangs

(In reply to nerdopolis1 from comment #18)
> Hi. I realized that the hang happens when I hover over an icon on the
> desktop shell, and it tries to show a tooltip
> 
> Output of weston running with WAYLAND_DEBUG=server
> http://pastebin.com/0aQGBLFH

Please don't put pastebin links here, they tend go bad over time. Much better to attach a file.

> Only weston-desktop-shell hangs. If I get another client to run before
> weston-desktop-shell hangs, that client stays running.

*sigh* I wish we had a way to differentiate between clients in WAYLAND_DEBUG=server output... (there are several different clients interleaved in the trace, but I expected that)

Ok, I see what happens.

The tooltip is a sub-surface (due to migration to xdg-shell). Sub-surfaces start in synchronized mode, and the mode is never changed here. That means the frame callback cannot trigger, until the parent wl_surface is committed. Toytoolkit or weston-desktop-shell does not commit the parent before EGL starts waiting for the sub-surface's frame callback, which causes the hang.

The immediate thing to investigate is whether EGL even gives the app a chance to commit the parent wl_surface (which also is a EGLSurface when you use cairo-egl). If the answer is yes, there is nothing wrong in Mesa, and the bug is in toytoolkit.

Whether the answer is yes or no, this issue needs to be filed as a separate bug against Weston's toytoolkit.

As fixing the toytoolkit is very low priority (and I would assume hardware accelerated GL to be broken the same way), the solution for end users is: do not configure Weston using --with-cairo=gl nor --with-cairo=glesv2; use the default --with-cairo=image.

A quick'n'dirty fix would be to set the tooltip sub-surface to desync mode when it's created. That should avoid the hang, but it may be arguably a wrong solution. One must be able to use the synchronized mode even with EGL surfaces, so making sure it can work is essential.

When filing a new bug, please copy my explanation and attach again the same protocol dump.