Re: [Qemu-devel] paravirtual mouse/tablet

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/14/2011 08:36 AM, Alexander Graf wrote:
> On 14.01.2011, at 12:27, Gerd Hoffmann wrote:
>
>    
>>   Hi,
>>
>>      
>>> * multitouch capabilities would be good to design in a mouse protocol
>>> for 2011, so having say 16 x/y pairs would be better
>>>        
>> Point.  What do we need here?  Finger $n down, finger $n up, finger $n moved to $x,$y?  Does it make sense to just add this to the move+buttonup/down structs?  Or should it better be separate?
>>      
> I guess a mere tuple of (x,y,down) N times should be enough for the protocol, no?

Surely, evdev has an interface to support this already.  Let's just do 
what it does instead of inventing something that none of us can validate 
actually works.

Or better yet, delay implementing it until someone actually knows how to 
support it.

Regards,

Anthony Liguori

>   This would even be useful for single-point tablets which usually also have a proximity detector. Thinking about this a bit more - there are proximity sensors in tablets :). So they know how hard you pressed. If we want to be able to forward that to the guest from a real world tablet, we need a pressure field.
>
> So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). The details of what exactly that means should be figured out by the guest driver. If the guest is multitouch capable, it'd forward those events to the respective system. If it's tablet compatible, take the first entry and if it only supports plain mice, just make it (x,y) when pressure>  0.
>
>    
>>      
>>> * on mac os at least scrolling is not done by pressing virtual
>>> buttons, but by having a separate scroll interface that knows about
>>> velocity and such - maybe worth adding that to the protocol from the
>>> beginning too.
>>>        
>> Is that actually done by the hardware?  I'd expect macos processes the multitouch events, then provides this (finger $n moves this fast into that direction) as high-level interface, so this isn't something we have to care about at virtual hardware level.
>>      
> I'm not familiar with the hardware interface, but in order to support that the background interface must be a lot more complex than a simple button press. I'd frankly assume they do that in software with their own multitouch detection code though, so it should be fine to have the buttons as legacy interface as long as there is multitouch to implement the scrolling.
>
> But then again - how would we forward fine-grained scrolling to the guest if we only know that it's scrolling, but not what the actual presses on the touchpad looked like? Ugh.
>
>
> Alex
>
>