Hi Charlie, On Wednesday 16 April 2008, Charlie Wyse wrote: > Laurent Pinchart wrote: > > 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 > > Taht is unfortunate. Laurent, do you have a recommended UVC camera? We > bought a bunch of 5000's and are pretty much getting what you said, most > of them work, some just simply don't. We are looking at the Quickcam > 9000 and so far our tests are positive, do you think that might be a > better option?
It should be. The current version of the QC Pro 9000 is based on a less-buggy chipset. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
