Table of Contents: Where it's at.

• Preface: Why are we here? How did we get here?
• List of requirements: Pull yourself together.
• Getting a clean copy of the kernel source: Start over with a clean slate.
• Patching: How to mess up your clean copy of the kernel source
• Configuring: Make my config!
• Compiling: Wake me when it's over.
• Installing your new kernel: Our father, who art in heaven...
• Installing xawtv: Packages are our friends!
• Installing the camera: "Huh-huh.. He said probe..."
• Configuring the webcam software: 1 fps is *not* cool.
• Starting the webcam: No more naked strolls through the computer room!

Preface: Why are we here?

The aim of this document is to help you have a working webcam in just a few hours. This NHF involves re-compiling your kernel. This isn't nearly as hard as it sounds. If you're kind of uncomfortable with the idea yet, read either the Kernel Compiling NHF or the Kernel-HOWTO. In my case I was forced to use the 2.2.17 backport, due to the fact that 2.4.0-test9 broke a lot of USB serial stuff (I need *working* USB for my Handspring Visor to sync via USB in Linux.) and at the time of this writing namesys hadn't released a patch for ReiserFS for 2.4.0-test10. (I needed that patch, since my entire file system is Reiser!) I will try to be as non-version-specific as possible.

List of requirements: Pull yourself together.

First, let's get our materials together.

A computer that is already running Linux (I'm assuming Intel, but doing it for other architectures probably isn't that different)

At least one USB port already physically installed on the computer, either on-board or as an add-on card.

A working web server on the computer (or at least somewhere to ftp the file to)

A Xirlink/IBM USB camera (this link points to it at buy.com, other vendors may have it for less)

A copy of the kernel source code, either the latest beta 2.4.0-testxx or 2.2.17

A copy of the USB backport (for 2.2.17)

A copy of the most recent update to the USB backport (for 2.2.17)

A recent copy of the xawtv distribution

Getting a clean copy of the kernel source: Start over with a clean slate.

