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
|
Home