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

[Laurent Pinchart]

Hi Florian,

On Monday 01 August 2011 01:58:27 Florian Tobias Schandinat wrote:
> On 07/31/2011 11:28 PM, Laurent Pinchart wrote:
> > On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote:
> >> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
> >>> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart 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
> > 
> > Without a FOURCC capability applications will need to try FOURCCs
> > blindly. Drivers that are not FOURCC aware would then risk interpreting
> > the FOURCC as something else. As you mention below applications will
> > need that check that visual == FB_VISUAL_FOURCC, so it's less of an
> > issue than I initially thought, but it doesn't become a non-issue. The
> > display might still show glitches.
> 
> True.
> 
> >> 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,
> > 
> > This sounds good to me, except that I would use the grayscale field
> > instead of the nonstd field. nonstd has pretty weird usecases, while
> > grayscale is better defined. nonstd might also make sense combined with
> > FOURCC-based modes, while grayscale would be completely redundant.
> > 
> > What's your opinion on that ?
> 
> I do not really care, either one would be okay for me.
> You're right that nonstd is used for a lot of things and perhaps some of
> those should still be possible in FOURCC mode. On the other hand I think
> applications are more likely to pass random values to grayscale as its
> meaning seems globally accepted (in contrast to nonstd where the
> application needs to know the driver to get any use of it).
> Perhaps you should also say that in FOURCC mode all unused pixel format
> fields should be set to 0 by the application and other values of those may
> get a meaning in later extensions or individual drivers.

Good point. I'll add that to the documentation.

-- 
Regards,

Laurent Pinchart