Created attachment 432563 [details] output of `sudo lsusb -vv' Description of problem: After boot and after wakeup from hibernate the LED indicator on the built-in webcam of my ASUS F3 laptop is turned on. Version-Release number of selected component (if applicable): It has happened with all kernel (and other related versions) I've upgraded to for a few months, first in Fedora 12 and now in Fedora 13. How reproducible: Get such a laptop running Fedora 13 and boot it, or hibernate & resume it. Or: Actual results: The webcam LED will be on after boot / resume. Expected results: The webcam LED should be off after boot / resume. Additional info: The LED can be turned off by enabling the webcam using some webcam software for a few moments, e.g. vlc or cheese. At first the LED will stay on when the software turns the webcam on, but the LED will go off when the software is closed. In this software, the webcam works fine. This bug also happened on Fedora 12 (I upgraded a few days ago). On Fedora 12, I used the following workaround: `sleep 30 && modprobe -r uvcvideo && modprobe uvcvideo' in /etc/rc.local. After upgrading to Fedora 13, this stopped to work: removing and re-inserting the uvcvideo module does (usually) not turn off the LED anymore. However, after the LED has been turned off, removing and re-inserting the uvcvideo module does not turn the LED on either (usually).
Created attachment 432564 [details] output of `sudo lspci -vv'
FYI, I am now using the following - incredibly ugly - hack to turn the LED off (in /etc/rc.local): mplayer -tv driver=v4l2 tv:// -vo xxxx >/dev/null & That works because mplayer opens the input before it figures the output is nonsense and exits with an error. Because it opens and closes the input the webcam LED is turned off...
Not sure if it is related, but I recently noticed that not only a boot or resume turns on the webcam LED unexpectedly, but also starting rhythmbox (version 0.12.8). I'm not aware of any webcam support in rhythmbox.
Another thing I now figured out, which might be useful: It occurred to me that maybe the LED would be turned on by an USB device scan or so. So I tried this using lsusb, and indeed running lsusb turns on the webcam LED! So I tried to narrow this down a little more using strace on lsusb, and finally came to the conclusion that apparently opening the device of the camera (/dev/bus/usb/001/002) switches the LED on. E.g. `dd if=/dev/bus/usb/001/002 of=/dev/null count=0' is sufficient to switch the LED on. As I expected, when opening other USB devices this does not influence the LED status at all. At this moment I do not know how to look further, but to me it seems clear that just opening the device file triggers something somewhere that turns on the webcam/LED.
Hi, Hmm, I'm getting the feeling that this may be related to bug 625852, which is also happening since F-12. I have 2 theories now: 1) Something changed in userspace and is probing the usb device in a way it does not like. I believe this is what is happening in your case. You write that simply opening /dev/bus/usb/001/002 is enough to re-enable the led. Can you try turning the led off by running a webcam using app and then do: udevadm trigger --action=add And see if this turns the led on again? 2) USB autosuspend is somehow causing this issue. Can you try booting with usbcore.autosuspend=-1 added your kernel cmdline and see if that helps? Thanks, Hans
Hello Hans, I tried both now, here are the results: 1) Running udevadm trigger --action=add turns the led on. 2) Booting with usbcore.autosuspend=-1 does not seem to make any difference: the led will still turn on in all the situations mentioned earlier.. Regards, Tobi
Hi Tobi, Thanks for the input, ok so lets try to figure out what exactly is causing the led being turned back on. Very likely it is something triggered from a udev rule, so lets start with the obvious candidates. First of all we will need to find out the sysfs path for your camera, do: /sys/bus/usb/devices/ For all entries which do not have a colon in their name, do (with 1-1 being an example): cat /sys/bus/usb/devices/1-1/idVendor cat /sys/bus/usb/devices/1-1/idProduct We are looking for an entry below /sys/bus/usb/devices/ which matches the following vendor:product : 0c45:62c0 Now lets say that 1-1 matches, then the udev sysfs path for your camer is: /bus/usb/devices/1-1 Notice how udev removes the /sys at the front. Now turn the led on your camera off by starting a video stream app, and then do: sudo /lib/udev/usb_id --export /bus/usb/devices/1-1 Does this turn on the led? Now turn the led on your camera off again by starting a video stream app, and then do: sudo /lib/udev/usb-db /bus/usb/devices/1-1 Does this turn on the led? Thanks, Hans
Hi Hans, I just remembered I still had to do this, sorry for the delay. I can not find the vendor:product ID you mention, hence I looked in lsusb output and found this ID: Bus 001 Device 002: ID 174f:5a35 Syntek Sonix 1.3MPixel USB 2.0 Camera $ cat /sys/bus/usb/devices/1-2/idVendor 174f $ cat /sys/bus/usb/devices/1-2/idProduct 5a35 So it's device 1-2. $ sudo /lib/udev/usb_id --export /bus/usb/devices/1-2 ID_VENDOR=Sonix_Technology_Co.__Ltd. ID_VENDOR_ENC=Sonix\x20Technology\x20Co.\x2c\x20Ltd. ID_VENDOR_ID=174f ID_MODEL=USB_2.0_Camera ID_MODEL_ENC=USB\x202.0\x20Camera ID_MODEL_ID=5a35 ID_REVISION=0411 ID_SERIAL=Sonix_Technology_Co.__Ltd._USB_2.0_Camera_SN0001 ID_SERIAL_SHORT=SN0001 ID_BUS=usb ID_USB_INTERFACES=:0e0100:0e0200: LED remains off. $ sudo /lib/udev/usb-db /bus/usb/devices/1-2 ID_VENDOR_FROM_DATABASE=Syntek ID_MODEL_FROM_DATABASE=Sonix 1.3MPixel USB 2.0 Camera LED remains off. (Still it turns on with the commands mentioned earlier.) I hope that helps :) Tobi
Hi, Harald, I'm moving this over to you, see below (and above). Tobi, Thanks for the update. I still believe that this is a udev (rule) issue, as running: udevadm trigger --action=add Turns the led on the camera on without the camera actually being streaming. I wonder what is causing this though as neither: sudo /lib/udev/usb_id --export /bus/usb/devices/1-2 nor: sudo /lib/udev/usb-db /bus/usb/devices/1-2 Causes this issue. Tobi, Can you run: udevadm test --action=add /bus/usb/devices/1-2 &> udev-test.log Adjusting /bus/usb/devices/1-2 if necessary and attach udev-test.log here? Also can you please make sure the LED is turned off before doing this and let us know if this command turns the LED back on again ? Thanks, Hans
Created attachment 454752 [details] output of `udevadm test --action=add /bus/usb/devices/1-2'
I've attached the output of that command. Running it did not turn on the LED. Strangely turning on the LED has become less reproducable now. It was on a moment ago after I resumed from STD and resumed from STR. But now that I turned it off the dd command I mentioned above does NOT turn it on again (nor does lsusb nor udevadm trigger --action=add) So maybe half of the problem (LED switching on when accessing the USB device in any way) got fixed as a side effect of some other change already...
Hi, Thanks for the udevadm test --action=add output. Only thing I see in there is that it sends a signal to haldaemon. So this could be caused by hal (and have been fixed in the mean time), or it may have been fixed by some kernel fix. Can you try powering of the laptop and booting it again, and see if the problem still happens on boot? Thanks, Hans
On boot, the problem is gone: LED remains off. The problem still happens on STR. Didn't test STD yet. All ways I mentioned earlier to make the LED turn on by accessing the USB device in some way do not work anymore; the LED remains off, so that is good. Also when I was testing things anyway I tried the workaround I used in FC12 to turn off the LED again, and this suddenly works again! (modprobe -r uvcvideo && modprobe uvcvideo) This used not to work for me in FC13. So it seems somehow quite a bit of this issue has been solved already :-) Thanks for your efforts in any case, and hopefully the STR(+STD?) LED on will disappear too ;-) Tobi
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This still happened in F14 and also still happens in F15 (upgraded recently). Probably not useful but just a heads up that the bug is still present and to prevent the bug zapper from eating the bug :)
Hi, Thanks for the status update. Can you try removing hal? It should no longer be needed in F-15 (and will be completely gone in F-16). As root do: "yum remove hal" Thanks, Hans
Unfortunately that does not appear to change anything. Btw, with F-15 even connecting another USB device will switch on the LED. Regards, Tobi
Bummer, I'm afraid there is little else what we can do here then. It looks likem your laptop's webcam has some weird behavior wrt when it turns it leds on. It seems like it will turn it on on pretty much any usb activity and then not turn it of until data was streamed from it and the stream stopped. Nothing we can here I'm afraid. Regards, Hans
Yeah, looks like something like that indeed. Guess I'll have to live with it :-) Thanks for the time anyway!