REGISTER  


uvcvideo module compatibility
This thread belongs to expert.forumgeeks.net


2009-07-02 09:20 GMT   |   #1
 
I have a Thinkpad X61s, running sidux using stock kernel
2.6.23.12-slh-smp-2. I'm trying to get a Logitech QuickCam Pro for
Notebooks running on it, and it seems that given the kernel, I must
compile a uvcvideo module.

I went to linuxtv.org/hg/~pinchartl/uvcvideo and downloaded
uvcvideo-bff77ec33116.tar.gz, put it in /usr/src, unarchved it, ran #
make all and # make install. There did not seem to be any errors.

However, when I try to register the module (# modprobe uvcvideo) I'm
warned that all config files require .conf: /etc/modprobe.d/kgemu and
i2c. It will be ignored in a future release. I'm not sure what this
means. However, there was a fatal error: "Error inserting uvcvideo
/lib/modules/2.6.23.12-slp-smp-2/kernel/drivers/media/video/uvc/uvcvideo/uvcvideo.ko.:
Unknown symbol in module, or unknown parameter (see dmesg).

In dmesg I see:

uvcvideo: disagrees about version of symbol v4l_compat_translate_ioctl
uvcvideo: unknown symbol v4l_compat_translate_ioctl

and the same for these other variables: video_devdata, symbol
video_unregister_device, video_device_alloc, video_usercopy,
video_device_release.

Am I correct to infer that the driver I'm trying to register is not
compatible with the kernel version? If not, I'm not sure what to do (I
can't compile a new kernel version).

If there's no easy resolution of the problem, would someone recommend a
webcam and driver that has comparable quality to the QuickCam Pro and
will definitely work with the stock 2.6.23.12-slh-smp-2?
2009-07-03 05:20 GMT   |   #2
 
You can ignore the "config files require .conf" for now (it's not relevant
to the problem at hand).


Is it possible that you have not removed the old modules from
/lib/modules? Try this as root:

for F in `find /lib/modules/`uname -r` -name 'uvcvideo*'`
do mv "$F" "$F".`date +'%Y-%m-%d'`; done

Now re-run your make install:

cd /where/ever/
make install

Now update the modules list and try to reload the uvcvideo module:

depmod -a
modprobe uvcvideo


I don't think you have told us the actual version of the QuickCam Pro
you're trying to use? Also, is there any chance you can upgrade to (at
least) 2.6.28? I found a significant improvement in the V4L layers here.


I also found that I needed a newer version of the V4L1 compatibility
layer (the kernel provides V4L2 for user-space decoding, but applications
mostly still talk V4L1). You might want to search for a newer v4l1compat
library, and then set this before trying any of your video applications
(change the path appropriately)

export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so

