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
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
