[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RFC: drop frontend support for relative pointer
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? [*] https://bugzilla.redhat.com/show_bug.cgi?id=523914 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |