----- Original Message ----- From: "James Ralston" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 21, 2002 1:56 AM Subject: [Xpert]adding radeon driver documentation
> Attached is the first draft. Good to see the new Radeon man page being worked on. I'll try to explain some of FIXMEs below. > In particular, the following cards are known to work (FIXME: check list): > ATI Radeon 8500 series > All-In-Wonder Radeon 8500 > All-In-Wonder Radeon 8500DV > Radeon 8500 128MB > Radeon 8500 64MB > Radeon 8500LE > ATI Radeon 7500 series > All-In-Wonder Radeon 7500 > Radeon 7500 > ATI Radeon 7000 series > Radeon 7000 (also known as the Radeon VE) > ATI Radeon series > Radeon All-In-Wonder > Radeon 64MB DDR (VIVO) > Radeon 64MB SDR > Radeon 32MB DDR > Radeon 32MB SDR > ATI Radeon Mobility series > Radeon Mobility M6 > Radeon Mobility M7 The supported chips (series) in the list are almost complete, except 7200 series (new version of old Radeon). I'm not sure if we should list all memory+connector configurations here. There are quite a few OEM versions of Radeon boards which may have different configurations. > Note that the following cards are known not to work with the radeon > driver. Support for these cards will be added in a future release of XFree86 (FIXME: check both of these assertions): > ATI Radeon 9700 series > ATI Radeon 9000 series These cards (also M9, using the same RV250 core as 9000) will be supported (at least 2D part) in the near future. > Note that not all monitors and not all Radeon cards support the VESA > DDC/CI standard. If DDCMode is enabled, but the monitor and/or card > does not support the VESA DDC/CI standard, then XFree86 will emit a > warning message and use the standard VESA mode timings instead. All Radeon cards can do DDC probe, while some old CRTs or LCDs may not be DDC capable. > The advantage of not using DDCMode is that the VESA standard mode > timings are supported by virtually all monitors. Additionally, a monitor which > does not support the VESA standard mode timings will almost certainly not > support the VESA DDC/CI standard. The last statement is a bit confusing and may not be true. Traditionally, the driver uses lookup-best-refresh routine looking for the best refresh mode within standard VESA modes according to the specified VRefresh/HSync ranges. It should work well for most of displays. > The advantage of using DDCMode is that your particular monitor may > support non-standard non-VESA) mode timings which are better (e.g., a > higher refresh rate) than the VESA standard mode timings. Additionally, > for flat panel displays being used in analog mode, DDCMode will avoid using > unstable modes (some VESA standard modes don't really work with these > panels). This is okay. > VideoKey Option > This Option can be used to override the default video key value > (FIXME: what does the video key do? Why would one want to override > the default value?) VideoKey (aka colorkey) color is used by hardware overlay for displaying. The hardware overlay image is only visible on the colorkey color. When an application (like gtv) calls into driver for displaying a frame of video, the driver will paint the background of the application window to the colorkey color so that the hardware overlay can display on it. When another window overlaps on top of the video window, the overlay (video image) will be covered as long as the colors in the overlapped window do not match the colorkey color. If one color in the overlapped window matches the colorkey color, that part of window will appear to be transparent (you can see thru it to the underneath video image). To avoid this, you can specify an uncommon color to your system as the colorkey. > The following Options are designed for Radeon cards with multiple video ports, .... > Specifying these Options for cards without multiple video ports will have no > effect. (FIXME: is this true?) True. > The Options are: > Option CloneDisplay boolean > If set to true, then the DVI port will be cloned onto the CRT port. The > default is false (meaning, the DVI port will not be cloned onto the CRT port). This option may be set to default on in future after more tests. All clone mode stuffs shouldn't have any effect if only one monitor connected or if there are two Screen sections. > FIXME: the "Here is a hack for cloning first display on the second > head" comments in radeon_driver.c (in the RADEONPreInitModes function) > seem to imply that if both the DVI and CRT ports are being used, and > both have displays connected to them, and only one screen is defined > in XF86Config, and CloneDisplay isn't being used, then the monitor > connected to the CRT port will be driven according to the capability > of the monitor/panel connected to the DVI port. But the "VE and M6 > have both DVI and CRT ports" comments (in the > RADEONGetBIOSParameters function) seem to imply that if both > the DVI and CRT ports are being used, and both have displays connected to > them, and only one screen is defined in XF86Config, then the screen will be > used for the DVI port, and the CRT port won't be used. These sets of > comments seem incongruous with each other; what's the real deal? The comments in RADEONPreInitModes is correct. > See also the PanelOff Option > Option PanelOff > This Option works in conjunction with the CloneDisplay option . > If CloneDisplay is set to true and PanelOff is also set totrue , > then the only device XFree86 will use is the CRT port instead of the DVI > port, regardless of whether the DVI port has a display connected to it. The > default is false (meaning, XFree86 will use both the DVI port and the CRT port, > if both are enabled). > The PanelOff Option is intended for laptop systems (which is why it's named > "PanelOff" instead of something like "DVIOff"). Unlike desktop Radeon cards, > on laptops, it isn't possible to disconnect the flat panel display from the DVI > port. Because XFree86 prefers the DVI port over the CRT port if both ports > have monitors connected to them (and only a single > screen is defined in XF86Config(5x)), without the PanelOff Option, it > wouldn't be possible to use exclusively the external VGA connector on > laptops. This option is for laptop LVDS panels using mobile chips (M6/M7). The laptop panel (connected internally) and destop panel (thru DVI port) wont work together at the same time on these chips (at least for now). In fact, the laptops with M6/M7 usually only have a CRT output. Originally this option is supposed to turn off both LVDS and backlight. But when doing so, some panels behave strangely (blooming). For now, it just turns off syncs, like in DPMS display off mode. > Option CloneMode string > ... Just to add, you don't need to use this option if you just want to mirror all modes from the primary head. > Option CloneHSync string > Option CloneVRefresh string > ... Just to add, you don't need to use these options if your CRT is DDC capable. > If you set ForcePCIMode on any other architecture, DRI support will be > disabled. > (FIXME: I'm probably misunderstanding this option. How would one > force an AGP Radeon card to work on the PCI bus? Or a PCI Radeon card > (are there any?) to work on the AGP bus? Are there "dual-bus" > integrated Radeon cards floating around, which can sit on either the > PCI or AGP bus?) For AGP board, you can force it to use PCI GART instead of default AGP GART. This option can be used in following cases: (1) You have a PCI card. (2) You have an AGP card, but the agpgart kernel driver doesn't support the AGP bridge chipset on your motherboard. (3) The AGP GART doesn't work correctly. I'm not sure the current status of pcigart support. It didn't work reliably a few month ago. > Option CPPIOMode boolean > This Option can be used to force the CP into Programmable I/O (PIO) mode > instead of BM mode. The default is false (meaning, the CP will use BM mode). > (FIXME: What is CP? What is BM? What are the advantages and > disadvantages of using PIO versus BM?) CP -- Command Processor, BM -- Bus Master PIO mode is generally slower. I don't think this option has ever been implemented, should be removed in future. > "Option CPusecTimeout integer > This Option can be used to override the default CPusecTimeout value of 10000. > (FIXME: what does this do? Why would one want to override the default > value?) This option is used in the DRI kernel driver to wait for the graphic engine into certain state (like idle state or having enough ring/indirect buffer for accepting further commands). When it timeouts, an engine reset usually follows (not a good sign). > AGPMode > Legal values for the AGPMode Option are 1 through 4 inclusive. (Note that > although 3 is accepted as a legal value, very few systems will support it.) > (FIXME: on PCs, does XFree86 actually override the AGP mode as set in > the system BIOS?) During initialization, 2D driver calls into the kernel agpgart driver to set specified AGP mode. There is no 3x AGP mode. If you set it to 3, the agpgart kernel driver will set it to 2x. Future versions of AGP bridges/cards will support 8x mode. > Option AGPSize integer > ... > (FIXME: on PCs, does XFree86 actually override the AGP aperture size > as set in the system BIOS?) To my understanding, the kernel agpgart driver maintains all available AGP memory. DRI driver calls into the agpgart driver to allocate a part of AGP memory with specified AGPSize. This doesn't really change the BIOS setting. > Option RingSize integer > ... > (FIXME: what does this do? In PCs, does this correspond to one of the > common AGP-related BIOS options? If so, does XFree86 actually > override the value set in the system BIOS?) > ... > Option BufferSize integer > ... > (FIXME: is this explanation correct? In PCs, does this correspond to > one of the common AGP-related BIOS options? If so, does XFree86 > actually override the value set in the system BIOS?) Ring buffer and indirect buffer are assigned by radeon driver within the allocated part of AGP memory. They will not override any system BIOS settings. > "Option EnableDepthMoves boolean > If set to true, then depth moves are enabled. Since depth moves are > extremely slow, the default is false (meaning, depth moves are disabled). > (FIXME: what are depth moves? Find out and flush out this explanation > more.) With the recent changes in the DRI kernel driver, this option may not be useful anymore. Hui _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
