Hello all, The recent qemu update (to 11.0) has regressed in a test that checks accelerated graphical rendering with SDL UI frontend. Rather than dig into the fail and fix it (or hope that someone else is able to figure it out), I'd like to put forward a proposal to simplify what the Yocto project enables and tests when it comes to qemu-native graphics.
The current situation is this: 1. qemu and its recipe support three UI frontends: SDL 2.x, Gtk 3.x and a built-in VNC server. By default, SDL and VNC are enabled, but not Gtk. 2. All three UI frontends can also optionally be used with accelerated GL rendering in the guest, using the resources of the host (e.g. a physical GPU, or a massively multi-core CPU). Virglrenderer is the key piece that provides this, its enabled by default, and runqemu has options to opt into it. 3. Without such acceleration, running interesting graphics in the guest is basically impossible or extremely sluggish. There are however issues and an ongoing support burden with this setup, particularly: 1. Every now and then the SDL/Gtk rendering regresses. It's difficult to reproduce and look into it, as it requires setting up a build on a machine that can run some kind of X server, and it also requires a bit of specialist knowledge. 2. Qemu doesn't support latest major releases of either SDL (3.x) or Gtk (4.x) and there's no indication that such support is forthcoming. 3. Yocto autobuilder worker machines need to provide a continuously running X server too, currently in the shape of XTigervnc. 4. Enabling SDL/Gtk in native qemu drags in a lot of native dependencies, particularly, the entire x11-native stack. 5. SDL/Gtk are not useful on the most typical yocto build machine: a headless server in a closet. They need a physical screen, and the user sitting in front of it. It's possible to redirect into a X vnc server, like the autobuilder does, but then one might as well use qemu's own vnc support. So the proposal is this: 1. Disable SDL UI frontend by default in qemu-system native. The option isn't going away, it just isn't on by default. 2. Disable the test that checks that accelerated graphics with sdl/gtk frontend works. There's a second test that checks accelerated headless graphics, and that remains, as it can be used with qemu's own vnc server. 3. Yocto documentation is adjusted to explain that the project's supported and recommended way to see the graphical output is to use qemu's vnc feature. I don't feel this would cause a significant reduction in usability, but it will greatly reduce the support burden, and the amount of things that need to be built to get to working qemu-system-native. Cheers, Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2374): https://lists.openembedded.org/g/openembedded-architecture/message/2374 Mute This Topic: https://lists.openembedded.org/mt/119596308/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
