On Fri, Dec 11, 2009 at 10:58:31AM +1000, Peter Hutterer wrote: > On Thu, Dec 10, 2009 at 04:47:20PM -0800, Dmitry Torokhov wrote: > > On Fri, Dec 11, 2009 at 10:35:04AM +1000, Peter Hutterer wrote: > > > On Thu, Dec 10, 2009 at 04:19:22PM -0800, Dmitry Torokhov wrote: > > > > > are we talking about kernel drivers or userspace drivers here? > > > > > > > > > > not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well, > > > > > not-yet-implemented feature) but if the kernel hands out both ABS_X and > > > > > ABS_MT_X that makes it difficult to determine which event is a valid one and > > > > > which one can be ignored. > > > > > > > > > > > > > No, it is pretty simple - all events are valid, otherwise it is kernel > > > > driver bug. Now, as userspace consumer, if you know how to handle > > > > multitouch protocol then use it, ignore ABS_X/ABS_Y. Otherwise you'd be > > > > dropping ABS_MT_* events and naturally handling ABS_X/ABS_Y. > > > > > > Thanks, that's the answer I hoped for - if ABS_MT_X is available, we can > > > ignore ABS_X. > > > > > > The tricky part would have been if both were equally valid _at the same > > > time_ but refer to different inputs. at which point you'd have to find out > > > which one to map to which pointer axis, etc. We already have a problem with > > > REL_X and ABS_X on the same device, adding the ABS_MT_X to that mess > > > wouldn't have helped the situation. > > > > What devices report both ABS_X and REL_X events? > > Xen Virtual Pointer > AlpsPS/2 ALPS GlidePoint Hmm, ALPS should not be reporting REL_X/REL_Y on touchpad device, only on the secondary device. I will fix it, thank you for the report. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
