XPost: linux.debian.bugs.dist   
   From: post@ralfj.de   
      
   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"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)