faq.html

Linux support for Philips USB webcams halted Latest version: pwc-9.0.2.tar.gz (including documents

  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td bgcolor="#00cc00">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#00cc00">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
</tr>
<tr>
  <th>CIF<br>352x288</td>
  <td bgcolor="#00cc00">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td bgcolor="#00cc00">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
</tr>
<tr>
  <th>VGA<br>640x480</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td bgcolor="#cc0000">&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
</tr>
</table>

<p>(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).

<p><b>Note:</b> 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 <i>is</i>.

<br>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.


<h3><a name="R11">The box says I can take images at 60 frames per second, but I seem to be stuck at 15 fps?!</a></h3>


<p>Uh yeah, Philips lied a bit. See the <a href="#Q3">answer above</a>.</p>

<h3><a name="13">What are the correct device-nodes for the webcam?</a></h3>

<p>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....)</p>

<h4>Checking which system you are using</h4>

<p>Type 
<pre>
    # mount -t devfs
</pre>

<br>If mount returns no lines or an error, you are using the old system. If
it does return something like <b>none on /dev type devfs (rw)</b>, the new
style device nodes can be found in the directory /dev (Note: the exact
place may vary).


<h4>Old style /dev</h4>

<p>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:

<p>
<pre>
	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
</pre>

<p>You can create the device inodes with commands like <b>mknod
/dev/video0 c 81 0</b> (this requires root permission). You can create up
to 64 video devices.</p>

<p>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-).

<h4>New style devfs</h4>

<p>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!)</p>

<p>The devices work exactly the same, but their place is different from the
old system (devfs uses subdirectories). The video devices are placed in
<b>/dev/v4l</b>, and mine looks like this:</p>

<p>
<pre>
    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
</pre>
</p>

<p>(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):
<pre>
    # xawtv -c /dev/v4l/video2
</pre>
</p> 

<p><a href="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html"
target="_blank">Linux devfs FAQ</a></p>


<h3><a name="14">What device gets the cam assigned when I load the
module/plug the camera in? Can I specify the video device?</a></h3>

<p>This applies in case you have multiple webcams and/or other video devices
like TV cards. The answers to these questions are then: &quot;I don't
know&quot; and &quot;Yes, you can&quot;.

<p>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.

<p>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 <a
href="philips.txt">Documentation/usb/philips.txt</a> in your linux kernel
sources for a full description of this parameter.</p>


<h3><a name="15">Can you compile a module for me for kernel X or Linux distro Y?</a></h3>

<p>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.

<p>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).

<p>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 &amp; 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.

<p>Also see the next item.


<h3><a name="16">Which kernel versions <i>do</i> you support, then?</a></h3>

<p>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.

<p>I plan to release modules at least every month or so, for a recent kernel
and backport.


<h3><a name="G17">Which OS/processors/hardware do you support?</a></h3>

<p>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 <a href="release.html#pwcx">PWCX download
section</a> 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.</p>



<h3><a name="18">When will you write support for the microphone?</a></h3>

<p>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 <b>has</b> 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).

<p>If you want to know all the details behind these classes, read the
documentation at <a href="http://www.usb.org/">www.usb.org</a>.


<h3><a name="19">What device gets the microphone assigned?</a></h3>

<p>Unfortunately, the answer is the same as to the <a
href="#14">question</a> 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:

<p>
<pre>
	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
</pre>

<p>That's 3 devices for my soundcards and 2 for the cams that I have.

<h3><a name="20">What applications work with this cam and module?</a></h3>

<p>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 <a href="#12">item 12</a> for a list of allowed image sizes).
Sometimes a little tweak or option is needed to get a program working.

<p>You can of course check out the <a href="working.html">Working stuff</a>
page for applications that are known to work at some point in time. Feedback
is welcome!


<h3><a name="Q10">Is there a way to access the button on the cam?</a></h3>

<p>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....


<h3><a name="22">I get lots of buffer underflow/overflows, or mysterious
'URB unlink timeout' messages</a></h3>

<p>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*.

<h3><a name="23">Can I use multiple cameras at the same time?</a></h3>

<p>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
<i>simultaneously</i>: USB bandwidth. Video uses a significant amount of
bytes to get the image across. I've looked at the tables and <b>in
theory</b> 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:</p>

<p><pre>
	# modprobe pwc fps=5 compression=3
</pre></p>	

</p>

<p>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.</p>


<h3><a name="24">The module loads, USB says something about a device detected, but no go...</a></h3>

<p>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. 

<p>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...


<h3><a name="25">The image is too dark/bright/discoloured</a></h3>