On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat <FlorianSchandinat at gmx.de> wrote: > On 06/21/2011 10:31 PM, Laurent Pinchart wrote: >> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: >>> On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote: >>>> +The FOURCC-based API replaces format descriptions by four character >>>> codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a >>>> format +without explicitly describing it. This is the only API that >>>> supports YUV +formats. Drivers are also encouraged to implement the >>>> FOURCC-based API for RGB +and grayscale formats. >>>> + >>>> +Drivers that support the FOURCC-based API report this capability by >>>> setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities >>>> field. + >>>> +FOURCC definitions are located in the linux/videodev2.h header. >>>> However, >>>> and +despite starting with the V4L2_PIX_FMT_prefix, they are not >>>> restricted to V4L2 +and don't require usage of the V4L2 subsystem. >>>> FOURCC documentation is +available in >>>> Documentation/DocBook/v4l/pixfmt.xml. >>>> + >>>> +To select a format, applications set the FB_VMODE_FOURCC bit in the >>>> +fb_var_screeninfo vmode field, and set the fourcc field to the desired >>>> FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields >>>> must be set to +0 by applications and ignored by drivers. Note that the >>>> grayscale and fourcc +fields share the same memory location. Application >>>> must thus not set the +grayscale field to 0. >>> >>> These are the only parts I don't like: (ab)using the vmode field (this >>> isn't really a vmode flag), and the union of grayscale and fourcc (avoid >>> unions where possible). >> >> I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a >> FOURCC >> mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very >> happy >> with that, and proposed using the vmode field instead. >> >> Given that there's virtually no fbdev documentation, whether the vmode >> field >> and/or nonstd field are good fit for a FOURCC mode indicator is subject to >> interpretation. > > The reason for my suggestion is that the vmode field is accepted to contain > only flags and at least to me there is no hard line what is part of the > video mode and what is not. In contrast the nonstd field is already used in > a lot of different (incompatible) ways. I think if we only use the nonstd > field for handling FOURCC it is likely that some problems will appear. > >>> What about storing the FOURCC value in nonstd instead? >> >> Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format >> setting will be a standard fbdev API, I'm not very keen on storing it in >> the >> nonstd field without a union. >> >>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must >>> be non-zero), I don't think there are any conflicts with existing values >>> of >>> nonstd. To make it even safer and easier to parse, you could set bit 31 >>> of >>> nonstd as a FOURCC indicator. >> >> I would then create a union between nonstd and fourcc, and document nonstd >> as >> being used for the legacy API only. Most existing drivers use a couple of >> nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and >> uses >> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd& >> 0xff000000 != 0 could be used as a FOURCC mode test. >> >> This assumes that FOURCCs will never have their last character set to >> '\0'. Is >> that a safe assumption for the future ? > > Yes, I think. The information I found indicates that space should be used > for padding, so a \0 shouldn't exist. > I think using only the nonstd field and requiring applications to check the > capabilities would be possible, although not fool proof ;)
So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if any of them is set. Nicely backwards compatible, as sane drivers should reject nonstd values they don't support (apps _will_ start filling in FOURCC values ignoring capabilities, won't they?). Gr{oetje,eeting}s, ? ? ? ? ? ? ? ? ? ? ? ? Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds