From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44267 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiTER-0000IW-AP for qemu-devel@nongnu.org; Thu, 27 Jan 2011 09:53:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiTEQ-0003DP-Ah for qemu-devel@nongnu.org; Thu, 27 Jan 2011 09:53:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiTEQ-0003DJ-3r for qemu-devel@nongnu.org; Thu, 27 Jan 2011 09:53:54 -0500 Message-ID: <4D4186FB.3030308@redhat.com> Date: Thu, 27 Jan 2011 15:53:47 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] paravirtual mouse/tablet, v5 References: <4D416F07.6060604@redhat.com> <4D4180DD.3020504@codemonkey.ws> In-Reply-To: <4D4180DD.3020504@codemonkey.ws> 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: Anthony Liguori Cc: Peter Hutterer , "qemu-devel@nongnu.org" , spice-devel 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. 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. cheers, Gerd