Hi guys On Mon, Feb 25, 2013 at 1:29 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: > On Mon, 25 Feb 2013, Benjamin Tissoires wrote: > >> Hi guys, >> >> this is the v2 of the hid transport cleanup. >> >> Changes since v1: >> - gathered reviewed/acked/etc.. >> - changed commit messages of patches 4-6 >> - add newcomer into account (thingm) >> - incorporated the i2c-hid driver change into the series >> >> I still did not implemented the final usb cleanup for hid-multitouch as it may >> required few comments. > > I have now taken the series. Thanks Benjamin, thanks Henrik. I rewrote the Bluetooth HID session-management last week (patches pending on linux-bluetooth@vger) as it was horribly broken. This week I will try to fix the get_report/set_report mess with Bluetooth-HID, so I was wondering whether you could clear some things up. (I did read the Bluetooth HID Profile specification but I have no idea how USB does it, so please bear with me if I mix things up. Maybe some day I will have the time to read the USB specs, too) * There are several drivers using "dev->hid_get_raw_report()" and "dev->hid_output_raw_report()". Any objections to moving these to "hid_ll_driver" and adding wrapper functions hid_hw_get/output_raw_report()? * What should the ll->report() callback exactly do? Should it simply send a GET_REPORT or SET_REPORT request depending on the direction (nonblocking)? * Why don't we do the hid_output_report() call in the hid_hw_report() helper and pass the raw buffers down? It would allow GFP_KERNEL and avoid duplicating code in all four backends. * What should ll->wait() exactly do? Block until the last SET/GET_REPORT call has been ack'ed by the device? * Bluetooth-HID might return errors on GET/SET_REPORT. Why don't we return these in hid_hw_wait() for the last report? It would allow synchronous calls like: hid_hw_report(); ret = hid_hw_wait(); * Should hid_hw_report() allow multiple pending requests? Or should it return an error if there is another pending report that hasn't been ack'ed, yet? I will try to implement it for Bluetooth-HID and UHID if no-one else wants to do it. Doing it for UHID would make debugging/emulating devices a lot easier. Thanks 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
