On Thu Mar 19, 2026 at 12:58 PM +05, Markus Armbruster wrote: > Sergei Heifetz <[email protected]> writes: > >> D-Bus display can be used even when QEMU is configured with >> `--disable-audio`. In that case, audio interface will not be available >> on `/org/qemu/Display1/Audio`. >> >> (The current handling of the situation when audio is enabled but >> no D-Bus-compatible audio backend is available is different and >> hasn’t been changed.) >> >> Signed-off-by: Sergei Heifetz <[email protected]> >> --- >> qapi/ui.json | 2 +- >> qemu-options.hx | 4 ++++ >> ui/dbus.c | 8 ++++++++ >> 3 files changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/qapi/ui.json b/qapi/ui.json >> index e3da77632a8..62eb05c6091 100644 >> --- a/qapi/ui.json >> +++ b/qapi/ui.json >> @@ -1385,7 +1385,7 @@ >> 'data' : { '*rendernode' : 'str', >> '*addr': 'str', >> '*p2p': 'bool', >> - '*audiodev': 'str' } } >> + '*audiodev': { 'type': 'str', 'if': 'CONFIG_AUDIO' } } } > > Is this a compatibility break? > > DisplayDBus is only used in DisplayOptions, which is only used as return > type of query-display-options in the QAPI schema. However, vl.c also > uses it to parse -display. > > Removing parameter @audiodev from -display is technically a > compatibility break. However, we're removing an optional paramater that > would always be rejected when present: it has no valid value, because > there are no audiodevs. > > Removal from query-display-options is similar: it could not be present. > > Removal affects introspection, which could conceivably confuse client. > I don't expect such trouble here, because @audiodev always existed, i.e. > there's no real reason to look for it in introspection. > > I think we're okay. I'm cc'ing the libvirt list just in case.
These are questions I would like to know the answers to as well. From my perspective, disabling compilation of the audio subsystem is worth it, but you should expect to potentially tweak a few audio-related things to make it work. I agree that technically makes it a compatibility break. But preserving meaningless parameters (like audiodev in the total absence of audio) certainly makes less sense to me. > Do we need a release note? > > Do we need an entry in docs/about/removed-features.rst? Feels a bit > odd; we're not removing a feature, we're adding one, namely "can compile > out audio". > Maybe we should add something like, "If you compile out audio, be careful with these things: [list of changes]". But honestly, I don't know. I'd be happy to add whatever is needed. >> + (If audio is disabled at compile time via the ``--disable-audio`` >> option, >> + no audio backend is used, and none of the audio-related D-Bus >> interfaces >> + are exported.) >> [...] > > Well, audio is either compiled in or it isn't. > > If it's compiled in, then why tell the user how things behave when it's > not? > > If it's not compiled in, then why document stuff that doesn't work? How > much of -audiodev still works then? -audiodev none? Anything else? I agree it's weird, but I don't see a clear way around it. Simple ifdef'ing isn't possible in a reStructuredText section (at least I couldn't get it to work). > [...]
