Ubuntu 21.04 QEMU virgl Couldn't find current GLX or EGL context

Hi Von,
thanks for the report!

I used to have this in the past:
$ qemu-system-x86_64 -machine ubuntu,vmport=off -cpu host -accel kvm -smp 2 -m 1G -device virtio-mouse -device virtio-keyboard -device virtio-vga,virgl=on -display gtk,gl=on -usb -nodefaults -monitor vc ...

That worked with the 4.2 in Focal and the 5.0 in groovy.
It can be run without a disk image just to see it qemu would start up properly, but needs a local Desktop env (not a remote X11 through e.g. ssh).

The stack for Groovy->Hirsute for virgl isn't too different:
  virgl: 0.8.2-4 -> 0.8.2-5
(no functional change between those)
Qemu did jump 5.0 -> 5.2 thou
  1:5.0-5ubuntu9.2 -> 1:5.2+dfsg-3ubuntu1

For me my command above is starting on Hirsute just as much as on the former releases.

On searching for the issue I found various:
- https://patches.openembedded.org/patch/166423/
- https://github.com/anholt/libepoxy/issues/163
- https://github.com/flathub/ca._0ldsk00l.Nestopia/issues/1

The pattern there is that the particular error messages seem to be in any sort of SW if the GTK/X stack fails to initialize.

But OTOH I guess you'd have noticed if no UI at all would be present anymore :-)
So I wonder if the new builds need some feature that is now missing - e.g. I think of the various acceleration features.

The fail itself (in all such cases) is in libepoxy.
But that is on the same version/build throughout Focal->Hirsute.
 libepoxy0 | 1.5.4-1 | focal | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 libepoxy0 | 1.5.4-1 | groovy | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 libepoxy0 | 1.5.4-1 | hirsute | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Since it works for me on the same qemu and the theory is that we need to hunt for something in your UI stack that changes I'll mark qemu incomplete until we have found more.
At the same time I'll add a libepoxy task to bring in people knowing what all it would check.

@Vun - there are two angles we can IMHO attack this:
1) check if qemu changed (even if working for me). To check that you might enable the groovy repositories and downgrade qemu to 1:5.0-5ubuntu9.3 (a bit hacky but good for a try). Try to change nothing else - if any libs will be installed as dependency please report. Let me know if you manage to get an "all else is unchanging but qemu 5.0 works whie 5.2 fails" situation

2. check the glx/egl status on old vs new environment (Kernel / X stack). I'd think of e.g.
$ glxinfo
$ for i in $(gegl --list-all); do gegl -v --info $i; done
$ git clone https://github.com/KDAB/eglinfo.git
$ cd eglinfo
$ apt install qtchooser qt5-default build-essential
$ qmake -o Makefile eglinfo.pro
$ make
$ ./eglinfo
Compare those outputs between old&new env is anything missing that might explain why it failed to initialize it?

Hi Christian,
thanks for replying!

I uploaded output from #2.2, however i tried to downgrade qemu without success. I will try to install ubuntu 20.04 on a physical machine latter.

It is worth mentioning that qemu(5.2+dfsg-3ubuntu1)+virgl works on GTK/Wayland without those errors. Outputs are included in info.tar.xz.

Thanks, looking forward for that later extra data as well then.

One thing to clarify, you said "qemu(5.2+dfsg-3ubuntu1)+virgl works on GTK/Wayland without those errors".
I'm slightly lost, isn't "qemu(5.2+dfsg-3ubuntu1)+virgl on GTK/Wayland" exactly what you initially reported as failing? If not what is different on the failing case to "qemu(5.2+dfsg-3ubuntu1)+virgl on GTK/Wayland"?

... I guess "qemu(5.2+dfsg-3ubuntu1)+virgl on GTK/X11" is the bad case then?

As I said I added a libepoxy task and subscribed ubuntu-desktop as this might be much more their home-turf to e.g. be up to date about known cases why that would fail to initialize GTK/EGL.

Sorry, I forgot to add X11 in the bug description. "qemu(5.2+dfsg-3ubuntu1)+virgl on GTK/X11" is the bad case.

Yeah that is what I thought - Thanks for confirming Von!

My search engine use on this case found a few but no really related issues either. If you happen to stumble over one please let me know.

Since it works fine for me I have to hope for the Desktop team taking a look from the libepoxy POV what might be wrong here.

We don't really have anyone knowing the libeproxy details in desktop so I'm not sure we are going to be able to provide more useful details. It works fine here on intel hardware, it could be an issue with the ati driver or the kernel...

@Von, does the example command line Christian gave fail for you?

$ qemu-system-x86_64 -machine ubuntu,vmport=off -cpu host -accel kvm -smp 2 -m 1G -device virtio-mouse -device virtio-keyboard -device virtio-vga,virgl=on -display gtk,gl=on -usb -nodefaults -monitor vc

if it's failing, could you add your 'journalctl -b 0 log' after getting the issue?

any chance you could try booting with an older kernel to see if that makes a difference?

I have the same problem. I am trying to run chromiumos x86 on aarch64.

My command line is:

 qemu-system-x86_64 -m 2048 -smp 2 -accel tcg -device nec-usb-xhci -device usb-kbd -device usb-mouse -usb -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -device virtio-blk-pci,drive=hd -drive if=none,file=chromiumos_qemu_image.bin,index=0,media=disk,cache=unsafe,format=raw,id=hd -netdev user,id=mynet -device virtio-net-pci,netdev=mynet

Output:
gl_version 0 - compat profile
WARNING: running without ARB robustness in place may crash
qemu-system-x86_64: Couldn't find current GLX or EGL context.