* Re: [linux-fbdev] Re: Xfree86-4.0.1, Lombard, Mach64 driver
@ 2000-09-29 18:31 Petr Vandrovec
2000-09-29 21:18 ` Geert Uytterhoeven
0 siblings, 1 reply; 2+ messages in thread
From: Petr Vandrovec @ 2000-09-29 18:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt, Jon Erick Ween, linuxppc-dev, linux-fbdev,
toe
On 29 Sep 00 at 13:05, Geert Uytterhoeven wrote:
> The main thing we need to be careful about is that the xor mask is different
> for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
> while directcolor needs `15' for each color component (drivers that incorrectly
> report a directcolor instead of truecolor visual will easily be identified).
What about killing directcolor completely, and using directcolor capable
hardware as truecolor one with per-fb global gamma correction table?
(as windows do...)
List of modified files is shorter then ;-)
Petr
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [linux-fbdev] Re: Xfree86-4.0.1, Lombard, Mach64 driver
2000-09-29 18:31 [linux-fbdev] Re: Xfree86-4.0.1, Lombard, Mach64 driver Petr Vandrovec
@ 2000-09-29 21:18 ` Geert Uytterhoeven
0 siblings, 0 replies; 2+ messages in thread
From: Geert Uytterhoeven @ 2000-09-29 21:18 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Benjamin Herrenschmidt, Jon Erick Ween, linuxppc-dev, linux-fbdev,
toe
On Fri, 29 Sep 2000, Petr Vandrovec wrote:
> On 29 Sep 00 at 13:05, Geert Uytterhoeven wrote:
> > The main thing we need to be careful about is that the xor mask is different
> > for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
> > while directcolor needs `15' for each color component (drivers that incorrectly
> > report a directcolor instead of truecolor visual will easily be identified).
>
> What about killing directcolor completely, and using directcolor capable
> hardware as truecolor one with per-fb global gamma correction table?
> (as windows do...)
That's another possibility...
The advantage of using the directcolor features by storing the console palette
in the color LUT, is that the console behaves more like the original VGA text
console: if you change one console palette entry, all characters drawn in that
color will change as well.
Besides, if you have e.g. 32 bpp hardware that uses XRGB 8888, with X
specifying some special features, you don't want to xor with 0xffffffff
neither, but with a fbdev specific value. Another reason for using the 17th
entry as the xor mask.
> List of modified files is shorter then ;-)
Yes, but the changes to the drivers that we do have to update (the ones
supporting directcolor) are more complex:
- When in truecolor mode, the gamma correction table must be loaded
- Setcolreg() should update dispsw_data[i] when in truecolor mode, instead
of changing the color LUT
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-09-29 21:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-09-29 18:31 [linux-fbdev] Re: Xfree86-4.0.1, Lombard, Mach64 driver Petr Vandrovec
2000-09-29 21:18 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).