[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: drop frontend support for relative pointer
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |