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: Anthony Liguori
Subject: Re: [Qemu-devel] paravirtual mouse/tablet
Date: Fri, 14 Jan 2011 09:37:45 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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





reply via email to

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