On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot <mpieuc...@nolizard.org> wrote: > On 08/12/14(Mon) 09:02, David Higgs wrote: >> On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot <mpieuc...@nolizard.org> >> wrote: >> > The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in >> > usbd_transfer_complete() so the HCD should only set the status to >> > USBD_NORMAL_COMPLETION, see below. >> > >> > Concerning your broken firmware, what we should do is change the >> > uhidev_*_report() function to somehow return the number of transferred >> > bytes (actlen). Since this involves calling usbd_do_request_flag() and >> > update all the consumers of this API, here's a first step. >> > >> > Could you test the diff below and tell me if it still works for you? >> > You'll still need your upd(4) diff. If that works, I'll commit it and >> > send a second diff to deal with your broken firmware. >> >> Seems to work fine when patched against -stable. (Sorry, I'd rather >> not update this box to -current, unless necessary for some later >> diff). > > Stable should be fine. Does this include the ohci(4) diff?
Yes, I replaced my ohci(4) tweak with your full diff, while keeping my changes to upd(4). >> Since uhidev_set_report didn't change, why did wacom behavior need >> tweaking? I don't own this peripheral... > > Because it was using usb_set_report() instead of uhidev_set_report() and > doing the reportID dance by itself. Whoops, you're right. I missed that there was a different function prefix. > Now I'd like to finish the transition that started with the import of > upd(4) and move away from the actual 1 reportID = 1 driver model. > Because in the end they are all sharing the same USB device actually > represented by an uhidev(4) instance. So I'll ride the refactoring > needed by your buggy firmware to also change that. Since all the > uhidev_*_report() will be modified, we can also pass a pointer to > the uhidev(4) device instead of one of its children. Is it clearer? Sounds great to me. --david
