From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Subject: directcolor colormap question
Date: Mon, 19 Sep 2005 20:00:47 +0600 [thread overview]
Message-ID: <432EC48F.40804@ums.usu.ru> (raw)
Hello,
I am still writing a framebuffer driver for S3 Trio 3D/2X cards. Since
this card supports (hardware) gamma correction in Windows 98, I decided
to implement directcolor visuals (Xorg guys: you can set SR1B to 0x18 if
bpp>8, and then standard VGA PEL registers will alter the hardware
colormap).
The problem here is that I don't know the proper semantics for colormap
persistence.
Consider the following scenario:
fbset -depth 16 -rgba 5,5,5,1 -nonstd 1
run some program that sets a colormap, e.g. Xorg with the "fbdev" driver
fbset -depth 16 -rgba 5,6,5,0 -nonstd 1
(oops, the text is all purple!)
The problem is that the program sets the following colormap:
reg 0 -> (0,0,0)
reg 1 -> (8,4,8)
...
reg 31 -> (255,125,255)
reg 32 -> (0,129,0)
reg 33 -> (0,133,0)
...
reg 62 -> (0,250,0)
reg 63 -> (0,255,0)
(i.e. just a linear colormap for 16 bpp). When I switch the framebuffer
to 15bpp, the colormap persists, but it is no longer a proper colormap
for that mode! Is this colormap persistence an expected behaviour, or
should I somehow initialize the colormap to something sane on depth
switch? If that's a bug in my driver, could you please point me where
some other driver does this colormap initialization?
--
Alexander E. Patrakov
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
next reply other threads:[~2005-09-19 14:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 14:00 Alexander E. Patrakov [this message]
2005-09-19 15:00 ` directcolor colormap question Antonino A. Daplas
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=432EC48F.40804@ums.usu.ru \
--to=patrakov@ums.usu.ru \
--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.