webcam led is on when camera is not really used

Bug #897792 reported by mazurkin
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Fedora)
Invalid
Medium
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

After I had upgraded from Natty to Oneiric I found that sometimes the led of my webcam was on after boot (ASUS K52 laptop). It makes me a bit nervous because I really don't want to have my webcam on while using laptop :)

I tried to find out which program uses the webcam (lsof /dev/video0) but failed. Today I've found that led becomes active while any USB device is connected to laptop: USB flash drive or photo camera.

This information helped me to find the problem on Fedora forum:

https://bugzilla.redhat.com/show_bug.cgi?id=615589

so I know that even `sudo udevadm trigger --action=add` leads to led flash

Unfortunatelly they have no solution, me either.

I believe the problem is somewhere in new udev rules because I never noticed this problem in Natty before

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: udev 173-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
Uname: Linux 3.0.0-14-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Tue Nov 29 21:19:43 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
MachineType: ASUSTeK Computer Inc. K52F
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.0.0-14-generic root=UUID=4e4cc7d6-9f02-49c1-8151-15b191c8c4c5 ro quiet splash vt.handoff=7
SourcePackage: udev
UpgradeStatus: Upgraded to oneiric on 2011-11-09 (19 days ago)
dmi.bios.date: 07/12/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: K52F.218
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: K52F
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrK52F.218:bd07/12/2011:svnASUSTeKComputerInc.:pnK52F:pvr1.0:rvnASUSTeKComputerInc.:rnK52F:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: K52F
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

Created attachment 432563
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).

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

Created attachment 432564
output of `sudo lspci -vv'

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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.

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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.

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

Created attachment 454752
output of `udevadm test --action=add /bus/usb/devices/1-2'

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

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

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

Unfortunately that does not appear to change anything.

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

Regards,

Tobi

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

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

Revision history for this message
In , Tobi (tobi-redhat-bugs) wrote :

Yeah, looks like something like that indeed. Guess I'll have to live with it :-)

Thanks for the time anyway!

Revision history for this message
mazurkin (mazurkin) wrote :
Revision history for this message
mazurkin (mazurkin) wrote :

Some more information:

- Sometimes webcam led is completely off and the problem doesn't bother me
- When it happens led shines brightly when login screen appears and after second or two the led becomes dim for a long time
- I am able to switch the led off by running (and closing then) Cheese, Skype Settings, guvcview or any other software which really uses webcam (including ffmpeg and mencoder)

Revision history for this message
Martin Pitt (pitti) wrote :

I'm afraid there's not much we can do here, for the same reasons as stated in the Fedora bug.

affects: udev (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: New → Invalid
Revision history for this message
jsevi83 (jsevi83) wrote :

I also have an Asus K52 with the same problem, webcam led switches on at boot. I solved it editing the file /etc/colord.conf and changing to "UseSANE=false".

With some applications it happens the same, when you start them the led switches on even if the webcam is not active. This can be solved running the application like this:

- For 64bit applications:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so application-command

- For 32bit applications:
LD_PRELOAD=/usr/lib/i386-linux-gnu/libv4l/v4l1compat.so application-command

Revision history for this message
jsevi83 (jsevi83) wrote :

Still happens in Ubuntu 14.04. Webcam led is on after wake up from suspend or when opening a webpage with flash in Chrome. Using the LD_PRELOAD workaround stated above still works.

Changed in linux (Ubuntu):
status: Invalid → Confirmed
Changed in linux (Fedora):
importance: Unknown → Medium
status: Unknown → Invalid
Revision history for this message
janny (jannywilson) wrote :

I have faced same issue in webcam of my laptop I didn't know why my webcam led is "on" mode still camera is not really used. Can anyone explain in detail the solution. if anyone is getting any problem with their HP Computer then visit- https://hpetechnicalsupportnumber.com/hp-computer-support/

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.