Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes

[Gerd Hoffmann]

  Hi,

> > The problem is that when using relative mouses, we can't really assume that
> > there is any relationship between the absolute position of the host cursor
> > vs. the guest cursor, we should only operate in deltas and even then, we
> > probably want to dampen them to compensate for the guest own acceleration.
> 
> The guest's own acceleration can easily be non-linear, so we can't 
> really tell. However, FWIW we basically have 2 modes
> 
>    1) absolute pointing device (usb tablet for example or vmmouse)
>    2) relative pointing device
> 
> In case 1, we can keep using the host cursor, and just tell the guest 
> where exactly the cursor is in absolute coordinates. This works very 
> well with VNC too ;).

Yep, #1 is the easy case and only that works reasonable well in qemu
today.

> In case 2, we can't tell anything at all. We can calculate the delta and 
> hope for the best. That's why with any backend that supports it, we 
> enable mouse grabbing here. In mouse grabbing mode we behave like any 
> game that may do whatever it likes with the mouse delta information.

There is dpy_mouse_set() which the gfx emulation can use to tell the UI
where the cursor actually is.  So we can move the host cursor to that
point, and sdl/gtk UIs attempt to do that.

Problem is that this has some latency due to the round-trip to the
guest.  Also things like mouse acceleration easily can make the mouse
pointer a bit jumpy.  I think it needs some experimentation to see
whenever operating in that mode can be made work well in practice.

On top of that I think we currently have some kind of feedback loop in
there, which makes the pointer quickly go totally wonky.  To be
debugged ...

> > But that means that the guest HW cursor is never quite where the host cursor
> > is. So unless the guest draws its own (or something like VNC can draw one),
> > we have a problem.
> 
> VNC can explicitly draw the host cursor at specific locations IIRC. You 
> can just send a packet where the cursor is at the moment.

Guess we should actually do that in vnc_mouse_set() then ;)

> I don't know 
> about SDL or GTK+ though.

See above.

> > I'm thinking that for relative mouse, we should probably draw a cursor 
> > ourselves
> > by moving / drawing the cursor pixmap on top of the display pixmap at the UI
> > backend (gtk/SDL) level... Or am I missing a big part of the puzzle ?
> 
> Can't we just always draw it ourselves with a second surface on top of 
> our normal guest screen?

We might want create some helper functions to do that, so UIs which need
it can use them.  I don't think we should do that unconditionally, UI
support for RGBA cursors isn't that bad.

> Then we can make the "real cursor" for GTK+ / 
> SDL / VNC be a 100% alpha cursor as soon as we enable this self-drawn 
> surface and can expose hardware pointers that the respective backend 
> couldn't support.
> 
> For example, IIRC VNC only supports 1-bit cursors. We certainly want 
> more fancy ones :).

SDL1 has 1bit cursors.
SDL2 has full RGBA cursors.
gtk has full RGBA cursors.
vnc has RGB cursors + 1-bit mask (with VNC_FEATURE_RICH_CURSOR).
spice has full RGBA cursors.

cheers,
  Gerd