|
From: | Alexander Graf |
Subject: | Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes |
Date: | Sun, 06 Jul 2014 13:08:06 +0200 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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 deviceIn 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
[Prev in Thread] | Current Thread | [Next in Thread] |