[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: drop frontend support for relative pointer


  • To: Markus Armbruster <armbru@xxxxxxxxxx>
  • From: Jean Guyader <jean.guyader@xxxxxxxxx>
  • Date: Tue, 13 Oct 2009 21:58:35 +0100
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Daniel P. Berrange" <berrange@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 13 Oct 2009 13:59:06 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g0GOzNsgzy+wgUUBaVqQsjRWgql2n3Ttcfdl+gcZQuNyO5N6vWLq/fTOO/c6NF3RvI a/ps7lwWvUz53UyqpWknvI8FDyWVxrfp+EiyLCbrMKaJEDi4e4QRAUkepwebfsvGQP/k E6UQGjPo2QEvWrez7voudpOGEQxRxKoS/Xzws=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

2009/10/13 Markus Armbruster <armbru@xxxxxxxxxx>:
> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> writes:
>
>> On Tue, 13 Oct 2009, Markus Armbruster wrote:
>>> > I don't really thing we could use absolute because we do graphic
>>> > device pass through with PV guest and the resolution we have on the
>>> > screen is completely decouple with the fb resolution.
>>>
>>> I figure the real solution is to decouple the PV pointer/keyboard from
>>> the PV framebuffer, so you can configure the pointer independently, and
>>> don't have to drag a PV framebuffer along, just to get a PV
>>> pointer/keyboard.
>>>
>>
>> True, but it still wouldn't solve the problem of dropping relative mouse
>> coordinates support from vkbd.
>
> You can always convert between relative and absolute in the backend.
> Pointer resolution need not match the graphics resolution (think tablet,
> not touchscreen).

Even something a touchpad is absolute.

>
> Nevertheless, it might be more convenient for this use case to keep
> relative around.  Then the backend need only be able to convert from
> absolute to relative (for frontends declining feature-abs-pointer), not
> the other direction.  XCI is of course free to require a frontend that
> doesn't decline.
>

We already have some bit of code to do the absolute -> relative conversion.
But we try to avoid dom0 driver to use abusolute of its devices.

> If we decide to keep relative, we need to restructure pointer frontend
> initialization to each axis either relative or absolute.  Unless evdev
> developers find a way to continue coping with both.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.