Hi Sergey, On Wed, Oct 02, 2019 at 09:15:45PM +0400, Sergey Zakharchenko wrote: > Sergey Zakharchenko <doublef.mob...@gmail.com>: > > Laurent Pinchart <laurent.pinch...@ideasonboard.com>: > > > 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 > > > ? > > > > 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. > > It's likely possible to directly replace the bpp-using computation in > https://github.com/torvalds/linux/blob/2874c5fd284268364ece81a7bd936f3c8168e567/drivers/media/usb/uvc/uvc_driver.c#L636 > with a call to v4l2_fill_pixfmt() and the sizeimage it returns. > However, bpp is used elsewhere, and it's hard to tell what it should > be taken to be to in the hypothetical exotic cases I'm considering, so > I'm reluctant to go that route.
Would it make sense to split the calculation from v4l2_fill_pixfmt() to a helper function that the UVC driver could call ? > I'm going to send v3 in an hour unless there are other suggestions. -- Regards, Laurent Pinchart
