Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

(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