Hi Charlie, On Tuesday 15 April 2008, Charlie Wyse wrote: > Brandon Philips wrote: > > On 12:33 Tue 15 Apr 2008, Charlie Wyse wrote: > >> Whenever I run a make on the uvcvideo directory I get an error about > >> the version.h file. If I look at the file itself it is a 0 length > >> file. This file is removed with a make clean, so it looks like > >> something in the make process isn't working. > > > > If you aren't using a SVN checkout or don't have svn installed the > > version.h generation won't work. The driver will still build however. > > > > Relevant source entries. > > > > Makefile: > > <snip> > > @sh svn-version.sh > version.h 2>/dev/null > > > > uvc_driver.c: > > <snip> > > #ifndef DRIVER_VERSION > > #define DRIVER_VERSION "v0.1.0" > > #endif > > > >> My QC 9000 works most of the time, but I figure this might be why all > >> my devices come up as <unnamed>, even if I put the vender/product id > >> into the uvc_driver.c file before running a make. Any one know what > >> is going on with that file? > > > > Your device comes up as <unnamed> because the device vendor didn't > > include the optional string descriptor for it. It shouldn't effect the > > device functioning. > > > > What functional problems are you having with the device? > > > > Cheers, > > > > Brandon > > Good to know about the version.h thing, I was afraid that was the > problem as the 08ce was no in the uvc_driver.c file until I added it. > We are having problems with some of our Logitech QC 5000's. When we > create the module on the same kernel we keep getting things in dmesg > like the following: > uvcvideo: Found UVC 1.00 device <unnamed> (046d:08ce) > uvcvideo: Failed to query (1) UVC control 2 (unit 0) : -71 (exp. 26). > uvcvideo: Failed to initialize the device (-5).
-71 is -EPROTO. This is a low level error that can be caused either by electrical issues (noisy environment, bad cables, bad USB ports, ...) or a buggy device (firmware and/or hardware). The Logitech QC 5000 is known to be buggy. Sad but true. There are lots of timing issues that are usually not triggered when using the webcam under Windows. Linux has different timings, and things sometimes break depending on your kernel version, on the USB controller, on the CPU speed, ... Plugging the camera into another USB port might help. If it doesn't I'm afraid there's not much I can do. > This prevents us from seeing any video and causes ekiga to crash with > the following error in dmesg logs: > Apr 15 10:51:39 duel kernel: uvcvideo: Failed to query (132) UVC control > 4 (unit 2) : -32 (exp. 2). That's a non-fatal error that you will see quite often when you run into timing issues. It basically means Ekiga tried to modify a control (probably brightness in this case) and the device didn't answer the request because of timings issues caused by a firmware bug. > On my other machine I am getting past the dmesg part with both the QC > 5000 and 9000, ekiga still doesn't want to switch video with whomever I > call, but I believe that might be an ekiga problem. I can still look at > gstreamer-properties and see video without errors. I was afraid this > was just due to vendor ids not being listed, but it looks like I was > troubleshooting down the wrong path. Any ideas what could case those > issues? Webcam bugs unfortunately :-( There might be a way to work around them in software, but that would require in-depth analysis with a USB 2.0 analyser, comparing traces captured using Windows and Linux, ... Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
