Re: drm pixel formats update

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Nov 16, 2011 at 09:26:20PM +0000, Alan Cox wrote:
> > I think the only format in my list where I didn't use an existing fourcc
> > is I420/IYUV. And BTW, for that one I used the same "fake" fourcc that
> 
> Right but you redefine all sorts of stuff in the driver in your patch to
> non FourCC names which is just confusing (and painful given the format
> picked)

Sorry, now I lost you completely. Care to elaborate, or perhaps
point to a specific line or lines in the patch?

> > v4l2 uses (YU12). 
> > 
> > And that brings another matter to the table. How should we deal with
> > duplicate fourccs? I420/IYUV and YUY2/YUYV come to mind.
> 
> Just accept both. FourCC as with all API's is not perfect
>  
> > Also, if I now add these ad-hoc fourccs for the RGB formats, and some
> > time later someone comes in with a format with a conflicting official
> > fourcc, what should we do?
> 
> One possibility I suggested originally was to mix FourCC codes and native
> formats which are numbered. That works fine in both endiannesses in
> theory because you'll always have a \0 in it which is invalid FourCC
> 
> ie just number the Linux specific DRM formats 0, 1, 2, 3, 4, 5, ...

I suggested a running number too. But I'd rather leave the fourccs to
user space completely. But if people insist that the kernel should eat
them too, we could just convert them to the simple number format in
some helper function, to isolate the rest of the code from fourccs.
And then there'd be no point in even defining any fourcc stuff in the
headers, as everyone knows how to construct them.

> > Oh and one extra detail just occured to me regarding the three plane
> > formats. Should we even define formats for both the YUV vs. YVU
> > variant. Seeing as we now have independent handles and offsets for
> > each plane, we can make do with just one format definition.
> 
> I think so - or the helper should do the translation and flip the planes.
> We want the user to get flexibility and the driver to be as simple as
> possible.
> 
> (and btw I've no problem at all with the idea that you can pass in a
> FourCC *or* a format specifying structure, or with an internal API where
> a fourCC is always internally turned into a struct of offsets and other
> useful info before hitting the drivers)

Even if there's such a structure, I think it's still beneficial to have
a constant identifier for each format. It allows you utilize switch
statements, whereas otherwise you'd possibly need to look at multiple
bits of information inside the structure.

-- 
Ville Syrjälä
Intel OTC