On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote:
> On Thu, 09 Jun 2011 14:05:59 +1000
> Dave Airlie <airlied@xxxxxxxxxx> wrote:
>
> > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > > To properly support the various plane formats supported by different
> > > hardware, the kernel must know the pixel format of a framebuffer object.
> > > So add a new ioctl taking a format argument corresponding to a fourcc
> > > name from videodev2.h.
> >
> > I'd rather we don't directly tie things like that, either create a
> > fourcc header that isn't V4L2 or DRM related and use that or generate
> > two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can
> > keep the DRM interface in some way OS agnostic.
>
> It *is* OS agnostic (it started on the Amiga)
>
> 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
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.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
