Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Rolf Offermanns <rolf.offermanns@gmx.net>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: color map vs. pseudo-palette vs. RAMDAC registers
Date: Mon, 24 Oct 2005 09:48:50 +0200	[thread overview]
Message-ID: <200510240948.50185.rolf.offermanns@gmx.net> (raw)

Hi All,
I tried to understand the skeletonfb driver code, and I am confused by some 
comments in it:

I do not understand what the color map and pseudo palette stuff is used for.

From the c file:
--------------------------------------------------------------------
Pseudocolor:
* cmap 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 
support pseudocolor visual? Is pseudocolor always used for 8bpp or are there 
situations where 16bpp pseudocolor makes sense?

-----------------------------------------------------------------------------
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?

-> cmap is programmed to...
In the code that follows this comment, not the cmap is programmed, but the 
pseudo palette.
1. Why do I need a pseudo palette and where does its size 16 comes from?
2. What do I need a color map for?

-> RAMDAC does not exist <-> "usually has 3 of them"
???

Please shed some light on me.

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  7:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-24  7:48 Rolf Offermanns [this message]
2005-10-24  7:57 ` color map vs. pseudo-palette vs. RAMDAC registers Geert Uytterhoeven
2005-10-24 11:01   ` Rolf Offermanns
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=200510240948.50185.rolf.offermanns@gmx.net \
    --to=rolf.offermanns@gmx.net \
    --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