[Spice-devel] [Qemu-devel] paravirtual mouse/tablet

[Peter Hutterer]

On Fri, Jan 21, 2011 at 05:14:11PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >>The spice-specific issue here is that spice supports multihead, i.e.
> >>you have two displays in the guest and two windows on the host, and
> >>mouse positions are reported as (x,y,window).  Question is how to
> >>handle this best ...
> >
> >how much do you know about the window configuration?
> >if you know the root window offset of each window, you can add this to the
> >event coordinates and the initial axis range, so the offset will be correct
> >in the client.
> 
> The position of the windows in the host doesn't matter at all
> (although if is of course less confusing if the window arrangement
> matches the guests monitor arrangement).
> 
> Today the (x,y,window) tuple is sent to the guest and a spice guest
> agent (which knows the display configuration) will take care to
> handle the offset calculation before stuffing the event in the input
> queue.
> 
> We want switch spice to use the new pvmouse instead and the question
> is how to do that best.  I think there are basically two options:
> 
>   (1) Continue sending the display/window ID with the events and let
>       the guest do the offset calculation.  Question is how to pass on
>       the window/display ID then.  I think you can't squeeze it through
>       the linux input layer, and even if you can the xorg evdev driver
>       would need a special tweak to understand it and handle it.
>   (2) Inform the host about the display configuration, so it can do the
>       offset calculation.  Drawback is that this needs a spice protocol
>       change/extension.

I have to admit, I'm getting a bit confused with the partially overlapping
nomenclature between spice and X but if I understood correctly, 2 seems the
way to go.

> >A number of X drivers have features built-in along the lines of "if pressure
> >goes past this point, send a click". You as the X client will receive the
> >press but you cannot know if that was in result to pressure or an actual
> >click. all this is hidden from you. so in reporting this to the guest,
> >you're now reporting a button click instead of the pure pressure.
> 
> Tricky indeed.  Do you know whenever it is possible to identify
> those generated clicks when getting the events from the linux input
> layer directly?

not without being the driver that converts those events, sorry. and even
then it isn't 100% predictable since some pointer events may be converted to
keyboard events in the server (thanks XKB).

Cheers,
  Peter