On Thu, May 3, 2012 at 3:54 PM, Henrik Rydberg [off-list ref] wrote:

quoted

quoted

quoted

quoted

2) Add the interface type to the group descision, which should
probably be done anyway. I have a patch in the pipe that, will send it
later today.

A simpler solution consists in adding the macros HID_USB_MT_DEVICE(v,
p) and HID_BLUETOOTH_MT_DEVICE(v, p) as you had introduced in a
earlier patch (I don't know why it disappeared).

No, the specific entries in the hid-multitouch device list matches any
group, so those defines were simplified away in the second version.

disagree: a device can present several interface (because it has
several "devices") and only those presenting Contact ID can and should
be handled by hid-multitouch.

Obviously this is only a problem for the devices with mixed
interfaces, but for those, solution 2) together with specifying the
group as you suggest should work. We can definitely change all devices
in the list, it just was not necessary before (or so I thought).

quoted

The think is that they do match hid-generic (they get the group
HID_GROUP_GENERIC).
However they also match hid-multitouch (as hid-multitouch does not ask
for a particular group). So, if hid-multitouch is loaded __before__
hid-generic, it will be given the device whatever the match with
hid-generic.

I suppose what you describe here is how it was working before the
device groups.

Just to be clear: no, this last paragraph occurs after device groups.
Before, it was working as hid-generic catch the device first, then
released it while looking at the report descriptors. Now, it's purely
dependent on which driver is loaded first for this particaular case.

Benjamin

Ok, I see what to do now. I will be back shortly with a
patch which should make USB_DEVICE_ID_TOPSEED2_PERIPAD_701 work, and
let's take it from there.

Thanks for testing,
Henrik