Re: [PATCH v3 0/6] hid: Introduce device groups

[Benjamin Tissoires <benjamin.tissoires@gmail.com>]

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