Taking the reverse engineering seriously
$ usb_capture 1234:4567 data.cap $ usb_replay 1234:4567 data.cap $ usb_detach 1234:4567 $ usb_reset 1234:4567
# transfer_type:bmRequestType:bRequest:wValue:wIndex:wLength:data CTRL_OUT(0.0):21:01:0200:0600:0005:80b8000000 CTRL_IN(0.0): 00:00:0000:0000:0000:0000 # 0.0030059999553487 # transfer_type:endpoint:data BULK_OUT(0.1):80b8000000 # 0.0028590000001714 INTR_OUT(0.1):80b8000000 # 0.0028590000001714 ISOC_OUT(0.1):eeffffff00000000f40b00000000000 # 0.1025490000611171 BULK_IN(0.1): 80b8000000 # 0.0028590000001714 INTR_IN(0.1): 80b8000000 # 0.0028590000001714 ISOC_IN(0.1): eeffffff00000000f40b00000000000 # 0.1025490000611171
How does usb_replay handles the input transfers?
It fires an input request through libusb-1.0 which blocks until the response will be received.
Does usb_replay respects the timings?
Yes, it waits for a specified interval (which is specified in seconds after the sharp sign) before performing each call.
Why do I need to replug the device after running usb_replay?
It performs a detach_kernel_driver() call in the beginning, so in the case of your mouse, it may be looking like it's suddenly stopped working. This doesn't means that something is actually went wrong, and there is no need to replug until you'll need it interacting with your system again.
This software is distributed under the terms of a General Public License as defined at http://www.gnu.org/copyleft/gpl.html.