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