[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3] audio: add help option for -audio and -audiodev
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v3] audio: add help option for -audio and -audiodev |
Date: |
Fri, 9 Sep 2022 14:50:09 +0100 |
User-agent: |
Mutt/2.2.6 (2022-06-05) |
On Fri, Sep 09, 2022 at 03:41:22PM +0200, Claudio Fontana wrote:
> On 9/9/22 00:05, Paolo Bonzini wrote:
> > Il gio 8 set 2022, 15:47 Claudio Fontana <cfontana@suse.de> ha scritto:
> >
> >> On 9/8/22 11:39, Paolo Bonzini wrote:
> >>> Queued, thanks.
> >>>
> >>> Paolo
> >>>
> >>>
> >>
> >> Thanks. When it comes to programmatic checks about what QEMU supports in
> >> terms of audio,
> >>
> >> is there something that can be done with QMP?
> >>
> >> I checked the QMP manual at:
> >>
> >>
> >> https://qemu.readthedocs.io/en/latest/interop/qemu-qmp-ref.html#qapidoc-2948
> >>
> >> but in the "Audio" section there is a bunch of Objects and enums defined,
> >> but no command to query them...
> >>
> > No, there's nothing yet.
You're now reminding me of the patch I sent a while ago for reporting
audiodev backends and then completely forgot to followup on
https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg00656.html
> Interesting. What about Display (ie ui-*) ? I mean how do I figure out from,
> say, libvirt,
> everything that QEMU can do in terms of display, which drivers are actually
> installed?
>
> Same for block...
>
> with the increasing modularization of QEMU we should I presume strengthen the
> discoverability of QEMU capabilities right?
> This way we can configure once, and install just what is needed to match the
> user requirements, or distro variant.
>
> As Markus mentioned maybe a more general solution would be to have these
> things as qom objects so that a
>
> qom-list-types
> can be used to get all 'audiodev' types, or all 'display' types, or all
> 'block' types and solve the problem this way?
> Is there a more general problem / solution that I am not seeing?
In an idealized world (where we can ignore the reality of our
existing legacy codebase) I think all backends would simply
be QOM objects, and created with -object, avoiding the need for
any backend type specific CLI args like -audiodev / -netdev / etc.
This would actually also extend to frontends, devices, cpus,
machine types etc all being objects, ought to be creatable via
-object, not requiring -device, -machine.
If we lived in the world where everything was a QOM Object,
then qom-list-types would serve as the universal detection
mechanism for everything.
Back in our current reality of pre-existing legacy code though,
we have to be a little more pragmattic. If we can make things
into QOM objects that work with -object / qom-list-types that's
great, but if it is too much work we'll just have to create other
QMP commands for querying, such as the query-audiodev patch.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [PATCH v3] audio: add help option for -audio and -audiodev, Claudio Fontana, 2022/09/08
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Paolo Bonzini, 2022/09/08
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Claudio Fontana, 2022/09/08
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Paolo Bonzini, 2022/09/08
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Markus Armbruster, 2022/09/09
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Claudio Fontana, 2022/09/09
- Re: [PATCH v3] audio: add help option for -audio and -audiodev,
Daniel P . Berrangé <=
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Claudio Fontana, 2022/09/09
- Re: [PATCH v3] audio: add help option for -audio and -audiodev, Daniel P . Berrangé, 2022/09/09
Re: [PATCH v3] audio: add help option for -audio and -audiodev, Markus Armbruster, 2022/09/16