Least Significant Bits

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:

1. For devices that use nonstandard commands, e.g. Ricoh UVC cameras
2. 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.

1. Download SniffUsb from http://www.pcausa.com/Utilities/UsbSnoop/default.htm.
2. Unpack SniffUSB.exe to somewhere, maybe the desktop.
3. 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"
4. Answer "OK" when asked whether to copy the usbsnoop.sys driver to system folder.
5. Click OK when asked whether to start the service
6. Find your webcam on the list of devices, highlight it, click "Install."
7. Turn your computer all the way off (Start->Shutdown) and perform a cold boot.
8. 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...

9. Start and immediately stop a video capture application, ensuring that it did manage to turn on the camera.
10. 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:

• Hardware
• Software

• Login to post comments

Download Version 0.10.0, released 2007/4/7.

Download Ubuntu prebuilt binary packages from Arakhne

Download a DKMS package for Fedora 6, thanks to Naresh Kumar. What is a DKMS package?

If you have a Sony VAIO laptop or an HP Pavilion laptop, and primarily use Linux on it ... first of all, you're a freak. Second, you might have a little dot of a webcam above the screen -- that works fine in Windows -- giving you a blank stare.

The devices of interest are custom OEM built-in webcams based on the Ricoh R5U870 USB webcam controller chip or something very similar. They report USB vendor ID 0x05CA, and may or may not report UVC interface descriptors. The Windows device drivers are named Mvc25u870.sys, 5U870CAP.sys, and newer UVC model filter drivers are named R5U870FLx86.sys.

Devices known to fit this description include:

Help! My webcam is unsupported.

Adding support for devices that are listed as unsupported can be as simple as tracing USB activity of the Windows driver, and providing a good description of the Windows camera controls page. If you have a webcam listed on this page as unsupported, or maybe one that isn't listed on this page but should be, send me some mail at sam.revitch (at) gmail.com.

Driver Details

This driver supports all of the image formats and controls available with the Windows driver. It implements the Video4Linux 2 API, with consideration for V4L1 backward compatibility. It supports all frame buffer access methods specified by the V4L2 API, thanks to the video-buf module.

Applications Tested and Found to Work or Mostly Work

• xawtv -- the canonical video4linux test application
• Ekiga softphone.
• camstream version 0.27. Version 0.26.3 does not work due to YUYV bugs.
• Kopete instant messenger, although version 0.12 decodes color incorrectly and presents non-working video controls.
• aMSN instant messenger
• effectv real-time video effects
• Motion motion-detection and security

Applications That Do Not Work

As a warning, most of these applications do not work due to lack of support for the YUYV or UYVY pixel formats, or simple related application bugs.

• Camorama 0.18. This application does not understand YUYV or UYVY pixel formats, and will display a distorted image. A patch has been sent to the author.
• Wengophone 2.0. This application has trivial problems with its pixertool library that prevent it from recognizing the YUYV pixel format. Wengophone 2.1 will include a fix for this problem, and will correctly capture and display frames in most cases. Unfortunately, Wengophone 2.1's V4L input handler implements the minimum possible functionality and that app still has a few problems. It does not specifically request pixel formats that it understands, and if the last app to open the webcam configured UYVY, Wengophone won't work. Wengophone 2.1 also limits frame rates by not maintaining continuous capture and will cause the capture LED to blink erratically.

Notes

This driver is extremely unlikely to work with kernels prior to 2.6.17.

This driver could have been implemented in a way to use the usbvideo driver framework present in the Linux kernel. Instead, I ended up writing a new webcam driver abstraction library that is functionally similar to usbvideo but does away with a number of design problems present in usbvideo.

How This Driver Was Produced

Examining the Mvc25u870.sys driver shipped with my Sony VAIO SZ laptop, according to the version information, the copyright belongs to a company called Micro Vision. As others have pointed out, this company advertises a similarly named device on their web site called M25U870, a USB 2.0 camera controller chip. They mention that the device is based on an Intel 80C51 type microcontroller, they describe the types of image sensors it is compatible with, and say that the data sheet is only available under an NDA. Charming.

