On Fri, Mar 25, 2011 at 1:20 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote:
>> +static inline bool is_mt_axis(int axis)
>> +{
>> + return axis == ABS_MT_SLOT ||
>> + (axis >= ABS_MT_FIRST && axis <= ABS_MT_LAST);
>> +}
>
> It would be great to get this inline into input/mt.h instead.
Makes sense. I'll do that.
>> + else if (test_bit(ABS_MT_TRACKING_ID, dev->absbit))
>> + mt_slots = dev->absinfo[ABS_MT_TRACKING_ID].maximum -
>> + dev->absinfo[ABS_MT_TRACKING_ID].minimum + 1;
>
> This one is a bit iffy - the tracking id is not limited like this in
> mainline, looks like android usage. A test againts some arbitrary max
> should do it.
Yeah, I'm not sure about this one. Tracking ID could effectively have
any range. All of the MT Protocol A touch screen drivers I have
looked at, assuming they report tracking ids at all, report a
reasonable upper bound on the contact points they support.
Originally, I set an arbitrary maximum bound of 20 slots. In the
interests of keeping it simple, I decided to remove that bound when I
submitted the patch for review here.
How about:
mt_slots = min(MAX_MT_SLOTS_TO_INFER_FROM_TRACKING_ID_RANGE,
dev->absinfo[ABS_MT_TRACKING_ID].maximum -
dev->absinfo[ABS_MT_TRACKING_ID].minimum + 1);
Where MAX_MT_SLOTS_TO_INFER_FROM_TRACKING_ID_RANGE is set to 32 or something.
There's also the question of how many slots we should infer when
neither ABS_MT_SLOT or ABS_MT_TRACKING_ID is available. The drivers
I've seen that don't provide tracking ids, are very basic and tend to
only support 2 touch points.
I guess we could add a DEFAULT_NUMBER_OF_MT_SLOTS constant to handle that case.
Please feel free to suggest better names for these constants.
Jeff.
--
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
