On Thu, May 3, 2012 at 3:54 PM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: >> >> > 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). > >> 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 -- 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