On 10/14/2010 02:33 PM, Stéphane Chatty wrote:
>
> Le 14 oct. 10 à 14:06, Henrik Rydberg a écrit :
>>>
>>> +static int cypress_compute_slot(struct mt_device *td)
>>> +{
>>> + if (td->curcontactid != 0 || td->curcontact == 0)
>>> + return td->curcontactid;
>>> + else
>>> + return -1;
>>> +}
>>
>>
>> Returned slots should always be valid, since the intent is to actually report
>> data for the contact. If there is additional logic determining whether a touch
>> is valid, like here, it can simply be added to the validity computation.
>
> Then you'd need a second device-specific function, one that determines if a
> contact is valid. I was trying to minimize that, especially because it would be
> for the sake of one device only.
Now that single device clutters the logic for all other devices instead... We
could actually get away with zero device-specific functions, only branching on
the device class at a couple of places in the driver.
> Managing it in the compute_slot function makes
> sense to me, giving this function the semantics of "is this contact a real slot,
> and if yes which is it?".
>
> Maybe we could add somthing like td->curvalid = false to the computation
> function? This would not work in the current code, but maybe we can make it work.
Another thing I forgot about: do all the currently included devices have good
contact ids, in the sense that they handle contacts during their lifetime? Are
there any examples other than ntrig where it does not work that way? I am of
course asking to see if we need to care about non-slotted devices.
Cheers,
Henrik
--
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
