








		  Information for Chips and Technologies Users

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

				 28th July 1997



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 XFree includes support for

   o Linear Addressing

   o 16/ 24 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





 Information for Chips and Technologies Users



	    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)

      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)

      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








 Information for Chips and Technologies Users



	    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 XFree 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.

      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/24bpp are only supported with linear








 Information for Chips and Technologies Users



	    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 "sw_cursor" (Chips 65545 and later)
	    This disables use of the hardware cursor provided by the chip.  Try
	    this if the cursor seems to have problems.

      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.

      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/24bpp, 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








 Information for Chips and Technologies Users



	    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.

      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.

      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








 Information for Chips and Technologies Users



	    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
	    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 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 bpp modes








 Information for Chips and Technologies Users



	    will need 2 or 3 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.

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.














 Information for Chips and Technologies Users



	  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.  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 with the "sw_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" or sw_cursor" options.

      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.

      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"








 Information for Chips and Technologies Users



	    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
	    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.








 Information for Chips and Technologies Users



	    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 use the "sw_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
	    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 or 24bpp
	    Firstly, is your machine capable of 16/24bpp with the mode speci-
	    fied. Many LCD displays are incapable of using a 24bpp mode. Also
	    you need at least a 65540 to use 16/24bpp, and the amount of memory
	    used by the mode will be doubled/tripled. The correct options to
	    start the server with these modes are








 Information for Chips and Technologies Users



			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


	    Note that there is currently no "-bpp 32" mode in the Xserver,
	    although the 65550 is capable of this.

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.

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".


6.  Disclaimer

Xfree, 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!!


7.  Acknowledgement

The authors of this software wish to acknowledge the support supplied by Chips
and Technologies during the development of this software.


8.  Authors

Major Contributors (In no particular order)

   o Nozomi Ytow

   o Egbert Eich

   o David Bateman










 Information for Chips and Technologies Users



   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 XFree 3.2

     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/chips.sgml,v 3.12.2.7 1998/01/31 14:23:27 hohndel Exp $












































 Information for Chips and Technologies Users





































































				   CONTENTS



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

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

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

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

5. Troubleshooting  ......................................................... 8

6. Disclaimer  ............................................................. 11

7. Acknowledgement  ........................................................ 11

8. Authors  ................................................................ 11





































				       i



$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.chips,v 3.13.2.7 1998/02/08 11:19:32 dawes Exp $
