Hi, On Saturday 21 February 2009 19:58:02 Pivo wrote: > Hi Laurent, > I have the same webcam, the same problems than petr but the problem is not > solve and I think you didn't get the answers you wanted. > > > 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'. > > Bus 001 Device 002: ID 05ca:183b Ricoh Co., Ltd > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 64 > idVendor 0x05ca Ricoh Co., Ltd > idProduct 0x183b > bcdDevice 1.00 > iManufacturer 0 > iProduct 0 > iSerial 0 > bNumConfigurations 1
[snip] Thanks for the descriptors. Ricoh cameras are not renowned for their UVC compatibility :-/ > > > 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. > > # luvcview -s 640x480 -f yuv -i 30 > luvcview version 0.2.1 > size width: 640 height: 480 > interval: 30 fps > Video driver: x11 > A window manager is available > video /dev/video0 > > Stop asked > Clean Up done Quit > > # dmesg > [20451.408588] uvcvideo: Frame complete (EOF found). [snip] > [20456.138594] uvcvideo: Frame complete (EOF found). Looks pretty normal. > # luvcview -s 320x240 -f yuv -i 30 > luvcview version 0.2.1 > size width: 320 height: 240 > interval: 30 fps > Video driver: x11 > A window manager is available > video /dev/video0 > ^C > Stop asked > Clean Up done Quit > > # dmesg > [20516.062625] uvcvideo: Frame complete (overflow). > [20516.062637] uvcvideo: Dropping payload (out of sync). [snip] > [20516.067631] uvcvideo: Dropping payload (out of sync). > > Many and many lines like that! > > > 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). > > You are right! Unfortunately :-/ I don't know why the device didn't understand the resolution change request. It could be anything from a bug in the camera, a mostly-but-not-really UVC compatible firmware, or just an inability to stream at lower resolutions. Capturing a USB trace on Windows might help understanding what's going on. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
