Hi,
Le mardi 05 mars 2024 à 19:14 +0100, Maarten a écrit :
[...]
> > > + pixfmt-yuv411p
> > > + pixfmt-nv12
> > > + pixfmt-nv12m
> > > + pixfmt-nv12mt
> > > + pixfmt-nv12-col128
> > > + pixfmt-nv16
> > > + pixfmt-nv16m
> > > + pixfmt-nv24
> >
> > Unrelated fixes should have their own patch.
>
> Ok, I guess I should file seperate patches for all of these? Or do you
> want me to not touch these others?
Cleanup patches are more then welcome, I haven't looked deeply what this one is
about, just noticed it was not part of the changes, splitting is usually the
recommended way.
>
> > > pixfmt-m420
> > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > index f3584bc3e278..20c83a4c02d6 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > @@ -1368,6 +1368,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> > > *fmt)
> > > case V4L2_PIX_FMT_NV12MT: descr = "Y/UV 4:2:0 (64x32 MB, N-C)";
> > > break;
> > > case V4L2_PIX_FMT_NV12MT_16X16: descr = "Y/UV 4:2:0 (16x16 MB,
> > > N-C)"; break;
> > > case V4L2_PIX_FMT_P012M: descr = "12-bit Y/UV 4:2:0 (N-C)"; break;
> > > + case V4L2_PIX_FMT_NV12_COL128: descr = "Y/CbCr 4:2:0 (128b cols)";
> > > break;
> > > + case V4L2_PIX_FMT_NV12_10_COL128: descr = "10-bit Y/CbCr 4:2:0 (128b
> > > cols)"; break;
> > > case V4L2_PIX_FMT_YUV420M: descr = "Planar YUV 4:2:0 (N-C)"; break;
> > > case V4L2_PIX_FMT_YVU420M: descr = "Planar YVU 4:2:0 (N-C)"; break;
> > > case V4L2_PIX_FMT_YUV422M: descr = "Planar YUV 4:2:2 (N-C)"; break;
> > > diff --git a/include/uapi/linux/videodev2.h
> > > b/include/uapi/linux/videodev2.h
> > > index 1c9e1275c422..f93e341a1dd7 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -807,6 +807,10 @@ struct v4l2_pix_format {
> > > #define V4L2_PIX_FMT_QC10C v4l2_fourcc('Q', '1', '0', 'C') /*
> > > Qualcomm 10-bit compressed */
> > > #define V4L2_PIX_FMT_AJPG v4l2_fourcc('A', 'J', 'P', 'G') /*
> > > Aspeed JPEG */
> > > #define V4L2_PIX_FMT_HEXTILE v4l2_fourcc('H', 'X', 'T', 'L') /*
> > > Hextile compressed */
> > > +#define V4L2_PIX_FMT_NV12_COL128 v4l2_fourcc('N', 'C', '1', '2') /*
> > > 12 Y/CbCr 4:2:0 128 pixel wide column */
> > > +#define V4L2_PIX_FMT_NV12_10_COL128 v4l2_fourcc('N', 'C', '3', '0')
> > > + /* Y/CbCr 4:2:0 10bpc, 3x10 packed as 4 bytes in
> > > + * a 128 bytes / 96 pixel wide column */
> > >
> > > /* 10bit raw packed, 32 bytes for every 25 pixels, last LSB 6 bits
> > > unused */
> > > #define V4L2_PIX_FMT_IPU3_SBGGR10 v4l2_fourcc('i', 'p', '3', 'b') /*
> > > IPU3 packed 10-bit BGGR bayer */
> >
> > Can you add this format to v4l2-common please?
>
> You're referring to the 4CC definitions, I assume?
./drivers/media/v4l2-core/v4l2-common.c is a library to centralize common code
like pixel format handling. This is mostly for raw pixel formats, I don't think
bayer fits well there (but someone would have to give it a thought). We
recommend adding new formats into that library and using that library so that if
someone else needs to calculate strides and buffer size, they can do with the
same code and avoid recurrent mistakes. If a mistake get made, we have a single
place to fix.
Nicolas
