Hi On Thu, Jun 11, 2026 at 5:19 PM Akihiko Odaki <[email protected]> wrote: > > On 2026/06/11 18:03, Marc-André Lureau wrote: > > Add dbus_cleanup() to unparent the D-Bus display object, ensuring > > proper teardown before user_creatable_cleanup() runs. > > > > Signed-off-by: Marc-André Lureau <[email protected]> > > --- > > ui/dbus-console.c | 3 +++ > > ui/dbus.c | 13 +++++++++++++ > > 2 files changed, 16 insertions(+) > > > > diff --git a/ui/dbus-console.c b/ui/dbus-console.c > > index 742bf9639a4..63d21493101 100644 > > --- a/ui/dbus-console.c > > +++ b/ui/dbus-console.c > > @@ -152,6 +152,9 @@ dbus_display_console_dispose(GObject *object) > > DBusDisplayConsole *ddc = DBUS_DISPLAY_CONSOLE(object); > > > > qemu_console_unregister_listener(&ddc->dcl); > > + if (ddc->dcl.con) { > > + qemu_console_set_display_gl_ctx(ddc->dcl.con, NULL); > > Somewhat weird, but theoretically this may clear a console GL context > registered by another display. Below is an example I let an LLM generate > (not tested): > > qemu-system-x86_64 \ > -machine q35 \ > -device virtio-vga-gl \ > -display dbus,p2p=yes,gl=off \ > -spice unix=on,addr=/tmp/qemu-spice.sock,disable-ticketing=on,gl=on >
Right, it's a bit embarassing. I think spice should be a display (and vnc too eventually..), so we wouldn't have 2 competing console/display handlers that have their own GL. I think the safest for now is to simply prevent spice with a display providing GL. I'll work on a patch.
