On Tue, 28 Sep 2010, Henrik Rydberg wrote:
> >>> I'm working on a slot-based version of the Stantum driver, and have had a look
> >>> into this. The Stantum firmware actually cycles over 8-bit values for its
> >>> ContactID. In this, it conforms more to the definition you gave for
> >>> ABS_MT_TRACKING_ID ("The slot protocol requires the use of the
> >>> ABS_MT_TRACKING_ID, either provided by the hardware or computed from the raw
> >>> data [5]") than to a slot number, doesn't it? Nevertheless, given our recent
> >>> exchanges about the 3M driver, I planned to use the driver's own tracking ID.
> >>>
> >>> Your thoughts?
> >>
> >>
> >> Excellent. :-) Speaking of drivers and multiplication, I think many of the
> >> current drivers could in fact be merged. It seems we have two or three different
> >> types so far, and different manufacturers may well be served by the same driver.
> >
> > Yes, I have started reviewing all devices and making a summary of their
> > differences in that very purpose. Among the things we'll need is some standard
> > way for calling the filtering function at the end of a set of fingers.
> > CONTACTCOUNT is a good candidate, but I need to check some devices. One thing
> > bothers me though. It is that hid-core has the whole information, then is splits
> > it and calls us repeatedly, then we more or less undo that by storing the
> > information and trying to determine the last time it calls us.
>
>
> Right. A hid-mt device based on the raw protocol could be a good idea - after we
> reduced the current set a bit. :-)
Guys, that would be great, thanks in advance for the effort :)
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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
