Bug 615589 - webcam LED on after boot on ASUS F3 laptop
Summary: webcam LED on after boot on ASUS F3 laptop
Alias: None
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
(Show other bugs)
Version: 15
Hardware: i686 Linux
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-17 10:57 UTC by Tobi Vollebregt
Modified: 2011-06-13 14:22 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-13 13:27:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of `sudo lsusb -vv' (34.70 KB, text/plain)
2010-07-17 10:57 UTC, Tobi Vollebregt
no flags Details
output of `sudo lspci -vv' (37.35 KB, text/plain)
2010-07-17 10:58 UTC, Tobi Vollebregt
no flags Details
output of `udevadm test --action=add /bus/usb/devices/1-2' (10.17 KB, text/plain)
2010-10-21 09:00 UTC, Tobi Vollebregt
no flags Details

Description Tobi Vollebregt 2010-07-17 10:57:32 UTC
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.

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).

Comment 1 Tobi Vollebregt 2010-07-17 10:58:41 UTC
Created attachment 432564 [details]
output of `sudo lspci -vv'

Comment 2 Tobi Vollebregt 2010-07-23 22:07:55 UTC
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...

Comment 3 Tobi Vollebregt 2010-08-07 09:32:09 UTC
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.

Comment 4 Tobi Vollebregt 2010-09-10 15:09:57 UTC
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.

Comment 5 Hans de Goede 2010-09-14 07:54:35 UTC

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?



Comment 6 Tobi Vollebregt 2010-09-15 16:42:32 UTC
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..



Comment 7 Hans de Goede 2010-09-15 18:46:02 UTC
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:

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:

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?



Comment 8 Tobi Vollebregt 2010-09-30 19:55:26 UTC
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
$ cat /sys/bus/usb/devices/1-2/idProduct 

So it's device 1-2.

$ sudo /lib/udev/usb_id --export /bus/usb/devices/1-2

LED remains off.

$ sudo /lib/udev/usb-db /bus/usb/devices/1-2
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 :)


Comment 9 Hans de Goede 2010-10-05 13:26:56 UTC

Harald, I'm moving this over to you, see below (and above).


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
sudo /lib/udev/usb-db /bus/usb/devices/1-2

Causes this issue.


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 ?



Comment 10 Tobi Vollebregt 2010-10-21 09:00:34 UTC
Created attachment 454752 [details]
output of `udevadm test --action=add /bus/usb/devices/1-2'

Comment 11 Tobi Vollebregt 2010-10-21 09:11:16 UTC
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...

Comment 12 Hans de Goede 2010-10-21 09:14:16 UTC

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?



Comment 13 Tobi Vollebregt 2010-10-21 10:03:44 UTC
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 ;-)


Comment 14 Bug Zapper 2011-06-01 13:37:56 UTC
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: 

Comment 15 Tobi Vollebregt 2011-06-04 11:43:45 UTC
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 :)

Comment 16 Hans de Goede 2011-06-04 11:54:20 UTC

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"



Comment 17 Tobi Vollebregt 2011-06-13 12:31:23 UTC
Unfortunately that does not appear to change anything.

Btw, with F-15 even connecting another USB device will switch on the LED.



Comment 18 Hans de Goede 2011-06-13 13:27:25 UTC

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.



Comment 19 Tobi Vollebregt 2011-06-13 14:22:55 UTC
Yeah, looks like something like that indeed. Guess I'll have to live with it :-)

Thanks for the time anyway!

Note You need to log in before you can comment on or make changes to this bug.