From: Rolf Offermanns <rolf@offermanns.de>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: color map vs. pseudo-palette vs. RAMDAC registers
Date: Mon, 24 Oct 2005 13:01:16 +0200 [thread overview]
Message-ID: <200510241301.17275.rolf@offermanns.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0510240954290.16285@numbat.sonytel.be>
On Monday 24 October 2005 09:57, Geert Uytterhoeven wrote:
> > --------------------------------------------------------------------
> > Pseudocolor:
> > * cmap is not used
>
> That should be `pseudo palette is not used'.
>
> > * DAC[X] is programmed to (red, green, blue)
> > --------------------------------------------------------------------
> > Does that mean, I do not need to allocate a color map, if my driver would
> > only
>
> It means you don't have to fill in the pseudo palette in this mode.
OK.
> > support pseudocolor visual? Is pseudocolor always used for 8bpp or are
> > there situations where 16bpp pseudocolor makes sense?
>
> Pseudocolor is not always 8 bpp (1, 2, 4 are common values as well), but
> large values are very uncommon, since 16 bpp pseudocolor would mean a
> 65536-entries colormap.
OK.
> > -------------------------------------------------------------------------
> >---- Truecolor:
> > * does not use RAMDAC (usually has 3 of them).
> > * var->{color}.offset contains start of bitfield
> > * var->{color}.length contains length of bitfield
> > * cmap is programmed to (red << red.offset) |
> > (green << green.offset) |
> > (blue << blue.offset) |
> > (transp << transp.offset)
> > * RAMDAC does not exist
> > -------------------------------------------------------------------------
> >---- Now I am lost:
> > -> does not use RAMDAC.
> > I understand this. It states the same in my chip reference. But what
> > means "usually has 3 of them" in this context?
>
> Red, green, and blue.
OK. But this is for H/W with DirectColor support where each color has its own
CLUT, right?
> > -> cmap is programmed to...
> > In the code that follows this comment, not the cmap is programmed, but
> > the pseudo palette.
>
> That should be `pseudo palette' again.
OK.
>
> > 1. Why do I need a pseudo palette and where does its size 16 comes from?
>
> It's used to translate from the 16 text console colors to actual pixel
> values.
OK, and these 16 color can be set/defined by text mode apps, right?
Thanks for these explanations Gerd. Shall I provide a patch for the skeletonfb
driver comments?
The one thing, I still do not understand is:
What are color maps used for in the different visuals? In pseudo mode they are
not used at all. In TrueColor mode there should be no need to map anything?
I checked the documentation again, but there must be something I have
overread.
Could you please explain this?
Thanks,
Rolf
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
next prev parent reply other threads:[~2005-10-24 11:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-24 7:48 color map vs. pseudo-palette vs. RAMDAC registers Rolf Offermanns
2005-10-24 7:57 ` Geert Uytterhoeven
2005-10-24 11:01 ` Rolf Offermanns [this message]
2005-10-24 11:19 ` Geert Uytterhoeven
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=200510241301.17275.rolf@offermanns.de \
--to=rolf@offermanns.de \
--cc=geert@linux-m68k.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox