On Tue, Mar 17, 2026 at 12:51:14PM +0400, Marc-André Lureau wrote:
> Add a standalone VNC server binary that connects to a running QEMU
> instance via the D-Bus display interface (org.qemu.Display1, via the bus
> or directly p2p). This allows serving a VNC display without compiling
> VNC support directly into the QEMU system emulator, and enables running
> the VNC server as a separate process with independent lifecycle and
> privilege domain.

IIUC, this new binary is linking to all the existnig ui/vnc.c
code, so there's no actual new impl of the RFB protocol, just
a new glue layer for launching the existing impl with comms
over DBus instead of from direct callback functions ?

> Built only when both VNC and D-Bus display support are enabled.
> If we wanted to have qemu -vnc disabled, and qemu-vnc built, we would
> need to split CONFIG_VNC. This is left as a future exercise.
> 
> I left out for now:
>  - sasl & tls authz

IMHO these are must have features, as the default VNC protocol
security is a very bad joke.

>  - some runtime functionalities (better done by restarting)
>  - a few legacy options
>  - Windows support
> 
> Signed-off-by: Marc-André Lureau <[email protected]>
> ---
>  MAINTAINERS                    |   5 +
>  docs/conf.py                   |   3 +
>  docs/interop/dbus-display.rst  |   2 +
>  docs/interop/dbus-vnc.rst      |  26 ++
>  docs/interop/index.rst         |   1 +
>  docs/meson.build               |   1 +
>  docs/tools/index.rst           |   1 +
>  docs/tools/qemu-vnc.rst        | 199 +++++++++++
>  meson.build                    |  17 +
>  contrib/qemu-vnc/qemu-vnc.h    |  46 +++
>  contrib/qemu-vnc/trace.h       |   4 +
>  contrib/qemu-vnc/audio.c       | 307 +++++++++++++++++
>  contrib/qemu-vnc/chardev.c     | 127 +++++++
>  contrib/qemu-vnc/clipboard.c   | 378 +++++++++++++++++++++
>  contrib/qemu-vnc/console.c     | 168 ++++++++++
>  contrib/qemu-vnc/dbus.c        | 439 ++++++++++++++++++++++++
>  contrib/qemu-vnc/display.c     | 456 +++++++++++++++++++++++++
>  contrib/qemu-vnc/input.c       | 239 ++++++++++++++
>  contrib/qemu-vnc/qemu-vnc.c    | 450 +++++++++++++++++++++++++
>  contrib/qemu-vnc/stubs.c       |  66 ++++
>  contrib/qemu-vnc/utils.c       |  59 ++++

IMHO we should not really be adding more things to the contrib
directory, and rather wish most of the existing stuff was
not there. When I see "contrib" directories in projects, the
message is generally "unmaintained, abandoned junk".

If this is a serious maintained feature we expect people to use,
it should be formally under the ui/ directory, possibly a
'ui/dbus-vnc' subdir ?

>  tests/qtest/dbus-vnc-test.c    | 733 
> +++++++++++++++++++++++++++++++++++++++++
>  contrib/qemu-vnc/meson.build   |  26 ++
>  contrib/qemu-vnc/qemu-vnc1.xml | 174 ++++++++++
>  contrib/qemu-vnc/trace-events  |  20 ++
>  meson_options.txt              |   2 +
>  scripts/meson-buildoptions.sh  |   3 +
>  tests/dbus-daemon.sh           |  14 +-
>  tests/qtest/meson.build        |   8 +
>  29 files changed, 3971 insertions(+), 3 deletions(-)
> 

> diff --git a/meson_options.txt b/meson_options.txt
> index 31d5916cfce..ef938e74793 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -119,6 +119,8 @@ option('vfio_user_server', type: 'feature', value: 
> 'disabled',
>         description: 'vfio-user server support')
>  option('dbus_display', type: 'feature', value: 'auto',
>         description: '-display dbus support')
> +option('qemu_vnc', type: 'feature', value: 'auto',
> +       description: 'standalone VNC server over D-Bus')

Every option is about QEMU, so 'qemu_' on a name feels redundant,
and QEMU alrady has a VNC server too.

I suggest 'dbus_vnc' is possibly a better name


>  option('tpm', type : 'feature', value : 'auto',
>         description: 'TPM support')
>  option('valgrind', type : 'feature', value: 'auto',

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 :|


Reply via email to