une idée comme ca.
dans usb-skel le "write" est non bloquant :usb_submit_urb retourne immediatement cad avant que l'octet soit parti vers ton device.
Si tout de suite derriere tu fais un set_usb_interface le urb en pending est-il toujours vivant ?je ne saurais le dire.
1) au lieux de faire un fill_urb/submit urb peut tu essayer de faire un usb_ulk_msg ? et ensuite seulement (car la tu est garanti qu'au retour de usb_bulk_msg ton message a ete recu par le device ) de faire ton set_usb_interface.
2)C'est une methode de faire comme cela mais elle n'est pas dans l'esprit de l'usb qui as prevu le control-endpoint afin de gere ce genre de request.
[^] # Re: 1 pas en avant
Posté par TheBreton . En réponse au message driver USB. Évalué à 1.
dans usb-skel le "write" est non bloquant :usb_submit_urb retourne immediatement cad avant que l'octet soit parti vers ton device.
Si tout de suite derriere tu fais un set_usb_interface le urb en pending est-il toujours vivant ?je ne saurais le dire.
1) au lieux de faire un fill_urb/submit urb peut tu essayer de faire un usb_ulk_msg ? et ensuite seulement (car la tu est garanti qu'au retour de usb_bulk_msg ton message a ete recu par le device ) de faire ton set_usb_interface.
2)C'est une methode de faire comme cela mais elle n'est pas dans l'esprit de l'usb qui as prevu le control-endpoint afin de gere ce genre de request.