Re: [PATCH] hid: Do not create input devices for feature reports

[Benjamin Tissoires <benjamin.tissoires@enac.fr>]

Hi Henrik,

after some quick tests, I can deal with our two options (changing
feature_mapping signature or not, and so calling feature_mapping
before or after input_mapping).

So, my questions are:
- do we really need to change feature_mapping signature?
- is feature_mapping tied to an input or to a device?

Cheers,
Benjamin

On Thu, Feb 24, 2011 at 21:43, Henrik Rydberg <rydberg@euromail.se> wrote:
> On Thu, Feb 24, 2011 at 08:50:55PM +0100, Benjamin Tissoires wrote:
>> Hi Henrik,
>>
>> Thanks for spotting this. BTW, I'm not happy with your solution.
>>
>> You are sending the feature report before creating the struct
>> hid_input. To be consistent with the rest, we have to keep the same
>> signature. Today, the code does not make any use of it. But I use it
>> in my devel branch to auto-detect the maximum contact count of the
>> device. This was the safest place to call input_mt_init_slots.
>
> Well, the whole point is "which input device". It would only be
> well-defined when the hid device has a single input device. The
> feature callback could be called last, however, if that helps.
>
>> How about adding hidinput as an argument to report_features
>>
>> and calling it after the " for (k = HID_INPUT_REPORT; k <=
>> HID_OUTPUT_REPORT; k++) {" loop with
>>
>> list_for_each_entry_safe(hidinput, next, &hid->inputs, list)
>>     report_features(hid, hidinput);
>>
>> I did not even try to compile it right now (I don't have any
>> multitouch device right now) but I'll be able to make further tests
>> tomorrow.
>
> Thanks,
> Henrik
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>