As for Ricoh, many have pointed out a list of USB 2.0 Video Interface parts advertised on their site. They seem to offer an R5U870 USB 2.0 camera controller chip, which sounds remarkably similar to the Micro Vision M25U870. They also offer two complete webcam modules. It is unclear whether any of these exact modules were used as the actual OEM webcams, and in fact the webcam in my Sony VAIO could not possibly be as thick as Ricoh describes either of their modules. Anyway, these generic Ricoh webcam modules are described as being either UVC, or "supported by the Ricoh Original Driver."

There is also a series of more recently released drivers, which are named 5U870CAP.sys. These drivers actually claim to be copyright Ricoh. This style of driver can be found for both the HP webcam and the Sony VAIO AR webcam.

Similarities with Cypress EZ-USB type devices might be noted. However, the R5U870 clearly cannot be used with the same firmware loading mechanisms as EZ-USB devices.

Windows Drivers Compared

A brief inventory of Windows drivers that I've examined for Ricoh webcams is below.

Each of these can be downloaded from the various OEM customer support sites, although most have click-through licenses.

To break it down, these drivers are very similar, and those of the same file name are similar in their machine code and organization to the point that specific functions can be compared. All of them:

• Contain a microcode blob, which is discussed in more detail below.
• Use the same core USB command set.
• Use the same end-of-frame detection method.
• Use a core set of registry values to configure which controls are available.

Each driver contains a different microcode blob. The blob is stored in some internal format. The drivers named Mvc25u870.sys all use what can be referred to as format A, and the drivers named 5U870CAP.sys all use format B.

Specific differences include:

• Each driver's microcode blob is different.
• The internal storage format of microcode blobs is the same between drivers of the same file name, but different between all Mvc25u870.sys drivers and all 5U870CAP.sys drivers.
• The drivers named Mvc25u870.sys all seem to be derived from a near common ancestor code base. The drivers named 5U870CAP.sys also seem to be derived from a near common ancestor code base, but that ancestor seems like a clean-up or rewrite of the Mvc25u870.sys ancestor.
• The HP drivers understand registry options for ColorEnable
• The Sony drivers all understand registry options for Backlight_Compensation
• The .INF files contain initial, default, and enablement values for each control, and none are identical.
• The HP1 driver understands a registry option call First_InstallEnableEx, which causes it to send command 0xA6 on probe after checking the microcode state.
• The HP2 driver instead uses command 0xA3 to presumably query the microcode version directly from the camera.

Microcode

All of these OEM webcams require microcode blobs in order to operate, and all seem to store the microcode blobs in volatile memory. The microcode must be loaded the first time the device is probed after a power cycle. Despite this, after losing power, all devices are able to provide USB descriptor tables, support the microcode upload commands, and gracefully recover from having invalid microcode uploaded.

As an unplanned experiment, some folks took my driver with its Sony1 microcode, and tried altering the device IDs so that it would initialize their HP webcam. This was an interesting experiment, because they reported that the HP webcam functioned in every way except that all isochronous data packets returned were empty, and thus the capture application would "hang" waiting for frames to complete.

This XX5U870 chip appears to be yet another webcam building block. Image sensors can be mixed and matched, but there must be corresponding microcode to support each image sensor. In this case, the Sony and HP webcams contain different image sensors.

UVC Devices

Newer R5U870 based webcams report proper UVC descriptor tables, and behave as genuine UVC compliant devices. These cameras can even be used with a generic UVC driver such as linux-uvc. However, they cannot function until their microcode has been uploaded, and uvcvideo will fail to initialize the device unless the microcode was previously uploaded by some external entity, e.g. the Windows driver.

Aside from microcode problems, these devices cannot be completely controlled by a generic UVC driver, as they do not expose all of their picture controls through UVC interfaces.

The Windows driver for Ricoh UVC cameras is the Microsoft-provided usbvideo.sys generic UVC driver, plus a pair of filter drivers. The R5U870FUx86.sys is attached above uvcvideo.sys. I'm not quite sure exactly what this driver does. The R5U870FLx86.sys is attached below usbvideo.sys, between it and the USB bus drivers. This driver is responsible for uploading microcode, and sending vendor commands for certain picture controls that are not exposed through UVC interfaces.

Acknowledgements

