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"
