From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59630 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiTnS-0007Xt-Id for qemu-devel@nongnu.org; Thu, 27 Jan 2011 10:30:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiTnR-0004eU-8y for qemu-devel@nongnu.org; Thu, 27 Jan 2011 10:30:06 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:49127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiTnR-0004eL-52 for qemu-devel@nongnu.org; Thu, 27 Jan 2011 10:30:05 -0500 Received: by qwk4 with SMTP id 4so2256511qwk.4 for ; Thu, 27 Jan 2011 07:30:04 -0800 (PST) Message-ID: <4D418F6D.2010400@codemonkey.ws> Date: Thu, 27 Jan 2011 09:29:49 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] paravirtual mouse/tablet, v5 References: <4D416F07.6060604@redhat.com> <4D4180DD.3020504@codemonkey.ws> <4D4186FB.3030308@redhat.com> In-Reply-To: <4D4186FB.3030308@redhat.com> 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: Gerd Hoffmann Cc: Peter Hutterer , "qemu-devel@nongnu.org" , spice-devel On 01/27/2011 08:53 AM, Gerd Hoffmann wrote: > On 01/27/11 15:27, Anthony Liguori wrote: >> On 01/27/2011 07:11 AM, Gerd Hoffmann wrote: >>> Hi, >>> >>> Next revision the pvmouse protocol. It is quite different now, I've >>> decided to move to a model with one message per updated value, simliar >>> to the linux input layer. There isn't a "mouse move" message any more. >>> A mouse move event will be three messages now: one to update X, one to >>> update Y and a third sync message to mark the end of the message >>> block. That should be *alot* easier to extend in the future. >>> >>> Header file is attached. Comments are welcome. >> >> I can't comment on the multitouch bits but I like the new interface. > > BTW: Is there any plan for guest code already? Should it stay within > the qemu source tree, in a guest/ directory maybe? pvmouse daemon > would live there, also the upcoming guest agent bits. I think it should live in the QEMU tree or at least on qemu.org. We want these agents to be ubiquitous. > > Before finally committing to some protocol I'd like to have at least a > simple proof-of-concept which is able to handle all the mouse events > the current qemu mouse infrastructure is able to handle. > > Oh, and we'll have to define endianness of course so it keeps working > if host and guest have a different byteorder. I'd suggest to pick > network byte order aka bigendian. Makes sense to me. Regards, Anthony Liguori > > cheers, > Gerd > >