> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
