Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90342 > unrolled thread

Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes)

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Salvatore Bonaccorso <carnil@debian.org> - 2025-12-02 17:50 +0100
    Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2025-12-02 18:50 +0100
      Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2025-12-08 19:50 +0100
      Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2025-12-17 14:20 +0100
        Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Salvatore Bonaccorso <carnil@debian.org> - 2025-12-17 20:30 +0100
          Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2025-12-17 20:40 +0100
            Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2025-12-18 14:20 +0100
        Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2026-01-02 14:30 +0100
          Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Salvatore Bonaccorso <carnil@debian.org> - 2026-01-02 15:10 +0100
            Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2026-01-02 17:40 +0100
              Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2026-01-05 16:50 +0100
              Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2026-01-05 19:10 +0100
              Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2026-01-05 20:30 +0100
                Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes) Ralf Jung <post@ralfj.de> - 2026-01-20 15:30 +0100

#90342 — Bug#1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes)

Control: tags -1 + moreinfo

Hi Ralf,

On Mon, Dec 01, 2025 at 10:34:52AM +0100, Ralf Jung wrote:
> Package: src:linux
> Version: 6.17.8-1
> Severity: normal
> X-Debbugs-Cc: debian-amd64@lists.debian.org
> User: debian-amd64@lists.debian.org
> Usertags: amd64
> 
> Dear Maintainer,
> 
> Since a recent kernel update, my webcam stopped working properly. The webcam
> model is "Logitech C920 HD Pro" (USB ID 046d:0892); I will put the full lsusb
> output below. What happens is that, when I am in a Zoom call, after someone else
> joins the call, flickering artifacts start to appear: the bottom half of the
> image turns gray. I will attach an image. I have so far not been able to
> reproduce this outside of Zoom. I tried Jitsi in the browser and Gnome Cheese.
> (Zoom does *something* with the webcam when someone joins the call: the exact
> frame of the webcam, i.e. how much of the room I see and where the image cuts
> off, changes. I have no idea what that is about.)
> 
> I tried playing around with power_line_frequency; that did not help at all.
> 
> This only started recently. I tried booting a 6.12 kernel (with the same
> userspace), that fixed the issue -- so it very much looks like a kernel issue to
> me. The issue is also present in 6.16, so it's a regression introduced some time
> between 6.12 and 6.16. I use Zoom fairly regularly professionally, so this bug
> means I am pretty much stuck with a 6.12 kernel for now.

If you reliably can reproduce the issue then (although I realize that
each testing step is time consuming), I would suggest to start a
bisect.

First though narrow down more closely the Debian versions which expose
the problen and not (using the images fetched from
https://snapshot.debian.org/). Once you have two upstream versions
close enough, start a bisect.

Do you need instructions/help on how to do that?

Regards,
Salvatore

[toc] | [next] | [standalone]

#90347

Hi Salvatore,

Thank you for the reply!

> If you reliably can reproduce the issue then (although I realize that
> each testing step is time consuming), I would suggest to start a
> bisect.

Unfortunately I cannot reproduce it alone, I need someone else to be in the Zoom 
room. Also, I only have that webcam in the office, and I shouldn't spend hours 
of my employer's time on bisects. ;)  I guess I could take it home over a 
weekend or so, but I'd still need a way to reproduce the issue alone, and find a 
weekend day where I have nothing else to do.

So, a bisect is not currently practical I am afraid. I was hoping someone else 
might know better ways to reproduce this, e.g. some open-source program that 
also does whatever Zoom does when it reconfigures the camera when someone joins 
the call.

In case that changes in the future --
Do you know some folder(s) that the bisect could be limited to? That would cut 
down the number of steps significantly.

Kind regards,
Ralf

> First though narrow down more closely the Debian versions which expose
> the problen and not (using the images fetched from
> https://snapshot.debian.org/). Once you have two upstream versions
> close enough, start a bisect.
> 
> Do you need instructions/help on how to do that?
> 
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#90401

Dear Uwe,

> On Tue, Dec 02, 2025 at 06:36:38PM +0100, Ralf Jung wrote:
>>> If you reliably can reproduce the issue then (although I realize that
>>> each testing step is time consuming), I would suggest to start a
>>> bisect.
>>
>> Unfortunately I cannot reproduce it alone, I need someone else to be in the
>> Zoom room. Also, I only have that webcam in the office, and I shouldn't
>> spend hours of my employer's time on bisects. ;)  I guess I could take it
>> home over a weekend or so, but I'd still need a way to reproduce the issue
>> alone, and find a weekend day where I have nothing else to do.
> 
> I would try to wireshark the USB traffic. I guess that results in quite
> some amount of logs, but someone who is more familiar with USB and
> webcams might spot the relevant USB transfer that triggers the issue.

I think I managed to capture USB traffic from around the time when the webcam 
starts to show this issue:
- I joined the zoom room and activated the camera
- I started capturing
- Someone else joined the zoom
- The camera changed its "mode" and started flickering
- I stopped capturing

Then I filtered the result to only include the packets for the camera. I hope I 
did this correctly. I uploaded the result to:
<http://ralfj.de/upload/webcam.pcapng>

Kind regards,
Ralf

> 
> And even if that doesn't help to immediately spot the problem it might
> help to reproduce the problem and thus make a bisection possible.
> 
> Best regards
> Uwe

[toc] | [prev] | [next] | [standalone]

#90504

Hi all,

By trying out various snapshot kernels, I now got it nailed down to a single 
major version bump:

6.13.11-1~exp1 is still good.
6.14.6-1~exp1 has the problem.

Kind regards,
Ralf

[toc] | [prev] | [next] | [standalone]

#90509

Hi Ralf,

On Wed, Dec 17, 2025 at 02:05:41PM +0100, Ralf Jung wrote:
> Hi all,
> 
> By trying out various snapshot kernels, I now got it nailed down to a single
> major version bump:
> 
> 6.13.11-1~exp1 is still good.
> 6.14.6-1~exp1 has the problem.

While I understand from the context you gave that might not be the
easiiest thing to make possible, but I think the most effective next
step would be now to try upstream 6.13 and upstream 6.14.6 and then
bisect.

If you have a second device available maybe it is enough to join with
that to the call and trigger the problem? In particular if you can
take off work the device which exposes the problem.

I do realize this is much we ask, but you are as well the only one
able to reproduce the problem on the particular hardware, so actually
in the best position to find the offending change.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90511

Hi,

> On Wed, Dec 17, 2025 at 02:05:41PM +0100, Ralf Jung wrote:
>> Hi all,
>>
>> By trying out various snapshot kernels, I now got it nailed down to a single
>> major version bump:
>>
>> 6.13.11-1~exp1 is still good.
>> 6.14.6-1~exp1 has the problem.
> 
> While I understand from the context you gave that might not be the
> easiiest thing to make possible, but I think the most effective next
> step would be now to try upstream 6.13 and upstream 6.14.6 and then
> bisect.

There's probably a subfolder I can restrict this to? Which folder has the webcam 
drivers? (And maybe the v4l infrastructure.)

> If you have a second device available maybe it is enough to join with
> that to the call and trigger the problem? In particular if you can
> take off work the device which exposes the problem.

Yeah I can probably reproduce it by joining from the browser and the native client.

> I do realize this is much we ask, but you are as well the only one
> able to reproduce the problem on the particular hardware, so actually
> in the best position to find the offending change.

This is a pretty common webcam model so it's hard to believe that I am the only 
one who is affected... but with the kernel not having a (functional) central 
bugtracker we wouldn't even know about it. I also have to imagine it'd be easier 
to bisect this if someone familiar with webcam drivers had a clue about what 
happens in the release wehre this broke... oh well.

I will have to see if I have time and patience for a longer bisecting session 
over the holidays.

Kind regards,
Ralf

[toc] | [prev] | [next] | [standalone]

#90521

Hi Uwe,

On 18.12.25 10:18, Uwe Kleine-König wrote:
> Hello Ralf,
> 
> On Wed, Dec 17, 2025 at 08:31:34PM +0100, Ralf Jung wrote:
>>> On Wed, Dec 17, 2025 at 02:05:41PM +0100, Ralf Jung wrote:
>>>> By trying out various snapshot kernels, I now got it nailed down to a single
>>>> major version bump:
>>>>
>>>> 6.13.11-1~exp1 is still good.
>>>> 6.14.6-1~exp1 has the problem.
>>>
>>> While I understand from the context you gave that might not be the
>>> easiiest thing to make possible, but I think the most effective next
>>> step would be now to try upstream 6.13 and upstream 6.14.6 and then
>>> bisect.
>>
>> There's probably a subfolder I can restrict this to? Which folder has the
>> webcam drivers? (And maybe the v4l infrastructure.)
> 
> I would not recommend that. The problem might also be triggered by a
> change to your USB controller's driver or something in the graphics
> stack.

Fair, I didn't realize how entangled the webcam stack is these days.

Thanks for forwarding this to a kernel maintainer!

Kind regards,
Ralf

[toc] | [prev] | [next] | [standalone]

#90636

Hi all,

I did a (lengthy) bisect session, and came out with this commit:

52fbe173baa4df9d14bd733f42ee6b9ceab8299b is the first bad commit
commit 52fbe173baa4df9d14bd733f42ee6b9ceab8299b (HEAD)
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Wed Dec 18 21:39:09 2024 +0000

     media: uvcvideo: Invert default value for nodrop module param

     The module param `nodrop` defines what to do with frames that contain an
     error: drop them or sending them to userspace.

     The default in the rest of the media subsystem is to return buffers with
     an error to userspace with V4L2_BUF_FLAG_ERROR set in v4l2_buffer.flags.
     In UVC we drop buffers with errors by default.

     Change the default behaviour of uvcvideo to match the rest of the
     drivers and maybe get rid of the module parameter in the future.

     Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
     Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
     Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
     Reviewed-by: Hans de Goede <hdegoede@redhat.com>
     Link: 
https://lore.kernel.org/r/20241218-uvc-deprecate-v2-2-ab814139e983@chromium.org
     Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
     Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

  drivers/media/usb/uvc/uvc_driver.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

I added Ricardo in Cc. Ricardo, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121718 for context.

The bug does not always immediately manifest, so there is a small chance that 
for some of the commits that I marked "good", artifacts would have started 
appearing if I had waited a bit longer. But the commit seems reasonably 
plausible to be able to cause the kind of error I am seeing.

Given that this is about a module parameter, I assume I could test this by 
booting the latest kernel and setting the parameter back to its previous 
value... but I don't know enough about how the kernel works to actually do 
that.^^ Happy to try that if someone gives me some pointers.

Kind regards,
Ralf

[toc] | [prev] | [next] | [standalone]

#90638

Hi Ralf,

On Fri, Jan 02, 2026 at 02:24:20PM +0100, Ralf Jung wrote:
> Hi all,
> 
> I did a (lengthy) bisect session, and came out with this commit:

Thanks for doing so and for the time invested!

> 52fbe173baa4df9d14bd733f42ee6b9ceab8299b is the first bad commit
> commit 52fbe173baa4df9d14bd733f42ee6b9ceab8299b (HEAD)
> Author: Ricardo Ribalda <ribalda@chromium.org>
> Date:   Wed Dec 18 21:39:09 2024 +0000
> 
>     media: uvcvideo: Invert default value for nodrop module param
> 
>     The module param `nodrop` defines what to do with frames that contain an
>     error: drop them or sending them to userspace.
> 
>     The default in the rest of the media subsystem is to return buffers with
>     an error to userspace with V4L2_BUF_FLAG_ERROR set in v4l2_buffer.flags.
>     In UVC we drop buffers with errors by default.
> 
>     Change the default behaviour of uvcvideo to match the rest of the
>     drivers and maybe get rid of the module parameter in the future.
> 
>     Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>     Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>     Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>     Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>     Link: https://lore.kernel.org/r/20241218-uvc-deprecate-v2-2-ab814139e983@chromium.org
>     Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>     Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> 
>  drivers/media/usb/uvc/uvc_driver.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> I added Ricardo in Cc. Ricardo, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121718 for context.
> 
> The bug does not always immediately manifest, so there is a small chance
> that for some of the commits that I marked "good", artifacts would have
> started appearing if I had waited a bit longer. But the commit seems
> reasonably plausible to be able to cause the kind of error I am seeing.
> 
> Given that this is about a module parameter, I assume I could test this by
> booting the latest kernel and setting the parameter back to its previous
> value... but I don't know enough about how the kernel works to actually do
> that.^^ Happy to try that if someone gives me some pointers.

You can create a modprobe.d file /etc/modprobe.d/uvcvideo.conf with

options uvcvideo nodrop=0

to pass 'nodrop=0' parameter when loading the uvcvideo module (then
unload and load the module).

But it already warns in dmesg when doing so with:

uvcvideo: [Deprecated]: nodrop parameter will be eventually removed.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90657

Hi Salvatore,

>> 52fbe173baa4df9d14bd733f42ee6b9ceab8299b is the first bad commit
>> commit 52fbe173baa4df9d14bd733f42ee6b9ceab8299b (HEAD)
>> Author: Ricardo Ribalda <ribalda@chromium.org>
>> Date:   Wed Dec 18 21:39:09 2024 +0000
>>
>>      media: uvcvideo: Invert default value for nodrop module param
>>
>>      The module param `nodrop` defines what to do with frames that contain an
>>      error: drop them or sending them to userspace.
>>
>>      The default in the rest of the media subsystem is to return buffers with
>>      an error to userspace with V4L2_BUF_FLAG_ERROR set in v4l2_buffer.flags.
>>      In UVC we drop buffers with errors by default.
>>
>>      Change the default behaviour of uvcvideo to match the rest of the
>>      drivers and maybe get rid of the module parameter in the future.
>>
>>      Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>      Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>>      Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>      Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>      Link: https://lore.kernel.org/r/20241218-uvc-deprecate-v2-2-ab814139e983@chromium.org
>>      Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>      Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>>
>>   drivers/media/usb/uvc/uvc_driver.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I added Ricardo in Cc. Ricardo, see
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121718 for context.
>>
>> The bug does not always immediately manifest, so there is a small chance
>> that for some of the commits that I marked "good", artifacts would have
>> started appearing if I had waited a bit longer. But the commit seems
>> reasonably plausible to be able to cause the kind of error I am seeing.
>>
>> Given that this is about a module parameter, I assume I could test this by
>> booting the latest kernel and setting the parameter back to its previous
>> value... but I don't know enough about how the kernel works to actually do
>> that.^^ Happy to try that if someone gives me some pointers.
> 
> You can create a modprobe.d file /etc/modprobe.d/uvcvideo.conf with
> 
> options uvcvideo nodrop=0
> 
> to pass 'nodrop=0' parameter when loading the uvcvideo module (then
> unload and load the module).

Thanks, that seems to have worked! So at least for now this is a viable 
work-around...

> But it already warns in dmesg when doing so with:
> 
> uvcvideo: [Deprecated]: nodrop parameter will be eventually removed.

... but only until the parameter gets removed, of course.

Kind regards,
Ralf

> 
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#90708

Hi Ricardo,

> Thanks for the bisect and the report.

Thanks for taking a look. :)

> The patch to remove noprod parameter has been queued for 6.20 :S so we
> should look into a more permanent fix soon.

Ah, the days of my work-around are counted then -- good to know.

> When you say zoom, do you mean the desktop version of zoom (
> https://zoom.us/download?os=linux ) or the web version
> I would assume that it is the zoom app, that is ignoring the "error"
> flag from the frames and showing them to the users. Can you confirm
> that? Hopefully we can reach zoom and they can fix it.

Yes, I mean the Zoom app (specifically, the flatpak version: 
https://flathub.org/en/apps/us.zoom.Zoom). I have no idea how the protocol stack 
works here (how frames go from the camera to zoom and which layer is responsible 
to do what along the way); while I am a developer, I am entirely a user when it 
comes to webcam things. :D

I have not seen the error occur in Firefox -- but I am also not sure if Firefox 
ever puts the camera into the other "mode" the way Zoom does (when someone joins 
the call, the field of view of the camera slightly increases, so there are now 
things visible on the side of the frame that were previously cut off -- and then 
a few seconds later, the artifacts start to appear).

I will try the tracing flags you mention later when I have access to the camera 
again.

Kind regards,
Ralf

> 
> 
> Now about the error flag. I have given a fast look at your usb trace
> and have only seen 4 frames with "error bits" [1]. Can you add more
> tracing?
> Do something like:
> rmmod uvcvideo
> modprobe uvcvideo trace=0xffffffff
> 
> Then start zoom, trigger the error and share the content of your
> dmesg. It should contain an explanation of why the driver thinks that
> the frames are invalid.
> 
> Thanks!
> 
> [1] I used this filter in wireshark: usb.iso.data[1]!=0x0d &&
> usb.iso.data[1]!=0x0c && usb.iso.data[1]!=0x0f &&
> usb.iso.data[1]!=0x0e && usb.addr == "3.34.1"

[toc] | [prev] | [next] | [standalone]

#90709

On Mon, Jan 05, 2026 at 04:29:24PM +0100, Ricardo Ribalda wrote:
> Hi Ralf
> 
> Thanks for the bisect and the report.
> 
> 
> The patch to remove noprod parameter has been queued for 6.20 :S so we
> should look into a more permanent fix soon.
> 
> When you say zoom, do you mean the desktop version of zoom (
> https://zoom.us/download?os=linux ) or the web version
> I would assume that it is the zoom app, that is ignoring the "error"
> flag from the frames and showing them to the users. Can you confirm
> that? Hopefully we can reach zoom and they can fix it.

Should we revert the nodrop removal in the meantime ?

> Now about the error flag. I have given a fast look at your usb trace
> and have only seen 4 frames with "error bits" [1]. Can you add more
> tracing?
> Do something like:
> rmmod uvcvideo
> modprobe uvcvideo trace=0xffffffff
> 
> Then start zoom, trigger the error and share the content of your
> dmesg. It should contain an explanation of why the driver thinks that
> the frames are invalid.
> 
> Thanks!
> 
> [1] I used this filter in wireshark: usb.iso.data[1]!=0x0d &&
> usb.iso.data[1]!=0x0c && usb.iso.data[1]!=0x0f &&
> usb.iso.data[1]!=0x0e && usb.addr == "3.34.1"

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#90710

[Multipart message — attachments visible in raw view] — view raw

Hi Ricardo,

> Now about the error flag. I have given a fast look at your usb trace
> and have only seen 4 frames with "error bits" [1]. Can you add more
> tracing?
> Do something like:
> rmmod uvcvideo
> modprobe uvcvideo trace=0xffffffff
> 
> Then start zoom, trigger the error and share the content of your
> dmesg. It should contain an explanation of why the driver thinks that
> the frames are invalid.

I have attached the log from when I started zoom until I closed it. All I can 
see there is "Marking buffer as bad (error bit set)" but I assume all of the 
other things there will mean a lot more to you. :)

Kind regards,
Ralf

[toc] | [prev] | [next] | [standalone]

#90886

On 20.01.26 14:46, Ricardo Ribalda wrote:
> Another update
> 
> Zoom has notified that they plan to land this even earlier. In 6.7.5
> 
> Ralf, if you could confirm that it works/doesn't when zoom is released
> I will be very grateful.

Thanks for the update!
I'm happy to check this once the Zoom flatpak has been updated to whatever 
version has the fix.

Kind regards,
Ralf

> 
> Thanks :)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web