| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 31 Mar 2009 00:00:07 +0200
From: Michal Januszewski <spock@...too.org>
To: linux-kernel@...r.kernel.org
Cc: Krzysztof Helt <krzysztof.h1@...zta.fm>,
Ville Syrjälä <syrjala@....fi>,
Geert Uytterhoeven <geert.uytterhoeven@...il.com>,
linux-fbdev-devel@...ts.sourceforge.net
Subject: [PATCH] fbdev: fix color component field length documentation
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 the 1 << length is the number
of palette entries.
Signed-off-by: Michal Januszewski <spock@...too.org>
Cc: Krzysztof Helt <krzysztof.h1@...zta.fm>
Cc: Ville Syrjälä <syrjala@....fi>
Cc: Geert Uytterhoeven <geert.uytterhoeven@...il.com>
---
This patch will be followed by a number of patches which attempt to
introduce the correct interpretation of the length field in all fbdev
drivers. A separate patch will be sent for each driver so that
in case I made a mistake in a specific driver, the other ones will
not be affected.
diff --git a/drivers/video/skeletonfb.c b/drivers/video/skeletonfb.c
index df53365..3810dae 100644
--- a/drivers/video/skeletonfb.c
+++ b/drivers/video/skeletonfb.c
@@ -309,8 +309,8 @@ static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
*
* Pseudocolor:
* var->{color}.offset is 0
- * var->{color}.length contains width of DAC or the number of unique
- * colors available (color depth)
+ * 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 --git a/drivers/video/vfb.c b/drivers/video/vfb.c
index 93fe08d..e4eeb91 100644
--- a/drivers/video/vfb.c
+++ b/drivers/video/vfb.c
@@ -318,13 +318,14 @@ 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}.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 --git a/include/linux/fb.h b/include/linux/fb.h
index 31527e1..ab924b1 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -172,8 +172,11 @@ 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 is always 0 and length, which should be the same
+ * for all color components, indicates the number of available palette entries
+ * (i.e. # of entries = 1 << length).
*/
struct fb_bitfield {
__u32 offset; /* beginning of bitfield */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists