Re: [RFC] Standardize YUV support in the fbdev API

Hi Laurent,

On 05/17/2011 10:07 PM, Laurent Pinchart wrote:

Hi everybody,

I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.

Thanks. I think you did already a good job, hope we can get it done this time.

Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share data
and buffers between those subsystems, and the planned use of V4L2 FCCs in the
KMS overlay API, I believe using V4L2 FCCs to identify fbdev formats would be
a wise decision.

I agree.

To select a frame buffer YUV format, the fb_var_screeninfo structure will need
to be extended with a format field. The fbdev API and ABI must not be broken,
which prevents us from changing the current structure layout and replacing the
existing format selection mechanism (through the red, green, blue and alpha
bitfields) completely.

I agree.

- Other solutions are possible, such as adding new ioctls. Those solutions are
more intrusive, and require larger changes to both userspace and kernelspace
code.

I'm against (ab)using the nonstd field (probably the only sane thing we can do 
with it is declare it non-standard which interpretation is completely dependent 
on the specific driver) or requiring previously unused fields to have a special 
value so I'd like to suggest a different method:

I remembered an earlier discussion:
[ http://marc.info/?l=linux-fbdev&m9896686208130&w=2 ]

On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
 > On Tue, Mar 1, 2011 at 04:13, Damian[off-list ref]  wrote:
 >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
 >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
 >>> FB_VISUAL_*
 >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
 >>> fields are
 >>> YCbCr instead of RGB.
 >>> Depending on the frame buffer organization, you also need new
 >>> FB_TYPE_*/FB_AUX_*
 >>> types.
 >>
 >> I just wanted to clarify here.  Is your comment about these new flags in
 >> specific reference to this patch or to Magnus' "going forward" comment?  It
 >
 > About new flags.
 >
 >> seems like the beginnings of a method to standardize YCbCr support in fbdev
 >> across all platforms.
 >> Also, do I understand correctly that FB_VISUAL_ would specify the colorspace
 >
 > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped to
 > colors on the screen, so to me it looks like the sensible way to set up YCbCr.
 >
 >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
 >> semiplanar, interleaved, etc)?  I'm not really sure what you are referring
 >> to with the FB_AUX_* however.
 >
 > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame buffer
 > memory.
 >
 > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an additional
 > parameter (e.g. the interleave value for interleaved bitplanes).

Adding new standard values for these fb_fix_screeninfo fields would solve the 
issue for framebuffers which only support a single format. If you have the need 
to switch I guess it would be a good idea to add a new flag to the vmode 
bitfield in fb_var_screeninfo which looks like a general purpose modifier for 
the videomode. You could than reuse any RGB-specific field you like to pass more 
information.
Maybe we should also use this chance to declare one of the fix_screeninfo 
reserved fields to be used for capability flags or an API version as we can 
assume that those are 0 (at least in sane drivers).


Good luck,

Florian Tobias Schandinat