On Wed, Mar 9, 2011 at 10:38, Henrik Rydberg [off-list ref] wrote:

On Wed, Mar 09, 2011 at 10:03:45AM +0100, Benjamin Tissoires wrote:

quoted

On Wed, Mar 9, 2011 at 09:42, Henrik Rydberg [off-list ref] wrote:

quoted

Hi Benjamin,

quoted

This patch enables support of autodetection of maxcontacts.
We can still manually provide maxcontact in case the device
lies on it.

Signed-off-by: Benjamin Tissoires <redacted>

It seems quite alright to let the classes contain the expected number
of contacts, so I do not really see the reason for that part of the
patch. How about keeping the maxcontacts in the class, and then do
max(hid-provided-maxcontacts, default-maxcontacts)?

Yep, I've got three particular reasons:
- 3M: there are two devices now, 1968 and 2256. The first one is a 10
touches only, whereas the second one is a 60 touches.

Right, so increasing the number of touches based on device information
seems like a good idea.

So the patch is useful.

quoted

- autodetection of multitouch devices. I have some patches on my tree
(that we do not want to go upstream right now for some reasons) that
allows us to plug any unknown multitouch devices and to let
hid-multitouch handling it. As most of the devices are 2 touches only,
and as the generic way to work with a multitouch devices is to iterate
over all the slots, using 10 touches by default infers a lot of
instructions that can be avoided.

Right, so keeping the default number of touches per class seems like a
good idea.

That's the way the patch works: we can still manually provide the
maxcontact per class, but if it's not needed (the device sends proper
value), then we can skip it.

quoted

- finally, it simplifies the writing of the new CLS (we just need to
know how the device works to add the right quirks).

Right, we always need to know how the device works. :-)

What I meant was the dynamic behavior of the device, not the static
capabilities. ;)

Am I right if I take your reply as an Ack?

Cheers,
Benjamin