Re: [PATCH 2/2] Support for Stantum multitouch panel

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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