On Tue, Jun 28, 2011 at 7:49 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > > David Herrmann <dh.herrmann@xxxxxxxxxxxxxx> 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 -- 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
