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

[Markus Armbruster <armbru@xxxxxxxxxx>]

Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> writes:

> 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).

Why keep the then dead code in the frontend?  Note I'm not suggesting to
change the protocol or the backend.

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