Perhaps I'm just being thick here but I'm missing a vital point about interrupt transfers (well interrupt out transfers at least).
With an interrupt in, you get a callback every now and again, you look to see what actual_length is, if it's not zero, you copy data to your own buffer and return. The URB is resubmitted again with the same transfer_buffer and transfer_buffer_length and it's easy. What happens with an output URB? You submit it and let's assume for simplicity that the data is exactly the right length. Eventually you get called back, you do some processing and return from the callback handler. At that point the URB gets resubmitted. If your callback handler does nothing, will the same buffer of data get resubmitted over and over again? Or does the driver set something internally in the URB which tells it there's no new data to send? I looked at uhci_submit_interrupt and it just looks at transfer_buffer_length to decide what to send. That was fixed when you created the URB. What stops that same load of data going out again? You can't unlink the urb because, as we've discussed, you can't unlink urbs (uhci) in a callback. Could you just set the transfer_buffer_length to zero? Ok, what if you want to send another (full) buffer, do you just copy your new data into the same buffer space and continue, or do you have to reset something to tell the driver there is new data here? Finally - what if you only have a short buffer to send next? Can you put a half-buffer of data in there, set transfer_buffer_length to the new length and let it get resubmitted or is that wrong too? You see what I'm lost in? I can't see what's different in the output URB between one submission and the resubmission in order not to get the same data out twice nor can I see what you are supposed to do in the callback to prevent exactly that. Roland _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
