From jr@u.washington.edu Tue Apr 17 11:30:31 2001 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.11.2+UW01.01/8.11.2+UW01.03) with ESMTP id f3HIUS9113006 for ; Tue, 17 Apr 2001 11:30:28 -0700 Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mxu4.u.washington.edu (8.11.2+UW01.01/8.11.2+UW01.03) with ESMTP id f3HIUR720877 for ; Tue, 17 Apr 2001 11:30:27 -0700 Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.11.2+UW01.01/8.11.2+UW01.04) with ESMTP id f3HIURo07342 for ; Tue, 17 Apr 2001 11:30:27 -0700 Received: from u.washington.edu (cs331-8.spmodem.washington.edu [140.142.167.9]) by mailhost2.u.washington.edu (8.11.2+UW01.01/8.11.2+UW01.04) with ESMTP id f3HIUQ130026 for ; Tue, 17 Apr 2001 11:30:26 -0700 Message-ID: <3ADC89CA.4765E166@u.washington.edu> Date: Tue, 17 Apr 2001 11:22:02 -0700 From: Jesse Rehr X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: linux@u.washington.edu Subject: Re: Color-depth in X-windows, want >8-bit References: <3ADB3BF7.2AC859E6@u.washington.edu> <20010416140216.A14213@skaro.skaro.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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@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@halcyon.com -- ******************************************************** Jesse Rehr University of Washington jr@u.washington.edu MBA/MSE Class of 2000 ******************************************************** .