drm pixel formats update

[Alan Cox]

> 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)

> 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, ...

> 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)

Alan