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' } } }
##
# @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.)
+
The connection is registered with the "org.qemu" name (and queued when
already owned).
diff --git a/ui/dbus.c b/ui/dbus.c
index 4f24215555a..99dac3e7feb 100644
--- a/ui/dbus.c
+++ b/ui/dbus.c
@@ -217,6 +217,7 @@ dbus_display_complete(UserCreatable *uc, Error **errp)
return;
}
+#ifdef CONFIG_AUDIO
{
AudioBackend *audio_be = audio_get_default_audio_be(NULL);
if (audio_be && !audio_be_can_set_dbus_server(audio_be)) {
@@ -232,6 +233,7 @@ dbus_display_complete(UserCreatable *uc, Error **errp)
return;
}
}
+#endif
consoles = g_array_new(FALSE, FALSE, sizeof(guint32));
for (idx = 0;; idx++) {
@@ -370,6 +372,7 @@ set_dbus_addr(Object *o, const char *str, Error **errp)
dd->dbus_addr = g_strdup(str);
}
+#ifdef CONFIG_AUDIO
static char *
get_audiodev(Object *o, Error **errp)
{
@@ -386,6 +389,7 @@ set_audiodev(Object *o, const char *str, Error **errp)
g_free(dd->audiodev);
dd->audiodev = g_strdup(str);
}
+#endif
static int
@@ -412,7 +416,9 @@ dbus_display_class_init(ObjectClass *oc, const void *data)
ucc->complete = dbus_display_complete;
object_class_property_add_bool(oc, "p2p", get_dbus_p2p, set_dbus_p2p);
object_class_property_add_str(oc, "addr", get_dbus_addr, set_dbus_addr);
+#ifdef CONFIG_AUDIO
object_class_property_add_str(oc, "audiodev", get_audiodev, set_audiodev);
+#endif
object_class_property_add_enum(oc, "gl-mode",
"DisplayGLMode", &DisplayGLMode_lookup,
get_gl_mode, set_gl_mode);
@@ -502,7 +508,9 @@ dbus_init(DisplayState *ds, DisplayOptions *opts)
object_get_objects_root(),
"dbus-display", &error_fatal,
"addr", opts->u.dbus.addr ?: "",
+#ifdef CONFIG_AUDIO
"audiodev", opts->u.dbus.audiodev ?: "",
+#endif
"gl-mode", DisplayGLMode_str(mode),
"p2p", yes_no(opts->u.dbus.p2p),
NULL);
--
2.34.1
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).
>
[...]
On Thu, Mar 19, 2026 at 08:58:52AM +0100, Markus Armbruster wrote:
> 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.
Libvirt will almost always add -audiodev to all VMs, even if that
ends up being '-audiodev none'. For VNC it will always set the
audiodev property to resolve to this. Essentially, given our
minimum QEMU version always supports -audiodev, libvirt assumes
it is always available.
> 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?
IMHO, we need -audiodev none to always works, and other parts of the
schema should continue to accept audiodev.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
On Thu Mar 19, 2026 at 12:58 PM +05, Markus Armbruster wrote:
> 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.
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).
> [...]
"Sergei Heifetz" <heifetz@yandex-team.com> writes:
> On Thu Mar 19, 2026 at 12:58 PM +05, Markus Armbruster wrote:
>> 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.
>
> 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.
>>> + (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?
>> [...]
On Wed Apr 1, 2026 at 3:43 PM +05, Markus Armbruster wrote:
> "Sergei Heifetz" <heifetz@yandex-team.com> writes:
>
>> On Thu Mar 19, 2026 at 12:58 PM +05, Markus Armbruster wrote:
>>> 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.
>>
>> 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.
>>> [...]
© 2016 - 2026 Red Hat, Inc.