This lets Skype work happily with my i.t.works webcam (093a:2621 "Pixart
Imaging, Inc."). 
2009-07-03 13:20 GMT   |   #3
 
I had trouble with the command (syntax error near "done"), although if
I knew how to copy/paste the string in your message from emacs/gnus to
an xterm without a mouse, I might have done better. In any case there is
a .../uvc/uvcvideo.ko, which I suppose I could just delete. That you
didn't simply tell me to do that is the reason I hesitate to do it now.

I didn't realize there were different versions of the Logitech QuickCam
Pro for Notebooks. There's no version number on the device. Neither
lsusb or dmesg after a reconnect conveys that information.


I presume the reason is that the driver is built into that kernel and so
the webcam becomes plug-and-play. Is this right?
2009-07-03 14:10 GMT   |   #4
 
You may find that some manufacturers change critical chipsets for devices
without changing the model or revision of a product. I am aware of this
happening with wireless cards, and webcams. I have learned that sometimes
the USB ID is more important than the manufacturer and model of the product.

I have been impressed by the Linux webcam support (I use a UVC webcam), but
many programs don't support V4L2, and sometimes a device driver only supports
V4L (revision 1). Some programs work better than others with particular
webcams, because webcam formats can vary. Some webcam drivers don't support
read(), so only the programs that use mmap() work with those drivers.

I found that Skype worked best with my webcam, and the uvc driver, other
programs crashed, or displayed images I didn't expect. Your experience will
probably vary.
2009-07-06 13:20 GMT   |   #5
 
About the syntax error... there's an obvious problem there – nested `` don't
work well. You want one of these:
\`uname -r\`
$(uname -r)

$() is better since it's nestable without requiring more \s.

2009-07-06 19:20 GMT   |   #6
 
Yes, sorry about that. Trying to swap between a version that worked in
my specific instance, and one that was general enough to give me useful
results for your machine, I managed to double up my backticks.

Try this instead (which assumes bash as a shell):

for F in $(find /lib/modules/$(uname -r) -name 'uvcvideo*')
do echo "$F"; mv "$F" "$F".$(date +'%Y-%m-%d'); done

I've tweaked it slightly, to list the name of any file it moves out of
the way, so you've a chance of restoring what it's done if you don't
like it.
2009-07-10 11:20 GMT   |   #7
 
Thanks, Chris, the script worked as expected.

The original suggestion was to rerun # make install on skype, but I had
used a debian package for skype version 2.0.0.72-1 that I downloaded
from the Skype website, and so I assume that upgrading my kernel from
the present 2.6.23 to 2.6.26 would be unecessary.

After I renamed the skype uvcvideo module, and uninstalled skype, I
found I found I can't reinstall skype, for in preparation when I run
aptitude update:

Err ftp://ftp.us.debian.org sid/main Packages
Sub-process bzip2 returned an error code (2)

I suppose this means that one of the packages being updated is corrupted
and can't be unarchived. Is this error being returned from the debian
archive site, indicating the problem is at that end? I don't know how to
fix this other than using an alternative debian package repository. But
if this doesn't work, it seems I can't install anything, including a
reinstall of skype.

Two questions: a) Is there good reason to abandon Skype's skype-debian
package and compile skype from source?, b) Does it still look like it
might be necessary to update my kernel by getting the 2.6.26 kernel from
backport? None of this can proceed as long as my ability to unarchive
packages is being blocked?
2009-07-10 11:20 GMT   |   #8
 
Unless you work for Skype, you will not have the source code. Considering
your question, I assume you do not work for Skype.

In recent times I have found that the Skype package does not work since
upgrading from Ubuntu 8.x to 9.04. I experienced segfaults at first that
seemed to be random, and eventually Skype segfaulted repeatedly on startup.
So, I found that these segfaults were resolved in Ubuntu 9.04 by using a
static version of Skype. I suspect that something significant has changed
in an ABI that Skype depends on.

Debian has somewhat of a history of poorly maintaining proprietary packages
(Skype, nvidia, etc.). They do not include proprietary packages in the
default install, and they remove binary firmware images from the kernel (as
I understand it), which then forces those with the hardware that needs that
firmware to install another package. On the surface this may seem fine, but
it also may lose more users and not benefit Debian/Linux, because while it
might motivate a programmer, it will not motivate a general user. If the
user is trying to get wireless binary blobs, then they may be unable to even
access the Internet to get what they need to have a usable system.
2009-07-10 13:20 GMT   |   #9
 
haines_brown wrote:
After I renamed the skype uvcvideo module, and uninstalled skype, I found I
found I can't reinstall skype, for in preparation when I run aptitude
update:

Err ftp://ftp.us.debian.org sid/main Packages
Sub-process bzip2 returned an error code (2)

I suppose this means that one of the packages being updated is corrupted
and can't be unarchived. Is this error being returned from the debian
archive site, indicating the problem is at that end?


No and probably.

It's local in as much as the packages file is failing to be decompressed
locally, but probably remote in that one of the US mirrors is serving
corrupted files. (This isn't unknown.)