diff options
| author | Gaetan Nadon <memsize@videotron.ca> | 2010-06-13 16:41:01 -0400 |
|---|---|---|
| committer | Gaetan Nadon <memsize@videotron.ca> | 2010-06-13 16:46:16 -0400 |
| commit | 5c2ec580afce0830d270dbb25d9257b1a612d87a (patch) | |
| tree | 636742bbf439145628a6048112b7d79485c07400 | |
| parent | c9f5f2f6e868ce23e9ed4ca5c24bf0c64fb19206 (diff) | |
README: fix linuxdoc content
defs.ent are located under X11 directory
ident tag is not a Linuxdoc tag
replace docbook email tag with linuxdoc email tag
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
| -rw-r--r-- | README | 286 | ||||
| -rw-r--r-- | README.sgml | 11 |
2 files changed, 147 insertions, 150 deletions
@@ -1,6 +1,6 @@ Information for Chips and Technologies Users - David Bateman ( <dbateman@club-internet.fr>), Egbert Eich ( - <eich@freedesktop.org>) + David Bateman ( <mailto:dbateman@club-internet.fr>), Egbert + Eich ( <mailto:eich@freedesktop.org>) 1st January 2001 ____________________________________________________________ @@ -25,12 +25,12 @@ ______________________________________________________________________ - [1m1. Introduction[0m + 1. Introduction - The Chips and Technologies driver release in X11R6.8 came from XFree86 + The Chips and Technologies driver release in X11R7.5 came from XFree86 4.4 rc2; this document was originally included in that release and has - been updated modestly to reflect differences between X11R6.8 and + been updated modestly to reflect differences between X11R7.5 and XFree86 4.4 rc2. With the release of XFree86 version 4.0, the Chips and Technologies @@ -42,29 +42,29 @@ use this version. These features include - +o The long standing black/blue screen problem that some people have + o The long standing black/blue screen problem that some people have had should be fixed. - +o Hardware/Software cursor switching on the fly, that should fix many + o Hardware/Software cursor switching on the fly, that should fix many of the known hardware cursor problems. - +o Gamma correction at all depths and DirectColor visuals for depths + o Gamma correction at all depths and DirectColor visuals for depths of 15 or greater with the HiQV series of chipsets. - +o Supports PsuedoColor overlays on 16bpp TrueColor screens for HiQV. + o Supports PseudoColor overlays on 16bpp TrueColor screens for HiQV. - +o Supports YUV colour space conversion with the XVideo extension. + o Supports YUV colour space conversion with the XVideo extension. - +o 32bpp pixmaps while using a framebuffer in 24bpp packed pixel mode. + o 32bpp pixmaps while using a framebuffer in 24bpp packed pixel mode. - +o Heaps more acceleration. + o Heaps more acceleration. - +o 1/4bpp support. + o 1/4bpp support. - +o Multihead + o Multihead - +o Much more... + o Much more... This document attempts to discuss the features of this driver, the options useful in configuring it and the known problems. Most of the @@ -72,7 +72,7 @@ degree. - [1m2. Supported Chips[0m + 2. Supported Chips The Chips and Technologies chipsets supported by this driver have one @@ -81,58 +81,58 @@ completely new HiQV architecture. - [1m2.1. Basic architecture[0m + 2.1. Basic architecture - [1mct65520[0m + ct65520 (Max Ram: 1Mb, Max Dclk: 68MHz@5V) - [1mct65525[0m + 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. - [1mct65530[0m + 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 addressing of the video memory. (Max Ram: 1Mb, Max Dclk: 56MHz@3.3V, 68MHz@5V) - [1mct65535[0m + ct65535 This is the first chip of the ct655xx series to support fully programmable clocks. Otherwise it has the the same properties as the 65530. - [1mct65540[0m + ct65540 This is the first version of the of the ct655xx that was capable of supporting Hi-Color and True-Color. It also includes a fully programmable dot clock and supports all types of flat panels. (Max Ram: 1Mb, Max Dclk: 56MHz@3.3V, 68MHz@5V) - [1mct65545[0m + 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) - [1mct65546[0m + ct65546 This chip is specially manufactured for Toshiba, and so documentation 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?) - [1mct65548[0m + ct65548 This chip is similar to the 65545, but it also includes XRAM support and supports the higher dot clocks of the 65546. (Max Ram: 1Mb, Max Dclk: 80MHz) - [1m2.2. WinGine architecture[0m + 2.2. WinGine architecture - [1mct64200[0m + 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 @@ -140,7 +140,7 @@ only have limited support. Linear addressing is not supported for this card in the driver. (Max Ram: 2Mb, Max Dclk: 80MHz) - [1mct64300[0m + ct64300 This is a more advanced version of the WinGine chip, with specification very similar to the 6554x series of chips. However there are many differences at a register level. A similar level @@ -148,10 +148,10 @@ Ram: 2Mb, Max Dclk: 80MHz) - [1m2.3. HiQV Architecture[0m + 2.3. HiQV Architecture - [1mct65550[0m + ct65550 This chip includes many new features, including improved BitBLT support (24bpp colour expansion, wider maximum pitch, etc), Multimedia unit (video capture, zoom video port, etc) and 24bpp @@ -159,30 +159,30 @@ I/O is possible on all bus configurations. (Max Ram: 2Mb, Max Dclk: 80MHz@3.3V,100MHz@5V) - [1mct65554[0m + 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) - [1mct65555[0m + 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) - [1mct68554[0m + 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 desktop machines (Max Ram: 4Mb, Max Dclk: 110MHz@3.3V) - [1mct69000[0m + ct69000 Similar to the 65555 but incorporates 2Mbytes of SGRAM on chip. It is the first Chips and Technologies chipset where all of the registers are accessible through MMIO, rather than just the BitBlt registers. (Max Ram: 2Mb Only, Max Dclk: 130MHz@3.3V) - [1mct69030[0m + ct69030 Similar to the 69000 but incorporates 4Mbytes of SGRAM on chip and has faster memory and pixel clock limits. Also includes a second display channel so that the CRT can display independently @@ -190,32 +190,32 @@ - [1m3. xorg.conf Options[0m + 3. xorg.conf Options The following options are of particular interest to the Chips and Technologies driver. It should be noted that the options are case - insensitive, and that white space and "_" characters are ignored. + insensitive, and that white space and "_" characters are ignored. There are therefore a wide variety of possible forms for all options. The forms given below are the preferred forms. Options related to drivers can be present in the Screen, Device and - Monitor sections and the Display subsections. The order of precedence + Monitor sections and the Display subsections. The order of precedence is Display, Screen, Monitor, Device. - [1mOption[0m + Option 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). - [1mVideoRam 1024 (or another value)[0m + 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. - [1mOption[0m + Option By default linear addressing is used on all chips where it can be set up automatically. The exception is for depths of 1 or 4bpp where linear addressing is turned off by default. It is @@ -223,7 +223,7 @@ Note that H/W acceleration is only supported with linear addressing. - [1mOption[0m + Option When the chipset is capable of linear addressing and it has been turned off by default, this option can be used to turn it back on. This is useful for the 65530 chipset where the base address @@ -231,7 +231,7 @@ depths 1 and 4bpp. Note that linear addressing at 1 and 4bpp is not guaranteed to work correctly. - [1mMemBase 0x03b00000 (or a different address)[0m + MemBase 0x03b00000 (or a different address) This sets the physical memory base address of the linear framebuffer. Typically this is probed correctly, but if you believe it to be mis-probed, this option might help. Also for @@ -240,7 +240,7 @@ Note that for the 65530 this is required as the base address can't be correctly probed. - [1mOption[0m + Option For chipsets that support hardware cursors, this option enforces their use, even for cases that are known to cause problems on some machines. Note that it is overridden by the "SWcursor" @@ -249,16 +249,16 @@ is now given to the hardware. It also reduces the effect of cursor flashing during graphics operations. - [1mOption[0m + Option This disables use of the hardware cursor provided by the chip. Try this if the cursor seems to have problems. - [1mOption[0m + Option The server is unable to differentiate between SS STN and TFT displays. This forces it to identify the display as a SS STN rather than a TFT. - [1mOption[0m + Option The flat panel timings are related to the panel size and not the size of the mode specified in xorg.conf. For this reason the default behaviour of the server is to use the panel timings @@ -266,7 +266,7 @@ timings to be recalculated from the modeline with this option. However the panel size will still be probed. - [1mOption[0m + Option 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 @@ -276,13 +276,13 @@ "UseModeline" to program all the panel timings using the modeline values. - [1mOption[0m + Option 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. - [1mOption[0m + Option 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 @@ -291,7 +291,7 @@ effect of which is that the right-hand edge of the mode will be pushed off the screen. - [1mOption[0m + Option For the chips either using the WinGine or basic architectures, the chips generates a number of fixed clocks internally. With the chips 65535 and later or the 64300, the default is to use @@ -307,7 +307,7 @@ use isn't recommended. It is completely ignored for HiQV chipsets. - [1mTextClockFreq 25.175[0m + TextClockFreq 25.175 Except for the HiQV chipsets, it is impossible for the server to read the value of the currently used frequency for the text console when using programmable clocks. Therefore the server @@ -316,21 +316,21 @@ This allows the user to select a different clock for the server to use when returning to the text console. - [1mOption[0m - Option "FPClock16" "65.0MHz" Option "FPClock24" "65.0MHz" - Option "FPClock32" "65.0MHz"" In general the LCD panel clock - should be set independently of the modelines supplied. Normally - the chips BIOS set the flat panel clock correctly and so the - default behaviour with HiQV chipset is to leave the flat panel - clock alone, or force it to be 90% of the maximum allowable - clock if the current panel clock exceeds the dotclock limitation - due to a depth change. This option allows the user to force the - server the reprogram the flat panel clock independently of the - modeline with HiQV chipset. The four options are for 8bpp or - less, 16, 24 or 32bpp LCD panel clocks, where the options above - set the clocks to 65MHz. - - [1mOption[0m + Option + Option "FPClock16" "65.0MHz" Option "FPClock24" "65.0MHz" Option + "FPClock32" "65.0MHz"" In general the LCD panel clock should be + set independently of the modelines supplied. Normally the chips + BIOS set the flat panel clock correctly and so the default + behaviour with HiQV chipset is to leave the flat panel clock + alone, or force it to be 90% of the maximum allowable clock if + the current panel clock exceeds the dotclock limitation due to a + depth change. This option allows the user to force the server + the reprogram the flat panel clock independently of the modeline + with HiQV chipset. The four options are for 8bpp or less, 16, 24 + or 32bpp LCD panel clocks, where the options above set the + clocks to 65MHz. + + Option Option "FPClkIndx" "1"" 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 @@ -339,45 +339,45 @@ clock is unusable. These options can be used to force a particular clock index to be used - [1mOption[0m + Option This has a different effect depending on the hardware on which it is used. For the 6554x machines MMIO is only used to talk to - the BitBLT engine and is only usable with PCI buses. It is + the BitBLT engine and is only usable with PCI buses. It is enabled by default for 65545 machines since the blitter can not be used otherwise. The HiQV series of chipsets must use MMIO with their BitBLT engines, and so this is enabled by default. - [1mOption[0m + Option The 690xx chipsets can use MMIO for all communications with the video processor. So using this option on a 690xx chipset forces them to use MMIO for all communications. This only makes sense when the 690xx is on a PCI bus so that normal PIO can be disabled. - [1mOption[0m + Option 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 "LcdCenter" and "NoStretch". - [1mOption [22mFor 24bpp on TFT screens, the server assumes that + Option 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. - [1mChipset [22mIt is possible that the chip could be + Chipset 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. - [1mOption [22mComposite sync on green. Possibly useful if you + Option Composite sync on green. Possibly useful if you wish to use an old workstation monitor. The HiQV internal RAMDAC's supports this mode of operation, but whether a particular machine does depends on the manufacturer. - [1mDacSpeed 80.000 [22mThe server will limit the maximum dotclock to a + 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 @@ -386,7 +386,7 @@ this option, as driving the video processor beyond its specifications might cause damage. - [1mOption [22mOption "SetMClk" "38000kHz"" This option sets the + Option Option "SetMClk" "38000kHz"" This option sets the internal memory clock (MCLK) registers of HiQV chipsets to 38MHz or some other value. Use caution as excess heat generated by the video @@ -400,7 +400,7 @@ speed of the memory clock with the "Overlay" option. - [1mOption [22mBy default it is assumed that there are 6 + Option By default it is assumed that there are 6 significant bits in the RGB representation of the colours in 4bpp and above. If the colours seem darker than they should be, perhaps your ramdac @@ -408,14 +408,14 @@ server to assume that there are 8 significant bits. - [1mOption [22mThis is a debugging option and general users have + Option This is a debugging option and general users have no need of it. Using this option, when the virtual desktop is scrolled away from the zero position, the pixmap cache becomes visible. This is useful to see that pixmaps, tiles, etc have been properly cached. - [1mOption [22mThis option is only useful when acceleration + Option This option is only useful when acceleration can't be used and linear addressing can be used. With this option all of the graphics are rendered into a copy of the framebuffer that is keep in @@ -427,7 +427,7 @@ all done into a virtual framebuffer acceleration can not be used. - [1mOption [22mThe new TMED DSTN dithering scheme available on + Option The new TMED DSTN dithering scheme available on recent HiQV chipsets gives improved performance. However, some machines appear to have this feature incorrectly setup. If you have snow on @@ -435,7 +435,7 @@ is only relevant for chipsets more recent than the ct65555 and only when used with a DSTN LCD. - [1mOption [22mThe HiQV chipsets contain a multimedia engine + Option The HiQV chipsets contain a multimedia engine that allow a 16bpp window to be overlayed on the screen. This driver uses this capability to include a 16bpp framebuffer on top of an 8bpp @@ -459,21 +459,21 @@ disables the XVideo extension. - [1mOption [22mNormally the colour transparency key for the + Option Normally the colour transparency key for the overlay is the 8bpp lookup table entry 255. This might cause troubles with some applications, and so this option allows the colour transparency key to be set to some other value. Legal values are 2 to 255 inclusive. - [1mOption [22mThis sets the default pixel value for the YUV + Option This sets the default pixel value for the YUV video overlay key. Legal values for this key are depth dependent. That is from 0 to 255 for 8bit depth, 0 to 32,767 for 15bit depth, etc. This option might be used if the default video overlay key causes problems. - [1mOption [22mThe 69030 chipset has independent display + Option The 69030 chipset has independent display channels, that can be configured to support independent refresh rates on the flat panel and on the CRT. The default behaviour is to have both @@ -482,14 +482,14 @@ option forces the two display channels to be used, giving independent refresh rates. - [1mOption [22mThe ct69030 supports dual-head display. By + Option The ct69030 supports dual-head display. By default the two display share equally the available memory. This option forces the second display to take a particular amount of memory. Please read the section below about dual-head display. - [1mOption [22mOption "XaaNoSolidFillRect", Option "XaaNoSolid- + Option Option "XaaNoSolidFillRect", Option "XaaNoSolid- HorVertLine", Option "XaaNoMono8x8PatternFill- Rect", Option "XaaNoColor8x8PatternFillRect", Option "XaaNoCPUToScreenColorExpandFill", Option @@ -505,14 +505,14 @@ invaluable in debugging any problems. - [1m4. Modelines[0m + 4. Modelines When constructing a modeline for use with the Chips and Technologies driver you'll needed to considered several points - [1m* Virtual Screen Size[0m + * 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. @@ -522,11 +522,11 @@ but leave the virtual resolution untouched. This might further reduce the available memory. - [1m* 16/24/32 Bits Per Pixel[0m + * 16/24/32 Bits Per Pixel Hi-Color and True-Color modes are implemented in the 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 + 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 HiQV series of chips doesn't need to use additional clock cycles to display higher depths, and so the same modeline can be @@ -534,7 +534,7 @@ 16/24/32 bpp modes will need 2 , 3 or 4 times respectively more video ram. - [1m* Frame Acceleration[0m + * 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 @@ -547,7 +547,7 @@ bytes (640x480 panel), 96000 bytes (800x600 panel) and 157287 bytes (1024x768 panel). - [1m* H/W Acceleration[0m + * 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 cursor is stored in registers and so no allowance is needed for the H/W cursor. In addition to @@ -555,7 +555,7 @@ cache". Leaving too little memory available for the cache will only have a detrimental effect on the graphics performance. - [1m* PseudoColor Overlay[0m + * PseudoColor Overlay If you use the "overlay" option, then there are actually two framebuffers in the video memory. An 8bpp one and a 16bpp one. The total memory requirements in this mode of operation is @@ -563,20 +563,20 @@ bandwidth, so that the maximum dotclock will be similar to a 24bpp mode. - [1m* XVideo extension*[0m + * XVideo extension* Like the overlays, the Xvideo extension uses a part of the video memory for a second framebuffer. In this case enough memory needs to be left for the largest unscaled video window that will be displayed. - [1m* VESA like modes[0m + * 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. - [1m* Dot Clock[0m + * 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 @@ -586,7 +586,7 @@ complete discussion on the dot clock limitations, see the next section. - [1m* Dual-head display[0m + * Dual-head display Dual-head display has two effects on the modelines. Firstly, the memory requirements of both heads must fit in the available memory. Secondly, the memory bandwidth of the video processor is @@ -629,7 +629,7 @@ - The IBM PC110 works best with a 15MHz clock (Thanks to Alan Cox): + The IBM PC110 works best with a 15MHz clock (Thanks to Alan Cox): Modeline "640x480" 15.00 640 672 728 816 480 489 496 526 @@ -643,11 +643,11 @@ "FixPanelSize" options. - [1m5. Dual Display Channel[0m + 5. Dual Display Channel XFree86 releases later than 4.1.0 and X.Org releases later than 6.7.0 - support dual-channel display on the ct69030. This support can be used + support dual-channel display on the ct69030. This support can be used to give a single display image on two screen with different refresh rates, or entirely different images on the two displays. @@ -753,7 +753,7 @@ own problems as described above. - [1m6. The Full Story on Clock Limitations[0m + 6. The Full Story on Clock Limitations There has been much confusion about exactly what the clock limitations @@ -823,7 +823,7 @@ otherwise. This effectively means that there are two limits on the dotclock. One the overall maximum, and another due to the available - memory bandwidth of the chip. The 69030 and 69000 have a 64bit memory + memory bandwidth of the chip. The 69030 and 69000 have a 64bit memory bus and thus transfer 8 bytes every clock thus (hence the 8), while the other HiQV chipsets are 32bit and transfer 4 bytes per clock cycle (hence the 4). However, after accounting for the RAS/CAS signaling @@ -887,11 +887,11 @@ the video processor beyond it capabilities won't cause damage. - [1m7. Troubleshooting[0m + 7. Troubleshooting - [1mThe cursor appears as a white box, after switching modes[0m + 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 @@ -899,14 +899,14 @@ annoying the H/W cursor can be disabled by removing the "HWcursor" option. - [1mThe cursor hot-spot isn't at the same point as the cursor[0m + 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 "NoStretch" option or removing the HWcursor" option. - [1mThe lower part of the screen is corrupted[0m + 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 @@ -916,7 +916,7 @@ accelerator and will therefore be corrupt. Try reducing the amount of memory consumed by the mode. - [1mThere is a video signal, but the screen doesn't sync.[0m + 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 @@ -927,22 +927,22 @@ the "UseModeline" and perhaps also the "FixPanelSize" options to reprogram the LCD panel timings to sensible values. - [1m`Wavy' screen.[0m + `Wavy' screen. Horizontal waving or jittering of the whole screen, continuously - (independent from drawing operations). You are probably using a + (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 increasing the second horizontal value somewhat. - [1mCrash or hang after start-up (probably with a black screen).[0m + Crash or hang after start-up (probably with a black screen). Try the "NoAccel" or one of the XAA acceleration options discussed above. Check that the BIOS settings are OK; in particular, disable caching of 0xa0000-0xaffff. Disabling hidden DRAM refresh may also help. - [1mHang as the first text is appearing on the screen on SVR4[0m - [1mmachines.[0m + 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 @@ -950,7 +950,7 @@ the use of CPU to screen acceleration with the "XaaNoCPUToScreenColorExapndFill" option. - [1mCrash, hang, or trash on the screen after a graphics operation.[0m + 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 one of the XAA acceleration options discussed @@ -959,11 +959,11 @@ little bandwidth left for using the BitBLT engine. Try reducing the clock. - [1mChipset is not detected.[0m + Chipset is not detected. Try forcing the chipset to a type that is most similar to what you have. - [1mThe screen is blank when starting X[0m + The screen is blank when starting X One possible cause of this problem with older linux kernels is that the "APM_DISPLAY_BLANK" option didn't work correct. Either upgrade your kernel or rebuild it with the "APM_DISPLAY_BLANK" @@ -971,7 +971,7 @@ linux, a CRT/LCD or switch to and from the virtual console will often fix it. - [1mTextmode is not properly restored[0m + 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 @@ -985,7 +985,7 @@ kernels are compiled with the "APM_DISPLAY_BLANK" option. As mentioned before, try disabling this option. - [1mI can't display 640x480 on my 800x600 LCD[0m + 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 @@ -995,7 +995,7 @@ than the panel size. Try deleting theses options from xorg.conf or using an LCD/CRT switch. - [1mI can't get a 320x240 mode to occupy the whole 640x480 LCD[0m + 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 @@ -1004,7 +1004,7 @@ remove the "HWcursor" option. The server will then allow the mode to occupy the whole 640x480 LCD. - [1mAfter a suspend/resume my screen is messed up[0m + 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 @@ -1015,16 +1015,16 @@ displayed incorrectly. This shouldn't affect higher depths, and is fixable with a switch to the virtual console and back. - [1mThe right hand edge of the mode isn't visible on the LCD[0m + The right hand edge of the mode isn't visible on the LCD This is usually due to a problem with the "LcdCenter" option. If this option is removed form xorg.conf, then the problem might go away. Alternatively the manufacturer could have incorrectly programmed the panel size in the EGA console mode. The "FixPanelSize" 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". + problem are the "HP OmniBook 5000" and the "NEC Versa 4080". - [1mMy TFT screen has a reddish tint in 24bpp mode[0m + My TFT screen has a reddish tint in 24bpp mode For 6554x chipsets 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 "18BitBus" @@ -1033,14 +1033,14 @@ reddish. Note that this option only has an effect on TFT screens. - [1mSuperProbe won't work with my chipset[0m + SuperProbe won't work with my chipset At least one non-PCI bus system with a HiQV chipset has been found to require the "-no_bios" option for SuperProbe to correctly detect the chipset with the factory default BIOS settings. The server itself can correctly detect the chip in the same situation. - [1mMy 690xx machine lockups when using the[0m + My 690xx machine lockups when using the The 690xx MMIO mode has been implemented entirely from the manual as I don't have the hardware to test it on. At this point no testing has been done and it is entirely possible that the @@ -1048,7 +1048,7 @@ However if you do try this option and are willing to debug it, I'd like to hear from you. - [1mMy TrueColor windows are corrupted when using the[0m + My TrueColor windows are corrupted when using the Chips and Technologies specify that the memory clock used with the multimedia engine running should be lower than that used without. As use of the HiQV chipsets multimedia engine was @@ -1059,14 +1059,14 @@ "SetMClk" option to reduce the speed of the memory clock is recommended. - [1mThe mpeg video playing with the XVideo extension has corrupted[0m - [1mcolours[0m + The mpeg video playing with the XVideo extension has corrupted + colours The XVideo extension has only recently been added to the chips driver. Some YUV to RGB colour have been noted at 15 and 16 bit colour depths. However, 8 and 24 bit colour depths seem to work fine. - [1mMy ct69030 machine locks up when starting X[0m + My ct69030 machine locks up when starting X The ct69030 chipset introduced a new dual channel architecture. In its current form, X can not take advantage of this second display channel. In fact if the video BIOS on the machine sets @@ -1076,7 +1076,7 @@ IOSS and MSS registers are set to a single channel mode. Work is underway to fix this. - [1mI can't start X-windows with 16, 24 or 32bpp[0m + I can't start X-windows with 16, 24 or 32bpp Firstly, is your machine capable of 16/24/32bpp with the mode specified. Many LCD displays are incapable of using a 24bpp mode. Also you need at least a 65540 to use 16/24bpp and at @@ -1095,7 +1095,7 @@ startx -- -depth 24 -fbbpp 32 8-8-8 RGB truecolor - however as X11R6.8 allows 32bpp pixmaps to be used with frame- + however as X11R7.5 allows 32bpp pixmaps to be used with frame- buffers operating in 24bpp, this mode of operating will cost per- formance for no gain in functionality. @@ -1126,10 +1126,10 @@ If you are having driver-related problems that are not addressed by this document, or if you have found bugs in accelerated functions, you can try contacting the Xorg team (the current driver maintainer can be - reached at <eich@freedesktop.org>). + reached at <mailto:eich@freedesktop.org>). - [1m8. Disclaimer[0m + 8. Disclaimer The Xorg X server, allows the user to do damage to their hardware with @@ -1140,38 +1140,38 @@ screen, TURN THE COMPUTER OFF!! - [1m9. Acknowledgement[0m + 9. Acknowledgement The authors of this software wish to acknowledge the support supplied by Chips and Technologies during the development of this software. - [1m10. Authors[0m + 10. Authors Major Contributors (In no particular order) - +o Nozomi Ytow + o Nozomi Ytow - +o Egbert Eich + o Egbert Eich - +o David Bateman + o David Bateman - +o Xavier Ducoin + o Xavier Ducoin Contributors (In no particular order) - +o Ken Raeburn + o Ken Raeburn - +o Shigehiro Nomura + o Shigehiro Nomura - +o Marc de Courville + o Marc de Courville - +o Adam Sulmicki + o Adam Sulmicki - +o Jens Maurer + o Jens Maurer We also thank the many people on the net who have contributed by reporting bugs and extensively testing this server. diff --git a/README.sgml b/README.sgml index 1e73362..c189e72 100644 --- a/README.sgml +++ b/README.sgml @@ -1,18 +1,15 @@ <!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN"[ -<!ENTITY % defs SYSTEM "defs.ent"> %defs; +<!ENTITY % defs SYSTEM "X11/defs.ent"> %defs; ]> <article> <!-- Title information --> <title> Information for Chips and Technologies Users -<author> David Bateman (<email>dbateman@club-internet.fr</email>), - Egbert Eich (<email>eich@freedesktop.org</email>) +<author> David Bateman (<url url="mailto:dbateman@club-internet.fr">), + Egbert Eich (<url url="mailto:eich@freedesktop.org">) <date> 1st January 2001 -<ident> -</ident> - <!-- Table of contents --> <toc> @@ -1042,7 +1039,7 @@ video processor beyond it capabilities won't cause damage. If you are having driver-related problems that are not addressed by this document, or if you have found bugs in accelerated functions, you can try contacting the Xorg team (the current driver maintainer can be - reached at <email>eich@freedesktop.org</email>). + reached at <url url="mailto:eich@freedesktop.org">). <sect> Disclaimer <p> |