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

[Gerd Hoffmann]

   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.

> button labels are provided by the driver (if possible) through X atoms of
> defined strings.

/me somehow expected that answer ;)

>> Ok, I understand that for the mouse.  But for the pad?  Isn't there
>> just a surface to touch and nothing else?  Does the device behave
>> differently depending on how many fingers it detects on the surface?
>
> afaik, the kernel converts some fingers into the standard non-MT protocol
> events in addition to the MT events so the device is usable by userspace
> apps without MT support. With XI 2.1 (X server multitouch) coming up, you'll
> see these events happen in parallel in some cases.

Ok, so it is the driver, not the hardware.  Makes sense to do that for 
compatibility reasons.

>> Ok.  I think for the virtual hardware it is just fine to report the
>> pressure to the guest and let the guest handle the interpretion of
>> the data (i.e. should that be a mouse click or not depending on the
>> threshold and maybe other data).
>
> heh. that's where it gets interesting again if you get the virtual hardware
> through X events on the window. (mini glossary: X client - the process that
> pops up the window displaying the guest)
>
> 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?

> there's no solution to this other than to forward the usb device itself.

That will work indeed.  I'd prefer to be able to forward 
/dev/input/event<x> devices as pvmouse/tablet though.  That will cover 
more devices and the emulation has less cpu overhead.

cheers,
   Gerd