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 WALTOP International Corp. Slim Tablet MS Optical Desktop 2000 are the ones I've got evtest outputs for and that I found in a 2 minute search. There's quite a few of them around, tablets, touchscreens and IIRC even some mice. This is valid from the kernel's perspective and it makes sense too. The problem is solely within X where we're not flexible enough yet to switch between rel and abs after the initial setup. We end up ignoring one of the two axes depending on what the device is but there are always corner cases. Cheers, Peter -- 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
