Linux Framebuffer Layer development
 help / color / mirror / Atom feed
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

  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