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:

quoted

quoted

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?

-- 
Dmitry