








                  Information for Chips and Technologies Users

                   David Bateman (dbateman@eng.uts.edu.au),
                    Egbert Eich (Egbert.Eich@Physik.TH-Darmstadt.DE)

                                 5th June 1998



1.  Introduction

The Chips and Technologies range of chips are primarily manufactured for use in
laptop computers, where their power conservation circuitry is of importance.
They can however be found in a few "Green" video cards for desktop machines.
This release of XFree86 includes support for

   o Linear Addressing

   o 16/24/32 bits per pixel

   o Fully programmable clocks are supported

   o H/W cursor support

   o BitBLT acceleration of many operations using XAA

Most of the Chips and Technologies chipsets are supported by this driver to
some degree.


2.  Supported Chips

      ct65520
            (Max Ram: 1Mb, Max Dclk: 68MHz@5V)

      ct65525
            This chip is basically identical to the 65530. It has the same ID
            and is identified as a 65530 when probed. See ct65530 for details.

      ct65530
            This is a very similar chip to the 65520. However it additionally
            has the ability for mixed 5V and 3.3V operation and linear address-
            ing of the video memory.  (Max Ram: 1Mb, Max Dclk: 56MHz@3.3V,
            68MHz@5V)

      ct65535
            This is the first chip of the ct655xx series to support fully pro-
            grammable clocks. Otherwise it has the the same properties as the
            65530.

      ct65540
            This is the first version of the of the ct655xx that was capable of


 Information for Chips and Technologies Users                                 1





 Information for Chips and Technologies Users                                 2



            supporting Hi-Color and True-Color. It also includes a fully pro-
            grammable dot clock and supports all types of flat panels.  (Max
            Ram: 1Mb, Max Dclk: 56MHz@3.3V, 68MHz@5V)

      ct65545
            The chip is very similar to the 65540, with the addition of H/W
            cursor, pop-menu acceleration, BitBLT and support of PCI Buses.
            PCI version also allow all the BitBLT and H/W cursor registers to
            be memory mapped 2Mb above the Base Address.  (Max Ram: 1Mb, Max
            Dclk: 56MHz@3.3V,68MHz@5V)

      ct65546
            This chip is specially manufactured for Toshiba, and so documenta-
            tion is not widely available. It is believed that this is really
            just a 65545 with a higher maximum dot-clock of 80MHz.  (Max Ram:
            1Mb?, Max Dclk: 80MHz?)

      ct65548
            This chip is similar to the 65545, but it also includes XRAM sup-
            port and supports the higher dot clocks of the 65546.  (Max Ram:
            1Mb, Max Dclk: 80MHz)

      ct65550
            This chip started a completely new architecture to previous ct655xx
            chips. It includes many new features, including improved BitBLT
            support (24bpp color expansion, wider maximum pitch, etc), Multime-
            dia unit (video capture, zoom video port, etc) and 24bpp uncom-
            pressed true color (i.e 32bpp mode). Also memory mapped I/O is pos-
            sible on all bus configurations.  (Max Ram: 2Mb, Max Dclk:
            80MHz@3.3V,100MHz@5V)

            ( Note: At least one non-PCI bus system with a ct65550 requires the
            "-no_bios" option for the SuperProbe to correctly detect the
            chipset with the factory default BIOS settings. The XF86_SVGA
            server can correctly detect the chip in the same situation. )

      ct65554
            This chip is similar to the 65550 but has a 64bit memory bus as
            opposed to a 32bit bus. It also has higher limits on the maximum
            memory and pixel clocks (Max Ram: 4Mb, Max Dclk: 100MHz@3.3V)

      ct65555
            Similar to the 65554 but has yet higher maximum memory and pixel
            clocks. It also includes a new DSTN dithering scheme that improves
            the performance of DSTN screens.  (Max Ram: 4Mb, Max Dclk:
            110MHz@3.3V)

      ct68554
            Similar to the 65555 but also incorporates "PanelLink" drivers.
            This serial link allows an LCD screens to be located up to 100m
            from the video processor. Expect to see this chip soon in LCD desk-
            top machines (Max Ram: 4Mb, Max Dclk: 110MHz@3.3V)










 Information for Chips and Technologies Users                                 3



      ct69000
            Similar to the 65555 but incorporates 2Mbytes of SGRAM on chip. It
            is the first Chips and Technologies chipset where all of the regis-
            ters are accessible through MMIO, rather than just the BitBlt reg-
            isters.  (Max Ram: 2Mb Only, Max Dclk: 220MHz@3.3V)

      ct64200
            This chip, also known as the WinGine, is used in video cards for
            desktop systems. It often uses external DAC's and programmable
            clock chips to supply additional functionally. None of these are
            currently supported within the driver itself, so many cards will
            only have limited support. Linear addressing is not supported for
            this card in the driver.  (Max Ram: 2Mb, Max Dclk: 80MHz)

      ct64300
            This is a more advanced version of the WinGine chip, with specifi-
            cation very similar to the 6554x series of chips. However there are
            many difference at a register level. A similar level of accelera-
            tion to the 65545 is included for this driver.  (Max Ram: 2Mb, Max
            Dclk: 80MHz)


