On Wed, 14 Oct 2009, Markus Armbruster wrote:
> 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 :)
>
Yes I meant relative->absolute, sorry for the confusion.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home