[RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support

[Maxime Ripard]

Hi,

On Thu, Apr 11, 2019 at 09:38:06AM +0200, Hans Verkuil wrote:
> >> @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
> >>  		.has_alpha = true,
> >>  	}, {
> >>  		.drm_fmt = DRM_FORMAT_RGB565,
> >> +		.v4l2_fmt = V4L2_PIX_FMT_RGB565,
> >
> > -> V4L2_PIX_FMT_RGB565X
> >
> > Was added later, as what you expect is not compatible.
>
> All these 16-bit V4L2 pixelformats are ancient, but they are (to my knowledge)
> correct w.r.t. the documented layout of the bits in memory. I.e., that's what
> the hardware will give you.
>
> I think if there is no equivalence between the drm and v4l2 fourcc's, then
> you need two entries in this table, one for drm (v4l2_fmt == 0), one for v4l2
> (drm_fmt == 0).

Yeah, that was my plan. I'd definitely expect some formats in V4L2
while not supported by DRM, or the other way around.

> >> @@ -473,6 +496,7 @@ static const struct image_format_info formats[] = {
> >>  		.is_yuv = true,
> >>  	}, {
> >>  		.drm_fmt = DRM_FORMAT_NV24,
> >> +		.v4l2_fmt = V4L2_PIX_FMT_NV24,
> >
> > For extra fun, the M variant has not been added yet.
>
> Note that it has been the practice in V4L2 to avoid adding pixelformats unless
> they are in use by a V4L2 driver. So that's why some combinations do not exist.
>
> If we are creating a common library then I think we should change that rule
> to: "unless they are in use by a DRM or V4L2 driver". And when new formats are
> added, and they exists already for DRM or V4L2, then we should use the same
> fourcc for the other subsystem.
>
> I.e. if pixelformat V4L2_PIX_FMT_FOO was already defined, then add a:
>
> #define DRM_FORMAT_FOO V4L2_PIX_FMT_FOO
>
> rather than creating a new fourcc.

That makes sense

> We could even start looking at redoing the whole scheme in a unified way, but
> that's something for the (far) future.

Yeah, my secret plan is to have eventually a single fourcc (or even
#define) for both DRM and v4l2 for any new format. But don't tell
anyone :)

> This is already a big step forward.

Great, I'll respin this then.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190411/527c80ac/attachment.sig>