Re: X problems with CT65555 video hardware

Hi Mike,

The new version of X tries to push the hardware to the highest
combination of resolution, refresh rate and color count. The reason why
it can get away with doing this *some* of the time on newer hardware is
due to newer displays supporting DDC (v1, and/or v2), and thus telling
the driver what is supported by the display. When you start dealing
with older hardware, this new approach of pushing to the max breaks in a
number of ways, including subtle ways like video playback no longer
working but everything else looks good.

My *GUESS* is X is setting a max resolution, refresh rate, and color
depth beyond what your hardware can actually do.

I looked up the specs for your Toshiba 330CDT and it supposedly has a
12.1" diagonal, 800x600 TFT Active Matrix display. Again, it's only a
guess, but the below link containing the quoted text seems to suggest a
native LCD resolution of 800x600. On LCD's, everything above and below
the native resolution will involve scaling in one direction or
another to match the native resolution.

http://www.toshiba.ca/web/product.grp?lg=en&section=1&group=223&product=1608

As you'll see in the details, it will support non-native (to the LCD)
resolutions, with lower resolutions (480x640) at the same 16.7M colors
(24-bit), and higher resolutions (1024x768, and 1280x1024 at reduced
color depth. Unfortunately, the page says nothing about allowed refresh
rates, but often they state resolution/depth at 60Hz.

You can use gtf(1) to generate fixed modes for inclusion in your
xorg.conf file, and thereby force the driver to play nice with your
display.

# gtf 800 600 60

  # 800x600 @ 60.00 Hz (GTF) hsync: 37.32 kHz; pclk: 38.22 MHz
  Modeline "800x600_60.00"  38.22  800 832 912 1024  600 601 604 622
-HSync +Vsync


Sorry about the line wrapping. It's all one line.
You'll put *your* output (not mine above) into the "Modes" section of
your xorg.conf file.

---------------------------------------------------
Section "Modes"
	Identifier "ModeSet"
  # 800x600 @ 60.00 Hz (GTF) hsync: 37.32 kHz; pclk: 38.22 MHz
  Modeline "800x600_60.00"  38.22  800 832 912 1024  600 601 604 622
-HSync +Vsync
EndSection

Section "Monitor"
	...
        UseModes        "ModeSet"
	...
EndSection

Section "Screen"
	...
	SubSection "Display"
		Depth 24
		Modes "800x600_60.00"
	EndSubsection
	...
EndSection

---------------------------------------------------

Also be sure to use the VideoRAM option in the "device" section as you
mentioned below. 

The above will constrain the resolution, refresh and depth to something
we know that your hardware/display will probably support. --The only
question left is if my guess on the refresh rate of 60Hz was correct,
so you might need to experiment a bit.

If you want to run a higher resolution at a lower color depth, just
feed the values into gtf(1) as they are noted on the link above. You
can just add the resulting modelines to your xorg.conf file, and adjust
the "screen" section with the proper color depth.

In the best of all possible worlds, X should just work, and without an
xorg.conf file, but until we get there, the above might solve your
problems.

Kind Regards,
Jon


On Sat, 11 Jul 2009 15:43:28 -0500 beasley <[email protected]> wrote:

> I'm testing a 4.6 snapshot dated 07/09/2009 on my
> old Toshiba laptop that has a Chips and Technologies
> CT65555 video subsystem.
> 
> Running X -configure creates an xorg.conf.new file that
> calls for the correct driver ("chips"), but the result
> of using this file in X -config /root/xorg.conf/new
> is not usable video. I had thought that experimenting
> with the contents of xorg.conf.new would eventually
> lead to a solution, but so far I've been unsuccessful.
> 
> When I look at the log file the first problem I find
> is the driver thinks there's only 256K of video ram:
> 
> (--) CHIPS(0): VideoRAM: 256 kByte
> 
> It should have found 2048K. I added a "VideoRam 2048"
> line to the the config file to override the probed
> value and that results in different but still quite
> useless video.
> 
> I'm guessing that some other people (at least a few)
> are testing the chips driver with 4.6 successfully
> elsewhere, and so this problem could be unique to my
> old Toshiba 330CDT laptop. Perhaps I have a buggy
> bios. I do not think I have defective hardware as
> X/chips still works fine with OpenBSD 4.4 installed.
> 
> Comparing the dmesg outputs from 4.4 and 4.6 shows
> only one significantly different section:
> 
> 4.4-release dmesg output contains these lines:
> 
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "Toshiba PCI" rev 0xa0
> vga1 at pci0 dev 4 function 0 "Chips and Technologies 65555" rev 0xc6
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> drm at vga1 unsupported
> 
> 4.6-current (07/09/2009) dmesg contains these lines:
> 
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Toshiba PCI" rev 0xa0
> vga1 at pci0 dev 4 function 0 "Chips and Technologies 65555" rev 0xc6
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> 
> 
> I also captured and compared the outputs from pcidump
> under both 4.4 and 4.6 by doing fresh installs and
> running "pcidump", "pcidump -v", "pcidump -x", and
> "pcidump -xx".
> 
> Running pcidump from 4.6 (07/09/2009) yields:
> 
> Domain /dev/pci0:
>  0:0:0: Toshiba PCI
>  0:4:0: Chips and Technologies 65555
>  0:11:0: NEC USB
>  0:17:0: Toshiba Fast Infrared Type O
> 
> There's no significant difference between the outputs
> with -v and -x options, but -xx produces a difference
> only in the first section. (I don't know if this is
> significant or not.)
> 
> 4.4-release pcidump -xx 0:0:0 output is shown below:
> 
> 0:0:0: Toshiba PCI
> 	0x0000: 06011179 22800006 060000a0 00000008
> 	0x0010: 00000000 00000000 00000000 00000000
> 	0x0020: 00000000 00000000 00000000 00011179
> 	0x0030: 00000000 00000000 00000000 00000000
> 	0x0040: 00001500 000002bf dfc41819 00000003
> 	0x0050: 00000018 00000000 fd000007 fdf00000
> 	0x0060: 00000000 00000000 001a01f0 00000000
> 	0x0070: 00000000 00000000 00000000 00000000
> 	0x0080: 0ffc0133 00000000 0d480000 00000003
> 	0x0090: 000248ff 0000000b 00000000 00000000
> 	0x00a0: 0000001a 000000c2 0000001f 4000ffff
> 	0x00b0: 00000000 00000000 00000000 00000000
> 	0x00c0: 00000000 00000000 00000026 00000018
> 	0x00d0: 00000000 0cf40000 00006a9c 00000000
> 	0x00e0: 00000000 00000000 00000000 00000000
> 	0x00f0: 00000000 00000000 00000000 00000008
> 
> 4.6-current (07/09/2009) pcidump -xx 0:0:0 output is:
> 
> Domain /dev/pci:
>  0:0:0: Toshiba PCI
> 	0x0000: 06011179 22800006 060000a0 00000008
> 	0x0010: 00000000 00000000 00000000 00000000
> 	0x0020: 00000000 00000000 00000000 00011179
> 	0x0030: 00000000 00000000 00000000 00000000
> 	0x0040: 00001500 000002bf dfc41819 00000003
> 	0x0050: 00000018 00000000 fd000007 fdf00000
> 	0x0060: 00000000 00000000 001a01f0 00000000
> 	0x0070: 00000000 00000000 00000000 00000000
> 	0x0080: 0ffc0133 00000000 0d040000 00000003
> 	0x0090: 000248ff 0000000b 00000000 00000000
> 	0x00a0: 0000001a 000000c2 0000001f 4000ffff
> 	0x00b0: 00000000 00000000 00000000 00000000
> 	0x00c0: 00000000 00000000 00000026 00000018
> 	0x00d0: 00000000 1eec0000 000023a4 00000000
> 	0x00e0: 00000000 00000000 00000000 00000000
> 	0x00f0: 00000000 00000000 00000000 00000008
> 
> diff -w between these two output files yields:
> 
> 0a1
> > Domain /dev/pci:
> 10c11
> < 	0x0080: 0ffc0133 00000000 0d480000 00000003
> ---
> > 	0x0080: 0ffc0133 00000000 0d040000 00000003
> 15c16
> < 	0x00d0: 00000000 0cf40000 00006a9c 00000000
> ---
> > 	0x00d0: 00000000 1eec0000 000023a4 00000000
> 
> 
> So here is my question. Is is possible that my X
> troubles are related to the above differences in
> the way PCI space looks between the 4.4 and 4.6?
> 
> Thanks for any thoughts on this.
> 
> Mike Beasley
> 


-- 
J.C. Roberts