Hi Petr, On Monday 10 November 2008, Petr Menšík wrote: > hi, > > i found interesting news. my camera will change its resolution, but only > to 640x480 and 1280x1024 correctly. I was astonished when high > resolution worked, i did not expect that. I got working svn version of > luvcview, but really lower resolutions are still wrong in that also.
Could you please send me the USB descriptors of your camera ? You can retrieve them with 'lsusb -v'. > Yes, lower resolutions worked fine in ekiga before, i believe it is > using lowest one, 160x120. So there's probably a problem on the host side (or at least in the host <-> device communication). Your tests seem to point to the resolution change not being understood by the camera. To confirm that, I'd like you to check the kernel log with the uvcvideo trace parameter set to 128 (either when loading the driver, or later with 'echo 128 > /sys/modules/uvcvideo/parameters/trace'). Clear the kernel log (dmesg -c), run a video application in 640x480 for a second or two (longer would write too much messages to the log), close the application and capture the kernel log. Rerun the same test procedure in a lower, faulty resolution such as 320x240. If, as I suspect, the camera doesn't understand the resolution change properly, it should send a whole 640x480 frame even when the driver expects a lower resolution. Excess video data should be dropped and logged by the driver with a "Dropping payload (out of sync)" message. Those messages should not occur in 640x480 (or at least be way less frequent than in 320x240). > Really firmware loading is a bit problem, as you have to reload module if > you did not load before usb subsystem. Camera cannot be unpluged, because is > built-in. This is indeed a problem. Unfortunately the camera doesn't re-enumerate with a different product ID after firmware loading. Let's try to find a solution for that problem after fixing the lower resolutions issue. > What is for input layer for webcamera by the way? I have one pretty old > Genius GE111 with button on it, yet driver did not support button when i > tested it (and i doubt it will ever do, as image quality from camera is > very low). The uvcvideo driver creates an input device to report button events for cameras that have driver-accessible buttons. > It might be useful to direct owners of r5u870 to web page about it, tell > them it needs firmware and maybe refuse to handle them without special > parameters. Maybe print some warning at least for usb vendor id for > these cameras. Good point. I'd like to see if we can solve the lower resolutions problem first, then I'll make a list of the remaining issues and report them on the driver's website. > Oh and i forget to note interesting feature. In mplayer, it started to > show anything always after 10th frame on lower resolutions. There is > black first ten frames when resolution is lower than 640x480. > > When i see usage of UVC standard for my camera, is that reliable to buy > some camera claiming to support standard? Is it unusual having camera > like mine, working only after firmware loading? Yes it's very unusual, and even not allowed by the UVC standard. The camera should enumerate with a different PID and not advertise UVC capabilities before the firmware is loaded, and re-enumerate with UVC descriptors after firmware loading. This is what the iSight does. In addition to the firmware issue, there are also other UVC non-compliance problems with the r5u870 chipset that make it far from being UVC compliant. > I hoped that with adoption of uvc webcams will be finally plug&play without > messing with strage drivers from strange place. We're getting there. Some cameras (early Logitech models for instance) have bugs that make them quite unreliable, others claim to be UVC compliant while they really are not (Ricoh and Apple iSight come to mind). Fortunately most UVC webcams work out of the box with the Linux UVC driver, otherwise maintaining the driver would become a full-time job :-) > Is it again more about marketing than engineering? In case of Ricoh, I'd say yes. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
