This page describes the use of the SniffUsb tool to acquire traces of interactions between Windows webcam drivers and the hardware. These traces can mean the difference between supporting the camera or not.
Is a Trace Necessary?
Traces are not always required. Sometimes there are simpler ways to support new webcam hardware. Frequently, new hardware that is sufficiently similar to existing hardware will either work with the existing driver without changes, or can be made to work after cursory examination of the Windows driver.
Standards such as UVC are intended to allow a common UVC driver to support new devices without modification, as long as the manufacturer of the device upholds the UVC standard. Tracing a UVC camera should be completely unnecessary, except:
- For devices that use nonstandard commands, e.g. Ricoh UVC cameras
- For cases where the Windows UVC driver is able to control a device, but the Linux UVC driver fails
If your device is supported by my driver, and is listed on my page as Pending, chances are good that somebody has already acquired a trace.
Is a Trace Possible?
There are situations where sniffusb has difficulty attaching to a driver stack, or interferes with the driver stack. In particular, some new Ricoh devices use the Windows UVC driver -- usbvideo.sys, but attach filter drivers around it. In this system, the interesting traffic is between the bottom level filter driver of the device stack and the USB bus driver. Unfortunately, sometimes sniffusb does not manage to attach at the bottom of the device stack, and attaches somewhere else, causing it to fail to observe critically important traffic. In this situation, other measures must be taken.
Acquiring a Trace
If a trace is required, someone with physical access to the hardware must follow the instructions and acquire a trace file.
This process does require Windows. Depending on the device, it may be possible to use virtualization software including VMware, although this is not the most desirable option, as VMware does not support USB 2.0 / EHCI. In particular, Ricoh webcams cannot be traced under VMware because they require high speed mode.
The procedure is listed below, and shouldn't take more than about 20 minutes.
- Download SniffUsb from http://www.pcausa.com/Utilities/UsbSnoop/default.htm.
- Unpack SniffUSB.exe to somewhere, maybe the desktop.
- Start it for the first time.
Tip: If you're using Windows Vista, you might need to launch it by right-clicking on the executable and selecting "Run as Administrator" - Answer "OK" when asked whether to copy the usbsnoop.sys driver to system folder.
- Click OK when asked whether to start the service
- Find your webcam on the list of devices, highlight it, click "Install."
- Turn your computer all the way off (Start->Shutdown) and perform a cold boot.
- Start SniffUsb
At this point, if everything went according to plan, the log file should be 50KB-500KB. SniffUsb will indicate the size of its log file in the lower left area of its window. If it's not at least that large, something is probably wrong. This part of the log file should contain the microcode upload sequence.
If all is good so far...
- Start and immediately stop a video capture application, ensuring that it did manage to turn on the camera.
- Detach SniffUsb from your camera device.
At this point, depending on how long you let the capture program run, the log file will become really really big, anywhere between 10-500MB. If it isn't this large, something is probably wrong. The problem is that usbsnoop logs all of the bulk and isochronous packets. They aren't always useful for determining how the camera works, and I don't know a nice clean way to grep them out on Windows without using perl and cygwin. Anyway, all of the magic is usually in the first 2MB, so clip out the first 2MB, compress it, and send it to me.
For Those Interested in What it Means
Below is an excerpt of what the log file looks like for a Ricoh webcam from a Sony VAIO, with some annotations.
[1412 ms] UsbSnoop - DispatchAny(f885d610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[1412 ms] UsbSnoop - MyDispatchInternalIOCTL(f885ee80) : fdo=8170bf18, Irp=81704ce0, IRQL=0
[1412 ms] >>> URB 5 going down >>>
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 814d4518
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000
Request = 000000a4
Value = 00000000
Index = 00000000
This block describes an URB -- a USB Request Block, being sent from the webcam driver to the host controller driver. The Windows USB stack makes it about as clear as mud what's actually being sent, but in this case it's a control transfer from the device, with vendor class message 0xA4, value 0, index 0. It is requesting that the device return exactly 1 byte of data.
[1413 ms] UsbSnoop - MyInternalIOCTLCompletion(f885edb0) : fido=00000000, Irp=81704ce0, Context=814da260, IRQL=2
[1413 ms] <<< URB 5 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 816fdf80
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 814d4518
TransferBufferMDL = 81704428
00000000: 00
UrbLink = 00000000
SetupPacket =
00000000: c0 a4 00 00 00 00 01 00
This is the response from the device to the last URB. It returned one byte of data, 0x00. For the Ricoh webcam, command 0xA4 is requesting the microcode state from the webcam, and the camera replies with either 0 (no microcode) or 1 (microcode is present).
Filed Under:
- Login to post comments