On Fri, 25 Oct 2019, Patrick Wildt wrote:
> > So from what I understood the Yubikey expects the transfer to happen
> > on the Interrupt OUT pipe instead of doing a control transfer. Read-
> > ing some code and documentation, it looks like that we should by de-
> > fault send our reports on the interrupt pipe, and only if it does not
> > exist fall back to control transfers. Linux seems to do exactly that.
> >
> > I tried to come up with the following diff, which appeard to make a
> > test program work for me. Though I'm not sure I got all the specifics
> > right.
> >
> > Can you give this a go with your test progam?
> >
> > Patrick
>
> Oops, obvious error. Though I still cannot write/read multiple times
> in a row, so there is probably still something wrong (unless my test
> is as well).
It didn't work for me - I think because uhidev_set_report() (and _async)
is still prepending a report ID. If I modify uhid.c to send writes
without a report ID, then it does work:
Index: uhid.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.71
diff -u -p -r1.71 uhid.c
--- uhid.c 1 May 2018 18:14:46 -0000 1.71
+++ uhid.c 27 Oct 2019 22:03:16 -0000
@@ -322,7 +322,7 @@ uhid_do_write(struct uhid_softc *sc, str
error = uiomove(sc->sc_obuf, size, uio);
if (!error) {
if (uhidev_set_report(sc->sc_hdev.sc_parent,
- UHID_OUTPUT_REPORT, sc->sc_hdev.sc_report_id, sc->sc_obuf,
+ 0, sc->sc_hdev.sc_report_id, sc->sc_obuf,
size) != size)
error = EIO;
}
I don't think this is optimal though - perhaps we should do something
like Linux: if the endpoint has an output report then use it, and fall
back to not prepending a report ID otherwise. This should be compatible
with current devices too (well, at least it shouldn't break any that
aren't already broken.)
(again, caveat - I don't know much about USB programming).
-d
