Okay, first a little nitty-gritty. The e-mail address to report problems is at the bottom of this page, but before your scroll down immediately and click "Send", READ THIS PAGE. Time after time I get e-mails with incomplete information, and I simply want to make sure you understand what you have to send to me. It makes life easier for the both of us!
BTW, do not call the Philips helpdesk with problems about this camera under Linux. I cannot stress this enough. Their helpdesk simply doesn't know anything about Linux; their staff is trained for the Windows and Macintosh platforms, and Linux is out of their league. They don't officially support Linux (but they might be, if enough Linux users start using their products :)).
Unfortunately, I often get mail about 'problems' with PWC that actually aren't related to PWC at all, but have something to do with the underlying USB layer(s). Appearantly it is not always clear to people what the relation is between PWC, USB and the actual webcam. So here I provide a little bit of background on USB in Linux. You can skip this section, but I think that reading it will help you track down problems a lot faster and more accurate. And save me from mail to which I can only reply: "Sorry, not my problem."
The most important thing to know is that the PWC driver does not talk directly to the camera; there are several soft- and hardware layers in between: the usb-core, the USB controller driver, the USB controller chip and the actual cable running from your PC to your webcam. Here's a small dataflow diagram:
Application | - - - - - - - - - - - - - | Video4Linux | : | : | PWC | : | : | usb-core | (kernel) : | : | USB controller | - - - - - - - - - - - - - | [chip] || \ ====== [cable] ===== [webcam]
At the top is the actual application that will use the webcam; could be anything from a single snapshot program to CamStream. This talks to Video4Linux, which is a nice API for video devices in Linux; this, in turns talks to PWC, which takes commands like "Set image size to 352x288 pixels" or "Set the brightness to 150". PWC will translate this into USB commands that the camera will understand, and gather streaming data coming from the webcam through the underlying layers and convert that into actual image. So far, nothing spectacular.
The usb-core is the next layer, but this is rarely a problem either. It mediates between device drivers like PWC and the USB controller drivers, which talk directly to the actual chip on your motherboard. And there is where most problems occur.
Currently, there are 3 basic designs for the USB chip on your computer's motherboard, called UHCI, OHCI and more recently, EHCI. Each requires its own driver. To make matters more complicated, different manufacturers have different implementation of these controller chips and some are more, shall we say, compatible than other. So that's one source of problems.
Then, there can be bugs in the actual chip; it happens, and is often a source of great frustration for driver writers and results in ugly hacks in the code. Third, electrical problems can occur in the cables and connectors to your webcam. Bad connectors, corrosion, bends in the cable, breaks, interference, you name it.
In all of these layers something can go wrong that will prevent you from getting an image, but I can do something only at the PWC layers.
So how can you tell that the problem is with PWC or somewhere else? Here are some tell-tale signs:
This is a problem with the application itself: appearantly it does not understand, or support, the YUV 4:2:0 planar palette that PWC uses. Do not mail me, but the author of the program.
A typical message for this condition looks like this:
Dec 5 14:16:36 tinus kernel: usb_control/bulk_msg: timeout Dec 5 14:16:36 tinus kernel: pwc Failed to set video mode SIF@15 fps; return code = -110 Dec 5 14:16:37 tinus kernel: usb_control/bulk_msg: timeout Dec 5 14:16:37 tinus kernel: pwc Failed to set video mode QCIF@10 fps; return code = -110Unfortunately, this is one of the many cases PWC does not work because the underlying USB layer fails. In this particular case, the PWC driver is trying to initialize the webcam with a resolution & framerate, but the USB command simply does not get through (hence the timeout). There could be a million reasons why it fails, but you'd have to check with the developer of the USB controller.
Here's a short checklist that you should run over first:
/var/log/messages
)mount -t usbdevfs none /proc/bus/usb
)If the answer to any of the questions above is 'No' (provided it applies to your system), then correct the problem first, and please try again.
Kernel messages are very important, but hardly anyone seems to read them :( They are usually logged to /var/log/messages, or /usr/adm, but I strongly suggest you separate your kernel messages by putting the following line in your /etc/syslog.conf:
kern.* /var/log/Kernel
Loading the module should give the following entries:
linux: pwc Philips PCA645/646 + PCVC675/680/690 + PCVC730/740 webcam module version 6.01 P6 (UP) loaded. linux: pwc Also supports Askey VC010 cam. linux: usb.c: registered new driver Philips webcam
Followed by the detection of the cam:
linux: usb.c: USB new device connect, assigned device number 3 linux: pwc Philips PCA645VC USB webcam detected. linux: pwc Registered as /dev/video1.
Of course, you may have a different model cam and some of the numbers may change, but these lines must be there.
Fortunately, when a problem occurs with the module, it will just trigger an 'Oops' in the kernel, so you can save the output and generate a report while the module is still in memory.
Unfortunately the information of the 'Oops' itself is not really useful, since it only contains hexadecimal addresses. You have to run it through the ksymoops utility, that will translate these addresses into more comprehensible function names. To get a good 'Oops' do the following:
Use the 'dmesg' utility to see the last part of the kernel log; dump its output into a file.
In case 'dmesg' doesn't work, or after a reboot, locate the 'Oops' message in your syslog; the file is usually named /var/log/messages, /usr/adm/messages or /usr/log/messages, or, if your followed my advice above, in /var/log/Kernel. Copy the file and use an editor the remove the timestap, hostname and the word "linux:".
A good oops looks like this:
usbcore: USB disconnect on device -1 kmem_free: Bad obj addr (objp=c4db6f60, name=size-64) kernel BUG at slab.c:1651! invalid operand: 0000 CPU: 0 EIP: 0010:[<c0126c95>] EFLAGS: 00013282 eax: 0000001b ebx: c119b0e0 ecx: c5772000 edx: c156e060 esi: 00003202 edi: c4db6f60 ebp: 00010001 esp: c5169f28 ds: 0018 es: 0018 ss: 0018 Process khubd (pid: 1193, stackpage=c5169000) Stack: 00000673 00000005 c5d434d0 00000002 c54fd140 c4db6fbc 00000001 c68c08fd c4db6f60 c558a920 00000000 00000008 c558a920 00000000 c68bf749 c558a920 c5168000 c68c0a3e c558a920 c5168000 00000000 00000000 c558a4a0 c68c46fa Call Trace: [<c68c08fd>] [<c68bf749>] [<c68c0a3e>] [<c68c46fa>] [<c68c4878>] [<c68c699c>] [<c68c6a47>] [<c68c4941>] [<c68bf050>] [<c0109fa7>] [<c68bf000>] Code: 0f 0b 83 c4 0c eb 18 57 68 45 3e 1d c0 e8 95 01 ff ff c7 05
(The real start of the oops is at the 'invalid operand' line, but a little context doesn't hurt).
Run this file through ksymoops, save the output and send that to me.
# cat oopsfile | ksymoops > oops.out
The other type of problem that you might encounter is the infamous kernel panic; your system seems to 'hang'. The problem is that you usually cannot see what the problem is, because most webcam applications run in X, and since the kernel messages are printed on the text console you can't see them.
Also, because the system goes down hard, there are no messages written in your system log, so you really have to be at a text console when the problem occurs. This is a bit more tricky:
If possible, write down the EIP address, and the Call Trace. Send this information to me, along with:
This will help me determine where the crash exactly occurs.
NB: this technique does not always works; sometimes a recursive stack trace is printed on the screen that scrolls of your screen within a millisecond or so... There's not much you can do then.
There are a few other documents and sites you may want to check before sending mail; chances are your answer is already in there:
Now that you have finally read all the way to the bottom of this file :-) you can send e-mail to webcam @ smcc.demon.nl. Please include the following in your mail:
I usually answer within a few days. If you haven't heard from me after a week, try resending your mail, but first check out the main page to see if I'm not away on vacation, or something. Note: I speak both Dutch and English.