Thanks to Albert Vilella for establishing an interest group for this type of webcam, for early VAIO SZ testing, and generally collecting a good set of resources for Linux on VAIO SZ laptops.

Thanks to Geert Willems for extensive testing of HP Webcam support, general driver compatibility testing, and putting up with endless crazy requests for more debug information. :-)

Thanks to Mattia Dongili for taking usbsnoop traces of the VAIO UX50 webcam driver on Windows, and testing initial support in the Linux driver.

Thanks to Benoît Canet for support for the Sony VAIO AR webcam, device 05ca:1834. Benoît independently reverse engineered the Windows driver, extracted the microcode, and helped determine the control set.

Change Log

• Version 0.9.1, 2007/3/21 - Fix build with 2.6.19 kernel, usbcam library update.
• Version 0.9.0, 2007/3/6 - Major update, support three additional devices, restructure driver, fix at least one oops.
• Version 0.8.1, 2007/2/15 - Fix build problems with kernel 2.6.18.
• Version 0.8.0, 2007/2/14 - Initial public release

 Filed Under:

• Projects
• Hardware
• Software

• Login to post comments
• 1 attachment

Today was my first experience with Apple's support division. I bought an Intel Mac Mini a little over a month ago and have been having a problem with it. The issue is that it would randomly hang at boot before POSTing. The power light would come on solid, but it wouldn't display anything, it wouldn't make the CD-ROM drive chirp quietly, and it wouldn't even make its startup chime. It would do this persistently if powered off by holding down the power button for six seconds and powering it on within a minute. The hang would also affect sleep, where one could put the machine to sleep in OS X and come back to find it in the same sort of hung state with no video and the power light on solid. The problem gets worse with OS X configured to automatically put the machine to sleep. This problem would occur on maybe three out of five boot attempts.

Anyway, I took it in and must have consumed 45 minutes of the poor guy's time just trying to get the machine to fail. When I first tried to reproduce the problem, it booted reliably more than ten times in a row. Argh!! Anyway, the guy was patient and eventually the problem started occurring as frequently as it did at home. Then he suspected that the software I had installed was causing problems. I had installed their firmware update, Boot Camp, and used Boot Camp to repartition the disk and install Linux alongside OS X. Boot Camp is a beta product that they don't support, at least not yet, so we did a clean install of OS X and lo and behold, it's still possible to get the machine to hang.

Apple is going to replace the logic board under warranty. They don't have parts at the retail store I took it to so it will take a week. Case closed for now. I walked out having traded my Mac Mini for a piece of paper.

While I was trying to convince the guy that it really was broken, he managed to fix issues for three other people, including dead iPods, corrupt filesystems, etc.. The guy wouldn't even bring up warranties until after diagnosing a problem as a hardware problem. This guy, and probably Apple's service divison as a whole really seem to take care of their customers and I'm quite impressed.

Aside from all of this, the Mac Mini is quite an impressive piece of hardware. It has cutting edge Pentium-M "Yonah", i945GM, and ICH7 silicon from Intel, two SODIMM sockets, a Marvell gigabit ethernet chip, a CSR BlueCore4 Bluetooth HCI, Atheros wifi, and a 2.5" Serial ATA hard drive. The integrated Intel video is less than impressive though. All of it is generally compatible with Linux using various open-source drivers, although due to how new the hardware is, some drivers are still in their infancy and have bugs.

The major Linux problems I have with it are:

1. Suspend-to-RAM doesn't work, it seems to get stuck before successfully powering down. Hopefully this is related to my Mini having been broken.
2. The Intel HD Audio driver can't output to the headphone jack, can't sample from the line-in jack, and can't use the built-in speaker. It *can* output to the line-in jack. WTF?

Also, during this whole experience I heard reference to at least one web hosting service provider that deals in rack-mounted Mac Minis. Whoa!!

 Filed Under:

• Hardware

• Login to post comments

My apologies for having let things rot for two months. Since the last post, I have become a rabid cell phone and embedded device hacker. It's refreshing to see software run in your hand, rather than in a big noisy rack somewhere.

This isn't renouncing my complaints about cell phones -- I still stand behind every one.

 Filed Under:

• Diary
• Hardware

• 3 comments
• Read more

