On Tue, Mar 06, 2018 at 12:56:55PM +0100, Marc-André Lureau wrote:
> Hi
> On Tue, Mar 6, 2018 at 9:38 AM, Gerd Hoffmann <kra...@redhat.com> wrote:
> > Add support for cursor dmabufs.  qemu has to render the cursor for
> > that, so in case a cursor is present qemu allocates a new dmabuf, blits
> > the scanout, blends in the pointer and passes on the new dmabuf to
> > spice-server.  Without cursor qemu continues to simply pass on the
> > scanout dmabuf as-is.
> >
> > Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
> What about client side rendering mode? (for responsiveness etc)

Note that client side cursor rending needs guest support.  Intel added
some extra paravirtual registers for the hotspot location (on physical
hardware this isn't needed).  So client-side cursor rendering will only
work for guests which have support for those extra registers, and we
will need the current rendering code *anyway* in case we don't get the
hotspot location from the guest.  So I figured I go with this code base
for now, put it into shape and run for 2.12 merge.

> Why not read the cursor data and pass it as regular cursor update? I
> don't think such a small and infrequent CPU read will impact
> performance much.

Well, it's not *that* infrequent.  Cursor shape might have changed even
if the dmabuf is still the same (i.e. guest didn't place the cursor
elsewhere in memory).  Also note that Intel uses a 256x256 cursor sprite
(with most of it being unused), so it isn't that small either.

But, yes, I plan to check that out and try to send the cursor as regular
spice cursor update.  Will probably not make 2.12 though, too much
higher priority stuff in the pipeline ...


Reply via email to