All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Jon Smirl <jonsmirl@gmail.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: mono, gray and index configs
Date: Thu, 11 Aug 2005 19:08:34 +0800	[thread overview]
Message-ID: <b00ca3bd05081104086fa9e639@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0508111020520.1037@numbat.sonytel.be>

On 8/11/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, 11 Aug 2005, Antonino A. Daplas wrote:
> > that all the lengths = 1 and offsets = 0.  Currently, we have no way to
> > specifically request for mono01, mono10, or 1-bit pseudocolor. Just check
> > for fix->visual afterwards.
> 
> For mono01 or mono10, if the visual is pseudocolor, just set the colormap to
> black/white or white/black.


I don't know. If I can change the colormap, I would  advertise this as
1-bit pseudocolor, not monochrome.  Otherwise, why differentiate
between mono01 and mono10 if I can control what color is 0 and what
color is 1.  I think the closest definition of monochrome is 1-bit
static pseudocolor.  And we just have mono01 and mono10 to advertise
how hardware treats 0/1 (background/foreground or reverse).

I have a few things that are still not clear to me.  If I understand
it correctly, monochrome means 2 colors regardless of the bit depth. 
So it's possible, for example, to have 8-bit monochrome that has only
two colors, ie 0x00 and 0xff.   If this was 8-bit static pseudocolor,
then it has 256 different colors.

(Depending on how correct I am with the interpretation, there might be
some bugs in fbdev on how it determines the color depth. No one is
complaining yet though, so greater than 1-bit monochrome is probably
rare if not nonexistent.)

> 
> > For directcolor (indexed) vs truecolor, there is currently no way
> > to specify which visual you want.  You also have to check for fix->visual
> > afterwards.
> >
> > One of the reason I also want this sysfs attribute is because in at
> > least 1 driver (i810fb), it's possible to choose between truecolor and
> > directcolor but it uses a hack by checking for the var->nonstd flag.
> 
> So the driver should use directcolor instead of truecolor if the hardware
> supports it. The application can always set a linear colormap if it needs
> truecolor.


A few years ago, I discovered that there are several fbdev apps that
make ssumptions which are not necessarily correct.  For example, if
bits_per_pixel > 8, the app assumes the format is truecolor. So the
app produces wrong colors if fbdev is in directcolor mode (because it
failed to set the cmap).

So, it is useful to have the capability to choose between truecolor
and directcolor when dealing with those apps without rebooting or
recompiling.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

  reply	other threads:[~2005-08-11 11:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11  3:21 mono, gray and index configs Jon Smirl
2005-08-11  5:36 ` Antonino A. Daplas
2005-08-11  8:22   ` Geert Uytterhoeven
2005-08-11 11:08     ` Antonino Daplas [this message]
2005-08-11 11:49       ` Geert Uytterhoeven
2005-08-11 17:34         ` Antonino A. Daplas
2005-08-11 19:14           ` Jon Smirl
2005-08-20  1:13             ` Jon Smirl
2005-08-20  2:56               ` Antonino A. Daplas
2005-08-20  3:09                 ` Jon Smirl
2005-08-22 10:17                   ` Geert Uytterhoeven
2005-08-22 13:30                     ` Richard Smith
2005-08-22 14:06                       ` Geert Uytterhoeven
2005-08-22 14:36                         ` Richard Smith
2005-08-22 15:47                           ` Antonino A. Daplas
2005-08-22 17:19                           ` Geert Uytterhoeven
2005-08-22 19:00                             ` Richard Smith
2005-08-22 19:44                               ` Richard Smith
2005-08-22 15:57                     ` Jon Smirl
2005-08-12  7:24           ` Geert Uytterhoeven
2005-08-12 10:28             ` Antonino A. Daplas
2005-08-11  8:20 ` 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=b00ca3bd05081104086fa9e639@mail.gmail.com \
    --to=adaplas@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=jonsmirl@gmail.com \
    --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 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.