Xavier Bestel wrote:
Le dimanche 30 novembre 2008 à 21:09 +0100, Hans de Goede a écrit :
Attached is a new patch (replacing the previous one) which contains some
additional debugging stuff, as well as a new environment variable controlling
the possible culprit here.
Gregor, can you please do a new test build for Xav with this patch?
Xav,
Can you please test this test build (once done) 2 times launching cheese like
this:
LIBV4L2_LOG_FILENAME=/tmp/log1 cheese
LIBV4L2_LOG_FILENAME=/tmp/log2 LIBV4LCONVERT_NO_UVC=1 cheese
And mail both log files, I would also like to know if the second run with
"LIBV4LCONVERT_NO_UVC=1" perhaps fixes your issue.
Yes and no. With LIBV4LCONVERT_NO_UVC=1 I'm able to go from 160x120 to
176x144, but after that (i.e. at 320x240) it still fails.
I attached another log at this resolution to see the failure.
Ok, it looks like your hitting a cam firmware bug now, which is a know issue
(some cams unfortunately are just buggy at the hardware/firmware level) and
which is what the special UVC code, disabled by LIBV4LCONVERT_NO_UVC, tries to
avoid by being "gentle" to the cam. That or you are hitting an (old and fixed
in 2.6.27) driver bug, where it will fsck up when you switch between formats,
which libv4l will do with your cam when switching between 160x120/176x144 to
320x240 or higher, with the low res it will use YUYV and with the higher
resolutions it will use MJPEG.
You can test if the second case is the case by choosing 320x240 in cheese, then
as it freezes killing it (it will still remember the new settings). Then unplug
the cam and replug it, and then start cheese again.
I've just released 0.5.7, which Gregor will hopefully make available in a .deb
soon, which removes the need to use LIBV4LCONVERT_NO_UVC, which makes the
chances of triggering firmware bugs much smaller.
Regards,
Hans
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
