From: Michal Januszewski <spock@gentoo.org>
To: linux-kernel@vger.kernel.org
Cc: "Krzysztof Helt" <krzysztof.h1@poczta.fm>,
"Ville Syrjälä" <syrjala@sci.fi>,
"Geert Uytterhoeven" <geert.uytterhoeven@gmail.com>,
linux-fbdev-devel@lists.sourceforge.net
Subject: [PATCH] fbdev: fix color component field length documentation
Date: Tue, 31 Mar 2009 00:00:07 +0200 [thread overview]
Message-ID: <20090330220007.GC6540@spock.one.pl> (raw)
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@gentoo.org>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Geert Uytterhoeven <geert.uytterhoeven@gmail.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 */
next reply other threads:[~2009-03-30 22:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 22:00 Michal Januszewski [this message]
2009-03-31 7:18 ` [PATCH] fbdev: fix color component field length documentation Geert Uytterhoeven
2009-03-31 22:28 ` Michal Januszewski
2009-04-01 16:50 ` Krzysztof Helt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090330220007.GC6540@spock.one.pl \
--to=spock@gentoo.org \
--cc=geert.uytterhoeven@gmail.com \
--cc=krzysztof.h1@poczta.fm \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=syrjala@sci.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.