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

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Control: forwarded -1 https://lore.kernel.org/linux-media/uboug5ectzm4s32yfgopjbcxq2uhsoc4kluaby7a4b7nzfjave@boco7oocnftr

Hello Mauro,

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.

there is a Debian user (Ralf Jung, on Cc:) who experiences a regression
with his Logitech webcam. Sometimes when he participates in a video call
the image starts flickering when someone else enters the call. Ralf
captured USB traffic and provided it to the bug report (link below). The
problem doesn't reproduce reliably, so it's not completely bisected
(though Ralf might try over the christmas holidays).

Does this ring a bell? 

For the full details see https://bugs.debian.org/1121718

Best regards
Uwe

#regzbot introduced: v6.13..v6.14.6

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Ralf Jung]

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

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

[Salvatore Bonaccorso]

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

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

[Ralf Jung]

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

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

[Ricardo Ribalda]

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.


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"

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

[Ralf Jung]

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"

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

[Laurent Pinchart]

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

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

[Ricardo Ribalda]

On Mon, 5 Jan 2026 at 19:00, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> 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 ?

I think if we have not heard back from zoom by rc6 we should revert.
But IMO we should wait until then.

Maybe we can find more users of nodrop that way.


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



-- 
Ricardo Ribalda

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

[Ralf Jung]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

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

[-- Attachment #2: log.gz --]
[-- Type: application/gzip, Size: 16267 bytes --]

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

[Ricardo Ribalda]

Some updates.

- We have delayed removing the nodrop parameter, so the mitigation
will work for some more months.
- Zoom has confirmed that they have managed to repro the issue and
they plan to fit is for version 7.0.0 of their application.

Regards

On Mon, 5 Jan 2026 at 20:27, Ralf Jung <post@ralfj.de> wrote:
>
> 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



-- 
Ricardo Ribalda

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

[Ricardo Ribalda]

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

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

[Ralf Jung]

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

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Hello Ricardo and Ralf,

On Tue, Jan 20, 2026 at 02:46:54PM +0100, 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.

Given that this turned out to not be a bug in the kernel (and not even
Debian), I'm closing this bug. Even if the new Zoom release doesn't fix
it for you, this is their problem and not one in the kernel where we
could help.

I hope this is ok for all affected parties.

Best regards
Uwe


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Laurent Pinchart]

On Thu, Jan 22, 2026 at 06:38:56PM +0100, Uwe Kleine-König wrote:
> Hello Ricardo and Ralf,
> 
> On Tue, Jan 20, 2026 at 02:46:54PM +0100, 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.
> 
> Given that this turned out to not be a bug in the kernel (and not even
> Debian), I'm closing this bug. Even if the new Zoom release doesn't fix
> it for you, this is their problem and not one in the kernel where we
> could help.
> 
> I hope this is ok for all affected parties.

We addressed it in the kernel in mainline though, reverting for the time
being the commit that introduced the issue.

-- 
Regards,

Laurent Pinchart