qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC QEMU PATCH] ui: Make the DisplayType enum entries conditional


From: Thomas Huth
Subject: Re: [RFC QEMU PATCH] ui: Make the DisplayType enum entries conditional
Date: Thu, 10 Jun 2021 07:20:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0

On 09/06/2021 14.50, Gerd Hoffmann wrote:
   Hi,

The #if CONFIG_SDL approach will not work because qemu will continue to
report sdl as supported even when the sdl module is not installed any
more.

I guess we'd need a separate QMP command to fix that, which tries to load
the modules first when being called? Something similar to what is being done
in qemu_display_help() ?

That would work, yes.

That's certainly doable, too, just a little bit more complex...

Alternative idea: turn QemuDisplay into an ObjectClass, then it'll be
visible in qom introspection.  Likewise a bit more complex ...

do we want that?  Or is the quick-n-easy way via the schema good
enough for most use cases?

Would be better than nothing, but I'd prefer something which works
properly with modular qemu ...

I'm not sure whether we can even make it 100% rock solid if we introduce a dedicated QMP command here. For example imagine that libvirt did its probing while a X11 server was running, so it discovered that QEMU could be used with SDL. Now the user stops the X11 server, thus the cached information that QEMU could be used with SDL becomes useless. I think that's somehow similar to the situation whether the module is available or not. The information that is shown by "virsh domcapabilities" can only be an indication of what can be used in the best case (module available, X11 server running etc), but it can never be a 100% guarantee that the UI interface can really really be used. Thus I tend to continue with the simple way via the QAPI schema right now, unless someone really has an urgent need for a separate QMP command (at least for the BZ that I listed in my original mail, the simple way via the QAPI schema is enough).

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]