As many know, I have a very low opinion of cellular phones. I've tried to summarize some of the reasoning below:

10. A phone is as much a fashion statement as a contemporary gadget, and phones become obsolete faster than computer equipment. If the technology behind a phone isn't replaced in a year, count on it going out of style.
9. To maintain the balance of flashy new phones, and support of the American culture of purchasing on credit, service providers use shell games to subsidize and conceal the cost of new phones, and service contracts as enforcement. Their accounting is their own business, but this makes them seem less like champions of inexpensive luxuries and more like deceitful price discriminators.
8. When a phone is purchased through a provider subsidy, the phone is typically "locked" and made to work only with the subsidizing provider. An industry has sprung up around the (uncommon) need to remove the protection on these "locked" phones. This industry is arguably illegitimate in that the protection should not exist in the first place, should be freely removable, or should only be removable by the manufacturer or the provider that set it. "Business opportunities" for third parties make absolutely no sense.
7. If the last three points aren't enough of a deterrant to switching providers without buying a new phone, incompatible standards may be. While the rest of the world has standardized on GSM, the U.S. providers Sprint and Verizon insist on CDMA. No GSM phone can be used with these providers, and no CDMA phone can be used with Cingular or T-Mobile.
6. Service providers pad their revenues with a substantial amount of nickel-and-diming. This practice I find reprehensible. Features that providers charge extra recurring fees for, such as instant messaging, tend to have profit margins on the order of 90%. Service providers also have the balls to charge people $3 for a lousy ring tone, and almost everybody goes along with it! It's no wonder those bastards refuse to cooperate with Apple on an iPod phone. A number of media companies and even Motorola also engage in nickel-and-dime practices for mobile adaptations of services that are otherwise free on the Web.
5. For some reason, cellular phone owners feel the need to talk on the phone while driving. Research suggests that a 20-year-old driver talking on the phone has the reaction time of a 70-year-old, and can behave as if more impaired than a legally drunk driver.
4. Service providers build their voice service from a conglomeration of low-bandwidth data services, in a very restrictive and inflexible way. The stack of services that they sell seems entrenched, and irreflective of more modern methods, such as layered internet service and VOIP service. Mobile internet service is inherently more valuable than mobile voice service. I hope something like WiMax destroys them all.
3. Depending on how you add it up, U.S. providers are sales and marketing machines, not the technology powerhouses they might have you believe. As a good example, take Verizon. According to their 2004 SEC filing, their wireless division received $24.4B in monthly service revenues. During the same period, they spent $7.74B on "Cost of services and sales," including expansion and maintenance of their infrastructure, their FCC licenses, and their long distance operations. However, they spent a whopping $9.59B on "Selling, general and administrative" expenses, including sales, marketing, billing, and customer service. That's 39.3% of their monthly revenues. The other U.S. providers have similar figures between 25-40%. Perhaps this sector needs some federal regulation.
2. Service providers seem to have little regard for their customers' privacy, given the apparent ease of obtaining calling records.
1. Having a cellular phone has become a social requirement in most circles, and the combination of the phone and its adornments has become part of the impression one makes. Compare this to the near requirement of having a car in southern California.

 Filed Under:

• Hardware

• 5 comments

This morning my computer monitor seems to have died. It's a Nokia 445pro, a monster 70lb, 21" CRT that's about 3.5 years old, and conveniently covered by a three-year warranty. :-(

It went down very sliently: it just started failing to power up. No fireworks. The green LED comes on, but without the loud demagnetizer sound. About three seconds later, the green light starts blinking rapidly, as if to confirm the malfunction.

I found interesting links about this monitor, and a nine-page service manual of some sort with circuit schematics. Maybe Mike Badger can fix it. Otherwise it'll be time to start hunting on ebay. I seem to have extremely bad luck with monitors. My last monitor, a Fry's special of some sort, died within its warranty period, and the replacement died about six months after the warranty expired.

 Filed Under:

• Diary
• Hardware

• Login to post comments

This article documents upgrading the firmware of a built-in Memory Stick slot on a Linux-based Sony VAIO R505 laptop, to make it compatible with Memory Stick Pro media.

 Filed Under:

• Hardware

• Login to post comments
• Read more