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

[Markus Armbruster <armbru@xxxxxxxxxx>]

Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> writes:

> On Tue, 13 Oct 2009, Markus Armbruster wrote:
>> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>
> Given that absolute->relative conversion is not very good, I think it is
> best to keep relative alive.

Unless you mean relative->absolute, you're not making sense to me :)

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