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? > 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. 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? Martin
