Re: [PATCH 4/4] ui/vnc: notify client of clipboard peer status

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Aug 24, 2026 at 04:36:12PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Aug 18, 2026 at 5:56 PM Lucas Kornicki
> <lucas.kornicki@nutanix.com> wrote:
> >
> > Hi Marc-Andre
> >
> > I quickly became aware of the shortcomings of my v1 series and I've
> > already drafted a v2 where the cover is a bit more detailed and the
> > commits were fixed to remove the Change-IDs.
> >
> > On 8/18/26 15:33, Marc-André Lureau wrote:
> > > !-------------------------------------------------------------------|
> > >    CAUTION: External Email
> > >
> > > |-------------------------------------------------------------------!
> > >
> > > Hi Lukasz
> > >
> > > On Tue, Aug 18, 2026 at 4:15 PM Lukasz Kornicki
> > > <lucas.kornicki@nutanix.com> wrote:
> > >> Introduce a new vnc message (VNC_MSG_SERVER_QEMU_CLIPBOARD_STATUS) and
> > >> the corresponding feature/encoding.
> > >>
> > >> When a client requests this feature, the server will inform the client
> > >> whether a guest clipboard peer is present. The server will repeat the
> > >> notification each time availability of a guest clipboard peer changes.
> > >>
> > >> This change enables the VNC client to determine if a guest side
> > >> clipboard peer is available for clipboard exchange and react to
> > >> changes of its availability.
> > >>
> > >> Until now the VNC clipboard peer was only registered when
> > >> VNC_FEATURE_CLIPBOARD_EXT was enabled. With this change the VNC peer
> > >> can be registered just for the purpose of receiving peer status
> > >> updates. This requires introducing a VNC_FEATURE_CLIPBOARD_EXT guard
> > >> before the QEMU_CLIPBOARD_UPDATE_INFO handler which previously only ran
> > >> if VNC_FEATURE_CLIPBOARD_EXT was enabled.
> > >>
> > > The series looks good, but this extension is not documented afaict.
> > > Can you make a PR for it?
> >
> > Sure. I've found this repo before but was not aware that it functions in
> > any official capacity.
> 
> I dont think we should take the change until the rfbproto documents it.

Yes, please submit an rfbproto  PR for the extension, as we've tried
to ensure everything QEMU implements is specified there to aid in
future interoperability and to spot design mistakes at spec time.

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