On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat FlorianSchandinat@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@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