Sergei Heifetz <heifetz@yandex-team.com> 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 <heifetz@yandex-team.com> --- 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. 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".
## # @DisplayGLMode: diff --git a/qemu-options.hx b/qemu-options.hx index 29dc865820a..20d15c0004f 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -2232,6 +2232,10 @@ SRST If no audio backend is specified and the dbus display backend is specified, the dbus audio backend is used by default.
+ (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?
The connection is registered with the "org.qemu" name (and queued when already owned).
[...]