OK, the first thing we need to do is get a nice, clean copy of the linux kernel source. For most distributions, the source is stored in the directory /usr/src/linux/. Usually "linux" is just a symbolic link to a directory with a name like "linux-2.x.xx". ( the "x"'s mean whatever minor revision number and patch level the kernel is, as in 2.2.17) Delete this symlink with the command "rm -f /usr/src/linux". (You may have to be root to do this) Now, assuming your copy of the kernel source is in /usr/src/, use the following commands to un-tar.gz it and make a symlink named "linux" to it.

cd /usr/src/
tar -xzvf linux-2.x.xx.tar.gz
(copious amounts of filenames will scroll past, this may take a while depending on your system)
mv linux linux-2.x.xx
ln -s linux-2.x.xx linux

Now you have a clean copy of your kernel in /usr/src/linux-2.whatever.whatever, with a symlink to it at /usr/src/linux.

Patching: How to mess up your clean copy of the kernel source.

At this point, you need to apply any patches you need or want. Users who will be compiling 2.2.17 will need to apply the USB backport patch. Users of 2.4.x can just skip ahead to the section labeled "Configuring."

It is a good rule of thumb to apply patches in the order, from what you must have to what you'd kinda like to have. (This comes into play later!)

To apply the backport patch on 2.2.17, copy the USB backport patch to /usr/src, and execute the following commands:

cd /usr/src/linux
patch --dry-run -p 1 -i /usr/src/usb-2.4.0-test2-pre2-for-2.2.16-v3.diff

A list of patched files will scroll by. If you see it whine about "failed hunks", something is wrong.
If that command completes successfully, do it again, without the --dry-run option.

patch -p 1 -i /usr/src/usb-2.4.0-test2-pre2-for-2.2.16-v3.diff

Apply the update in the same manner, just change the file name to the name of the update.

In my particular case, I applied the ReiserFS, Openwall, and USB backport patches in that order. I ran into problems. Apparently the ReiserFS and USB backport patches conflict. I had several failed hunks in both /usr/src/linux/Documentation/Configure.help and /usr/src/linux/include/linux/fs.h. Since I already knew what the options did from reading documentation, and I wasn't going to be using USB for any file system related things, I decided that this would not be a problem. This is where that rule of thumb comes into play. If I had applied the USB patch first, Reiser would be broken. That does me no good since I must have ReiserFS support built into the kernel. Since I did it in the proper order, Reiser support is OK, but some non-used portions of the USB code are broken. So far it has worked just fine. I'll post an update if it does start to foul up.

Configuring: Make my config!

OK, at this point the source code is ready to configure and compile. The easiest way to do this is to cd into the /usr/src/linux directory and enter "make xconfig". This will bring up a slick GUI-fied configuration utility. You will need to know a lot of specifics about your system to configure it properly. Going over how to configure every single option in the kernel is far beyond the scope of this document. One thing you need to keep in mind is that you need to compile Video4Linux support to use the camera.

The specific option you're looking for is under the "USB support" menu, and it's called "USB IBM (Xirlink) 'C-it' Camera support". select the option to compile it as a MODULE. This is important, as building it in locks out a lot of the neat options you can use with it.

Whenever you're done playing with all the pretty buttons, click the "Save and Exit" option in the main menu.

Compiling: Wake me when it's over.

OK, you've gotten all the real brain work done. Now it's time for the hard labor. Enter the following commands:

cd /usr/src/linux
make dep
make modules
make modules_install
make bzImage

If any of those commands end in an error state, read the error messages and try to correct the error. I have yet to have a kernel build error out, but it can happen. After issuing the "make bzImage" command, go take a break. Rest your eyes. You're 1/2 way done.

Installing your new kernel: Our father, who art in heaven...

Some of you may have heard the term "smoke test" before. This is one. If you misconfigured, you're about to find out. Execute the following command to copy your new kernel to the /boot directory.

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-test

Now (assuming you're using LILO) you'll need to edit /etc/lilo.conf. First make a backup copy.

cp /etc/lilo.conf /etc/lilo.conf.bak

Now open /etc/lilo.conf in your text editor of choice. (emacs, vi, pico, M$ Windows Notepad under WINE, etc...) You should see a section like the one below. I've trimmed some of the fluff off clarity. LEAVE IT IN THE FILE. This is just showing the parts you'll be modifying.

image=/boot/vmlinuz
        label=linux
        root=/dev/hda1

The value for "root" may be different on your box. Just remember what it is. You're going to need to insert an almost identical section right below this, with just a couple modifications. This is what it should look like:

image=/boot/vmlinuz
        label=linux
        root=/dev/hda1
image=/boot/vmlinuz-test
        label=test
        root=/dev/hda1

Now that you've done that, save the file and exit, then run "lilo". (You must be root to do this.) If lilo exits with no errors, you're ready to test the new kernel. Reboot.

When you see the "lilo:" prompt, quickly type in "test". If you configured the kernel correctly, you will see no differences. If you didn't, you'll get some kind of error. You'll have to reboot, let it boot normally into linux, and try again. Please don't e-mail me questions about configuring your kernel. You know more about your box than I do.

If your new kernel works, You'll need to go back and edit your lilo.conf to boot to the new kernel by default. Execute the following commands:

mv /boot/vmlinuz /boot/vmlinuz-old
mv /boot/vmlinuz-test /boot/vmlinuz

Now go back and edit your /etc/lilo.conf to look like the following:

image=/boot/vmlinuz
        label=linux
        root=/dev/hda1
image=/boot/vmlinuz-old
        label=old
        root=/dev/hda1

Run "lilo" again to refresh it. You're now finished futzing with your kernel. (whew!)

Installing xawtv: Packages are our friends!

This one is easy. if you have a distro that uses RPM's, go here, sort out any dependencies you may have, and install it. If you're running a distro that uses DEB's just apt-get it. If you really want to compile from source, go for it.

Installing the camera: "Huh-huh.. He said probe..."

Plug the camera into an open USB port. It doesn't matter which one. Now get to a command prompt and do this:

modprobe ibmcam (You may have to be root to do this)
xawtv

You should now be looking at yourself on your screen. Frame rate and quality might not be that great, but all you want is stills anyhow.
Try playing with different module options to get the best image. The full list of options is in the ibmcam module documentation, usually in /usr/src/linux/Documentation/usb/ibmcam.txt. The command i use to install the module is "modprobe ibmcam framerate=0 videosize=4 flags=3 lighting=2". There's a reason for the monochrome flag. On my box, xawtv showed the video with pretty good color quality, with just a slight orange tint. However, "webcam" (the program that comes with xawtv that we'll be using later) showed the picture as if it were being taken through a grease smeared green beer bottle bottom. It looked like the "Amazing Nightvision LSD Cam". Therefore, I opted for plain old B&W.

Now that we know things work, let's configure "webcam".

Configuring the webcam software: 1 fps is *not* cool.

"webcam" uses a file called .webcamrc in the home directory of the user invoking it for it's options. The user should have write rights to your web directory. My .webcamrc looks like this:

[ftp]
host=my.own.box
user=dontcare
pass=asif
dir=/home/httpd/html
file=webcam.jpg
tmp=tmp.jpg
passive=1
debug=0
auto=0
local=1

[grab]
device=/dev/video
text="-=( DirkCam %d %b %Y at %H:%M )=-"
width=352
height=240
delay=60
input=0
norm=0
rotate = 0
top = 0
left = 0
bottom = -1
right = -1
quality = 75
trigger = 0
once = 0

The values for host, user, pass, and passive don't matter to us if we're doing this for a webcam on the local box. If you're going to be uploading the file to a remote server, fill in the fields with the proper info, and set local to "0". Also remember to set the delay value longer than you think it will take the image to upload! The values for dir and file set where we want the file to go, and what it's to be named. Set this to your web directory. The value in text will be stamped on the bottom of the image. Read the strftime man page for details. Width and height give the size of the image to be taken. I couldn't get it to work right on any setting other than 352x240, but YMMV. Delay is the number of seconds between updates. Don't set it too high. It's annoying to listen to your hard drive rattle once per second. Quality sets the amount of compression on the image. 75 is a good value for good quality in a economic file size.

Starting the webcam: No more naked strolls through the computer room!

To start the cam, simply su to the user that you've set up to use the webcam, and type "webcam" at a command prompt. You'll see some info about how the program is configured, and where it's putting the image. Do an "ee /home/httpd/html/webcam.jpg" to see the image. Cool, huh? Now just write up a page featuring it on your site, (remember, code theft is the most sincere form of flattery) and shazam! You're done!

Remember, anyone on the internet can see your picture. Try to avoid doing stuff you don't want others seeing in front of your new cam. It has been scientifically proven that the chances of the image updating during an embarrassing moment is directly proportional to the level of embarrassment said image would cause you! Enjoy!