[arch-general] Laptop's webcam gets blocked randomly
Hi, I'm having kind of a random webcam unavailability on a Dell XPS L502X (Sandy Bridge) with webcam: ``` $ lsusb Bus 001 Device 003: ID 0408:2fb1 Quanta Computer, Inc. Laptop_Integrated_Webcam_2HDM ``` I already checked [1] but couldn't find no hint in how to diagnose this. Sometimes webcam works fine. There's sort of a permanent static-noise with MJPG format in qv4l2 no matter which frame size I use (sometimes it even crash), and with guvcview using MJPG makes the image unstable if I activate the 'mirror' filter; rest of the time I get a lot of: ``` V4L2_CORE: Error - Couldn't decode frame V4L2_CORE: (jpeg decoder) error while decoding frame V4L2_CORE: (jpeg decoder) error while decoding frame V4L2_CORE: (jpeg decoder) Ignoring empty buffer ``` But using YUYV in guvcview, thou slower, the video seems OK (in qv4l2 it starts with a green screen and then the proper image appears). In the other hand, when the webcam doesn't responds, YUYV in qv4l2 only shows the green screen. The hardware lights indicate that webcam is being activated, but I have no image. When not working, qv4l2 only says: `Hue error: connection time expired`, I don't see any other console output. With xawtv I get: ``` $ xawtv This is xawtv-3.107, running on Linux/x86_64 (5.11.2-arch1-1) xinerama 0: 1366x768+0+0 vid-open-auto: using grabber/webcam device /dev/video0 v4l2: oops: select timeout ``` And with guvcview (YUYV) I have: ``` $ guvcview GUVCVIEW: version 2.0.6 V4L2_CORE: (UVCIOC_CTRL_MAP) Error: The file or directory does not exist ... ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ... connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=The file or directory does not exist) attempt to connect to server failed ... ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ... ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ... V4L2_CORE: Could not grab image (select timeout): Resource temporarily unavailable ... ``` The only related message I found on `sudo dmesg` says: ``` [33511.458233] uvcvideo: Failed to query (GET_CUR) UVC control 6 on unit 2: -110 (exp. 2). ``` `sudo journalctl -ex` doesn't seems to show nothing about. System is updated. Any idea on how to pinpoint/diagnose the source of this issue? Thanks a lot in advance! [1] https://wiki.archlinux.org/index.php/Webcam_setup
Hi, I have the same laptop. I cannot test it right now and never looked at the logs, but often the image stays pitch black even when the webcams hardware light is active. What works for me is if I flash a bright light (phones flashlight) at the camera right after I activate it (e.g. in Zoom), it turns on. Greetings Björn On 3/8/21 11:42 AM, riveravaldez via arch-general wrote:
Hi, I'm having kind of a random webcam unavailability on a Dell XPS L502X (Sandy Bridge) with webcam:
``` $ lsusb Bus 001 Device 003: ID 0408:2fb1 Quanta Computer, Inc. Laptop_Integrated_Webcam_2HDM ```
I already checked [1] but couldn't find no hint in how to diagnose this.
Sometimes webcam works fine. There's sort of a permanent static-noise with MJPG format in qv4l2 no matter which frame size I use (sometimes it even crash), and with guvcview using MJPG makes the image unstable if I activate the 'mirror' filter; rest of the time I get a lot of:
``` V4L2_CORE: Error - Couldn't decode frame V4L2_CORE: (jpeg decoder) error while decoding frame V4L2_CORE: (jpeg decoder) error while decoding frame V4L2_CORE: (jpeg decoder) Ignoring empty buffer ```
But using YUYV in guvcview, thou slower, the video seems OK (in qv4l2 it starts with a green screen and then the proper image appears). In the other hand, when the webcam doesn't responds, YUYV in qv4l2 only shows the green screen.
The hardware lights indicate that webcam is being activated, but I have no image.
When not working, qv4l2 only says: `Hue error: connection time expired`, I don't see any other console output.
With xawtv I get:
``` $ xawtv This is xawtv-3.107, running on Linux/x86_64 (5.11.2-arch1-1) xinerama 0: 1366x768+0+0 vid-open-auto: using grabber/webcam device /dev/video0 v4l2: oops: select timeout ```
And with guvcview (YUYV) I have:
``` $ guvcview GUVCVIEW: version 2.0.6 V4L2_CORE: (UVCIOC_CTRL_MAP) Error: The file or directory does not exist ... ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ... connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=The file or directory does not exist) attempt to connect to server failed ... ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ... ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ... V4L2_CORE: Could not grab image (select timeout): Resource temporarily unavailable ... ```
The only related message I found on `sudo dmesg` says:
``` [33511.458233] uvcvideo: Failed to query (GET_CUR) UVC control 6 on unit 2: -110 (exp. 2). ```
`sudo journalctl -ex` doesn't seems to show nothing about.
System is updated.
Any idea on how to pinpoint/diagnose the source of this issue?
Thanks a lot in advance!
On 3/8/21, Björn Seifert via arch-general <arch-general@lists.archlinux.org> wrote:
Hi,
I have the same laptop. I cannot test it right now and never looked at the logs, but often the image stays pitch black even when the webcams hardware light is active. What works for me is if I flash a bright light (phones flashlight) at the camera right after I activate it (e.g. in Zoom), it turns on.
Greetings Björn
Thanks a lot, Björn! Right now the webcam persists in keep working (Murphy's Laws at work...), but as soon as it gets blocked again (probably soon) I'll test this and inform of results. Best regards and thanks again.
On 3/8/21, Björn Seifert via arch-general <arch-general@lists.archlinux.org> wrote:
Hi,
I have the same laptop.
Hi, Björn, could you confirm if you have installed the xf86-video-intel driver? Because I'm under the suspicion that maybe the issue comes from it. Being testing for a while without it installed and the problem seems to disappear. I'm interested in confirm this because I also tested that with that Intel driver installed the performance in video-calls is a little superior (less CPU work and less Tº in the iGPU; the NVIDIA dGPU I have turned OFF at the moment). Maybe this can be diagnose and reported and maybe fixed? Thanks a lot!
On Fri, 19 Mar 2021 at 15:33, riveravaldez via arch-general <arch-general@lists.archlinux.org> wrote:
On 3/8/21, Björn Seifert via arch-general <arch-general@lists.archlinux.org> wrote:
Hi,
I have the same laptop.
Hi, Björn, could you confirm if you have installed the xf86-video-intel driver?
Because I'm under the suspicion that maybe the issue comes from it. Being testing for a while without it installed and the problem seems to disappear.
I suspect that you might be conflating things. The xf86-video-intel driver has nothing to do with the camera (v4l2) or audio (alsa) subsystems. They are quite orthogonal. Now, if the mentioned programs refuse to work - without any v4l2/alsa/pcm warnings - then the issue might be xf86-video-intel related. For a dead trivial way to dismiss issues related to X (via xf86-video-intel or otherwise) and Wayland compositors - switch to a VT and run the following: $ gst-launch-1.0 autovideosrc device=/dev/video0 ! autovideosink This should work with nvidia, although I haven't tried. Note that you might need to bump the number video0 to video1... -Emil
On 3/20/21, Emil Velikov <emil.l.velikov@gmail.com> wrote:
On Fri, 19 Mar 2021 at 15:33, riveravaldez via arch-general <arch-general@lists.archlinux.org> wrote:
On 3/8/21, Björn Seifert via arch-general <arch-general@lists.archlinux.org> wrote:
Hi,
I have the same laptop.
Hi, Björn, could you confirm if you have installed the xf86-video-intel driver?
Because I'm under the suspicion that maybe the issue comes from it.
Hi, Björn, this was apparently incorrect, problem appears also without xf86-video-intel, **but**, your solution seems to work also here! I'm deeply thankful. You saved me in the middle of a job. How do you discover that fix?, and do you have any idea why this happens and how that flashlight-action works?
I suspect that you might be conflating things.
I suspect you're completely right, Emil.
The xf86-video-intel driver has nothing to do with the camera (v4l2) or audio (alsa) subsystems. They are quite orthogonal.
Thanks a lot for the info.
Now, if the mentioned programs refuse to work - without any v4l2/alsa/pcm warnings - then the issue might be xf86-video-intel related.
For a dead trivial way to dismiss issues related to X (via xf86-video-intel or otherwise) and Wayland compositors - switch to a VT and run the following: $ gst-launch-1.0 autovideosrc device=/dev/video0 ! autovideosink
Thanks a lot for your answer and explanations, Emil. I tried the `gst-launch-1.0 ...` and obtained a playback capture in a separate window but extremely laggy, freezing a lot. Any idea? Right now this seems kind of a webcam-hardware issue, that gets incidentally solved (at least for the moment) rapidly exposing the webcam to an intense light (like the mobile phones flashlight) in the precise moment it's needed to be used (and appearing as blocked). Maybe if I can understand well the nature of the problem this could end in the Wiki, so other users have a quick-fix for this problem (specially in this times). Thanks a lot for any answer or hint. Best regards.
Am 2021-03-21 17:53, schrieb riveravaldez via arch-general:
your solution seems to work also here!
I'm deeply thankful. You saved me in the middle of a job.
How do you discover that fix?, and do you have any idea why this happens and how that flashlight-action works?
Nice to hear that I could help you! I honestly don't know how I discovered that fix. I think my first guess was the image was just extremely underexposed. Still I think that there is a problem with the exposure automatic and it just needs a strong "push".
Right now this seems kind of a webcam-hardware issue, that gets incidentally solved (at least for the moment) rapidly exposing the webcam to an intense light (like the mobile phones flashlight) in the precise moment it's needed to be used (and appearing as blocked).
At the moment I cannot test further as I installed Linux Mint on the laptop for my wife's remote teaching. I had told her what could happen with the camera and how to fix it, but as it seems she only faceed the problem once when it was too dark in her office turning on the light was enough to activate the cam.
participants (4)
-
Björn Seifert
-
Emil Velikov
-
riveravaldez
-
seifert＠oern.de