qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] paravirtual mouse/tablet


From: Alexander Graf
Subject: Re: [Qemu-devel] paravirtual mouse/tablet
Date: Fri, 14 Jan 2011 15:36:23 +0100

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? 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]