Hi Laurent, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: > Do you think it would make sense to do this by default, without > requiring a quirk ? Or are there cases where this calculation would lead > to incorrect results while the bpp reported by the camera would be right > ? I don't nearly have the experience with a broad range of webcams required to answer this question. At the very least that would tax well-behaved cameras with a tiny but unnecessary bit of initial computations. The loop is a simplified version of the v4l2_fill_pixfmt() loop. The calculation might need some checking, and might be invalid, in case block_w/block_h format fields are significant (not 0 and not 1), because then effective bits-per-pixel would seemingly be fractional, and depend on the image dimensions if they weren't aligned; however I see no formats using the block_w/block_h fields defined so far. AFAICT the division should need no rounding for the raw formats currently listed; just being cautious there. > Could you please keep the entries sorted by idVendor/idProduct ? > As this is the only device using this quirk, you can drop > uvc_quirk_force_bpp and use > > .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_FORCE_BPP) }, All makes sense and will be adjusted, thanks for the review! Best regards, -- Sergey Zakharchenko Digital Loggers, Inc.
