To make life easier for you, I divided the answers into several sections. Please read this carefully before you send mail. Chances are your question is already answered in here.
This question is now partially defunct. There used to be a binary only driver, and the story is covered here. Now, only a small binary only part remains; a fully functional driver is included in the main Linux 2.4.* kernel.
Unless you have a very recent version of 'modutils', modprobe won't
recognize the usb modules. The place to download modutils is
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3
You can place the module in /lib/modules/kernel-version/misc/,
or insert the modules manually with insmod.
Also, don't forget to run 'depmod -a' once when you just installed the modules.
This could be a number of things... First make sure you have the right kernel and applied all necessary patches and/or source. Second, check your processor version. If the P5 version of a module loads and the P6 version Oopses, then your processor does not understand some of the assembly instructions generated by gcc. If your Oops trace contains a line like this:
Code: 0f 4d c2 31 ....
And the first byte is '0f' you can be reasonably sure that is the problem. The P6 version has only a little performance gain over the P5 version.
If the problem persists however, run the 'Oops' message through ksymoops and send the output to me... I may be able to determine something from that. Also, tell me following things:
Note: this problem seems to have gone away with the 3.3.* versions of XFree86.
This is not the fault of my module; rather, X doesn't like to update its screen 15 times a second, especially with larger images. I suspect it's a buffer overflow problem or something. I hope to solve this by either using the X shared memory extension or direct writes to video memory.
The 645/646 models sometimes show a short green bar on the right hand side of the image. This has been fixed in the 4.* modules.
The usb-pwc-*.o module produces a few messages in the kernel log; most of them speak for themselves, but you might see this:
where XXX is a number that jumps up. This is nothing serious; it just means that the program that currently reads information from the driver is lagging behind and that the driver had to dump incoming frames from the camera. After 20 such messages it will stop nagging you, and print a total when the webcam device is closed.
Some messages that you might see in your kernel log are about scratch buffer over- or underflow. This is harmless; it means that the driver received too much or too little data in one frame and it can't be used to decode an image. The video frame is discarded and the driver waits for a new frame to arrive. This message could appear now and then when the system is loaded heavily or when there's a lot of USB traffic.
See also the item about interrupt, status messages from UHCI/OHCI..
Nope. It's just a fancy addition to the version number.
Some distributions (Mandrake, Redhat, some non-english distro's) are shipped with kernels that will give version mismatches while loading the webcam modules.
For example, Mandranke kernel have a version number like "2.2.14-15mdk", so insmod/modprobe complains that the kernel-version of the pwc-module is "2.2.14". Often these kernels contain additional/distro-specific code and the extra version string indicates this. But it breaks compatibility.
You can try forcing the module in with the '-f' option, but do that only if you know your kernel version really matches the module. But the best way is to use a vanilla kernel (see the installation notes).
Modules are always compiled on stock Linux kernels.
You shouldn't always believe what's printed on the box, nor what Windows does :) But seriously:
The point is that these resolutions are not really possible with the cams: the CCDs (light sensitive sensors) only have a resolution of 352x288 (PCVC645/646) or 640x480 (PCA675/680/690/730/740) pixels. This is the physical limit of the cameras. Any larger pictures are simply enlarged versions of the images at maximum resolution (though you would have to look real close to see it). So, rather than giving you the false impression you get some extraordinary imagesize, I limit the driver to the physical characteristics of the cams.
Below is a table that shows the possible resolutions and framerates for the webcams. On the left, all physical resolutions are listed; at the top, the various framerates.
If a cell is blank, it means the combination of resolution and framerate is not supported. A green cell means the combination is supported uncompressed; a red cell indicates that combination is only available in compressed mode.
Size | PCA 645/646 & VC010 | PCVC 675/680/690 | PCVC 730/740 | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
3.75 | 5 | 7.5 | 10 | 12 | 15 | 20 | 24 | 5 | 10 | 15 | 20 | 25 | 30 | 5 | 10 | 15 | 20 | 25 | 30 | |||
sQCIF 128x96 |
||||||||||||||||||||||
QSIF 160x120 |
||||||||||||||||||||||
QCIF 176x144 |
||||||||||||||||||||||
SIF 320x240 |
||||||||||||||||||||||
CIF 352x288 | ||||||||||||||||||||||
VGA 640x480 |
(Yes, VGA resolutions are limited to 15 fps: there isn't enough bandwidth available on the USB bus to squeeze through more, even with compression).
Note: I would like to point out that Philips is certainly not the
only manufacturer who overrates their products a bit. When you buy a 3.2 GB
harddisk, what you get is a capacity of about 3.200.000.000 bytes, not
3.435.973.837, which is what 3.2 gigabytes really is.
An even better example are scanners, which may claim extremely high
resolutions of 9600dpi, while in reality the element is limited to 600 dpi
(and sometimes only in just one direction). That means only 1 out of 12
pixels is 'real'; the rest are just interpolated in software.
Uh yeah, Philips lied a bit. See the answer above.
There are two possiblities here; either you are using the 'old' style /dev directory with fixed device inodes, or the so called 'devfs' (which, confusingly, is often mounted at the same spot....)
Type
# mount -t devfs
Usually all possible device inodes reside in a directory /dev on your system. Since the webcam driver uses the Video4Linux interface, it uses device inodes with major 81, minor 0...63. It does NOT use the 'usbcam' devices at major 180, minor 80. This is how your 'ls /dev/video*' should look like:
lrwxrwxrwx 1 root root 11 Jan 31 21:07 /dev/video -> /dev/video0 crw-rw---- 1 root video 81, 0 Nov 25 1998 /dev/video0 crw-rw---- 1 root video 81, 1 Nov 25 1998 /dev/video1 crw-rw---- 1 root video 81, 2 Nov 25 1998 /dev/video2 crw-rw---- 1 root video 81, 3 Nov 25 1998 /dev/video3
You can create the device inodes with commands like mknod /dev/video0 c 81 0 (this requires root permission). You can create up to 64 video devices.
It is not necessary to have a 'video' group, but if you have a multi-user system you may wish to give only certain people access to the video devices. If you are the only one using the system you can forget about this and just set the access permissions to 666 (rw-rw-rw-).
To overcome some limitations of the fixed device numbering, Linux has an alternate device system called 'devfs'; it is a dynamic directory maintained by the kernel, not unlike /proc. Entries come and go as devices are registered resp. unregistered, so you don't have to create them (well, you can't!)
The devices work exactly the same, but their place is different from the old system (devfs uses subdirectories). The video devices are placed in /dev/v4l, and mine looks like this:
crw------- 1 root root 81, 64 Jan 1 1970 radio0 crw------- 1 root root 81, 224 Jan 1 1970 vbi0 crw------- 1 root root 81, 0 Jan 1 1970 video0 crw------- 1 root root 81, 1 Jan 1 1970 video1 crw------- 1 root root 81, 2 Jan 1 1970 video2 crw------- 1 root root 81, 3 Jan 1 1970 video3 crw------- 1 root root 81, 4 Jan 1 1970 video4
(Yup, that's 5 video devices; the radio and vbi entry are from my TV card). So, if you want to use an application with your webcam, you may have to specify your device like this (example given for xawtv):
# xawtv -c /dev/v4l/video2
This applies in case you have multiple webcams and/or other video devices like TV cards. The answers to these questions are then: "I don't know" and "Yes, you can".
Video devices are normally assigned on a first come, first served basis; the first device to register gets /dev/video0, the second device /dev/video1, etc. So you can't predict which device (/dev/video0, /dev/video1, etc) gets assigned to you webcam. It depends on your hardware setup, the order in which the modules are loaded, the order in which the cam(s) are plugged into a hub and the phase of the moon. The driver logs the assigned device into your kernel log, but that's only informational.
Starting with PWC 8.4, you can 'hint' the driver as to what device number it should use with the 'dev_hint' module parameter. See Documentation/usb/philips.txt in your linux kernel sources for a full description of this parameter.
The answer is unfortunately, no. Although I'd love to get these cams working on all systems, I simply don't have the time nor resources to make specific kernels for everybody. You'll have to do it with the kernels that are mentioned in the release notes and that I've tested.
The modules are always compiled on stock Linux kernels, not on anything that is shipped with a Linux distribution (which may contain extra code that breaks my module).
FYI: On average, it takes 3-4 hours to build a release. I have to download the kernel patches, patch my kernel, hook in the code of the cam, compile the kernel & modules, do lilo, reboot, test if everything works (rarely at the first run), build 4 release modules, update HTML, build packages and upload it all. So that's a whole evening for me.
Also see the next item.
Now that 2.4.0 is finally out, I will support them of course. The 2.2.* series now has USB built in, as of 2.2.18. Unless people start over switching massively to 2.4.0 this version will be supported, but probably not with in every release.
I plan to release modules at least every month or so, for a recent kernel and backport.
Since PWC is open source now, in principle all platforms that Linux runs on. The PWCX decompressor is another story, however. The list is far from complete, but the PWCX download section usually has a chart of supported platforms, kernels and compilers. These modules are created by cross-compiling from my x86 boxes; so far, this seems to work.
The answer is: I don't have to! One of the benefits of USB devices is that devices are 'broken up' (in a logical sense) into separate classes; some classes are standarized, but hardware vendors can make up their own classes. So the Philips webcam has two classes: one for video (which this modules supports), and a class for audio stuff, which has a standard driver in the Linux USB stack, and is written and maintainted by someone else. So just compile and/or load the 'audio' module for USB and you're done (amazingly, it works too).
If you want to know all the details behind these classes, read the documentation at www.usb.org.
Unfortunately, the answer is the same as to the question about the video devices: I don't know. Audio devices are also handed out on a first-come, first served basis. However, since most distro's only have device inodes for 1 or 2 audio devices, you may need to create extra devices with 'mknod'. This is what I've got:
crw-rw---- 1 root audio 14, 4 Jul 18 1994 audio crw-rw---- 1 root audio 14, 20 Sep 8 1999 audio1 crw-rw---- 1 root audio 14, 36 Feb 7 1999 audio2 crw-rw---- 1 root audio 14, 52 Mar 24 21:45 audio3 crw-rw---- 1 root audio 14, 68 Mar 25 00:39 audio4 crw-rw---- 1 root audio 14, 3 Jul 18 1994 dsp crw-rw---- 1 root audio 14, 21 Sep 8 1999 dsp1 crw-rw---- 1 root audio 14, 35 Feb 7 1999 dsp2 crw-rw---- 1 root audio 14, 51 Mar 24 21:49 dsp3 crw-rw---- 1 root audio 14, 67 Mar 25 00:39 dsp4
That's 3 devices for my soundcards and 2 for the cams that I have.
Well, I can't test each and every application under the penguin, so you should first try your favorite app and see if it works. If an error occurs, see if it's related to the image size or the palette, and try to fix that (see item 12 for a list of allowed image sizes). Sometimes a little tweak or option is needed to get a program working.
You can of course check out the Working stuff page for applications that are known to work at some point in time. Feedback is welcome!
Not yet; there is an 'input' interface defined for Linux that was written for this kind of human interfaces (knobs, sliders, mousepads, joysticks, etc.). I haven't quite figured out how to program with this interface, but who knows, on a rainy Sunday afternoon....
Chances are, you are using an OHCI controller and the 2.2.14 kernel with backport. Unfortunately, my driver seems to trigger a bug or problem with this combination and therefor doesn't work well. I've had numerous reports related to the OHCI controller. The only recommendation I can give is to use a more recent kernel, like 2.4.0-test*.
Yes, the driver supports multiple Philips cams running at the same time. However, There is one thing that will limit the number of cams you can use simultaneously: USB bandwidth. Video uses a significant amount of bytes to get the image across. I've looked at the tables and in theory you could run up to 5 cameras on a single USB controller, but only at the smallest resolution and low framerate. Two cams at medium resolution sounds more reasonable. Try loading PWC with the following parameters to lower bandwidth usage:
# modprobe pwc fps=5 compression=3
NB: you can hook up as many cams as you like, but only use a few at the same time. If you want more cameras running simultaneously, or at a higher resolution/framereate. you must install an extra USB controller. On the other hand, a lot of motherboards nowadays come with multiple controllers installed (check the output of 'lspci'); these extra controllers are often wired to USB ports at the front of your computer. Or just the pins are available on the board, and then you can install an extra plate in one of the slots at the back of your computer with USB connectors.
This seems to be a problem that comes back time after time, especially in the 2.4.0-test* region. What happens is that the PWC driver gets registered, but it is never called by the USB core when a USB device is detected. The bad news is that I don't know why :-( You can play around with the order in which the modules are loaded (I suggest loading the pwc.o module before you load the module for your USB controller). Also, make quite sure your kernel version matches the one of the module exactly.
It's no use mailing me about this particular problem as I can't solve it now and I really don't want to delve into it, with the rapid kernel versions following each other...
Sometimes when the camera is plugged in, its image controls are stuck to some unusable state. Normally it has auto-exposure on and adjusts for different lighting conditions (daytime, fluorescent light, etc).
The only way to get this camera "unstuck" electronically is with CamStream at the moment. In the video controls dialog, there is a "Reset to Factory Settings" button. In 95% of the cases this does the trick. Unfortunately, there is currently no way to do it from a command line utility (I should probably make one), or have the camera reset every time it is opened.
Read this part in the Installation notes about it. Basicly, it's not problem.
In case you have an UHCI controller, try using the usb-uhci.o module, and not the uhci.o module. I'm having trouble with uhci.o too. The usb-uhci.o module is built when you select USB support -> UHCI Intel PIIX4, VIA, ... in your kernel.
The answer is simple: Philips doesn't make them. This may come as a shock to you, but it is quite common with computer hardware. These cameras are so called OEM products: some manufacturer develops a piece of hardware, and offers it for sale. Some other company (like Philips) then decides to buy these devices in large quantities, stamps their label on it, puts them in a box and sells them as their own, including warranty and support.
However, with these deals the hardware specifications are rarely sold
with the device. Thus, Philips does not even have the documentation
themselves to give to me.
The reverse also happens: Philips sells their hardware to others who
repackage it or design a camera around it; this explains the large number
of "strange" cameras supported by this driver.
But, not all is lost. The PVCV665 actually has a driver (see the main page for the link), based on its chipset. Something is happening for the PCVC720 too (again, link is on the main page).
The PCA635 is not supported because it is not a USB cam; it has a parallel port interface.
Good question, which gets asked quite a lot. The answer is: if the binary module works for you, don't bother. However, if the module goes Oops, hangs, produces weird images or lots of debug messages, then by all means try it.
The do-it-yourself package should in theory fit your kernel better, since it is compiled with the same options and compiler as your own kernel. Some things in the kernel are dependant on the compiler version and this could introduce a binary incompatibility. But in general, what I compile works on most kernels. Also, the do-it-yourself package does not offer any advantage in speed or functionality.
You forgot to install and/or load the pwcx.o module.
Only with a hardware modification. Yes, that means heating up a soldering iron, opening your webcam case and poke around the tiny SMD components with tiny wires. In other words, not recommended. If you are willing to take the risk, you can look at these instructions done by Steve Chambers.
The camera is quite sensitive however (that's why I get asked this question quite a lot), and by playing with the settings I mentioned about you can probably get a decent shot of the moon and some planets; but don't expect miracles. If you really want to do serious astronomy with an electronic camera I suggest you buy one of the commercially available CCD sensors (some may even have Linux drivers). Or submit your resume at NASA :)
Correct. With the inclusion of the driver in the standard kernel (version 7.0) Alan Cox insisted that all the palette conversion stuff be removed from the driver. The result is that 90% of the tools didn't work anymore. Blame Alan, and contact the writer of your tool to have it fixed, not me. The only palette currently supported by the driver is VIDEO_PALETTE_YUV420P.
The good news is that virtually all tools work with the PWC driver again; see the Working stuff page for what's known to work. The most notable exception is RealProducer Basic.
A yes... One day I'm going to have a word with the nitwit who decided that the USB information should not be available to the user unless he/she really requests it... Use this command:
# mount -t usbdevfs none /proc/bus/usb
No. There is a MacOS X driver, however.
The pwcx module was compiled on 2.4.6, so it won't load immediately on anything else. But you can force the module in with insmod like this:
insmod --force /lib/modules/usb/pwcx.o
Yes, there is! John Rodkey sent me a tip; add this to your /etc/modules.conf:
post-install pwc /sbin/insmod --force /lib/modules/usb/pwcx-i386.o >/dev/null 2>&1 || :
You may of course have to change the path to the pwcx module, depending on your setup. Now everytime pwc is loaded (either by modprobe or the kerneld), pwcx will loaded too. You will need the --force option because the pwcx kernel version will probably not match yours. And oh, since pwcx is kernel independant, you should indeed install it in /lib/modules/usb, instead of /lib/modules/<kernel-version>/kernel/drivers/usb.
You should copy the pwcx.o module to /lib/modules/usb; this directory is specifically set up for kernel-independant/external modules, and modprobe will look in this directory too. See also the item about automatic loading of PWCX.
This seems to happen with the PCVC730 and the Logitech cam; I have seen it myself, and it has been reported a number of times. Unfortunately I don't have a solution, and even the folks at Philips aren't sure what the problem is...
Of course that doesn't help you a lot, but at least you know you're not alone :-)
There have been a number of requests to make a 'mirror' option for the module. That is certainly possible, but that would require modifications to the PWCX module as well, including a new major number. Eventually, it will happen, no worries :)
Because then I would spend all day writing such step-by-step instructions for every imaginable Linux distribution and version out there. And next you're going to ask me to translate it as well, including Oompa-Loompa...
The observant reader will detect a hint of sarcasm in the above paragraph. But there is another reason: step-by-step instructions probably aren't going to help you much if you don't know what you're doing. And if something is missing from your installation or some other unexpected error occurs, you'll probably be stuck anyway. The best advice I can give you in this case is to ask a friend who has more knowledge about Linux and help you with the installation, and observe what they are doing.
Now I know that this sounds a bit like 'I know it all but I'm not going to tell you anything'. The point is: I don't know much. Not about the current Linux distributions anyway. And I think you should learn how to do your basic Linux stuff first before you attempt something like upgrading your kernel, which isn't that difficult, but still a bit tricky...
Nothing to worry about; since 2.4.something, kernel modules are required to have a license type encoded in the module, similiar to the kernel version number. This is because the Linux kernel is based on the GNU GPL (General Public License), and some kernel developers feel that all modules that are loaded in the kernel should be GPL 'licensed' too, so that's why this check is built into modutils. However, since PWCX is based on an NDA and closed source, it cannot be released as a GPL module. So I put in another text for the license type, and that's why modutils complains.
Fortunately, this does not affect the working of the module in any way; it is just a reminder that the module you're loading isn't 100% GPL 'pure'. To most people this doesn't matter; as long as it works without much hassle they don't care. But some people insist on having a 100% pure GPL system, so they are warned, and probably do not wish to use the PWCX module.
If you want to know my personal opinion of this tactic, you're invited to read my editorial "Tainting the kernel".
If you can't load pwcx.o because of these messages:
depmod: *** Unresolved symbols in /lib/modules/usb/pwcx.o depmod: pwc_unregister_decompressor depmod: pwc_register_decompressor depmod: printk
then you have a kernel with version information on module symbols turned on. Recompile and/or install a kernel with this option turned off. And yes, that is the only way.
If pwc.o (without x) doesn't load because of these missing functions:
pwc.o: unresolved symbol video_register_device pwc.o: unresolved symbol video_unregister_device
you forgot to load and/or build the videodev.o module. However, on newer systems this should almost never be the case. If this doesn't work or you have other missing functions, you have a problem :)
Presently, no. The reason is that the cameras are built for streaming data, not stills. There's no way to pause the image stream easily so you can take snapshots at a whim. The only method is to open the camera device, take a snapshot and close it again, then go to the next.
I have absoltely no idea. But if these kind of errors crop up regularely and cause problems:
usb-uhci.c: interrupt, status 2, frame# 1625
then you may have a problem with your USB controller. Exactly what, I can't tell you; but there is one common pattern: (heavy) IDE disk access. This is what I wrote to somebody in a mail recently:
I think the main problem is timing and PCI bandwidth hogging. USB is quite allergic to delays in its handling of incoming packets, or at least under Linux. In addition, PWC can send quite large USB frames (up to 960 bytes/frame). Now, as soon as the USB controller receives a packet it will try to send it to the computer's main memory, and to do so, it has to send the data over the PCI bus (the USB controller is usually a PCI busmaster); this can happen several hundred times per second. Now, with all these IDE UltraDMA 33/66/100/133 disks and controllers, it's quite possible the IDE disk hogs the PCI bus long enough for the USB transfer to fail. I think that in the BIOS on most motherboards the IDE controller gets a way higher priority than the USB controller. In the past I've suggested trying to play with the latency of PCI devices with the 'setpci' utility, however without any definite results.
So there. Either way, it's not my (or PWC) problem; you should write to the authors of the UHCI and OHCI controller drivers, they may be able to tell you what's wrong.
However, before you innundate them with email, try the following first:
Before you really start mailing these guys, make sure you can reproduce the problem. Unreproducable errors simply cannot be solved.
Note: the Philips webcams use isochronuous USB tranfers, which are not reliable. This means that if a bad or corrupted USB frame arrives, it is discarded and no retransmission is attempted. So it's quite normal for the PWC driver to drop a video frame or two.
The 2.6 kernels use a new (binary) format for their modules; the module files now end in '.ko', in stead of '.o'. This new format is incompatible with the old one, so you can't load old versions of PWCX. I suggest you use the new PWCX 9 module. You will need PWC/PWCX 9 anyway for kernel 2.6.7 and higher.
Before you continue, you should check with the manufacturer of your ARM board if the on-board USB controller can support large ISOC transfers. Some boards do not support isochronuous transfers at all, others are limited to a maximum of 240 bytes. Although theoretically some modes of the PWC cams use a framesize < 240 bytes, it does not always seem to work.
Before you contact me, check if your USB controller on your board supports ISOC transfers up to 1024 bytes. If not, PWC cannot work on your system.
In case you don't get a color image but a grayscale image that is repeated three times on a row, the program you are using does not support the VIDEO_PALETTE_YUV420P palette. Contact the author of the program. Or stop drinking so much :-)