GNOME Bugzilla – Bug 559057
cheese doesn't show v4l2 video output and disables output on gstreamer-based apps ran afterwards
Last modified: 2008-11-18 08:05:55 UTC
See also: https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/290506 Binary package hint: cheese == Regression details == Discovered in version: 8.10RC Last known good version: 8.04.1 gstreamer-based apps (gstreamer-properties, cheese) doesn't show the v4l2 video output. cheese can configure webcam (Dell Inspiron integrated webcam) but it does not provide any output. after some time the apps hang. vlc can play with the webcam (including sound). the hardware: [ 11.835433] uvcvideo: Found UVC 1.00 device Laptop Integrated Webcam (05a9:2640) [ 11.835731] uvcvideo: Failed to query (135) UVC control 1 (unit 0) : -32 (exp. 26). [ 11.893113] input: Laptop Integrated Webcam as /devices/pci0000:00/0000:00:1a.7/usb3/3-1/3-1:1.0/input/input11 [ 12.025138] usbcore: registered new interface driver uvcvideo
I confirm this bug (same issue here after upgrading to latest gstreamer and uvcvideo) and I'm pretty sure it's something related to gstreamer moving to libv4l and that few ioctls we do for camera detection. I have a bugfix patch but I'd like to better understand why the issue is happening before to post it. What concerns me is that we wrote that code with the help and suggestions from Hans de Goede (libv4l author) so why didn't he noticed it wasn't going to work properly after the libv4l switch?
Created attachment 121981 [details] [review] first test patch.. fixes the issue here This patch fixes the issue but I'm really not sure why.
Hans, some question for you: Is that patch really needed? It seems those ioctls someway lock uvcvideo devices so that gstreamer is unable to access them. The only way to make them work again is to remove and re-modprobe uvcvideo. It's strange the very same ioctl doesn't cause any issue with gspca or other webcam drivers. So is it a cheese bug or a uvcvideo one? In the patch I replaced the second ioctl with a v4l2 one but that's wrong, it's a v4l1 one, please ignore it (sorry). What should we do with that call? is libv4l really needed for a such a simple task like querying capabilities?
Filippo, That patch you attached can *NOT* fix this, when you call v4l2_ioctl with an fd which was not returned by v4l2_open (which this one is not) it will just pass the call through (unmodified!) to the regular ioctl function, so the result of your patch is that nothing has changed. I think this might be a timing issue in the uvc driver. Anyways, no matter what weird ioctl's we fire towards the uvc driver it should not stop function, after the device has been closed and gets reopened by another app, it should work no matter what the previous app did to it. The only thing which should stick is changes to v4l2 controls like contrast and brightness. I think this clearly is a driver bug, have you contacted the UVC driver author, he usually is very responsive to problem reports.
(In reply to comment #4) > That patch you attached can *NOT* fix this, when you call v4l2_ioctl with an fd > which was not returned by v4l2_open (which this one is not) it will just pass > the call through (unmodified!) to the regular ioctl function, so the result of > your patch is that nothing has changed. Hans, as I said I don't really know why it fixes it but I can *actually* reproduce the bug here without that patch and cannot reproduce it anymore with that patch applied. So it seems that ioctl call breaks the driver. It is probably a uvcvideo issue but I have no clue why it doesn't happen anymore using libv4l2.. Also note that I have no issue with current cheese trunk and a pre-libv4l gstreamer version so the issue could be caused by gstreamer later on.. Another detail is that there is no issue with gstreamer alone.. so it seems that particular combination of that ioctl + gstreamer causes this behavior. I thought that could be related to the mix of libv4l and plain ioctls.. but if you say it can't I cannot disagree for sure. > Anyways, no matter what weird ioctl's we fire towards the uvc driver it should > not stop function, after the device has been closed and gets reopened by > another app, it should work no matter what the previous app did to it. The only > thing which should stick is changes to v4l2 controls like contrast and > brightness. Completely agree.. no ioctl should cause such a behavior. I just tried to fix the issue here because I too often tell the reporters their issue is a driver one and not a cheese one... so I wanted to check if that was true with this case too. > I think this clearly is a driver bug, have you contacted the UVC driver author, > he usually is very responsive to problem reports. > I'll do, what it the right way to contact him? direct mail? kernel bugzilla? Thank you for your help!
Hmm, Some random ideas: 1) Can you try adding: #include <syscall.h> And then replacing the "ioctl(fd, ..." with "syscall(SYS_ioctl, fd, ...", that is what libv4l2 will turn this in, but that should not make any difference. 2) Can you try adding a sleep between the open and the ioctl? 3) Can you do export LIBV4L2_LOG_FILENAME=/tmp/log before starting cheese and attach the resulting log here About contacting the uvc author, direct mail will be the best.
(In reply to comment #6) > Hmm, > 3) Can you do > export LIBV4L2_LOG_FILENAME=/tmp/log before starting cheese and attach the > resulting log here Ok, please forget everything I said.. I don't know what happenend yesterday when I did my tests (probably I was too tired) but today I've been able to better nail down the problem. The issue seems to happen only if I use the webcam at maximum resolution (1280x1024).. it is reproducible both with cheese and gst-launch and has no relation with those ioctls (the driver actually locks when we try to use v4l2src at the maximum res). It happens both with and without that patch, I'm attaching a libv4l2 log for completeness. So, it is definitely a driver bug, I'll contact the uvcvideo developer.. Please forgive me for the noise ;)
Created attachment 122047 [details] libv4l2 log libv4l2 obtained with current cheese trunk, yesterday's uvcvideo checkout from v4l-dvb mercurial tree and latest gstreamer from ubuntu intrepid. I just started cheese until it locks up.
Ok it seems it was an issue related to gstreamer switching to libv4l. It should be fixed with new uvcvideo drivers, see changeset: http://linuxtv.org/hg/~pinchartl/uvcvideo/rev/62c88b326ecd and the correspondent thread in the linux-uvc-devel list: https://lists.berlios.de/pipermail/linux-uvc-devel/2008-November/004210.html For ubuntu intrepid users I suggest to follow the launchpad bug, a developer from the kernel team released a test package containing the patch so if you want it to be soon included go there and say it works! Closing as NOTGNOME.
*** Bug 560983 has been marked as a duplicate of this bug. ***