From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44111 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pdlio-00037O-Qe for qemu-devel@nongnu.org; Fri, 14 Jan 2011 10:37:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pdlin-0001kV-KZ for qemu-devel@nongnu.org; Fri, 14 Jan 2011 10:37:50 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:40215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pdlin-0001kK-GH for qemu-devel@nongnu.org; Fri, 14 Jan 2011 10:37:49 -0500 Received: by vws12 with SMTP id 12so1014638vws.4 for ; Fri, 14 Jan 2011 07:37:48 -0800 (PST) Message-ID: <4D306DC9.8040805@codemonkey.ws> Date: Fri, 14 Jan 2011 09:37:45 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] paravirtual mouse/tablet References: <4D2ED1C8.7070304@redhat.com> <4D2F1FA3.5030701@codemonkey.ws> <4D2F24EE.6070505@redhat.com> <4D2F2AB3.4020907@codemonkey.ws> <4D30332F.2070003@redhat.com> <108D35F5-7E49-4598-8903-599190A885E1@suse.de> In-Reply-To: <108D35F5-7E49-4598-8903-599190A885E1@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-devel@nongnu.org" , spice-devel , Gerd Hoffmann , Avi Kivity 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 > >