3.  XF86Config Options

The following options are of particular interest to the Chips and Technologies
driver.  Each of them must be specified in the `svga' driver section of the
XF86Config file, within the Screen subsections of the depths to which they are
applicable (you can enable options for all depths by specifying them in the
Device section).

      Option "noaccel"
            This option will disable the use of any accelerated functions.
            This is likely to help with some problems related to DRAM timing,
            high dot clocks, and bugs in accelerated functions, at the cost of
            performance (which will still be reasonable on VLB/PCI).

      Option "no_bitblt" (Chips 65545 and later)
            This option will disable the use of the BitBLT engine which the
            65545 and above have. If you can use the  "noaccel" option to cor-
            rect a problem, then this option might be better to use.  It still
            allows the use of generic speedups.

      Option "xaa_no_color_exp" (Chips 65545 and later)
            This option will have the effect of disabling the use of monochrome
            colour expansion. In particular this effects text and bitmaps. It
            is useful for problems related to image writes, and possible accel-
            eration problems. In general this will result in a reduced perfor-
            mance. Note that this option replaces the "no_imageblt" option used
            in XFree86 3.2.

      Option "xaa_benchmark" (Chips 65545 and later)
            Turns on the XAA acceleration benchmarks. Information regarding
            what graphics primitives are accelerated and their relatives speeds
            will be printed when the X server starts.








 Information for Chips and Technologies Users                                 4



      videoram 1024 (or another value)
            This option will override the detected amount of video memory, and
            pretend the given amount of memory is present on the card.  Note
            that many ct655xx chips only allow up to 1Mb of videoram, and the
            amount should be correctly detected.

      Option "nolinear" (Chips 65530 and later)
            By default linear addressing is used on all ct655xx chips.  However
            this might be broken in some implementations. It is possible to
            turn the linear addressing off with this option. Note that H/W
            acceleration and 16/24/32bpp are only supported with linear
            addressing.

      MemBase 0x03b00000 (or a different address)
            This sets the physical memory base address of the linear frame-
            buffer. Typically this is probed correctly, but if you believe it
            to be mis-probed, this option might help.  Also for non PCI
            machines specifying this force the linear base address to be this
            value, reprogramming the video processor to suit. Note that for the
            65530 this is required as the base address can't be correctly
            probed.

      Option "hw_cursor" (Chips 65545 and later)
            This option enables the use of a hardware accelerated cursor. This
            effectively speeds all graphics operations as the job of ensuring
            that the cursor remains on top is now given to the hardware. It
            also reduces the effect of cursor flashing during graphics opera-
            tions.

      Option "sw_cursor" (Chips 65545 and later)
            Software cursors have now been made the default and so this option
            has no effect.

      Option "STN"
            The server is unable to differentiate between SS STN and TFT dis-
            plays. This forces it to identify the display as a SS STN rather
            than a TFT.

      Option "use_modeline"
            The flat panel timings are related to the panel size and not the
            size of the mode specified in XF86Config. For this reason the
            default behaviour of the server is to use the panel timings already
            installed in the chip. The user can force the panel timings to be
            recalculated from the modeline with this option. However the panel
            size will still be probed.

      Option "fix_panel_size"
            For some machines the LCD panel size is incorrectly probed from the
            registers. This option forces the LCD panel size to be overridden
            by the modeline display sizes. This will prevent the use of a mode
            that is a different size than the panel. Before using this check
            that the server reports an incorrect panel size. This option can be
            used in conjunction with the option "use_modeline" to program all
            the panel timings using the modeline values.








 Information for Chips and Technologies Users                                 5



      Option "no_stretch"
            When the size of the mode used is less than the panel size, the
            default behaviour of the server is to stretch the mode in an
            attempt to fill the screen. A "letterbox" effect with no stretching
            can be achieved using this option.

      Option "lcd_center"
            When the size of the mode used is less than the panel size, the
            default behaviour of the server is to align the left hand edge of
            the display with the left hand edge of the screen. Using this
            option the mode can be centered in the screen. This option is
            reported to have problems with some machines at 16/24/32bpp, the
            effect of which is that the right-hand edge of the mode will be
            pushed off the screen.

      Option "hw_clocks" (Chips 65535 and later)
            On chips 65535 and later, the default is to use the programmable
            clock for all clocks. It is possible to use the fixed clocks sup-
            ported by the chip instead by using this option. Typically this
            will give you some or all of the clocks 25.175, 28.322, 31.000 and
            36.000MHz. The current programmable clock will be given as the last
            clock in the list. On a cold-booted system this might be the appro-
            priate value to use at the text console (see the "TextClockFreq"
            option), as many flat panels will need a dot clock different than
            the default to synchronise. The programmable clock makes this
            option obsolete and so it's use isn't recommended.

      Option "use_vclk1" (Chips 65550 and later)
            The HiQV series of chips have three programmable clocks. The first
            two are usually loaded with 25.175 and 28.322MHz for VGA backward
            compatibility, and the third is used as a fully programmable clock.
            On at least one system (the Inside 686 LCD/S single board computer)
            the third clock is unusable. This option forces the use of VClk1 as
            the programmable clock. It has been reported that this option can
            fix the blue/black screen problem on startup that a few machines
            suffer.

      TextClockFreq 25.175
            It is impossible for the server to read the value of the currently
            used frequency for the text console from the chip with the ct6554x
            series of chips. Therefore the server uses a default value of
            25.175MHz as the text console clock. For some LCDs, in particular
            DSTN screens, this clock will be wrong. This allows the user to
            select a different clock for the server to use when returning to
            the text console.

      Option "mmio"
            This enables the use of memory-mapped I/O to talk to the BitBLT
            engine. By default memory-mapped I/O is not enabled on the 6554x
            series of chips, and is only usable on 6554x's with PCI buses. This
            option has no effect when not using the BitBLT engine (e.g. when
            using "no_bitblt"), or for the 65550 which can only use MMIO for
            access to the BitBLT engine. On 65545 PCI machines MMIO is enabled
            by default because the blitter can not be used otherwise.








 Information for Chips and Technologies Users                                 6



      Option "suspend_hack"
            This option sets the centering and stretching to the bios default
            values. This can fix suspend/resume problems on some machines. It
            overrides the options "lcd_center" and "no_stretch".

      Option "use_18bit_bus"  (Chips 65540/45/46/48)
            For 24bpp on TFT screens, the server assumes that a 24bit bus is
            being used. This can result in a reddish tint to 24bpp mode.  This
            option, selects an 18 bit TFT bus. For other depths this option has
            no effect.

      Chipset "ct65546" (or some other chip)
            It is possible that the chip could be misidentified, particular due
            to interactions with other drivers in the server. It is possible to
            force the server to identify a particular chip with this option.

      Option "sync_on_green" (Chips 65550/54/55 and 68554)
            Composite sync on green. Possibly useful if you wish to use an old
            workstation monitor. The 65550/54 internal RAMDAC's support this
            mode of operation, but whether a particular machine does depends on
            the manufacturer.

      Option "fast_dram" (Chips 65550/54/55 and 68554)
            This option sets the internal memory clock (MCLK) registers to
            38MHz.  The default value programmed by the BIOS is usually OK, but
            some machines can accept a faster MClk to achieve a better perfor-
            mance.  One machine known to work well with this option is the
            Toshiba 720CDT.  Note that newer machines often have an MClk
            greater than 38MHz, and so this option might actually slower the
            machine down. This option is generally not recommended and is
            superseded by the "Set_MemClk" option.

      DacSpeed 80.000
            The server will limit the maximum dotclock to a value as specified
            by the manufacturer. This might make certain modes impossible to
            obtain with a reasonable refresh rate. Using this option the user
            can override the maximum dot-clock and specify any value they pre-
            fer. Use caution with this option, as driving the video processor
            beyond its specifications might cause damage.

      Set_MemClk 38.000 (Chips 65550/54/55 and 68554)
            This option sets the internal memory clock (MCLK) registers to
            38MHz or some other value. Use caution as excess heat generated by
            the video processor if its specifications are exceeded might cause
            damage. However careful use of this option might boost performance.


4.  Modelines

When constructing a modeline for use with the Chips and Technologies driver
you'll needed to considered several points

      * Virtual Screen Size
            It is the virtual screen size that determines the amount of memory








 Information for Chips and Technologies Users                                 7



            used by a mode. So if you have a virtual screen size set to
            1024x768 using a 800x600 at 8bpp, you use 768kB for the mode. Fur-
            ther to this some of the XAA acceleration requires that the display
            pitch is a multiple of 64 pixels. So the driver will attempt to
            round-up the virtual X dimension to a multiple of 64, but leave the
            virtual resolution untouched. This might further reduce the avail-
            able memory.

      * 16/24/32 Bits Per Pixel
            Chips later than the ct65540 are capable of supporting Hi-Color and
            True-Color modes. These are implemented in the current server. The
            clocks in the 6554x series of chips are internally divided by 2 for
            16bpp and 3 for 24bpp, allowing one modeline to be used at all
            depths.  The effect of this is that the maximum dot clock visible
            to the user is a half or a third of the value at 8bpp. The 6555x
            series of chips doesn't need to use additional clock cycles to dis-
            play higher depths, and so the same modeline can be used at all
            depths, without needing to divide the clocks.  Also 16/24/32 bpp
            modes will need 2 , 3 or 4 times respectively more video ram.

      * Frame Acceleration
            Many DSTN screens use frame acceleration to improve the performance
            of the screen. This can be done by using an external frame buffer,
            or incorporating the framebuffer at the top of video ram depending
            on the particular implementation. The Xserver assumes that the
            framebuffer, if used, will be at the top of video ram.  The amount
            of ram required for the framebuffer will vary depending on the size
            of the screen, and will reduce the amount of video ram available to
            the modes. Typical values for the size of the framebuffer will be
            61440 bytes (640x480 panel), 96000 bytes (800x600 panel) and 157287
            bytes (1024x768 panel).

      * H/W Acceleration
            The H/W cursor will need 1kB for the 6554x and 4kb for the 65550.
            On the 64300 chips the H/W cursors is stored in registers and so no
            allowance is needed for the H/W cursor. In addition to this many
            graphics operations are speeded up using a "pixmap cache". Leaving
            too little memory available for the cache will only have a detri-
            mental effect on the graphics performance.

      * VESA like modes
            We recommend that you try and pick a mode that is similar to a
            standard VESA mode. If you don't a suspend/resume or LCD/CRT switch
            might mess up the screen. This is a problem with the video BIOS not
            knowing about all the funny modes that might be selected.

      * Dot Clock
            For LCD screens, the lowest clock that gives acceptable contrast
            and flicker is usually the best one. This also gives more memory
            bandwidth for use in the drawing operations. Some users prefer to
            use clocks that are defined by their BIOS. This has the advantage
            that the BIOS will probably restore the clock they specified after
            a suspend/resume or LCD/CRT switch. For a complete discussion on
            the dot clock limitations, see the next section.








 Information for Chips and Technologies Users                                 8



The driver is capable of driving both a CRT and a flat panel display. In fact
the timing for the flat panel are dependent on the specification of the panel
itself and are independent of the particular mode chosen. For this reason it is
recommended to use one of the programs that automatically generate XF86Config
files, such as "xf86config" or "XF86Setup".

However there are many machines, particular those with 800x600 screen or
larger, that need to reprogram the panel timings. The reason for this is that
the manufacturer has used the panel timings to get a standard EGA mode to work
on flat panel, and these same timings don't work for an SVGA mode. For these
machines the "use_modeline" and/or possibly the "fix_panel_size" option might
be needed. Some machines that are known to need these options include.


          Modeline "640x480@8bpp"    25.175  640  672  728  816   480  489  501  526
          Modeline "640x480@16bpp"  25.175  640  672  728  816   480  489  501  526
          Options: "use_modeline"
          Tested on a Prostar 8200, (640x480, 65548, 1Mbyte)



          Modeline "800x600@8bpp"    28.322  800  808  848  936   600  600  604  628
          Options: "fix_panel_size", "use_modeline"
          Tested on a HP OmniBook 5000CTS (800x600 TFT, 65548, 1Mbyte)



          Modeline "800x600@8bpp"    30.150  800  896  960 1056   600  600  604  628
          Options: "fix_panel_size", "use_modeline"
          Test on a Zeos Meridan 850c (800x600 DSTN, 65545, 1Mbyte)


The NEC Versa 4080 just needs the "fix_panel_size" option.


5.  The Full Story on Clock Limitations

There has been much confusion about exactly what the clock limitations of the
Chips and Technologies chipsets are. Hence I hope that this section will clear
up the misunderstandings.

In general there are two factors determining the maximum dotclock.  There is
the limit of the maximum dotclock the video processor can handle, and there is
another limitation of the available memory bandwidth. The memory bandwidth is
determined by the clock used for the video memory.  For chipsets incapable of
colour depths greater that 8bpp like the 65535, the dotclock limit is solely
determined by the highest dotclock the video processor is capable of handling.
So this limit will be either 56MHz or 68MHz for the 655xx chipsets, depending
on what voltage they are driven with, or 80MHz for the 64200 WinGine machines.

The 6554x and 64300 WinGine chipsets are capable of colour depths of 16 or
24bpp. However there is no reliable way of probing the memory clock used in
these chipsets, and so a conservative limit must be taken for the dotclock
limit. In this case the driver divides the video processors dotclock limitation








 Information for Chips and Technologies Users                                 9



by the number of bytes per pixel, so that the limitations for the various
colour depths are

                             8bpp    16bpp   24bpp
     64300                   85      42.5    28.33
     65540/65545 3.3v        56      28      18.67
     65540/65545 5v          68      34      22.67
     65546/65548             80      40      26.67

For a CRT or TFT screen these limitations are conservative and the user might
safely override them with the "DacSpeed" option to some extent. However these
numbers take no account of the extra bandwidth needed for DSTN screens.

For the HiQV series of chips, the memory clock can be successfully probed.
Hence you will see a line like

     (--) SVGA: CHIPS: probed memory clock of 40090 KHz

in your startx log file. Note that many chips are capable of higher memory
clocks than actually set by BIOS. You can use the Set_MClk option in your
XF86Config file to get a higher MClk. However some video ram, particularly EDO,
might not be fast enough to handle this, resulting in drawing errors on the
screen. The formula to determine the maximum usable dotclock on the HiQV series
of chips is

     Max Dotclock = min(MaxDClk,  0.70  * 4 * MemoryClk / (BytesPerPixel +
                     (isDSTN == TRUE ? 1 : 0)))

which says that there are two limits on the dotclock. One the overall maximum,
and another due to the available memory bandwidth of the chip.  For the memory
bandwidth 4 bytes are transfered every clock cycle (Hence the 4), but after
accounting for the RAS/CAS signaling only about 70% of the bandwidth is avail-
able. The whole thing is divided by the bytes per pixel, plus an extra byte if
you are using a DSTN. The extra byte with DSTN screens is used for the frame
buffering/acceleration in these screens. So for the various Chips and Technolo-
gies chips the maximum specifications are

                         Max DClk MHz      Max Mem Clk MHz
     65550 rev A 3.3v          80                38
     65550 rev A 5v           110                38
     65550 rev B               95                50
     65554                     94.5              55
     65555                    110                55
     68554                    110                55
     69000                    220               100

Note that all of the chips except the 65550 rev A are 3.3v only. Which is the
reason for the drop in the dot clock. Now the maximum memory clock is just the
maximum supported by the video processor, not the maximum supported by the
video memory. So the value actually used for the memory clock might be signifi-
cantly less than this maximum value. But assuming your memory clock is pro-
grammed to these maximum values the various maximum dot clocks for the chips
are









 Information for Chips and Technologies Users                                10



                             ------CRT/TFT-------    --------DSTN--------
                             8bpp    16bpp   24bpp   8bpp    16bpp   24bpp
     65550 rev A 3.3v        80      53.2    35.47   53.2    35.47   26.6
     65550 rev A 5v          106.2   53.2    35.47   53.2    35.47   26.6
     65550 rev B             95      70      46.67   70      46.67   35.0
     65554                   94.5    77      51.33   77      51.33   38.5
     65555                   110     77      51.33   77      51.33   38.5
     68554                   110     77      51.33   77      51.33   38.5
     69000                   220    140      93.33  140      93.33   70.0

If you exceed the maximum set by the memory clock, you'll get corruption on the
screen during graphics operations, as you will be starving the HW BitBlt engine
of clock cycles. If you are driving the video memory too fast (too high a Mem-
Clk) you'll get pixel corruption as the data actually written to the video mem-
ory is corrupted by driving the memory too fast. You can probably get away with
exceeding the Max DClk at 8bpp on TFT's or CRT's by up to 10% or so without
problems, it will just generate more heat, since the 8bpp clocks aren't limited
by the available memory bandwidth.

If you find you truly can't achieve the mode you are after with the default
clock limitations, look at the options "DacSpeed" and "Set_MemClk". Using these
should give you all the capabilities you'll need in the server to get a partic-
ular mode to work. However use caution with these options, because there is no
guarantee that driving the video processor beyond it capabilities won't cause
damage.


6.  Troubleshooting

      The cursor appears as a white box, after switching modes
            There is a known bug in the H/W cursor, that sometimes causes the
            cursor to be redrawn as a white box, when the mode is changed.
            This can be fixed by moving the cursor to a different region,
            switching to the console and back again, or if it is too annoying
            the H/W cursor can be disabled by removing the "hw_cursor" option.

      The cursor hot-spot isn't at the same point as the cursor
            With modes on the 6555x machines that are stretched to fill the
            flat panel, the H/W cursor is not correspondingly stretched. This
            is a small and long-standing bug in the current server. You can
            avoid this by either using the "no_stretch" option or removing the
            hw_cursor" option.

      The lower part of the screen is corrupted
            Many DSTN screens use the top of video ram to implement a frame
            accelerator. This reduces the amount of video ram available to the
            modes. The server doesn't prevent the user from specifying a mode
            that will use this memory, it prints a warning on the console.  The
            effect of this problem will be that the lower part of the screen
            will reside in the same memory as the frame accelerator and will
            therefore be corrupt. Try reducing the amount of memory consumed by
            the mode.










 Information for Chips and Technologies Users                                11



      There is a video signal, but the screen doesn't sync.
            You are using a mode that your screen cannot handle. If it is a
            non-standard mode, maybe you need to tweak the timings a bit. If it
            is a standard mode and frequency that your screen should be able to
            handle, try to find different timings for a similar mode and fre-
            quency combination. For LCD modes, it is possible that your LCD
            panel requires different panel timings at the text console than
            with a graphics mode. In this case you will need the "use_modeline"
            and perhaps also the "fix_panel_size" options to reprogram the LCD
            panel timings to sensible values.

      `Wavy' screen.
            Horizontal waving or jittering of the whole screen, continuously
            (independent from drawing operations).  You are probably using a
            dot clock that is too high (or too low); it is also possible that
            there is interference with a close MCLK. Try a lower dot clock.
            For CRT's you can also try to tweak the mode timings; try increas-
            ing the second horizontal value somewhat.

      Crash or hang after start-up (probably with a black screen).
            Try the "noaccel" or "no_bitblt" options. Check that the BIOS set-
            tings are OK; in particular, disable caching of 0xa0000-0xaffff.
            Disabling hidden DRAM refresh may also help.

      Hang as the first text is appearing on the screen on SVR4 machines.
            This problem has been reported under UnixWare 1.x, but not tracked
            down. It doesn't occur under UnixWare 2.x and only occurs on the
            HiQV series of chips. It might affect some other SVR4 operating
            systems as well. The workaround is to turn off the use of CPU to
            screen acceleration with the "xaa_no_color_exp" option.

      Crash, hang, or trash on the screen after a graphics operation.
            This may be related to a bug in one of the accelerated functions,
            or a problem with the BitBLT engine. Try the "noaccel" or "no_bit-
            blt" options. Also check the BIOS settings. It is also possible
            that with a high dot clock and depth on a large screen there is
            very little bandwidth left for using the BitBLT engine. Try reduc-
            ing the clock.

      Chipset is not detected.
            Try forcing the chipset to a type that is most similar to what you
            have.

      The screen is blank when starting X
            One possible cause of this problem is if the kernel has been com-
            piled with the "APM_DISPLAY_BLANK" option. It appears that this
            option doesn't work as specified and can cause the Xserver to blank
            when starting X. In all cases the kernel should be compiled without
            this option. If the problem remains a CRT/LCD or switch to and from
            the virtual console will often fix it.

      Textmode is not properly restored
            This has been reported on some configurations. Many laptops use the
            programmable clock of the 6554x chips at the console.  It is not








 Information for Chips and Technologies Users                                12



            always possible to find out the setting that is used for this clock
            if BIOS has written the MClk after the VClk. Hence the server
            assumes a 25.175MHz clock at the console. This is correct for most
            modes, but can cause some problems. Usually this is fixed by
            switching between the LCD and CRT. Alternatively the user can use
            the "TextClockFreq" option described above to select a different
            clock for the text console. Another possible cause of this problem
            is if the kernel is compiled with the "APM_DISPLAY_BLANK" option.
            As mentioned before, this option should be disabled.

      I can't display 640x480 on my 800x600 LCD
            The problem here is that the flat panel needs timings that are
            related to the panel size, and not the mode size. There is no
            facility in the current Xservers to specify these values, and so
            the server attempts to read the panel size from the chip. If the
            user has used the "use_modeline" or "fix_panel_size" options the
            panel timings are derived from the mode, which can be different
            than the panel size. Try deleting theses options  from XF86Config
            or using an LCD/CRT switch.

      I can't get a 320x240 mode to occupy the whole 640x480 LCD
            There is a bug in the 6554x's H/W cursor for modes that are doubled
            vertically. The lower half of the screen is not accessible.  The
            servers solution to this problem is not to do doubling vertically.
            Which results in the 320x240 mode only expanded to 640x360. If this
            is a problem, a work around is to remove the "hw_cursor" option.
            The server will then allow the mode to occupy the whole 640x480
            LCD.

      After a suspend/resume my screen is messed up
            During a suspend/resume, the BIOS controls what is read and written
            back to the registers. If the screen is using a mode that BIOS
            doesn't know about, then there is no guarantee that it will be
            resumed correctly. For this reason a mode that is as close to VESA
            like as possible should be selected. It is also possible that the
            VGA palette can be affected by a suspend/resume.  Using an 8bpp,
            the colour will then be displayed incorrectly. This shouldn't
            affect higher depths, and is fixable with a switch to the virtual
            console and back.

      The right hand edge of the mode isn't visible on the LCD
            This is usually due to a problem with the "lcd-center" option. If
            this option is removed form XF86Config, then the problem might go
            away. Alternatively the manufacturer could have incorrectly pro-
            grammed the panel size in the EGA console mode. The
            "fix_panel_size" can be used to force the modeline values into the
            panel size registers. Two machines that are known to have this
            problem are the "HP OmniBook 5000" and the "NEC  Versa 4080".

      My TFT screen has a reddish tint in 24bpp mode
            The server assumes that the TFT bus width is 24bits. If this is not
            true then the screen will appear to have a reddish tint. This can
            be fixed by using the "use_18bit_bus" option. Note that the reverse
            is also true. If the "use_18bit_bus" is used and the TFT bus width








 Information for Chips and Technologies Users                                13



            is 24bpp, then the screen will appear reddish.  Note that this
            option only has an effect on TFT screens.

      I can't start X-windows with 16, 24 or 32bpp
            Firstly, is your machine capable of 16/24/32bpp with the mode spec-
            ified. Many LCD displays are incapable of using a 24bpp mode. Also
            you need at least a 65540 to use 16/24bpp and at least a 65550 for
            32bpp. The amount of memory used by the mode will be dou-
            bled/tripled/quadrupled. The correct options to start the server
            with these modes are

                        startx -- -bpp 16               5-6-5 RGB ('64K color', XGA)
                        startx -- -bpp 16 -weight 555   5-5-5 RGB ('Hicolor')
                        startx -- -bpp 24               8-8-8 RGB truecolor


            or with the HiQV series of chips (6555x, 68554 or 69000) you might
            try

                        startx -- -bpp 32               8-8-8 RGB truecolor

