XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   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 +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    
   >     Signed-off-by: Ricardo Ribalda    
   >     Reviewed-by: Laurent Pinchart    
   >     Reviewed-by: Hans de Goede    
   >     Link: https://lore.kernel.org/r/20241218-uvc-deprecate-v2-   
   -ab814139e983@chromium.org   
   >     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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)