Color-depth in X-windows, want >8-bit

['Robin' R. Battey]

Actually, I do use that chipset (well, the 65550, which uses the same
drivers).  Here's a link to a sample XF86Config with nice, explanatory
comments (it's the one I used initially):

http://www.sanpei.org/Laptop-X/Laptop-X/Gateway_2000_SOLO_9100-XL

And, according to the comments in the file, you were right, it's a
dot-clock issue. :-)

Cheers,
-robin

On Tue, 17 Apr 2001, Jesse Rehr wrote:

> Thanks for the very useful tip.  According to the created logfile x.out,
> I'm not finding any valid modes at these resolutions, although the X
> server is probing 4.096 Mb of memory. What I assumed was a memory issue
> appears to be, in fact, a dot-clock issue.  Linking through Intel, I
> found some documentation on www.xfree86.org that suggests dot-clocks on
> Chips drivers are goofy.  Although the RAMDAC, according to xfree86 and
> my manuals and other documentation, is supposed to be 110 MHz, linux is
> only polling a limit of 64.95 MHz (just 50kHz shy of what's needed for
> the modeline 1024x768 at 60Hz. :( !!).  A further complication- the C&T
> chip uses triple RAMDAC chips so it can deliver 8, 16, and 24 bit color
> at the same rate for all three modes: i.e. at 8-bit, only one chip
> works, at 16bit 2 chips deliver, and at 24bit, all three work.
>
> Alternately, the problem could be due to what linux is probing and the
> fact that the chips driver relies heavily on probing.  I used the $
> SuperProbe command and it found the "Generic 8-bit pseudo-color DAC
> (with 6-bit wide lookup tables (or in 6-bit mode))".  This is a feature
> of C&T 65555 that allows indexed 24-bit color depth in 8-bit mode, but
> might be confusing X:  At >=16bit modes, the memory is accessed directly
> and not from a Lookup Table.
>
> I have no idea whether these methods are unique to C&T, but if anyone
> has already implemented a similar chip please let me know.
>
> JSR
>
> Audin Malmin wrote:
> >
> > On Mon, Apr 16, 2001 at 11:37:43AM -0700, Jesse Rehr wrote:
> > > I suspect that X is trying to load all 4 virtual terminals (or
> > > workspaces, whatever) into the graphics card memory at once.
> >
> >         Multiple desktops are handled by your window manager, they
> > don't really have much to do with the x server itself.  They are not
> > all stored in the frame buffer (though I suppose the server could
> > cache some of the stuff in off-screen memory...)
> >
> > > This is strongly implied since I can also get 800x600x16bit to work
> > > (which multiplies to just under 1 Mb or 1/4 of graphics card
> > > memory).
> >
> >         How much memory does X think your video card has?  This sounds
> > like it doesn't actually believe you have 4 megs.  What does
> >
> >         $ X &>x.out
> >
> >         at the prompt say?  Somewhere in the X startup messages should
> > be a line listing what X thinks the video ram situation is...
> >
> > > (A) Configure X so that it can run 1024x768x24bit and other screens are
> > > kept in extended memory or just somewhere else while not being used.
> >
> >         probably, yes.
> >
> > --
> >                                             Audin Malmin - amalmin at halcyon.com
>
> --
> ********************************************************
> Jesse Rehr                      University of Washington
> jr at u.washington.edu             MBA/MSE Class of 2000
> ********************************************************
>