[PATCH/RFC] fbdev: Add FOURCC-based format configuration API

[Florian Tobias Schandinat]

On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart
> <laurent.pinchart at ideasonboard.com>  wrote:
>>> As for struct fb_var_screeninfo fields to support switching to a FOURCC
>>> mode, I also prefer an explicit dedicated flag to specify switching to it.
>>> Even though using FOURCC doesn't fit under the notion of a videomode, using
>>> one of .vmode bits is too tempting, so, I would actually take the plunge and
>>> use FB_VMODE_FOURCC.
>>
>> Another option would be to consider any grayscale>  1 value as a FOURCC. I've
>> briefly checked the in-tree drivers: they only assign grayscale with 0 or 1,
>> and check whether grayscale is 0 or different than 0. If a userspace
>> application only sets grayscale>  1 when talking to a driver that supports the
>> FOURCC-based API, we could get rid of the flag.
>>
>> What can't be easily found out is whether existing applications set grayscale
>> to a>  1 value. They would break when used with FOURCC-aware drivers if we
>> consider any grayscale>  1 value as a FOURCC. Is that a risk we can take ?
>
> I think we can. I'd expect applications to use either 1 or -1 (i.e.
> all ones), both are
> invalid FOURCC values.
>
> Still, I prefer the nonstd way.
> And limiting traditional nonstd values to the lowest 24 bits (there
> are no in-tree
> drivers using the highest 8 bits, right?).

Okay, it would be okay for me to
- write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
- not having an explicit flag to enable FOURCC
- in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
- making support of FOURCC visible to userspace by capabilites |= FB_CAP_FOURCC

The capabilities is not strictly necessary but I think it's very useful as
- it allows applications to make sure the extension is supported (for example to 
adjust the UI)
- it allows applications to distinguish whether a particular format is not 
supported or FOURCC at all
- it allows signaling further extensions of the API
- it does not hurt, one line per driver and still some bytes in fixinfo free


So using it would look like this:
- the driver must have capabilities |= FB_CAP_FOURCC
- the application may check capabilities to know whether FOURCC is supported
- the application may write a raw FOURCC value in nonstd to request changing to 
FOURCC mode with this format
- when the driver switches to a FOURCC mode it must have visual = 
FB_VISUAL_FOURCC and the current FOURCC format in nonstd
- the application should check visual and nonstd to make sure it gets what it wanted


So if there are no strong objections against this I think we should implement it.
I do not really care whether we use a union or not but I think if we decide to 
have one it should cover all fields that are undefined/unused in FOURCC mode.


Hope we can find anything that everyone considers acceptable,

Florian Tobias Schandinat