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?

** Bug watch added: github.com/anholt/libepoxy/issues #163
   https://github.com/anholt/libepoxy/issues/163

** Bug watch added: github.com/flathub/ca._0ldsk00l.Nestopia/issues #1
   https://github.com/flathub/ca._0ldsk00l.Nestopia/issues/1

** Changed in: qemu (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912706

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1912706/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to