A general problem with the server that can manifested in many way such as draw-
ing errors, wavy screens, etc is related to the programmable clock. Many poten-
tial programmable clock register setting are unstable.  However luckily there
are many different clock register setting that can give the same or very simi-
lar clocks. The clock code can be fooled into giving a different and perhaps
more stable clock by simply changing the clock value slightly. For example
65.00MHz might be unstable while 65.10MHz is not. So for unexplained problems
not addressed above, please try to alter the clock you are using slightly, say
in steps of 0.05MHz and see if the problem goes away. Alternatively, using the
"use_vclk1" option with chips later than the 65550 might also help.

For other screen drawing related problems, try the "noaccel" or "no_bitblt"
options. A useful trick for all laptop computers is to switch between LCD/CRT
(usually with something like Fn-F5), if the screen is having problems.

If you are having driver-related problems that are not addressed by this docu-
ment, or if you have found bugs in accelerated functions, you can try contact-
ing the XFree86 team (the current driver maintainer can be reached at dbate-
man@eng.uts.edu.au or Egbert.Eich@Physik.TH-Darmstadt.DE), or post in the
Usenet newsgroup "comp.windows.x.i386unix".


7.  Disclaimer

XFree86, allows the user to do damage to their hardware with software.
Although the authors of this software have tried to prevent this, they disclaim
all responsibility for any damage caused by the software. Use caution, if you
think the Xserver is frying your screen, TURN THE COMPUTER OFF!!


8.  Acknowledgement

The authors of this software wish to acknowledge the support supplied by Chips








 Information for Chips and Technologies Users                                14



and Technologies during the development of this software.


9.  Authors

Major Contributors (In no particular order)

   o Nozomi Ytow

   o Egbert Eich

   o David Bateman

   o Xavier Ducoin

Contributors (In no particular order)

   o Ken Raeburn

   o Shigehiro Nomura

   o Marc de Courville

   o Adam Sulmicki

   o Jens Maurer

We also thank the many people on the net who have contributed by reporting bugs
and extensively testing this server before its inclusion in XFree86 3.2

     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/chips.sgml,v 3.12.2.12 1998/11/07 13:52:45 dawes Exp $































 Information for Chips and Technologies Users                                15





































































                                   CONTENTS



1. Introduction  ............................................................ 1

2. Supported Chips  ......................................................... 1

3. XF86Config Options  ...................................................... 3

4. Modelines  ............................................................... 6

5. The Full Story on Clock Limitations  ..................................... 8

6. Troubleshooting  ........................................................ 10

7. Disclaimer  ............................................................. 13

8. Acknowledgement  ........................................................ 13

9. Authors  ................................................................ 14



































                                       i


