fbdev: fix color component field length documentation
authorMichal Januszewski <spock@gentoo.org>
Mon, 13 Apr 2009 21:39:41 +0000 (14:39 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 13 Apr 2009 22:04:29 +0000 (15:04 -0700)
The documentation about the meaning of the color component bitfield
lengths in pseudocolor modes is inconsistent.  Fix it, so that it
indicates the correct interpretation everywhere, i.e.  that 1 << length is
the number of palette entries.

Signed-off-by: Michal Januszewski <spock@gentoo.org>
Acked-by: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: <syrjala@sci.fi>
Acked-by: Geert Uytterhoeven <geert.uytterhoeven@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/video/skeletonfb.c
drivers/video/vfb.c
include/linux/fb.h

index a439159204a8490fe79e2e0bebae3f9b47167481..89158bc71da2b3ea982d355c2e6ee0dfeaee7244 100644 (file)
@@ -308,9 +308,11 @@ static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
      *   color depth = SUM(var->{color}.length)
      *
      * Pseudocolor:
-     *    var->{color}.offset is 0
-     *    var->{color}.length contains width of DAC or the number of unique
-     *                        colors available (color depth)
+     *    var->{color}.offset is 0 unless the palette index takes less than
+     *                        bits_per_pixel bits and is stored in the upper
+     *                        bits of the pixel value
+     *    var->{color}.length is set so that 1 << length is the number of
+     *                        available palette entries
      *    pseudo_palette is not used
      *    RAMDAC[X] is programmed to (red, green, blue)
      *    color depth = var->{color}.length
index cc919ae465711e17cee1648b61bb679576ed3242..050d432c7d952c3160794e30f22ad5f0cb7d4151 100644 (file)
@@ -318,13 +318,16 @@ static int vfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
         *   {hardwarespecific} contains width of RAMDAC
         *   cmap[X] is programmed to (X << red.offset) | (X << green.offset) | (X << blue.offset)
         *   RAMDAC[X] is programmed to (red, green, blue)
-        * 
+        *
         * Pseudocolor:
-        *    uses offset = 0 && length = RAMDAC register width.
-        *    var->{color}.offset is 0
-        *    var->{color}.length contains widht of DAC
+        *    var->{color}.offset is 0 unless the palette index takes less than
+        *                        bits_per_pixel bits and is stored in the upper
+        *                        bits of the pixel value
+        *    var->{color}.length is set so that 1 << length is the number of available
+        *                        palette entries
         *    cmap is not used
         *    RAMDAC[X] is programmed to (red, green, blue)
+        *
         * Truecolor:
         *    does not use DAC. Usually 3 are present.
         *    var->{color}.offset contains start of bitfield
index f563c50139325b98c11ec5ea492b36d9aa1b7ee3..330c4b1bfcaa58b32907cd9f050c9cc67b097cb0 100644 (file)
@@ -173,8 +173,12 @@ struct fb_fix_screeninfo {
 /* Interpretation of offset for color fields: All offsets are from the right,
  * inside a "pixel" value, which is exactly 'bits_per_pixel' wide (means: you
  * can use the offset as right argument to <<). A pixel afterwards is a bit
- * stream and is written to video memory as that unmodified. This implies
- * big-endian byte order if bits_per_pixel is greater than 8.
+ * stream and is written to video memory as that unmodified.
+ *
+ * For pseudocolor: offset and length should be the same for all color
+ * components. Offset specifies the position of the least significant bit
+ * of the pallette index in a pixel value. Length indicates the number
+ * of available palette entries (i.e. # of entries = 1 << length).
  */
 struct fb_bitfield {
        __u32 offset;                   /* beginning of bitfield        */