Hi Geert, On Monday 01 August 2011 11:49:46 Geert Uytterhoeven wrote: > On Mon, Aug 1, 2011 at 00:54, 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 > > > > > > 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 > > As several of the FOURCC formats duplicate formats you can already specify > in some other way (e.g. the RGB and greyscale formats), and as FOURCC makes > life easier for the application writer, I'm wondering whether it makes sense > to add FOURCC support in the generic layer for drivers that don't support > it? I.e. the generic layer would fill in fb_var_screeninfo depending on the > requested FOURCC mode, if possible. That's a good idea, but I'd like to add that in a second step. I'm working on a proof-of-concept by porting a driver to the FOURCC-based API first. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
