Re: [Qemu-devel] Question about hardware cursor in VGA

[BALATON Zoltan]

On Thu, 7 Mar 2019, Gerd Hoffmann wrote:
> On Wed, Mar 06, 2019 at 02:50:36PM +0100, BALATON Zoltan wrote:
> > On Wed, 6 Mar 2019, Gerd Hoffmann wrote:
> > > On Wed, Mar 06, 2019 at 12:48:59AM +0100, BALATON Zoltan wrote:
> > > > On Tue, 5 Mar 2019, Gerd Hoffmann wrote:
> > > > > Use dpy_cursor_define().
> > > >
> > > > I've done that but it's not working very well. The mouse pointer is quite
> > > > jumpy with this and there are some problems updating the pointer image when
> > > > the guest changes image data in video ram without changing registers. (Like
> > >
> > > When using a relative pointing device (i.e. mouse instead of tablet) you
> > > also need dpy_mouse_set(), to update the host mouse position when the
> > > guest moves the cursor sprite around.
> >
> > Sure, I figured that out otherwise the mouse pointer would not move.
> >
> > > Is it possible to figure where the cursor hotspot is?
> >
> > Not sure what you mean. I call dpy_mouse_set() on writing the reg that
> > contains mouse position. Hot spot is always top left of sprite (or I don't
> > know where it's set). I'll submit a v5 after adding some more checks to make
> > it a bit safer then you can have a look.
>
> Well, paravirtual graphics devices propagate the hot-spot information
> from the guest to the host.  But on real hardware you typically don't
> have registers for that information as the GPU doesn't need to know the
> hotspot for cursor display.  The guest driver can simply take the
> hotspot location into account when programming the cursor position into
> the hardware registers.
>
> So, the suggestion to use dpy_cursor_define() wasn't a good one after
> all.  I totally forgot about the hotspot issue as I work with
> paravirtual graphics devices most of the time.  Sorry for that.

Hmm, OK but this still does not explain why mouse is jumping when it's 
just moved around without changing the image.

> > > > least doing hw cursor like this works somewhat but I note that the other
> > > > version with cursor_invalidate and cursor_draw_line callbacks worked much
> > > > smoother, alas I've found that cannot work with shared_surface.
> > >
> > > There is a VGAComminState->force_shadow ...
> >
> > Yes, but that would also make things slower so I like to keep advantage of
> > shared_surface and try to fix the jumpy mouse we get with define_cursor
> > instead if possible.
>
> Its not so much a performance issue.  But you need a round-trip to the
> guest to update the cursor position, which adds noticeable latency to
> mouse moves ...

It's not a big performance issue when rendering the mouse but may be when 
rendering the screen having to copy contents to the display surface at 
each refresh (at least the part that changed) instead of using it directly 
from guest VRAM with shared_surface where this copy is avoided if I got 
that right.

I still have the unfinished version using the callbacks which might work 
with force_shadow like for cirrus but I'd need to finish and clean that 
up. Now that we have both implemented probably will allow switching 
between them but may not be able to do it before the freeze so don't wait 
for that. (The define_cursor way is enough for testing at the moment and 
rewriting it to use different callback could be considered bugfix or 
added in next devel cycle as well.)

Regards,
BALATON Zoltan