Re: 16bpp @ 1024x768 with ct65554?
Hi.
In <[🔎] 3A0C2D4B.C1705D08@hecke.dartmouth.edu>,
on Fri, 10 Nov 2000 12:15:55 -0500,
on Re: 16bpp @ 1024x768 with ct65554?,
"Thomas R. Shemanske" <trs@hecke.dartmouth.edu> wrote:
> I am only trying to drive the LCD so the hsync and vrefresh can be
> arbitrary as far as I know, although they were 30-70 (H) and 50-100(V)
> in the 8 bit run.
As far as I've heard, most of built-in (not analog-connected-external)
LCDs has fixed hsync and vrefresh setting. And the driver code in
X server uses these setting as the limit of clock timings.
So you should be careful to choose the correct setting.
> I have tried UseModeline option. In 8bit, it gives me a warm pale blue
> (striped) screen and in 16bpp it gives a black vertical band along the
> left side of the screen (about 15% wide), and the rest white (with one
> or more vertical lines)
Without UseModeline, C&T driver just use the dotclock setting in modeline
as the base information, and calculates other settings by that.
With UseModeline option, all the information in modelines are used.
So if you have problem with UseModeline option, then the information
in modeline other than dotclock is not the correct setting.
The result that you descrived above implies that in 8bit the used
modeline is completely out of range, and in 16bit the used modeline
is not correct horizontal timings but vertical timings maybe not so
bad.
So the log in 8bit
(**) CHIPS(0): Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz
shows this is not correct setting, but the log in 16bit
shows this is closer to right setting.
In this case, you should tune just the dotclock setting and hsync/vrefresh
in your XF86Config-4 file without UseModeline option.
> I have enclosed (below) my XF86Config-4 file and the XFree86.0.log from
> a 16bpp run. I tried to use the data above to build a modeline, but
> obviously I am not doing something right.
Checked.
> Section "Device"
> Identifier "Generic Graphics Device"
> Driver "chips"
> # Option "XaaNoCPUToScreenColorExpandFill"
> # Option "NoAccel"
> # Option "FPClock16" "75 MHz"
> # Option "SetMClk" "55 MHz"
> Option "NoStretch"
> # Option "LcdCenter"
> EndSection
You can read available options for chips driver in V4 Xserver
at </usr/share/doc/xserver-xfree86/chips.4.html>
Option SetMClk is removed, and new options FPClock8, FPClock16,
FPClock24, and FPClock32 are added. Maybe you can use these
to order a specific Video Clock speed. When you enable the
FPClock16 option, are there any difference in the X log ?
How it goes with "FPClock16" "77.1" option ?
Maybe the second "1024x768@16bpp" modeline is not deleted ?
> HorizSync 30-70
> VertRefresh 50-120
>
> ModeLine "1024x768@16bpp" 94.5 1024 1072 1168 1376 768 769 772 808
> ModeLine "1024x768@16bpp" 73.78 1024 1072 1168 1376 768 769 772 808
> (--) CHIPS(0): Dot clock 0: 25.172 MHz
> (--) CHIPS(0): Dot clock 1: 28.325 MHz CRTclk
> (--) CHIPS(0): Dot clock 2: 65.082 MHz FPclk
> (--) CHIPS(0): Probed memory clock of 40.090 MHz
> (==) CHIPS(0): Min pixel clock is 11.000 MHz
> (--) CHIPS(0): Max pixel clock is 56.125 MHz
> (II) CHIPS(0): FP clock set to 50.512 MHz
This shows "Max pixel clock is 56.125 MHz", and it is much less
than the specified setting in both of modelines above (94.5 and
73.78) so these lines are removed.
> (II) CHIPS(0): Generic Monitor: Using hsync range of 30.00-70.00 kHz
> (II) CHIPS(0): Generic Monitor: Using vrefresh range of 50.00-120.00 Hz
> (II) CHIPS(0): Clock range: 11.00 to 56.12 MHz
> (WW) CHIPS(0): Mode "1024x768@16bpp" deleted (bad mode
> clock/interlace/doublescan)
> (WW) CHIPS(0): Mode "1024x768@16bpp" deleted (bad mode
> clock/interlace/doublescan)
> (--) CHIPS(0): Virtual size is 800x600 (pitch 800)
> (**) CHIPS(0): Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz
49.5MHz is within a range of 56.125, so this mode is enabled.
You should find a setting to use 1024x600 under the limit of 56.125MHz
or use new option FPClock16 to extend the maxpixelclock (But it can
burn your video circuit, at lease I've told so).
Maybe you can try:
ModeLine "1024x768@16bpp" 55.6 1024 1072 1168 1376 768 769 772 808
I'm not sure if this works or not. But this modeline will not be
deleted in X log. Perhaps you have to lower the vertrefresh limit
to 40 or so to enable this modeline...
BTW, You wrote that in 8bpp without UseModeline:
(--) CHIPS(0): Dot clock 0: 25.172 MHz
(--) CHIPS(0): Dot clock 1: 28.325 MHz CRTclk
(--) CHIPS(0): Dot clock 2: 65.082 MHz FPclk
(--) CHIPS(0): Probed memory clock of 40.090 MHz
(==) CHIPS(0): Min pixel clock is 11.000 MHz
(--) CHIPS(0): Max pixel clock is 95.000 MHz
(--) CHIPS(0): Virtual size is 1024x768 (pitch 1024)
(**) CHIPS(0): Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz
(**) CHIPS(0): Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz
(II) CHIPS(0): Generic Monitor: Using hsync range of 30.00-70.00 kHz
(II) CHIPS(0): Generic Monitor: Using vrefresh range of 50.00-100.00 Hz
(II) CHIPS(0): Clock range: 11.00 to 95.00 MHz
GetModeLine - hdsp: 1024 hbeg: 1072 hend: 1168 httl: 1376
vdsp: 768 vbeg: 769 vend: 772 vttl: 808 flags: 5
So this modeline "1024 1072 1168 1376 768 769 772 808" can be used
for base calculation, I think.
Regards.
--
Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>
Reply to: