From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52568 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PdQIT-0003Hg-Jk
	for qemu-devel@nongnu.org; Thu, 13 Jan 2011 11:45:15 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PdQIS-0000TC-Ih
	for qemu-devel@nongnu.org; Thu, 13 Jan 2011 11:45:13 -0500
Received: from mail-iw0-f173.google.com ([209.85.214.173]:49548)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PdQIS-0000T6-Ff
	for qemu-devel@nongnu.org; Thu, 13 Jan 2011 11:45:12 -0500
Received: by iwn40 with SMTP id 40so1947675iwn.4
	for <qemu-devel@nongnu.org>; Thu, 13 Jan 2011 08:45:11 -0800 (PST)
Message-ID: <4D2F2BC8.2040005@codemonkey.ws>
Date: Thu, 13 Jan 2011 10:43:52 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] paravirtual mouse/tablet
References: <4D2ED1C8.7070304@redhat.com> <4D2F25EA.3020606@redhat.com>
In-Reply-To: <4D2F25EA.3020606@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: spice-devel <spice-devel@lists.freedesktop.org>, Gerd Hoffmann <kraxel@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

On 01/13/2011 10:18 AM, Avi Kivity wrote:
> On 01/13/2011 12:19 PM, Gerd Hoffmann wrote:
>>   Hi,
>>
>> Just throwing a quick writeup into the ring to kickstart the design 
>> discussion ;)
>>
>>
>> typedef struct qemu_pvtablet_message {
>>      uint32_t size;            /* whole message size */
>>      uint32_t type;            /* qemu_pvtablet_type */
>>      uint64_t tv_secs;
>>      uint64_t tv_usecs;
>
> time relative to what base?
>
> can we actually provide it? if the tablet is remote, there may not be 
> a synchronized time source.

I had the same thought, but if it's just treated as time since the init 
message, the guest is capable of working it out (minus drift).

>>      union {
>>          qemu_pvtablet_position position;
>>          qemu_pvtablet_button   button;
>>          qemu_pvtablet_display  display;
>>      } m;
>> } qemu_pvtablet_message;
>>
>
> So the message size for a qemu_pvtablet_position would only include 
> the position member?

I didn't comment on this because I was treating this as a protocol 
proposal and not actual code but usually the following is clearer:

struct qemu_pvtablet_hdr {
     uint32_t size;
     uint32_t type;
     uint64_t tv_secs;
     uint64_t tv_usecs;
};

struct qemu_pvtablet_position {
     struct qemu_pvtablet_hdr hdr;
     uint32_t x;
     uint32_t y;
};

union qemu_pvtablet_message {
     struct qemu_pvtablet_hdr hdr;
     struct qemu_pvtablet_position position;
     ...
};

Regards,

Anthony Liguori