Messages in this thread |  | | Date | Tue, 28 Apr 2026 11:49:42 +0300 | | From | Sakari Ailus <> | | Subject | Re: [PATCH 2/2] media: i2c: imx471: Add Sony IMX471 image sensor driver |
| |
Hi Kate,
On Tue, Apr 28, 2026 at 11:08:56AM +0800, Kate Hsuan wrote: > > > >> Updating both offsets here is wrong when hflip != vflip, you > > > >> should only update V_WIN_OFFSET when changing vflip and > > > >> H_WIN_OFFSET when changing hflip. > > > > > > > > The cropping configuration should reflect the values on the sensor's pixel > > > > array and should not be affected by flipping. At least the crop window > > > > needs to be adjusted accordingly by the driver. Is there a need to change > > > > flipping while streaming? > > > > > > Ah, that is a very valid question, no I don't think we do need to > > > set them while streaming. > > > > > > Kate if you cannot get the start_x / start_y coordinate changes > > > when changing flipping to work to get a stable bayer output > > > pattern, then another way to fix this is to only allow changing > > > the flip controls while not streaming and return -EBUSY otherwise. > > > > > > This can then be combined with reporting a flip-ctrl dependend > > > bayer-order so that userspace sees the right bayer-order after > > > flipping is applied as long as userspace reads the subdev format > > > after setting the controls (which libcamera does I believe). > > > > It's indeed currently a bit annoying to implement this. The common raw > > sensor model will make this easier as the driver just indicates the native > > pattern to userspace. I don't have an estimate currently when that set > > would be in so the wait could be very long. Libcamera will need changes, > > too. > > > > > > > > For an example of an imx driver which reports a different > > > bayer order depending in flipping see: imx214.c and > > > the imx214_get_format_code() helper, a call to which should > > > be used to replace any hardcoded mbus-formats in the driver. > > > > After many configuration attempts, tweaking the X, Y coordinates can > not get the right Bayer order for the hflip, and also breaks the > sensor's requirement (multiple by 4). However, changing the Bayer > format for each kind of flipping works, and the colour is correct for > every kind of flip, including h/v flipping. The side-effect is that > the user can't flip the image during runtime. > > It also worked with libcamera. Qcam shows the right colour when > rotating the image 180 degrees. > I'll continue to work on this approach, :)
Sounds good. Thanks for confirming this.
-- Kind regards,
Sakari Ailus
|  |