The patch titled fbdev: fix color component field length documentation has been removed from the -mm tree. Its filename was fbdev-fix-color-component-field-length-documentation.patch This patch was dropped because it was merged into mainline or a subsystem tree The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: fbdev: fix color component field length documentation From: Michal Januszewski <spock@xxxxxxxxxx> 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@xxxxxxxxxx> Acked-by: Krzysztof Helt <krzysztof.h1@xxxxxxxxx> Cc: <syrjala@xxxxxx> Acked-by: Geert Uytterhoeven <geert.uytterhoeven@xxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- drivers/video/skeletonfb.c | 8 +++++--- drivers/video/vfb.c | 11 +++++++---- include/linux/fb.h | 8 ++++++-- 3 files changed, 18 insertions(+), 9 deletions(-) diff -puN drivers/video/skeletonfb.c~fbdev-fix-color-component-field-length-documentation drivers/video/skeletonfb.c --- a/drivers/video/skeletonfb.c~fbdev-fix-color-component-field-length-documentation +++ a/drivers/video/skeletonfb.c @@ -308,9 +308,11 @@ static int xxxfb_setcolreg(unsigned regn * 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 diff -puN drivers/video/vfb.c~fbdev-fix-color-component-field-length-documentation drivers/video/vfb.c --- a/drivers/video/vfb.c~fbdev-fix-color-component-field-length-documentation +++ a/drivers/video/vfb.c @@ -318,13 +318,16 @@ static int vfb_setcolreg(u_int regno, u_ * {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 diff -puN include/linux/fb.h~fbdev-fix-color-component-field-length-documentation include/linux/fb.h --- a/include/linux/fb.h~fbdev-fix-color-component-field-length-documentation +++ a/include/linux/fb.h @@ -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 */ _ Patches currently in -mm which might be from spock@xxxxxxxxxx are origin.patch linux-next.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html