On Wed Apr 1, 2026 at 3:43 PM +05, Markus Armbruster wrote: > "Sergei Heifetz" <[email protected]> writes: > >> 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. > > I guess a brief release note should suffice. As long as the affected > interfaces are obviously audio-related, enumerating them seems > unnecessary.
Understood, thank you. >>>> + (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). > > Context: this is in an SRST...ERST section of qemu-options.hx. > > As far as I can tell, we simply ignore the possibility of the thing > being compiled out when we document a thing there. > > Drop the patch hunk? OK. >>> [...]
