[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.