X problems with CT65555 video hardware

[beasley-3]

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-3]

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§ion=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 <beasley@...> 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

[beasley-3]

Hello Jon,

Thank you very much for your post. I'm sorry it's
taken me these several days to find time to respond.

As you suggested I created a modeline using gtf.

On my old laptop running "gtf 800 600 60" results in:

  # 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

I copied the contents of "xorg.conf.new" produced by X -configure
into a new file "test.conf" and then edited that file to add the
modeline above and the "VideoRam 2048" line. I also added lines
to try to set default depth.

The test.conf file content after all edits is shown below:


Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
        ModulePath   "/usr/X11R6/lib/modules"
        FontPath     "/usr/X11R6/lib/X11/fonts/misc/"
        FontPath     "/usr/X11R6/lib/X11/fonts/TTF/"
        FontPath     "/usr/X11R6/lib/X11/fonts/OTF"
        FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
        FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
        FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
EndSection

Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "extmod"
        Load  "glx"
        Load  "freetype"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option    "Protocol" "wsmouse"
        Option    "Device" "/dev/wsmouse"
        Option    "ZAxisMapping" "4 5 6 7"
EndSection

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"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        UseModes     "ModeSet"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
        ### [arg]: arg optional
        #Option     "Linear"                    # [<bool>]
        #Option     "NoAccel"                   # [<bool>]
        #Option     "HWclocks"                  # [<bool>]
        #Option     "SWcursor"                  # [<bool>]
        #Option     "HWcursor"                  # [<bool>]
        #Option     "STN"                       # [<bool>]
        #Option     "UseModeline"               # [<bool>]
        #Option     "Stretch"                   # [<bool>]
        #Option     "LcdCenter"                 # [<bool>]
        #Option     "MMIO"                      # [<bool>]
        #Option     "SuspendHack"               # [<bool>]
        #Option     "FixPanelSize"              # [<bool>]
        #Option     "18BitBus"                  # [<bool>]
        #Option     "ShowCache"                 # [<bool>]
        #Option     "ShadowFB"                  # [<bool>]
        #Option     "Rotate"                    # [<str>]
        #Option     "SetMclk"                   # <freq>
        #Option     "FPClock8"                  # <freq>
        #Option     "FPClock16"                 # <freq>
        #Option     "FPClock24"                 # <freq>
        #Option     "FPMode"                    # [<bool>]
        Identifier  "Card0"
        Driver      "chips"
        VendorName  "Chips and Technologies"
        BoardName   "65555"
        BusID       "PCI:0:4:0"
        VideoRam    2048
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        # DefaultDepth   24
        # DefaultDepth   16
        DefaultDepth      8
        SubSection "Display"
                Viewport   0 0
                Depth     8
                Modes     "800x600_60.00"
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     16
                Modes     "800x600_60.00"
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes     "800x600_60.00"
        EndSubSection
EndSection


When I run "X -config /root/test.conf" with this file
I still get bad video. The logfile shows the new mode
line is there and there are no (EE) errors anywhere.

Notice that I have a "DefaultDepth 8" line above, with
the other DefaultDepth lines commented out. At first I
tried DefaultDepth 24. That resulted in the following
error lines in the Xorg.0.log file:

(EE) CHIPS(0): Driver can't support depth 24
...
(EE) Screen(s) found, but none have a usable configuration.

When I tried setting DefaultDepth 16 I got these error lines:

(EE) CHIPS(0): Given depth (16) is not supported by this driver
...
(EE) Screen(s) found, but none have a usable configuration.

So it looks like the driver doesn't think it can handle more
than 8 bits per pixel. It should be able to support both
16 and 24 bit color at 800x600 using the ct65555 video chip.

Here's something else different between the logfile produced
from the file above (with DefaultDepth 8) and my old logfile
from OpenBSD 4.4 where X/chips worked. (I'm always looking
for log differences trying to find some sort of clue.)

Near the end of the logfile from 4.6 & test.conf I see these
lines:
...
(==) CHIPS(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"

(II) Loading /usr/X11R6/lib/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
        compiled for 1.5.3, module version = 1.0.0
        ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Module "ramdac" already built-in
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
        [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
        [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
        [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
        [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [4] 0 0 0x00000200 - 0x000083fc  IX[S]
        [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
        [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(==) CHIPS(0): Backing store disabled
(==) RandR enabled
...

Near the end of the logfile from 4.4 & xorg.conf.new I see these:

...
(==) CHIPS(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/X11R6/lib/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
        compiled for 1.4.2, module version = 1.0.0
        ABI class: X.Org ANSI C Emulation, version 0.3
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/X11R6/lib/modules//libxaa.so
(II) Module xaa: vendor="X.Org Foundation"
        compiled for 1.4.2, module version = 1.2.0
        ABI class: X.Org Video Driver, version 2.0
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"(II) Module "ramdac" already built-in
(--) Depth 24 pixmap format is 32 bpp
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
        [0] 0 0 0xfd000000 - 0xfdffffff (0x1000000) MS[B]
        [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
        [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
        [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
        [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [5] -1 0 0xfcfff000 - 0xfcffffff (0x1000) MX[B]E
        [6] -1 0 0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
        [7] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
        [8] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
        [9] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
        [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
        [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
        [12] -1 0 0x0000ffe0 - 0x0000ffff (0x20) IX[B]E
        [13] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
        [14] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(--) CHIPS(0): 177152 bytes off-screen memory available
(II) CHIPS(0): Using XFree86 Acceleration Architecture (XAA)
        Screen to screen bit blits
        Solid filled rectangles
        Solid Horizontal and Vertical Lines
        Offscreen Pixmaps
        Driver provided WritePixmap replacement
        Setting up tile and stipple cache:
                7 32x54 slots
(==) CHIPS(0): Backing store disabled
(==) RandR enabled
...

I'm not sure what the resource ranges differences are about,
but if the driver doesn't see all the resources it expects
to see couldn't that lead to big trouble?

Anyway I'm beginning to think getting this to work on my
old dinosaur machine might be more than I'm up for. I'm
not a software professional so digging way deep into the
source code is not an option. It could be that sometimes
when X changes to support the newest video hardware some
of the really old video hardware falls off the truck!

In the end I can use OpenBSD 4.4, or maybe another OS :-(

Thank you again Jon for your interest in this problem.

Regards,
Mike Beasley


On Mon, 2009-07-13 at 07:07 -0700, J.C. Roberts wrote:

> 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§ion=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 <beasley@...> 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