On Sat, Apr 06, 2002 at 10:00:28PM +0100, Philip Blundell wrote:
> On Fri, 2002-04-05 at 23:11, Philip Blundell wrote:
> > Thirdly, I was getting "FBIOPUT_VSCREENINFO: Invalid argument" errors.
> > This seemed to be caused by my choice of 24bpp as my colour depth.
> > Changing to 16bpp allowed the X server to start without error but the
> > screen was completely blank. 8bpp appeared to work OK.
>
> Some additional data I just discovered: in the 16bpp case the problem
> seems to be that the colourmap is wrong, with most colours being mapped
> to black. If I allow the machine to boot as far as the GDM login
> screen, a few fragments of the window are visible but incorrectly
> coloured.
Hmm, sounds like X isn't changing the Linux default console colours.
The way we handle the VIDC's 16bpp, we turn it into an RGB555
direct colourmap display:
5 8
R bits --/--> R LUT --/--> R DAC
5 8
G bits --/--> G LUT --/--> G DAC
5 8
B bits --/--> B LUT --/--> B DAC
(The X code agrees with my understanding that this is a direct colourmap
display - see programs/Xserver/dix/colormap.c::AllocColor in X11 code.)
PseudoColor tries to look up a pixel value Vrgb for colour (RGB)
but DirectColor tries to look up a value Vr in R map, Vg in G map,
Vb in B map.
I'd imagine that the XFree's fbcon layer isn't correctly handling
direct colourmapped displays.
True color on the other hand would be something like:
8
R bits --/--> R DAC
8
G bits --/--> G DAC
8
B bits --/--> B DAC
ie, no LUT. In this case, X would not need to set up the palette.
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
http://www.arm.linux.org.uk/armlinux/mailinglists.php
Please visit the above addresses for information on this list.
