From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54778 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Peqbj-0005bS-DR
	for qemu-devel@nongnu.org; Mon, 17 Jan 2011 10:03:00 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Peqbi-00066j-Gv
	for qemu-devel@nongnu.org; Mon, 17 Jan 2011 10:02:59 -0500
Received: from mail-vw0-f45.google.com ([209.85.212.45]:36587)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Peqbi-00066U-Ee
	for qemu-devel@nongnu.org; Mon, 17 Jan 2011 10:02:58 -0500
Received: by vws12 with SMTP id 12so1948400vws.4
	for <qemu-devel@nongnu.org>; Mon, 17 Jan 2011 07:02:58 -0800 (PST)
Message-ID: <4D345A1F.6000607@codemonkey.ws>
Date: Mon, 17 Jan 2011 09:02:55 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] paravirtual tablet v3
References: <4D307B69.1030801@redhat.com> <4D30B6A8.6020603@codemonkey.ws>
	<4D33FB99.6080207@redhat.com>
In-Reply-To: <4D33FB99.6080207@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: Gerd Hoffmann <kraxel@redhat.com>
Cc: spice-devel <spice-devel@lists.freedesktop.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

On 01/17/2011 02:19 AM, Gerd Hoffmann wrote:
> On 01/14/11 21:48, Anthony Liguori wrote:
>> On 01/14/2011 10:35 AM, Gerd Hoffmann wrote:
>>> Hi,
>>>
>>> Now v3 featuring multitouch ;)
>>>
>>> cheers,
>>> Gerd
>>
>> I really think multitouch needs to be a feature such that the guest can
>> nack it and the host can adjust accordingly. If it's there from day 1,
>> that's fine, but it still should be a feature.
>>
>> There are a lot of non-multitouch aware guests out there and I don't
>> think we want the driver to be the one deciding how to map a multitouch
>> device to something that doesn't support mulitouch.
>
> Sure, someone needs to map multitouch to non-multitouch.  I'd leave 
> that job to the guest driver tough.  Why do you think doing it in the 
> host is better?

My assumptions are 1) the host is capable of doing the mapping just as 
easily as the guest 2) the host can do something useful with the 
information that the guest is not multitouch capable.

Regards,

Anthony Liguori

>
> cheers,
>   Gerd
>