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
