Re: [PATCH 05/12] HID: wiimote: Synchronize wiimote input and hid event handling

[David Herrmann <dh.herrmann@googlemail.com>]

On Tue, Jun 28, 2011 at 7:49 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
>
> David Herrmann <dh.herrmann@googlemail.com> wrote:
>
>>The wiimote first starts HID hardware and then registers the input
>>device. We need to synchronize the startup so no event handler will
>>start parsing events when the wiimote device is not ready, yet.
>>
>
> I believe this is generic HID layer problem. Would it be possible to fix this issue there?

The point is, I do not use HIDINPUT/HIDDEV (see commit message 2/12).
The wiimote has no valid report-descriptor table so hidinput/hiddev do
not make sense. I could set up a valid report-descriptor-table, use
input_mapping, input_mapped, report_fixup callbacks and then use
HIDINPUT. However, that would be far more complex than my current
solution, which is creating my own input instance and also my own
synchronization.
Furthermore, the wiimote provides input/output features that cannot be
handled by the generic HID handler, so I would need to extend the
input_mapping, anyway.

But, thanks to your hint, I looked at hid_hw_start() again and as far
as I can see the synchronization issue exists there, too.
The ll_driver->start() function is called first and after that, the
input instance is registered.
If the ll_driver reports an event before the input instance is
registered, the hidinput/other-driver will call input_event() on an
invalid input instance (probably even a NULL dereference).
This may not be a problem for usbhid, because usbhid_open() has to be
called first, however, hidp (bluetooth hid) ignores the *_open()
callback and therefore may fail.

I will look at this again and send a separate mail to this list,
however, I don't think this is related to my driver? Or do you think I
should replace my input-handling with HIDINPUT to be more homogeneous
with the other hid drivers?

> Thanks.
>
> --
> Dmitry

Regards
David