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

[Alexander Graf <agraf@suse.de>]

On 06.07.14 12:13, Benjamin Herrenschmidt wrote:
> On Sun, 2014-07-06 at 17:22 +1000, Benjamin Herrenschmidt wrote:
>>   - With SDL, the cursor quickly goes bonkers, starts jumping around all
>> over the place, I'm not sure what exactly is going on here. It starts ok
>> but as soon as one does a too fast movement, it's dead.
> At least this one also happens with gtk and appears to be the guest (NT4)
> "warping" the cursor to the edges of the screen as soon as you start moving
> too quickly. I'm not quite sure what's going on yet, so far I've seen us
> send reasonable deltas down. I *suspect* it might have to do with NT's
> own mouse acceleration scheme.
>
> The way we do the relative mouse stuff, we more/less assume that the diff
> we send down gets applied "as is". It's not and thus we warp which causes
> funny artifacts and when it gets too big, things get nasty inside NT4 itself
> as far as I can tell (but I may well have missed something).
>
> 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 ;).

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.

> 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. I don't know 
about SDL or GTK+ though.

> 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? 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 :).


Alex