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 ... cheers, Gerd
