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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 7 Oct 2009, Markus Armbruster wrote:
> The protocol between PVFB frontend and backend supports relative and
> absolute pointer.
> 
> In theory, support for absolute pointer in the backend is optional.  In
> practice, our backend has always supported it.
> 
> Absolute pointers provide a superior user experience, and our frontend
> always enabled them.
> 
> However, because the backend could theoretically not offer the absolute
> pointer option, the frontend still supports both.  This has worked fine
> so far, but it's starting to cause trouble now.
> 
> We support both relative and absolute pointer by setting both EV_REL and
> EV_ABS in input device, then use whatever the backend sends us.  The
> backend either sends only relative or only absolute events.
> 
> Nothing in the kernel suggests setting both EV_REL and EV_ABS is bad.
> In fact, drivers/hid/hid-wacom.c and drivers/input/tablet/aiptek.c seem
> to do the same.
> 
> Unfortunately, X is having difficulties with it.  It worked only because
> of a bug in evdev.  This bug was fixed recently, and the fix broke the
> Xen PV pointer.  Impact: pointer doesn't work at all with Fedora Rawhide
> guests.  See [*] for the gory details.
> 
> X will eventually be fixed, but waiting for that isn't practical.  We
> need to work around the problem in xen-kbdfront, or possibly evdev.
> 
> My preferred solution is dropping support for relative pointer in the
> frontend, then set only EV_ABS.  It's easy, safe, and sends user space
> down well-trodden paths.  Requires a backend supporting absolute
> pointers, but as mentioned above, they all do.
> 
> Opinions?
> 

I think that it is fair to assume that the backend supports absolute
coordinates, in fact the stubdom frontend does that already.
As a consequence removing the EV_REL bit is fine as a workaround but I
wouldn't go as far as removing the actual code that support it
(XENKBD_TYPE_MOTION).


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