(Looping linux-media in)
On Thursday 09 June 2011 13:55:13 Alan Cox wrote:
> > > You also don't need a headwer with a complete list of fourcc names in
> > > it, that is the half the point of FourCC.
> >
> > #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
> > RGB-3-3-2 */
> >
> > See that V4L2 and v4l2? I'd rather not have them used in the drm
>
> They are just helpers. The only thing that fourcc is is a 4 byte packed
> value of four symbols.
>
> > interface, either a DRM_ variant or a FOURCC_ variant that removes the
> > V4L2. Also having it in a different include file to "videodev2.h", so
> > yes we can pass FOURCC values but I'd rather we gave people a drm
> > specific way to generate them or make a generic set of macros that don't
> > include the V4L2 headers.
>
> You need a macro to assemble fourcc codes and that seems to be about it -
> so just an equivalent of the v4l2_fourcc macro.
Given that I plan to use the V4L2 FOURCCs in fbdev as well, it might indeed be
a good idea to split them from videodev2.h into their own header file.
Renaming the macros to make them V4L2-agnostic is a no-go, as that would break
the API. Manually maintaining separate sets of identical FOURCCs accross
subsystems also doesn't sound like a very good idea to me. We could create a
header that contains V4L2-agnostic FOURCC #define's, and generate a V4L2
header with the V4L2_ prefix, but I'm not sure it would be a good idea either.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
