Le 14 oct. 10 à 14:54, Henrik Rydberg a écrit :
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.
Yes, but we don't know how many classes we'll get and might be safer
to protect the core logic of the driver from people who'll want to
add a new class.
Coming back to your point about the invalid slot number, I'll try to
think about it again. Honestly, I'm pretty much at ease with the
concept of overloading the return value of a function with a code for
errors, because it is so common in Unix and Linux. And the overall
meaning of the function is "is there any slot that corresponds to
this contact?", which makes sense to me. But let's see if we can find
a better way.
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.
NTrig is alone in its class so far.
St.
--
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
