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

2026-01-20 Thread 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 :)

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

2026-01-20 Thread 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 :)

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

2026-01-14 Thread 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  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=0x
> >
> > 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

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

2026-01-05 Thread Ralf Jung 

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=0x

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


log.gz
Description: application/gzip

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

2026-01-05 Thread Ricardo Ribalda 
On Mon, 5 Jan 2026 at 19:00, Laurent Pinchart
 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=0x
> >
> > 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

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

2026-01-05 Thread 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=0x
> 
> 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

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

2026-01-05 Thread 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=0x

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"

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

2026-01-05 Thread 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=0x

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"

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

2026-01-02 Thread Ralf Jung 

Hi Salvatore,


52fbe173baa4df9d14bd733f42ee6b9ceab8299b is the first bad commit
commit 52fbe173baa4df9d14bd733f42ee6b9ceab8299b (HEAD)
Author: Ricardo Ribalda 
Date:   Wed Dec 18 21:39:09 2024 +

 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 
 Signed-off-by: Ricardo Ribalda 
 Reviewed-by: Laurent Pinchart 
 Reviewed-by: Hans de Goede 
 Link: 
https://lore.kernel.org/r/[email protected]
 Signed-off-by: Laurent Pinchart 
 Signed-off-by: Mauro Carvalho Chehab 

  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

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

2026-01-02 Thread 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 
> Date:   Wed Dec 18 21:39:09 2024 +
> 
> 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 
> Signed-off-by: Ricardo Ribalda 
> Reviewed-by: Laurent Pinchart 
> Reviewed-by: Hans de Goede 
> Link: 
> https://lore.kernel.org/r/[email protected]
> Signed-off-by: Laurent Pinchart 
> Signed-off-by: Mauro Carvalho Chehab 
> 
>  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

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

2026-01-02 Thread 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 
Date:   Wed Dec 18 21:39:09 2024 +

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 
Signed-off-by: Ricardo Ribalda 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Hans de Goede 
Link: 
https://lore.kernel.org/r/[email protected]

Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 

 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

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

2025-12-18 Thread Ralf Jung 

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

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

2025-12-18 Thread Uwe Kleine-König 
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.

Best regards
Uwe


signature.asc
Description: PGP signature

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

2025-12-18 Thread Uwe Kleine-König 
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


signature.asc
Description: PGP signature

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

2025-12-17 Thread Ralf Jung 

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

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

2025-12-17 Thread Salvatore Bonaccorso 
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

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

2025-12-17 Thread Ralf Jung 

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

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

2025-12-08 Thread Ralf Jung 

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:



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

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

2025-12-06 Thread Uwe Kleine-König 
Hello Ralf,

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.

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


signature.asc
Description: PGP signature

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

2025-12-02 Thread Ralf Jung 

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

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

2025-12-02 Thread Salvatore Bonaccorso 
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: [email protected]
> User: [email protected]
> 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