--- v5
+++ v3
@@ -6,18 +6,17 @@
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
- Documentation/fb/api.txt | 306 ++++++++++++++++++++++++++++++++++++++++++++++
- drivers/video/fbmem.c | 14 ++
- include/linux/fb.h | 14 ++-
- 3 files changed, 330 insertions(+), 4 deletions(-)
+ Documentation/fb/api.txt | 317 ++++++++++++++++++++++++++++++++++++++++++++++
+ include/linux/fb.h | 28 +++-
+ 2 files changed, 339 insertions(+), 6 deletions(-)
create mode 100644 Documentation/fb/api.txt
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
-index 0000000..d4ff7de
+index 0000000..d842534
--- /dev/null
+++ b/Documentation/fb/api.txt
-@@ -0,0 +1,306 @@
+@@ -0,0 +1,317 @@
+ The Frame Buffer Device API
+ ---------------------------
+
@@ -68,7 +67,7 @@
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
-+bits_per_pixel, grayscale, red, green, blue and transp fields.
++bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
+
+Visuals describe how color information is encoded and assembled to create
+macropixels. Types describe how macropixels are stored in memory. The following
@@ -105,7 +104,7 @@
+- FB_TYPE_FOURCC
+
+Macropixels are stored in memory as described by the format FOURCC identifier
-+stored in the variable screen information grayscale field.
++stored in the variable screen information fourcc field.
+
+- FB_VISUAL_MONO01
+
@@ -158,7 +157,7 @@
+- FB_VISUAL_FOURCC
+
+Pixels are encoded and interpreted as described by the format FOURCC
-+identifier stored in the variable screen information grayscale field.
++identifier stored in the variable screen information fourcc field.
+
+
+3. Screen information
@@ -207,12 +206,22 @@
+ __u32 yoffset; /* resolution */
+
+ __u32 bits_per_pixel; /* guess what */
-+ __u32 grayscale; /* 0 = color, 1 = grayscale, */
-+ /* >1 = FOURCC */
-+ struct fb_bitfield red; /* bitfield in fb mem if true color, */
-+ struct fb_bitfield green; /* else only length is significant */
-+ struct fb_bitfield blue;
-+ struct fb_bitfield transp; /* transparency */
++ union {
++ struct { /* Legacy format API */
++ __u32 grayscale; /* 0 = color, 1 = grayscale */
++ /* bitfields in fb mem if true color, else only */
++ /* length is significant */
++ struct fb_bitfield red;
++ struct fb_bitfield green;
++ struct fb_bitfield blue;
++ struct fb_bitfield transp; /* transparency */
++ };
++ struct { /* FOURCC-based format API */
++ __u32 fourcc; /* FOURCC format */
++ __u32 colorspace;
++ __u32 reserved[11];
++ } fourcc;
++ };
+
+ __u32 nonstd; /* != 0 Non standard pixel format */
+
@@ -234,8 +243,7 @@
+ __u32 sync; /* see FB_SYNC_* */
+ __u32 vmode; /* see FB_VMODE_* */
+ __u32 rotate; /* angle we rotate counter clockwise */
-+ __u32 colorspace; /* colorspace for FOURCC-based modes */
-+ __u32 reserved[4]; /* Reserved for future compatibility */
++ __u32 reserved[5]; /* Reserved for future compatibility */
+};
+
+To modify variable information, applications call the FBIOPUT_VSCREENINFO
@@ -311,46 +319,23 @@
+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 grayscale field to the desired FOURCC.
-+For YUV formats, they should also select the appropriate colorspace by setting
-+the colorspace field to one of the colorspaces listed in linux/videodev2.h and
-+documented in Documentation/DocBook/v4l/colorspaces.xml.
-+
-+The red, green, blue and transp fields are not used with the FOURCC-based API.
-+For forward compatibility reasons applications must zero those fields, and
-+drivers must ignore them. Values other than 0 may get a meaning in future
-+extensions.
++To select a format, applications set the fourcc.fourcc field to the desired
++FOURCC. For YUV formats, they should also select the appropriate colorspace by
++setting the fourcc.colorspace field to one of the colorspaces listed in
++linux/videodev2.h and documented in Documentation/DocBook/v4l/colorspaces.xml.
++
++For forward compatibility reasons applications must zero the fourcc reserved
++fields by zeroing the whole fourcc structure before filling it. The reserved
++fields must be ignored by drivers. Values other than 0 may get a meaning in
++future extensions. Note that the grayscale, red, green, blue and transp field
++share memory with the fourcc field. Application must thus not touch those
++fields when using the FOURCC-based API.
+
+Upon successful format configuration, drivers update the fb_fix_screeninfo
+type, visual and line_length fields depending on the selected format. The type
+and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.
-diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
-index ad93629..ac9141b 100644
---- a/drivers/video/fbmem.c
-+++ b/drivers/video/fbmem.c
-@@ -967,6 +967,20 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
- memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
- u32 activate = var->activate;
-
-+ /* When using FOURCC mode, make sure the red, green, blue and
-+ * transp fields are set to 0.
-+ */
-+ if ((info->fix.capabilities & FB_CAP_FOURCC) &&
-+ var->grayscale > 1) {
-+ if (var->red.offset || var->green.offset ||
-+ var->blue.offset || var->transp.offset ||
-+ var->red.length || var->green.length ||
-+ var->blue.length || var->transp.length ||
-+ var->red.msb_right || var->green.msb_right ||
-+ var->blue.msb_right || var->transp.msb_right)
-+ return -EINVAL;
-+ }
-+
- if (!info->fbops->fb_check_var) {
- *var = info->var;
- goto done;
diff --git a/include/linux/fb.h b/include/linux/fb.h
-index 1d6836c..c18122f 100644
+index 1d6836c..98b23e3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -45,6 +45,7 @@
@@ -388,27 +373,35 @@
};
/* Interpretation of offset for color fields: All offsets are from the right,
-@@ -246,8 +251,8 @@ struct fb_var_screeninfo {
+@@ -246,12 +251,23 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
- __u32 grayscale; /* != 0 Graylevels instead of colors */
--
-+ __u32 grayscale; /* 0 = color, 1 = grayscale, */
-+ /* >1 = FOURCC */
- struct fb_bitfield red; /* bitfield in fb mem if true color, */
- struct fb_bitfield green; /* else only length is significant */
- struct fb_bitfield blue;
-@@ -273,7 +278,8 @@ struct fb_var_screeninfo {
- __u32 sync; /* see FB_SYNC_* */
- __u32 vmode; /* see FB_VMODE_* */
- __u32 rotate; /* angle we rotate counter clockwise */
-- __u32 reserved[5]; /* Reserved for future compatibility */
-+ __u32 colorspace; /* colorspace for FOURCC-based modes */
-+ __u32 reserved[4]; /* Reserved for future compatibility */
- };
-
- struct fb_cmap {
+
+- struct fb_bitfield red; /* bitfield in fb mem if true color, */
+- struct fb_bitfield green; /* else only length is significant */
+- struct fb_bitfield blue;
+- struct fb_bitfield transp; /* transparency */
++ union {
++ struct { /* Legacy format API */
++ __u32 grayscale; /* 0 = color, 1 = grayscale */
++ /* bitfields in fb mem if true color, else only */
++ /* length is significant */
++ struct fb_bitfield red;
++ struct fb_bitfield green;
++ struct fb_bitfield blue;
++ struct fb_bitfield transp; /* transparency */
++ };
++ struct { /* FOURCC-based format API */
++ __u32 fourcc; /* FOURCC format */
++ __u32 colorspace;
++ __u32 reserved[11];
++ } fourcc;
++ };
+
+ __u32 nonstd; /* != 0 Non standard pixel format */
+
--
1.7.3.4