diff options
Diffstat (limited to 'xorg-server/hw/xfree86/doc/sgml')
| -rw-r--r-- | xorg-server/hw/xfree86/doc/sgml/DESIGN.sgml | 14834 |
1 files changed, 7420 insertions, 7414 deletions
diff --git a/xorg-server/hw/xfree86/doc/sgml/DESIGN.sgml b/xorg-server/hw/xfree86/doc/sgml/DESIGN.sgml index e95df7999..c6fc63edb 100644 --- a/xorg-server/hw/xfree86/doc/sgml/DESIGN.sgml +++ b/xorg-server/hw/xfree86/doc/sgml/DESIGN.sgml @@ -1,7414 +1,7420 @@ -<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN" [ - <!ENTITY % defs SYSTEM "X11/defs.ent"> %defs; - <!-- config file keyword markup --> - <!ENTITY s.key STARTTAG "bf"> - <!ENTITY e.key ENDTAG "bf"> - <!-- specific config file keywords --> - <!ENTITY k.device "&s.key;Device&e.key;"> - <!ENTITY k.monitor "&s.key;Monitor&e.key;"> - <!ENTITY k.display "&s.key;Display&e.key;"> - <!ENTITY k.inputdevice "&s.key;InputDevice&e.key;"> - <!ENTITY k.screen "&s.key;Screen&e.key;"> - <!ENTITY k.serverlayout "&s.key;ServerLayout&e.key;"> - <!ENTITY k.driver "&s.key;Driver&e.key;"> - <!ENTITY k.module "&s.key;Module&e.key;"> - <!ENTITY k.identifier "&s.key;Identifier&e.key;"> - <!ENTITY k.serverflags "&s.key;ServerFlags&e.key;"> - <!-- command line markup --> - <!ENTITY s.cmd STARTTAG "tt"> - <!ENTITY e.cmd ENDTAG "tt"> - <!-- inline code markup --> - <!ENTITY s.code STARTTAG "tt"> - <!ENTITY e.code ENDTAG "tt"> - <!-- function indent --> - <!ENTITY f.indent "&nl          "> -] > - -<article> - -<title>XFree86 server 4.x Design (DRAFT) -<author>The XFree86 Project, Inc -<and>Updates for X11R&relvers; by Jim Gettys -<date>19 December 2003 - - - - - - - -<ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.53 2003/08/23 14:10:14 dawes Exp $ -</ident> - - -<p> -<bf>NOTE</bf>: This is a DRAFT document, and the interfaces described here -are subject to change without notice. - - -<sect>Preface -<p> - -The broad design principles are: -<itemize> - <item>keep it reasonable - <itemize> - <item>We cannot rewrite the complete server - <item>We don't want to re-invent the wheel - </itemize> - <item>keep it modular - <itemize> - <item>As many things as possible should go into modules - <item>The basic loader binary should be minimal - <item>A clean design with well defined layering is important - <item>DDX specific global variables are a nono - <item>The structure should be flexible enough to allow - future extensions - <item> The structure should minimize duplication of common code - </itemize> - <item>keep important features in mind - <itemize> - <item>multiple screens, including multiple instances of drivers - <item>mixing different color depths and visuals on different - and ideally even on the same screen - <item>better control of the PCI device used - <item>better config file parser - <item>get rid of all VGA compatibility assumptions - </itemize> -</itemize> - -Unless we find major deficiencies in the DIX layer, we should avoid -making changes there. - -<sect>The xorg.conf File -<p> - -The xorg.conf file format is similar to the old format, with the following -changes: - -<sect1>&k.device; section -<p> - - The &k.device; sections are similar to what they used to be, and - describe hardware-specific information for a single video card. - &k.device; - Some new keywords are added: - - - <descrip> - <tag>Driver "drivername"</tag> - Specifies the name of the driver to be used for the card. This - is mandatory. - <tag>BusID "busslot"</tag> - Specifies uniquely the location of the card on the bus. The - purpose is to identify particular cards in a multi-headed - configuration. The format of the argument is intentionally - vague, and may be architecture dependent. For a PCI bus, it - is something like "bus:slot:func". - </descrip> - - A &k.device; section is considered ``active'' if there is a reference - to it in an active &k.screen; section. - -<sect1>&k.screen; section -<p> - - The &k.screen; sections are similar to what they used to be. They - no longer have a &k.driver; keyword, but an &k.identifier; keyword - is added. (The &k.driver; keyword may be accepted in place of the - &k.identifier; keyword for compatibility purposes.) The identifier - can be used to identify which screen is to be active when multiple - &k.screen sections are present. It is possible to specify the active - screen from the command line. A default is chosen in the absence - of one being specified. A &k.screen; section is considered ``active'' - if there is a reference to it either from the command line, or from - an active &k.serverlayout; section. - -<sect1>&k.inputdevice; section -<p> - - The &k.inputdevice; section is a new section that describes - configuration information for input devices. It replaces the old - &s.key;Keyboard&e.key;, &s.key;Pointer&e.key; and &s.key;XInput&e.key; - sections. Like the &k.device; section, it has two mandatory keywords: - &k.identifier; and &k.driver;. For compatibility purposes the old - &s.key;Keyboard&e.key; and &s.key;Pointer&e.key; sections are - converted by the parser into &k.inputdevice; sections as follows: - - <descrip> - <tag>&s.key;Keyboard&e.key;</tag> - &k.identifier; "Implicit Core Keyboard"<newline> - &k.driver; "keyboard" - <tag>&s.key;Pointer&e.key;</tag> - &k.identifier; "Implicit Core Pointer"<newline> - &k.driver; "mouse" - </descrip> - - An &k.inputdevice; section is considered active if there is a - reference to it in an active &k.serverlayout; section. An - &k.inputdevice; section may also be referenced implicitly if there - is no &k.serverlayout; section, if the &s.cmd;-screen&e.cmd; command - line options is used, or if the &k.serverlayout; section doesn't - reference any &k.inputdevice; sections. In this case, the first - sections with drivers "keyboard" and "mouse" are used as the core - keyboard and pointer respectively. - -<sect1>&k.serverlayout; section -<p> - - The &k.serverlayout; section is a new section that is used to identify - which &k.screen; sections are to be used in a multi-headed configuration, - and the relative layout of those screens. It also identifies which - &k.inputdevice; sections are to be used. Each &k.serverlayout section - has an identifier, a list of &k.screen; section identifiers, and a list of - &k.inputdevice; section identifiers. &k.serverflags; options may also be - included in a &k.serverlayout; section, making it possible to override - the global values in the &k.serverflags; section. - - A &k.serverlayout; section can be made active by being referenced on - the command line. In the absence of this, a default will be chosen - (the first one found). The screen names may optionally be followed - by a number specifying the preferred screen number, and optionally - by information specifying the physical positioning of the screen, - either in absolute terms or relative to another screen (or screens). - When no screen number is specified, they are numbered according to - the order in which they are listed. The old (now obsolete) method - of providing the positioning information is to give the names of - the four adjacent screens. The order of these is top, bottom, left, - right. Here is an example of a &k.serverlayout; section for two - screens using the old method, with the second located to the right - of the first: - - <code> - Section "ServerLayout" - Identifier "Main Layout" - Screen 0 "Screen 1" "" "" "" "Screen 2" - Screen 1 "Screen 2" - Screen "Screen 3" - EndSection - </code> - - The preferred way of specifying the layout is to explicitly specify - the screen's location in absolute terms or relative to another - screen. - - In the absolute case, the upper left corner's coordinates are given - after the &s.key;Absolute&e.key; keyword. If the coordinates are - omitted, a value of &s.code;(0,0)&e.code; is assumed. An example - of absolute positioning follows: - - <code> - Section "ServerLayout" - Identifier "Main Layout" - Screen 0 "Screen 1" Absolute 0 0 - Screen 1 "Screen 2" Absolute 1024 0 - Screen "Screen 3" Absolute 2048 0 - EndSection - </code> - - In the relative case, the position is specified by either using one of - the following keywords followed by the name of the reference screen: - - <quote> - &s.key;RightOf&nl; - LeftOf&nl; - Above&nl; - Below&nl; - Relative&e.key; - </quote> - - When the &s.key;Relative&e.key; keyword is used, the reference screen - name is followed by the coordinates of the new screen's origin - relative to reference screen. The following example shows how to use - some of the relative positioning options. - - <code> - Section "ServerLayout" - Identifier "Main Layout" - Screen 0 "Screen 1" - Screen 1 "Screen 2" RightOf "Screen 1" - Screen "Screen 3" Relative "Screen 1" 2048 0 - EndSection - </code> - -<sect1>Options -<p> - - Options are used more extensively. They may appear in most sections - now. Options related to drivers can be present in the &k.screen;, - &k.device; and &k.monitor; sections and the &k.display; subsections. - The order of precedence is &k.display;, &k.screen;, &k.monitor;, - &k.device;. Options have been extended to allow an optional value - to be specified in addition to the option name. For more details - about options, see the <ref id="options" name="Options"> section - for details. - -<sect>Driver Interface -<p> - -The driver interface consists of a minimal set of entry points that are -required based on the external events that the driver must react to. -No non-essential structure is imposed on the way they are used beyond -that. This is a significant difference compared with the old design. - -The entry points for drawing operations are already taken care of by -the framebuffer code (including, XAA). Extensions and enhancements to -framebuffer code are outside the scope of this document. - -This approach to the driver interface provides good flexibility, but does -increase the complexity of drivers. To help address this, the XFree86 -common layer provides a set of ``helper'' functions to take care of things -that most drivers need. These helpers help minimise the amount of code -duplication between drivers. The use of helper functions by drivers is -however optional, though encouraged. The basic philosophy behind the -helper functions is that they should be useful to many drivers, that -they should balance this against the complexity of their interface. It -is inevitable that some drivers may find some helpers unsuitable and -need to provide their own code. - -Events that a driver needs to react to are: - - <descrip> - <tag>ScreenInit</tag> - - An initialisation function is called from the DIX layer for each - screen at the start of each server generation. - - <tag>Enter VT</tag> - - The server takes control of the console. - - <tag>Leave VT</tag> - - The server releases control of the console. - - <tag>Mode Switch</tag> - - Change video mode. - - <tag>ViewPort change</tag> - - Change the origin of the physical view port. - - <tag>ScreenSaver state change</tag> - - Screen saver activation/deactivation. - - <tag>CloseScreen</tag> - - A close screen function is called from the DIX layer for each screen - at the end of each server generation. - </descrip> - - -In addition to these events, the following functions are required by -the XFree86 common layer: - - <descrip> - <tag>Identify</tag> - - Print a driver identifying message. - - <tag>Probe</tag> - - This is how a driver identifies if there is any hardware present that - it knows how to drive. - - <tag>PreInit</tag> - - Process information from the xorg.conf file, determine the - full characteristics of the hardware, and determine if a valid - configuration is present. - </descrip> - -The VidMode extension also requires: - - <descrip> - <tag>ValidMode</tag> - - Identify if a new mode is usable with the current configuration. - The PreInit function (and/or helpers it calls) may also make use - of the ValidMode function or something similar. - </descrip> - - -Other extensions may require other entry points. The drivers will -inform the common layer of these in such cases. - -<sect>Resource Access Control Introduction -<p> - -Graphics devices are accessed through ranges in I/O or memory space. -While most modern graphics devices allow relocation of such ranges many -of them still require the use of well established interfaces such as -VGA memory and IO ranges or 8514/A IO ranges. With modern buses (like -PCI) it is possible for multiple video devices to share access to these -resources. The RAC (Resource Access Control) subsystem provides a -mechanism for this. - -<sect1>Terms and Definitions -<p> - -<sect2>Bus -<p> - - ``Bus'' is ambiguous as it is used for different things: it may refer - to physical incompatible extension connectors in a computer system. - The RAC system knows two such systems: The ISA bus and the PCI bus. - (On the software level EISA, MCA and VL buses are currently treated - like ISA buses). ``Bus'' may also refer to logically different - entities on a single bus system which are connected via bridges. A - PCI system may have several distinct PCI buses connecting each other - by PCI-PCI bridges or to the host CPU by HOST-PCI bridges. - - Systems that host more than one bus system link these together using - bridges. Bridges are a concern to RAC as they might block or pass - specific resources. PCI-PCI bridges may be set up to pass VGA - resources to the secondary bus. PCI-ISA buses pass any resources not - decoded on the primary PCI bus to the ISA bus. This way VGA resources - (although exclusive on the ISA bus) can be shared by ISA and PCI - cards. Currently HOST-PCI bridges are not yet handled by RAC as they - require specific drivers. - -<sect2>Entity -<p> - - The smallest independently addressable unit on a system bus is - referred to as an entity. So far we know ISA and PCI entities. PCI - entities can be located on the PCI bus by an unique ID consisting of - the bus, card and function number. - -<sect2>Resource -<p> - - ``Resource'' refers to a range of memory or I/O addresses an entity - can decode. - - If a device is capable of disabling this decoding the resource is - called sharable. For PCI devices a generic method is provided to - control resource decoding. Other devices will have to provide a - device specific function to control decoding. - - If the entity is capable of decoding this range at a different - location this resource is considered relocatable. - - Resources which start at a specific address and occupy a single - continuous range are called block resources. - - Alternatively resource addresses can be decoded in a way that they - satisfy the conditions: - <quote><verb> - address & mask == base - </verb></quote> - and - <quote><verb> - base & mask == base - </verb></quote> - Resources addressed in such a way are called sparse resources. - -<sect2>Server States -<p> - - The resource access control system knows two server states: the - SETUP and the OPERATING state. The SETUP state is entered whenever - a mode change takes place or the server exits or does VT switching. - During this state all entity resources are under resource access - control. During OPERATING state only those entities are controlled - which actually have shared resources that conflict with others. - -<sect>Control Flow in the Server and Mandatory Driver Functions -<p> - -At the start of each server generation, &s.code;main()&e.code; -(&s.code;dix/main.c&e.code;) calls the DDX function -&s.code;InitOutput()&e.code;. This is the first place that the DDX gets -control. &s.code;InitOutput()&e.code; is expected to fill in the global -&s.code;screenInfo&e.code; struct, and one -&s.code;screenInfo.screen[]&e.code; entry for each screen present. Here -is what &s.code;InitOutput()&e.code; does: - -<sect1>Parse the xorg.conf file -<p> - - This is done at the start of the first server generation only. - - The xorg.conf file is read in full, and the resulting information - stored in data structures. None of the parsed information is - processed at this point. The parser data structures are opaque to - the video drivers and to most of the common layer code. - - The entire file is parsed first to remove any section ordering - requirements. - - -<sect1>Initial processing of parsed information and command line options -<p> - - This is done at the start of the first server generation only. - - The initial processing is to determine paths like the - &s.key;ModulePath&e.key;, etc, and to determine which &k.serverlayout;, - &k.screen; and &k.device; sections are active. - - -<sect1>Enable port I/O access -<p> - - Port I/O access is controlled from the XFree86 common layer, and is - ``all or nothing''. It is enabled prior to calling driver probes, at - the start of subsequent server generations, and when VT switching - back to the Xserver. It is disabled at the end of server generations, - and when VT switching away from the Xserver. - - The implementation details of this may vary on different platforms. - - -<sect1>General bus probe -<p> - - This is done at the start of the first server generation only. - - In the case of ix86 machines, this will be a general PCI probe. - The full information obtained here will be available to the drivers. - This information persists for the life of the Xserver. In the PCI - case, the PCI information for all video cards found is available by - calling &s.code;xf86GetPciVideoInfo()&e.code;. - - <quote> - &s.code;pciVideoPtr *xf86GetPciVideoInfo(void)&e.code; - <quote><p> - returns a pointer to a list of pointers to - &s.code;pciVideoRec&e.code; entries, of which there is one for - each detected PCI video card. The list is terminated with a - &s.code;NULL&e.code; pointer. If no PCI video cards were - detected, the return value is &s.code;NULL&e.code;. - - </quote> - </quote> - - After the bus probe, the resource broker is initialised. - - -<sect1>Load initial set of modules -<p> - - This is done at the start of the first server generation only. - - The core server contains a list of mandatory modules. These are loaded - first. Currently the only module on this list is the bitmap font module. - - The next set of modules loaded are those specified explicitly in the - &k.module; section of the config file. - - The final set of initial modules are the driver modules referenced - by the active &k.device; and &k.inputdevice; sections in the config - file. Each of these modules is loaded exactly once. - - -<sect1>Register Video and Input Drivers -<p> - - This is done at the start of the first server generation only. - - When a driver module is loaded, the loader calls its - &s.code;Setup&e.code; function. For video drivers, this function - calls &s.code;xf86AddDriver()&e.code; to register the driver's - &s.code;DriverRec&e.code;, which contains a small set of essential - details and driver entry points required during the early phase of - &s.code;InitOutput()&e.code;. &s.code;xf86AddDriver()&e.code; adds - it to the global &s.code;xf86DriverList[]&e.code; array. - - The &s.code;DriverRec&e.code; contains the driver canonical name, - the &s.code;Identify()&e.code;, - &s.code;Probe()&e.code; and &s.code;AvailableOptions()&e.code; - function entry points as well as a pointer - to the driver's module (as returned from the loader when the driver - was loaded) and a reference count which keeps track of how many - screens are using the driver. The entry driver entry points are - those required prior to the driver allocating and filling in its - &s.code;ScrnInfoRec&e.code;. - - For a static server, the &s.code;xf86DriverList[]&e.code; array is - initialised at build time, and the loading of modules is not done. - - A similar procedure is used for input drivers. The input driver's - &s.code;Setup&e.code; function calls - &s.code;xf86AddInputDriver()&e.code; to register the driver's - &s.code;InputDriverRec&e.code;, which contains a small set of - essential details and driver entry points required during the early - phase of &s.code;InitInput()&e.code;. - &s.code;xf86AddInputDriver()&e.code; adds it to the global - &s.code;xf86InputDriverList[]&e.code; array. For a static server, - the &s.code;xf86InputDriverList[]&e.code; array is initialised at - build time. - - Both the &s.code;xf86DriverList[]&e.code; and - &s.code;xf86InputDriverList[]&e.code; arrays have been initialised - by the end of this stage. - - Once all the drivers are registered, their - &s.code;ChipIdentify()&e.code; functions are called. - - <quote> - &s.code;void ChipIdentify(int flags)&e.code; - <quote> - This is expected to print a message indicating the driver name, - a short summary of what it supports, and a list of the chipset - names that it supports. It may use the xf86PrintChipsets() helper - to do this. - </quote> - </quote> - - <quote> - &s.code;void xf86PrintChipsets(const char *drvname, const char *drvmsg, - &f.indent;SymTabPtr chips)&e.code; - <quote> - This function provides an easy way for a driver's ChipIdentify - function to format the identification message. - </quote> - </quote> - -<sect1>Initialise Access Control -<p> - - This is done at the start of the first server generation only. - - The Resource Access Control (RAC) subsystem is initialised before - calling any driver functions that may access hardware. All generic - bus information is probed and saved (for restoration later). All - (shared resource) video devices are disabled at the generic bus - level, and a probe is done to find the ``primary'' video device. These - devices remain disabled for the next step. - - -<sect1>Video Driver Probe<label id="probe"> -<p> - This is done at the start of the first server generation only. The - &s.code;ChipProbe()&e.code; function of each registered video driver - is called. - - <quote><p> - &s.code;Bool ChipProbe(DriverPtr drv, int flags)&e.code; - <quote><p> - The purpose of this is to identify all instances of hardware - supported by the driver. The flags value is currently either 0, - &s.code;PROBE_DEFAULT&e.code; or &s.code;PROBE_DETECT&e.code;. - &s.code;PROBE_DETECT&e.code; is used if "-configure" or "-probe" - command line arguments are given and indicates to the - &s.code;Probe()&e.code; function that it should not configure the - bus entities and that no xorg.conf information is available. - - The probe must find the active device sections that match the - driver by calling &s.code;xf86MatchDevice()&e.code;. The number - of matches found limits the maximum number of instances for this - driver. If no matches are found, the function should return - &s.code;FALSE&e.code; immediately. - - Devices that cannot be identified by using device-independent - methods should be probed at this stage (keeping in mind that access - to all resources that can be disabled in a device-independent way - are disabled during this phase). The probe must be a minimal - probe. It should just determine if there is a card present that - the driver can drive. It should use the least intrusive probe - methods possible. It must not do anything that is not essential, - like probing for other details such as the amount of memory - installed, etc. It is recommended that the - &s.code;xf86MatchPciInstances()&e.code; helper function be used - for identifying matching PCI devices, and similarly the - &s.code;xf86MatchIsaInstances()&e.code; for ISA (non-PCI) devices - (see the <ref id="rac" name="RAC"> section). These helpers also - checks and claims the appropriate entity. When not using the - helper, that should be done with &s.code;xf86CheckPciSlot()&e.code; - and &s.code;xf86ClaimPciSlot()&e.code; for PCI devices and - &s.code;xf86ClaimIsaSlot()&e.code; for ISA devices (see the - <ref id="rac" name="RAC"> section). - - The probe must register all non-relocatable resources at this - stage. If a resource conflict is found between exclusive resources - the driver will fail immediately. This is usually best done with - the &s.code;xf86ConfigPciEntity()&e.code; helper function - for PCI and &s.code;xf86ConfigIsaEntity()&e.code; for ISA - (see the <ref id="rac" name="RAC"> section). It is possible to - register some entity specific functions with those helpers. When - not using the helpers, the &s.code;xf86AddEntityToScreen()&e.code; - &s.code;xf86ClaimFixedResources()&e.code; and - &s.code;xf86SetEntityFuncs()&e.code; should be used instead (see - the <ref id="rac" name="RAC"> section). - - If a chipset is specified in an active device section which the - driver considers relevant (ie it has no driver specified, or the - driver specified matches the driver doing the probe), the Probe - must return &s.code;FALSE&e.code; if the chipset doesn't match - one supported by the driver. - - If there are no active device sections that the driver considers - relevant, it must return &s.code;FALSE&e.code;. - - Allocate a &s.code;ScrnInfoRec&e.code; for each active instance of the - hardware found, and fill in the basic information, including the - other driver entry points. This is best done with the - &s.code;xf86ConfigIsaEntity()&e.code; helper function for ISA - instances or &s.code;xf86ConfigPciEntity()&e.code; for PCI instances. - These functions allocate a &s.code;ScrnInfoRec&e.code; for active - entities. Optionally &s.code;xf86AllocateScreen()&e.code; - function may also be used to allocate the &s.code;ScrnInfoRec&e.code;. - Any of these functions take care of initialising fields to defined - ``unused'' values. - - Claim the entities for each instance of the hardware found. This - prevents other drivers from claiming the same hardware. - - Must leave hardware in the same state it found it in, and must not - do any hardware initialisation. - - All detection can be overridden via the config file, and that - parsed information is available to the driver at this stage. - - Returns &s.code;TRUE&e.code; if one or more instances are found, - and &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;int xf86MatchDevice(const char *drivername, - &f.indent;GDevPtr **driversectlist)&e.code; - <quote><p> - - This function takes the name of the driver and returns via - &s.code;driversectlist&e.code; a list of device sections that - match the driver name. The function return value is the number - of matches found. If a fatal error is encountered the return - value is &s.code;-1&e.code;. - - The caller should use &s.code;xfree()&e.code; to free - &s.code;*driversectlist&e.code; when it is no longer needed. - - </quote> - - &s.code;ScrnInfoPtr xf86AllocateScreen(DriverPtr drv, int flags)&e.code; - <quote><p> - This function allocates a new &s.code;ScrnInfoRec&e.code; in the - &s.code;xf86Screens[]&e.code; array. This function is normally - called by the video driver &s.code;ChipProbe()&e.code; functions. - The return value is a pointer to the newly allocated - &s.code;ScrnInfoRec&e.code;. The &s.code;scrnIndex&e.code;, - &s.code;origIndex&e.code;, &s.code;module&e.code; and - &s.code;drv&e.code; fields are initialised. The reference count - in &s.code;drv&e.code; is incremented. The storage for any - currently allocated ``privates'' pointers is also allocated and - the &s.code;privates&e.code; field initialised (the privates data - is of course not allocated or initialised). This function never - returns on failure. If the allocation fails, the server exits - with a fatal error. The flags value is not currently used, and - should be set to zero. - </quote> - </quote> - - At the completion of this, a list of &s.code;ScrnInfoRecs&e.code; - have been allocated in the &s.code;xf86Screens[]&e.code; array, and - the associated entities and fixed resources have been claimed. The - following &s.code;ScrnInfoRec&e.code; fields must be initialised at - this point: - - <quote><verb> - driverVersion - driverName - scrnIndex(*) - origIndex(*) - drv(*) - module(*) - name - Probe - PreInit - ScreenInit - EnterVT - LeaveVT - numEntities - entityList - access - </verb></quote> - - <tt>(*)</tt> These are initialised when the &s.code;ScrnInfoRec&e.code; - is allocated, and not explicitly by the driver. - - The following &s.code;ScrnInfoRec&e.code; fields must be initialised - if the driver is going to use them: - - <quote><verb> - SwitchMode - AdjustFrame - FreeScreen - ValidMode - </verb></quote> - -<sect1>Matching Screens -<p> - - This is done at the start of the first server generation only. - - After the Probe phase is finished, there will be some number of - &s.code;ScrnInfoRecs&e.code;. These are then matched with the active - &k.screen; sections in the xorg.conf, and those not having an active - &k.screen; section are deleted. If the number of remaining screens - is 0, &s.code;InitOutput()&e.code; sets - &s.code;screenInfo.numScreens&e.code; to &s.code;0&e.code; and - returns. - - At this point the following fields of the &s.code;ScrnInfoRecs&e.code; - must be initialised: - - <quote><verb> - confScreen - </verb></quote> - - -<sect1>Allocate non-conflicting resources -<p> - - This is done at the start of the first server generation only. - - Before calling the drivers again, the resource information collected - from the Probe phase is processed. This includes checking the extent - of PCI resources for the probed devices, and resolving any conflicts - in the relocatable PCI resources. It also reports conflicts, checks - bus routing issues, and anything else that is needed to enable the - entities for the next phase. - - If any drivers registered an &s.code;EntityInit()&e.code; function - during the Probe phase, then they are called here. - - -<sect1>Sort the Screens and pre-check Monitor Information -<p> - - This is done at the start of the first server generation only. - - The list of screens is sorted to match the ordering requested in the - config file. - - The list of modes for each active monitor is checked against the - monitor's parameters. Invalid modes are pruned. - - -<sect1>PreInit -<p> - - This is done at the start of the first server generation only. - - For each &s.code;ScrnInfoRec&e.code;, enable access to the screens entities and call - the &s.code;ChipPreInit()&e.code; function. - - <quote><p> - &s.code;Bool ChipPreInit(ScrnInfoRec screen, int flags)&e.code; - <quote><p> - The purpose of this function is to find out all the information - required to determine if the configuration is usable, and to - initialise those parts of the &s.code;ScrnInfoRec&e.code; that - can be set once at the beginning of the first server generation. - - The number of entities registered for the screen should be checked - against the expected number (most drivers expect only one). The - entity information for each of them should be retrieved (with - &s.code;xf86GetEntityInfo()&e.code;) and checked for the correct - bus type and that none of the sharable resources registered during - the Probe phase was rejected. - - Access to resources for the entities that can be controlled in a - device-independent way are enabled before this function is called. - If the driver needs to access any resources that it has disabled - in an &s.code;EntityInit()&e.code; function that it registered, - then it may enable them here providing that it disables them before - this function returns. - - This includes probing for video memory, clocks, ramdac, and all - other HW info that is needed. It includes determining the - depth/bpp/visual and related info. It includes validating and - determining the set of video modes that will be used (and anything - that is required to determine that). - - This information should be determined in the least intrusive way - possible. The state of the HW must remain unchanged by this - function. Although video memory (including MMIO) may be mapped - within this function, it must be unmapped before returning. Driver - specific information should be stored in a structure hooked into - the &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; - field. Any other modules which require persistent data (ie data - that persists across server generations) should be initialised in - this function, and they should allocate a ``privates'' index to - hook their data into by calling - &s.code;xf86AllocateScrnInfoPrivateIndex().&e.code; The ``privates'' - data is persistent. - - Helper functions for some of these things are provided at the - XFree86 common level, and the driver can choose to make use of - them. - - All additional resources that the screen needs must be registered - here. This should be done with - &s.code;xf86RegisterResources()&e.code;. If some of the fixed - resources registered in the Probe phase are not needed or not - decoded by the hardware when in the OPERATING server state, their - status should be updated with - &s.code;xf86SetOperatingState()&e.code;. - - Modules may be loaded at any point in this function, and all - modules that the driver will need must be loaded before the end - of this function. Either the &s.code;xf86LoadSubModule()&e.code; - or the &s.code;xf86LoadDrvSubModule()&e.code; function should be - used to load modules depending on whether a - &s.code;ScrnInfoRec&e.code; has been set up. A driver may unload - a module within this function if it was only needed temporarily, - and the &s.code;xf86UnloadSubModule()&e.code; function should be used - to do that. Otherwise there is no need to explicitly unload modules - because the loader takes care of module dependencies and will - unload submodules automatically if/when the driver module is - unloaded. - - The bulk of the &s.code;ScrnInfoRec&e.code; fields should be filled - out in this function. - - &s.code;ChipPreInit()&e.code; returns &s.code;FALSE&e.code; when - the configuration is unusable in some way (unsupported depth, no - valid modes, not enough video memory, etc), and &s.code;TRUE&e.code; - if it is usable. - - It is expected that if the &s.code;ChipPreInit()&e.code; function - returns &s.code;TRUE&e.code;, then the only reasons that subsequent - stages in the driver might fail are lack or resources (like xalloc - failures). All other possible reasons for failure should be - determined by the &s.code;ChipPreInit()&e.code; function. - - </quote> - </quote> - - The &s.code;ScrnInfoRecs&e.code; for screens where the &s.code;ChipPreInit()&e.code; fails are removed. - If none remain, &s.code;InitOutput()&e.code; sets &s.code;screenInfo.numScreens&e.code; to &s.code;0&e.code; and returns. - - At this point, further fields of the &s.code;ScrnInfoRecs&e.code; would normally be - filled in. Most are not strictly mandatory, but many are required - by other layers and/or helper functions that the driver may choose - to use. The documentation for those layers and helper functions - indicates which they require. - - The following fields of the &s.code;ScrnInfoRecs&e.code; should be filled in if the - driver is going to use them: - - <quote><verb> - monitor - display - depth - pixmapBPP - bitsPerPixel - weight (>8bpp only) - mask (>8bpp only) - offset (>8bpp only) - rgbBits (8bpp only) - gamma - defaultVisual - maxHValue - maxVValue - virtualX - virtualY - displayWidth - frameX0 - frameY0 - frameX1 - frameY1 - zoomLocked - modePool - modes - currentMode - progClock (TRUE if clock is programmable) - chipset - ramdac - clockchip - numClocks (if not programmable) - clock[] (if not programmable) - videoRam - biosBase - memBase - memClk - driverPrivate - chipID - chipRev - </verb></quote> - - <quote><p> - &s.code;pointer xf86LoadSubModule(ScrnInfoPtr pScrn, const char *name)&e.code: - and - &s.code;pointer xf86LoadDrvSubModule(DriverPtr drv, const char *name)&e.code: - <quote><p> - Load a module that a driver depends on. This function loads the - module &s.code;name&e.code; as a sub module of the driver. The - return value is a handle identifying the new module. If the load - fails, the return value will be &s.code;NULL&e.code;. If a driver - needs to explicitly unload a module it has loaded in this way, - the return value must be saved and passed to - &s.code;xf86UnloadSubModule()&e.code; when unloading. - - </quote> - - &s.code;void xf86UnloadSubModule(pointer module)&e.code; - <quote><p> - Unloads the module referenced by &s.code;module&e.code;. - &s.code;module&e.code; should be a pointer returned previously - by &s.code;xf86LoadSubModule()&e.code; or - &s.code;xf86LoadDrvSubModule()&e.code; . - - </quote> - </quote> - -<sect1>Cleaning up Unused Drivers -<p> - - At this point it is known which screens will be in use, and which - drivers are being used. Unreferenced drivers (and modules they - may have loaded) are unloaded here. - - -<sect1>Consistency Checks -<p> - - The parameters that must be global to the server, like pixmap formats, - bitmap bit order, bitmap scanline unit and image byte order are - compared for each of the screens. If a mismatch is found, the server - exits with an appropriate message. - - -<sect1>Check if Resource Control is Needed -<p> - - Determine if resource access control is needed. This is the case - if more than one screen is used. If necessary the RAC wrapper module - is loaded. - -<sect1>AddScreen (ScreenInit) -<p> - - At this point, the valid screens are known. - &s.code;AddScreen()&e.code; is called for each of them, passing - &s.code;ChipScreenInit()&e.code; as the argument. - &s.code;AddScreen()&e.code; is a DIX function that allocates a new - &s.code;screenInfo.screen[]&e.code; entry (aka - &s.code;pScreen&e.code;), and does some basic initialisation of it. - It then calls the &s.code;ChipScreenInit()&e.code; function, with - &s.code;pScreen&e.code; as one of its arguments. If - &s.code;ChipScreenInit()&e.code; returns &s.code;FALSE&e.code;, - &s.code;AddScreen()&e.code; returns &s.code;-1&e.code;. Otherwise - it returns the index of the screen. &s.code;AddScreen()&e.code; - should only fail because of programming errors or failure to allocate - resources (like memory). All configuration problems should be - detected BEFORE this point. - - <quote><p> - &s.code;Bool ChipScreenInit(int index, ScreenPtr pScreen, - &f.indent;int argc, char **argv)&e.code; - <quote><p> - This is called at the start of each server generation. - - Fill in all of &s.code;pScreen&e.code;, possibly doing some of - this by calling ScreenInit functions from other layers like mi, - framebuffers (cfb, etc), and extensions. - - Decide which operations need to be placed under resource access - control. The classes of operations are the frame buffer operations - (&s.code;RAC_FB&e.code;), the pointer operations - (&s.code;RAC_CURSOR&e.code;), the viewport change operations - (&s.code;RAC_VIEWPORT&e.code;) and the colormap operations - (&s.code;RAC_COLORMAP&e.code;). Any operation that requires - resources which might be disabled during OPERATING state should - be set to use RAC. This can be specified separately for memory - and IO resources (the &s.code;racMemFlags&e.code; and - &s.code;racIoFlags&e.code; fields of the &s.code;ScrnInfoRec&e.code; - respectively). - - Map any video memory or other memory regions. - - Save the video card state. Enough state must be saved so that - the original state can later be restored. - - Initialise the initial video mode. The &s.code;ScrnInfoRec&e.code;'s - &s.code;vtSema&e.code; field should be set to &s.code;TRUE&e.code; - just prior to changing the video hardware's state. - - </quote> - </quote> - - - The &s.code;ChipScreenInit()&e.code; function (or functions from other - layers that it calls) should allocate entries in the - &s.code;ScreenRec&e.code;'s &s.code;devPrivates&e.code; area by - calling &s.code;AllocateScreenPrivateIndex()&e.code; if it needs - per-generation storage. Since the &s.code;ScreenRec&e.code;'s - &s.code;devPrivates&e.code; information is cleared for each server - generation, this is the correct place to initialise it. - - After &s.code;AddScreen()&e.code; has successfully returned, the - following &s.code;ScrnInfoRec&e.code; fields are initialised: - - <quote><verb> - pScreen - racMemFlags - racIoFlags - </verb></quote> - - The &s.code;ChipScreenInit()&e.code; function should initialise the - &s.code;CloseScreen&e.code; and &s.code;SaveScreen&e.code; fields - of &s.code;pScreen&e.code;. The old value of - &s.code;pScreen->CloseScreen&e.code; should be saved as part of - the driver's per-screen private data, allowing it to be called from - &s.code;ChipCloseScreen()&e.code;. This means that the existing - &s.code;CloseScreen()&e.code; function is wrapped. - -<sect1>Finalising RAC Initialisation -<p> - - After all the &s.code;ChipScreenInit()&e.code; functions have been - called, each screen has registered its RAC requirements. This - information is used to determine which shared resources are requested - by more than one driver and set the access functions accordingly. - This is done following these rules: - - <enum> - <item>The sharable resources registered by each entity are compared. - If a resource is registered by more than one entity the entity - will be marked to indicate that it needs to share this resources - type (IO or MEM). - - <item>A resource marked ``disabled'' during OPERATING state will be - ignored entirely. - - <item>A resource marked ``unused'' will only conflict with an overlapping - resource of an other entity if the second is actually in use - during OPERATING state. - - <item>If an ``unused'' resource was found to conflict but the entity - does not use any other resource of this type the entire resource - type will be disabled for that entity. - </enum> - - -<sect1>Finishing InitOutput() -<p> - - At this point &s.code;InitOutput()&e.code; is finished, and all the - screens have been setup in their initial video mode. - - -<sect1>Mode Switching -<p> - - When a SwitchMode event is received, &s.code;ChipSwitchMode()&e.code; - is called (when it exists): - - <quote><p> - &s.code;Bool ChipSwitchMode(int index, DisplayModePtr mode, int flags)&e.code; - <quote><p> - Initialises the new mode for the screen identified by - &s.code;index;&e.code;. The viewport may need to be adjusted - also. - - </quote> - </quote> - - -<sect1>Changing Viewport -<p> - - When a Change Viewport event is received, - &s.code;ChipAdjustFrame()&e.code; is called (when it exists): - - <quote><p> - &s.code;void ChipAdjustFrame(int index, int x, int y, int flags)&e.code; - <quote><p> - Changes the viewport for the screen identified by - &s.code;index;&e.code;. - - It should be noted that many chipsets impose restrictions on where the - viewport may be placed in the virtual resolution, either for alignment - reasons, or to prevent the start of the viewport from being positioned - within a pixel (as can happen in a 24bpp mode). After calculating the - value the chipset's panning registers need to be set to for non-DGA - modes, this function should recalculate the ScrnInfoRec's - &s.code;frameX0&e.code;, &s.code;frameY0&e.code, &s.code;frameX1&e.code; - and &s.code;frameY1&e.code; fields to correspond to that value. If - this is not done, switching to another mode might cause the position - of a hardware cursor to change. - - </quote> - </quote> - - -<sect1>VT Switching -<p> - - When a VT switch event is received, &s.code;xf86VTSwitch()&e.code; - is called. &s.code;xf86VTSwitch()&e.code; does the following: - - <descrip> - <tag>On ENTER:</tag> - <itemize> - <item>enable port I/O access - - <item>save and initialise the bus/resource state - - <item>enter the SETUP server state - - <item>calls &s.code;ChipEnterVT()&e.code; for each screen - - <item>enter the OPERATING server state - - <item>validate GCs - - <item>Restore fb from saved pixmap for each screen - - <item>Enable all input devices - </itemize> - <tag>On LEAVE:</tag> - <itemize> - <item>Save fb to pixmap for each screen - - <item>validate GCs - - <item>enter the SETUP server state - - <item>calls &s.code;ChipLeaveVT()&e.code; for each screen - - <item>disable all input devices - - <item>restore bus/resource state - - <item>disables port I/O access - </itemize> - </descrip> - - <quote><p> - &s.code;Bool ChipEnterVT(int index, int flags)&e.code; - <quote><p> - This function should initialise the current video mode and - initialise the viewport, turn on the HW cursor if appropriate, - etc. - - Should it re-save the video state before initialising the video - mode? - - </quote> - - &s.code;void ChipLeaveVT(int index, int flags)&e.code; - <quote><p> - This function should restore the saved video state. If - appropriate it should also turn off the HW cursor, and invalidate - any pixmap/font caches. - - </quote> - - Optionally, &s.code;ChipLeaveVT()&e.code; may also unmap memory - regions. If so, &s.code;ChipEnterVT()&e.code; will need to remap - them. Additionally, if an aperture used to access video memory is - unmapped and remapped in this fashion, &s.code;ChipEnterVT()&e.code; - will also need to notify the framebuffer layers of the aperture's new - location in virtual memory. This is done with a call to the screen's - &s.code;ModifyPixmapHeader()&e.code; function, as follows - - <quote><p> - &s.code;(*pScreen->ModifyPixmapHeader)(pScrn->ppix, - &f.indent;-1, -1, -1, -1, -1, <it>NewApertureAddress</it>);&e.code; - <quote><p> - where the &s.code``ppix''&e.code; field in a ScrnInfoRec - points to the pixmap used by the screen's - &s.code;SaveRestoreImage()&e.code; function to hold the screen's - contents while switched out. - - </quote> - </quote> - - Currently, aperture remapping, as described here, should not be - attempted if the driver uses the &s.code;xf8_16bpp&e.code; or - &s.code;xf8_32bpp&e.code; framebuffer layers. A pending - restructuring of VT switching will address this restriction in - the near future. - - </quote> - - Other layers may wrap the &s.code;ChipEnterVT()&e.code; and - &s.code;ChipLeaveVT()&e.code; functions if they need to take some - action when these events are received. - -<sect1>End of server generation -<p> - - At the end of each server generation, the DIX layer calls - &s.code;ChipCloseScreen()&e.code; for each screen: - - <quote><p> - &s.code;Bool ChipCloseScreen(int index, ScreenPtr pScreen)&e.code; - <quote><p> - This function should restore the saved video state and unmap the - memory regions. - - It should also free per-screen data structures allocated by the - driver. Note that the persistent data held in the - &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; field - should not be freed here because it is needed by subsequent server - generations. - - The &s.code;ScrnInfoRec&e.code;'s &s.code;vtSema&e.code; field - should be set to &s.code;FALSE&e.code; once the video HW state - has been restored. - - Before freeing the per-screen driver data the saved - &s.code;CloseScreen&e.code; value should be restored to - &s.code;pScreen->CloseScreen&e.code;, and that function should - be called after freeing the data. - - </quote> - </quote> - -<sect>Optional Driver Functions -<p> - -The functions outlined here can be called from the XFree86 common layer, -but their presence is optional. - -<sect1>Mode Validation -<p> - - When a mode validation helper supplied by the XFree86-common layer is - being used, it can be useful to provide a function to check for hw - specific mode constraints: - - <quote><p> - &s.code;ModeStatus ChipValidMode(int index, DisplayModePtr mode, - &f.indent;Bool verbose, int flags)&e.code; - <quote><p> - Check the passed mode for hw-specific constraints, and return the - appropriate status value. - - </quote> - </quote> - -<p> -This function may also modify the effective timings and clock of the passed -mode. These have been stored in the mode's &s.code;Crtc*&e.code; and -&s.code;SynthClock&e.code; elements, and have already been adjusted for -interlacing, doublescanning, multiscanning and clock multipliers and dividers. -The function should not modify any other mode field, unless it wants to modify -the mode timings reported to the user by &s.code;xf86PrintModes()&e.code;. - -<p> -The function is called once for every mode in the xorg.conf Monitor section -assigned to the screen, with &s.code;flags&e.code; set to -&s.code;MODECHECK_INITIAL&e.code;. It is subsequently called for every mode -in the xorg.conf Display subsection assigned to the screen, with -&s.code;flags&e.code; set to &s.code;MODECHECK_FINAL&e.code;. In the second -case, the mode will have successfully passed all other tests. In addition, -the &s.code;ScrnInfoRec&e.code;'s &s.code;virtualX&e.code;, -&s.code;virtualY&e.code; and &s.code;displayWidth&e.code; fields will have been -set as if the mode to be validated were to be the last mode accepted. - -<p> -In effect, calls with MODECHECK_INITIAL are intended for checks that do not -depend on any mode other than the one being validated, while calls with -MODECHECK_FINAL are intended for checks that may involve more than one mode. - -<sect1>Free screen data -<p> - - When a screen is deleted prior to the completion of the ScreenInit - phase the &s.code;ChipFreeScreen()&e.code; function is called when defined. - - <quote><p> - &s.code;void ChipFreeScreen(int scrnindex, int flags)&e.code; - <quote><p> - Free any driver-allocated data that may have been allocated up to - and including an unsuccessful &s.code;ChipScreenInit()&e.code; - call. This would predominantly be data allocated by - &s.code;ChipPreInit()&e.code; that persists across server - generations. It would include the &s.code;driverPrivate&e.code;, - and any ``privates'' entries that modules may have allocated. - - </quote> - </quote> - - -<sect>Recommended driver functions -<p> - -The functions outlined here are for internal use by the driver only. -They are entirely optional, and are never accessed directly from higher -layers. The sample function declarations shown here are just examples. -The interface (if any) used is up to the driver. - -<sect1>Save -<p> - - Save the video state. This could be called from &s.code;ChipScreenInit()&e.code; and - (possibly) &s.code;ChipEnterVT()&e.code;. - - <quote><p> - &s.code;void ChipSave(ScrnInfoPtr pScrn)&e.code; - <quote><p> - Saves the current state. This will only be saving pre-server - states or states before returning to the server. There is only - one current saved state per screen and it is stored in private - storage in the screen. - - </quote> - </quote> - -<sect1>Restore -<p> - - Restore the original video state. This could be called from the - &s.code;ChipLeaveVT()&e.code; and &s.code;ChipCloseScreen()&e.code; - functions. - - <quote><p> - &s.code;void ChipRestore(ScrnInfoPtr pScrn)&e.code; - <quote><p> - Restores the saved state from the private storage. Usually only - used for restoring text modes. - - </quote> - </quote> - - -<sect1>Initialise Mode -<p> - - Initialise a video mode. This could be called from the - &s.code;ChipScreenInit()&e.code;, &s.code;ChipSwitchMode()&e.code; - and &s.code;ChipEnterVT()&e.code; functions. - - <quote><p> - &s.code;Bool ChipModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)&e.code; - <quote><p> - Programs the hardware for the given video mode. - - </quote> - </quote> - - -<sect>Data and Data Structures -<p> - -<sect1>Command line data -<p> - -Command line options are typically global, and are stored in global -variables. These variables are read-only and are available to drivers -via a function call interface. Most of these command line values are -processed via helper functions to ensure that they are treated consistently -by all drivers. The other means of access is provided for cases where -the supplied helper functions might not be appropriate. - -Some of them are: - -<quote><verb> - xf86Verbose verbosity level - xf86Bpp -bpp from the command line - xf86Depth -depth from the command line - xf86Weight -weight from the command line - xf86Gamma -{r,g,b,}gamma from the command line - xf86FlipPixels -flippixels from the command line - xf86ProbeOnly -probeonly from the command line - defaultColorVisualClass -cc from the command line -</verb></quote> - -If we ever do allow for screen-specific command line options, we may -need to rethink this. - -These can be accessed in a read-only manner by drivers with the following -functions: - - <quote><p> - &s.code;int xf86GetVerbosity()&e.code; - <quote><p> - Returns the value of &s.code;xf86Verbose&e.code;. - - </quote> - - &s.code;int xf86GetDepth()&e.code; - <quote><p> - Returns the &s.cmd;-depth&e.cmd; command line setting. If not - set on the command line, &s.code;-1&e.code; is returned. - - </quote> - - &s.code;rgb xf86GetWeight()&e.code; - <quote><p> - Returns the &s.cmd;-weight&e.cmd; command line setting. If not - set on the command line, &s.code;{0, 0, 0}&e.code; is returned. - - </quote> - - &s.code;Gamma xf86GetGamma()&e.code; - <quote><p> - Returns the &s.cmd;-gamma&e.cmd; or &s.cmd;-rgamma&e.cmd;, - &s.cmd;-ggamma&e.cmd;, &s.cmd;-bgamma&e.cmd; command line settings. - If not set on the command line, &s.code;{0.0, 0.0, 0.0}&e.code; - is returned. - - </quote> - - &s.code;Bool xf86GetFlipPixels()&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; if &s.cmd;-flippixels&e.cmd; is - present on the command line, and &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;const char *xf86GetServerName()&e.code; - <quote><p> - Returns the name of the X server from the command line. - - </quote> - </quote> - -<sect1>Data handling -<p> - -Config file data contains parts that are global, and parts that are -Screen specific. All of it is parsed into data structures that neither -the drivers or most other parts of the server need to know about. - -The global data is typically not required by drivers, and as such, most -of it is stored in the private &s.code;xf86InfoRec&e.code;. - -The screen-specific data collected from the config file is stored in -screen, device, display, monitor-specific data structures that are separate -from the &s.code;ScrnInfoRecs&e.code;, with the appropriate elements/fields -hooked into the &s.code;ScrnInfoRecs&e.code; as required. The screen -config data is held in &s.code;confScreenRec&e.code;, device data in -the &s.code;GDevRec&e.code;, monitor data in the &s.code;MonRec&e.code;, -and display data in the &s.code;DispRec&e.code;. - -The XFree86 common layer's screen specific data (the actual data in use -for each screen) is held in the &s.code;ScrnInfoRecs&e.code;. As has -been outlined above, the &s.code;ScrnInfoRecs&e.code; are allocated at probe -time, and it is the responsibility of the Drivers' &s.code;Probe()&e.code; -and &s.code;PreInit()&e.code; functions to finish filling them in based -on both data provided on the command line and data provided from the -Config file. The precedence for this is: - - <quote> - command line -> config file -> probed/default data - </quote> - -For most things in this category there are helper functions that the -drivers can use to ensure that the above precedence is consistently -used. - -As well as containing screen-specific data that the XFree86 common layer -(including essential parts of the server infrastructure as well as helper -functions) needs to access, it also contains some data that drivers use -internally. When considering whether to add a new field to the -&s.code;ScrnInfoRec&e.code;, consider the balance between the convenience -of things that lots of drivers need and the size/obscurity of the -&s.code;ScrnInfoRec&e.code;. - -Per-screen driver specific data that cannot be accommodated with the -static &s.code;ScrnInfoRec&e.code; fields is held in a driver-defined -data structure, a pointer to which is assigned to the -&s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; field. This -is per-screen data that persists across server generations (as does the -bulk of the static &s.code;ScrnInfoRec&e.code; data). It would typically -also include the video card's saved state. - -Per-screen data for other modules that the driver uses (for example, -the XAA module) that is reset for each server generation is hooked into -the &s.code;ScrnInfoRec&e.code; through it's &s.code;privates&e.code; -field. - -Once it has stabilised, the data structures and variables accessible to -video drivers will be documented here. In the meantime, those things -defined in the &s.code;xf86.h&e.code; and &s.code;xf86str.h&e.code; -files are visible to video drivers. Things defined in -&s.code;xf86Priv.h&e.code; and &s.code;xf86Privstr.h&e.code; are NOT -intended to be visible to video drivers, and it is an error for a driver -to include those files. - - -<sect1>Accessing global data -<p> - -Some other global state information that the drivers may access via -functions is as follows: - - <quote><p> - &s.code;Bool xf86ServerIsExiting()&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; if the server is at the end of a - generation and is in the process of exiting, and - &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;Bool xf86ServerIsResetting()&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; if the server is at the end of a - generation and is in the process of resetting, and - &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;Bool xf86ServerIsInitialising()&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; if the server is at the beginning of - a generation and is in the process of initialising, and - &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;Bool xf86ServerIsOnlyProbing()&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; if the -probeonly command line flag - was specified, and &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;Bool xf86CaughtSignal()&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; if the server has caught a signal, - and &s.code;FALSE&e.code; otherwise. - - </quote> - </quote> - -<sect1>Allocating private data -<p> - -A driver and any module it uses may allocate per-screen private storage -in either the &s.code;ScreenRec&e.code; (DIX level) or -&s.code;ScrnInfoRec&e.code; (XFree86 common layer level). -&s.code;ScreenRec&e.code; storage persists only for a single server -generation, and &s.code;ScrnInfoRec&e.code; storage persists across -generations for the lifetime of the server. - -The &s.code;ScreenRec&e.code; &s.code;devPrivates&e.code; data must be -reallocated/initialised at the start of each new generation. This is -normally done from the &s.code;ChipScreenInit()&e.code; function, and -Init functions for other modules that it calls. Data allocated in this -way should be freed by the driver's &s.code;ChipCloseScreen()&e.code; -functions, and Close functions for other modules that it calls. A new -&s.code;devPrivates&e.code; entry is allocated by calling the -&s.code;AllocateScreenPrivateIndex()&e.code; function. - - <quote><p> - &s.code;int AllocateScreenPrivateIndex()&e.code; - <quote><p> - This function allocates a new element in the - &s.code;devPrivates&e.code; field of all currently existing - &s.code;ScreenRecs&e.code;. The return value is the index of this - new element in the &s.code;devPrivates&e.code; array. The - &s.code;devPrivates&e.code; field is of type - &s.code;DevUnion&e.code;: - - <verb> - typedef union _DevUnion { - pointer ptr; - long val; - unsigned long uval; - pointer (*fptr)(void); - } DevUnion; - </verb> - - which allows the element to be used for any of the above types. - It is commonly used as a pointer to data that the caller allocates - after the new index has been allocated. - - This function will return &s.code;-1&e.code; when there is an - error allocating the new index. - - </quote> - </quote> - -The &s.code;ScrnInfoRec&e.code; &s.code;privates&e.code; data persists -for the life of the server, so only needs to be allocated once. This -should be done from the &s.code;ChipPreInit()&e.code; function, and Init -functions for other modules that it calls. Data allocated in this way -should be freed by the driver's &s.code;ChipFreeScreen()&e.code; functions, -and Free functions for other modules that it calls. A new -&s.code;privates&e.code; entry is allocated by calling the -&s.code;xf86AllocateScrnInfoPrivateIndex()&e.code; function. - - - <quote><p> - &s.code;int xf86AllocateScrnInfoPrivateIndex()&e.code; - <quote><p> - This function allocates a new element in the &s.code;privates&e.code; - field of all currently existing &s.code;ScrnInfoRecs&e.code;. - The return value is the index of this new element in the - &s.code;privates&e.code; array. The &s.code;privates&e.code; - field is of type &s.code;DevUnion&e.code;: - - <verb> - typedef union _DevUnion { - pointer ptr; - long val; - unsigned long uval; - pointer (*fptr)(void); - } DevUnion; - </verb> - - which allows the element to be used for any of the above types. - It is commonly used as a pointer to data that the caller allocates - after the new index has been allocated. - - This function will not return when there is an error allocating - the new index. When there is an error it will cause the server - to exit with a fatal error. The similar function for allocation - privates in the &s.code;ScreenRec&e.code; - (&s.code;AllocateScreenPrivateIndex()&e.code;) differs in this - respect by returning &s.code;-1&e.code; when the allocation fails. - - </quote> - </quote> - -<sect>Keeping Track of Bus Resources<label id="rac"> -<p> - -<sect1>Theory of Operation -<p> - -The XFree86 common layer has knowledge of generic access control mechanisms -for devices on certain bus systems (currently the PCI bus) as well as -of methods to enable or disable access to the buses itself. Furthermore -it can access information on resources decoded by these devices and if -necessary modify it. - -When first starting the Xserver collects all this information, saves it -for restoration, checks it for consistency, and if necessary, corrects -it. Finally it disables all resources on a generic level prior to -calling any driver function. - -When the &s.code;Probe()&e.code; function of each driver is called the -device sections are matched against the devices found in the system. -The driver may probe devices at this stage that cannot be identified by -using device independent methods. Access to all resources that can be -controlled in a device independent way is disabled. The -&s.code;Probe()&e.code; function should register all non-relocatable -resources at this stage. If a resource conflict is found between -exclusive resources the driver will fail immediately. Optionally the -driver might specify an &s.code;EntityInit()&e.code;, -&s.code;EntityLeave()&e.code; and &s.code;EntityEnter()&e.code; function. - -&s.code;EntityInit()&e.code; can be used to disable any shared resources -that are not controlled by the generic access control functions. It is -called prior to the PreInit phase regardless if an entity is active or -not. When calling the &s.code;EntityInit()&e.code;, -&s.code;EntityEnter()&e.code; and &s.code;EntityLeave()&e.code; functions -the common level will disable access to all other entities on a generic -level. Since the common level has no knowledge of device specific -methods to disable access to resources it cannot be guaranteed that -certain resources are not decoded by any other entity until the -&s.code;EntityInit()&e.code; or &s.code;EntityEnter()&e.code; phase is -finished. Device drivers should therefore register all those resources -which they are going to disable. If these resources are never to be -used by any driver function they may be flagged &s.code;ResInit&e.code; -so that they can be removed from the resource list after processing all -&s.code;EntityInit()&e.code; functions. &s.code;EntityEnter()&e.code; -should disable decoding of all resources which are not registered as -exclusive and which are not handled by the generic access control in -the common level. The difference to &s.code;EntityInit()&e.code; is -that the latter one is only called once during lifetime of the server. -It can therefore be used to set up variables prior to disabling resources. -&s.code;EntityLeave()&e.code; should restore the original state when -exiting the server or switching to a different VT. It also needs to -disable device specific access functions if they need to be disabled on -server exit or VT switch. The default state is to enable them before -giving up the VT. - -In &s.code;PreInit()&e.code; phase each driver should check if any -sharable resources it has registered during &s.code;Probe()&e.code; has -been denied and take appropriate action which could simply be to fail. -If it needs to access resources it has disabled during -&s.code;EntitySetup()&e.code; it can do so provided it has registered -these and will disable them before returning from -&s.code;PreInit()&e.code;. This also applies to all other driver -functions. Several functions are provided to request resource ranges, -register these, correct PCI config space and add replacements for the -generic access functions. Resources may be marked ``disabled'' or -``unused'' during OPERATING stage. Although these steps could also be -performed in &s.code;ScreenInit()&e.code;, this is not desirable. - -Following &s.code;PreInit()&e.code; phase the common level determines -if resource access control is needed. This is the case if more than -one screen is used. If necessary the RAC wrapper module is loaded. In -&s.code;ScreenInit()&e.code; the drivers can decide which operations -need to be placed under RAC. Available are the frame buffer operations, -the pointer operations and the colormap operations. Any operation that -requires resources which might be disabled during OPERATING state should -be set to use RAC. This can be specified separately for memory and IO -resources. - -When &s.code;ScreenInit()&e.code; phase is done the common level will -determine which shared resources are requested by more than one driver -and set the access functions accordingly. This is done following these -rules: - -<enum> -<item>The sharable resources registered by each entity are compared. If - a resource is registered by more than one entity the entity will be - marked to need to share this resources type (&s.code;IO&e.code; or - &s.code;MEM&e.code;). - -<item>A resource marked ``disabled'' during OPERATING state will be ignored - entirely. - -<item>A resource marked ``unused'' will only conflicts with an overlapping - resource of an other entity if the second is actually in use during - OPERATING state. - -<item>If an ``unused'' resource was found to conflict however the entity - does not use any other resource of this type the entire resource type - will be disabled for that entity. -</enum> - -The driver has the choice among different ways to control access to -certain resources: - -<enum> -<item>It can rely on the generic access functions. This is probably the - most common case. Here the driver only needs to register any resource - it is going to use. - -<item>It can replace the generic access functions by driver specific - ones. This will mostly be used in cases where no generic access - functions are available. In this case the driver has to make sure - these resources are disabled when entering the &s.code;PreInit()&e.code; - stage. Since the replacement functions are registered in - &s.code;PreInit()&e.code; the driver will have to enable these - resources itself if it needs to access them during this state. The - driver can specify if the replacement functions can control memory - and/or I/O resources separately. - -<item>The driver can enable resources itself when it needs them. Each - driver function enabling them needs to disable them before it will - return. This should be used if a resource which can be controlled - in a device dependent way is only required during SETUP state. This - way it can be marked ``unused'' during OPERATING state. -</enum> - -A resource which is decoded during OPERATING state however never accessed -by the driver should be marked unused. - -Since access switching latencies are an issue during Xserver operation, -the common level attempts to minimize the number of entities that need -to be placed under RAC control. When a wrapped operation is called, -the &s.code;EnableAccess()&e.code; function is called before control is -passed on. &s.code;EnableAccess()&e.code; checks if a screen is under -access control. If not it just establishes bus routing and returns. -If the screen needs to be under access control, -&s.code;EnableAccess()&e.code; determines which resource types -(&s.code;MEM&e.code;, &s.code;IO&e.code;) are required. Then it tests -if this access is already established. If so it simply returns. If -not it disables the currently established access, fixes bus routing and -enables access to all entities registered for this screen. - -Whenever a mode switch or a VT-switch is performed the common level will -return to SETUP state. - -<sect1>Resource Types -<p> - -Resource have certain properties. When registering resources each range -is accompanied by a flag consisting of the ORed flags of the different -properties the resource has. Each resource range may be classified -according to - -<itemize> - <item>its physical properties i.e., if it addresses - memory (&s.code;ResMem&e.code;) or - I/O space (&s.code;ResIo&e.code;), - <item>if it addresses a - block (&s.code;ResBlock&e.code;) or - sparse (&s.code;ResSparse&e.code;) - range, - <item>its access properties. -</itemize> - -There are two known access properties: - -<itemize> - <item>&s.code;ResExclusive&e.code; - for resources which may not be shared with any other device and - <item>&s.code;ResShared&e.code; - for resources which can be disabled and therefore can be shared. -</itemize> - -If it is necessary to test a resource against any type a generic access -type &s.code;ResAny&e.code; is provided. If this is set the resource -will conflict with any resource of a different entity intersecting its -range. Further it can be specified that a resource is decoded however -never used during any stage (&s.code;ResUnused&e.code;) or during -OPERATING state (&s.code;ResUnusedOpr&e.code;). A resource only visible -during the init functions (ie. &s.code;EntityInit()&e.code;, -&s.code;EntityEnter()&e.code; and &s.code;EntityLeave()&e.code; should -be registered with the flag &s.code;ResInit&e.code;. A resource that -might conflict with background resource ranges may be flagged with -&s.code;ResBios&e.code;. This might be useful when registering resources -ranges that were assigned by the system Bios. - -Several predefined resource lists are available for VGA and 8514/A -resources in &s.code;common/xf86Resources.h&e.code;. - -<sect1>Available Functions<label id="avail"> -<p> - -The functions provided for resource management are listed in their order -of use in the driver. - - -<sect2>Probe Phase -<p> - -In this phase each driver detects those resources it is able to drive, -creates an entity record for each of them, registers non-relocatable -resources and allocates screens and adds the resources to screens. - -Two helper functions are provided for matching device sections in the -xorg.conf file to the devices: - - <quote><p> - &s.code;int xf86MatchPciInstances(const char *driverName, int vendorID, - &f.indent;SymTabPtr chipsets, PciChipsets *PCIchipsets, - &f.indent;GDevPtr *devList, int numDevs, DriverPtr drvp, - &f.indent;int **foundEntities)&e.code; - <quote><p> - This function finds matches between PCI cards that a driver supports - and config file device sections. It is intended for use in the - &s.code;ChipProbe()&e.code; function of drivers for PCI cards. - Only probed PCI devices with a vendor ID matching - &s.code;vendorID&e.code; are considered. &s.code;devList&e.code; - and &s.code;numDevs&e.code; are typically those found from - calling &s.code;xf86MatchDevice()&e.code;, and represent the active - config file device sections relevant to the driver. - &s.code;PCIchipsets&e.code; is a table that provides a mapping - between the PCI device IDs, the driver's internal chipset tokens - and a list of fixed resources. - - When a device section doesn't have a &s.key;BusID&e.key; entry it - can only match the primary video device. Secondary devices are - only matched with device sections that have a matching - &s.key;BusID&e.key; entry. - - Once the preliminary matches have been found, a final match is - confirmed by checking if the chipset override, ChipID override or - probed PCI chipset type match one of those given in the - &s.code;chipsets&e.code; and &s.code;PCIchipsets&e.code; lists. - The &s.code;PCIchipsets&e.code; list includes a list of the PCI - device IDs supported by the driver. The list should be terminated - with an entry with PCI ID &s.code;-1&e.code;". The - &s.code;chipsets&e.code; list is a table mapping the driver's - internal chipset tokens to names, and should be terminated with - a &s.code;NULL&e.code; entry. Only those entries with a - corresponding entry in the &s.code;PCIchipsets&e.code; list are - considered. The order of precedence is: config file chipset, - config file ChipID, probed PCI device ID. - - In cases where a driver handles PCI chipsets with more than one - vendor ID, it may set &s.code;vendorID&e.code; to - &s.code;0&e.code;, and OR each devID in the list with (the - vendor ID << 16). - - Entity index numbers for confirmed matches are returned as an - array via &s.code;foundEntities&e.code;. The PCI information, - chipset token and device section for each match are found in the - &s.code;EntityInfoRec&e.code; referenced by the indices. - - The function return value is the number of confirmed matches. A - return value of &s.code;-1&e.code; indicates an internal error. - The returned &s.code;foundEntities&e.code; array should be freed - by the driver with &s.code;xfree()&e.code; when it is no longer - needed in cases where the return value is greater than zero. - - </quote> - - &s.code;int xf86MatchIsaInstances(const char *driverName, - &f.indent;SymTabPtr chipsets, IsaChipsets *ISAchipsets, - &f.indent;DriverPtr drvp, FindIsaDevProc FindIsaDevice, - &f.indent;GDevPtr *devList, int numDevs, - int **foundEntities)&e.code; - <quote><p> - This function finds matches between ISA cards that a driver supports - and config file device sections. It is intended for use in the - &s.code;ChipProbe()&e.code; function of drivers for ISA cards. - &s.code;devList&e.code; and &s.code;numDevs&e.code; are - typically those found from calling &s.code;xf86MatchDevice()&e.code;, - and represent the active config file device sections relevant to - the driver. &s.code;ISAchipsets&e.code; is a table that provides - a mapping between the driver's internal chipset tokens and the - resource classes. &s.code;FindIsaDevice&e.code; is a - driver-provided function that probes the hardware and returns the - chipset token corresponding to what was detected, and - &s.code;-1&e.code; if nothing was detected. - - If the config file device section contains a chipset entry, then - it is checked against the &s.code;chipsets&e.code; list. When - no chipset entry is present, the &s.code;FindIsaDevice&e.code; - function is called instead. - - Entity index numbers for confirmed matches are returned as an - array via &s.code;foundEntities&e.code;. The chipset token and - device section for each match are found in the - &s.code;EntityInfoRec&e.code; referenced by the indices. - - The function return value is the number of confirmed matches. A - return value of &s.code;-1&e.code; indicates an internal error. - The returned &s.code;foundEntities&e.code; array should be freed - by the driver with &s.code;xfree()&e.code; when it is no longer - needed in cases where the return value is greater than zero. - - </quote> - </quote> - -These two helper functions make use of several core functions that are -available at the driver level: - - <quote><p> - &s.code;Bool xf86ParsePciBusString(const char *busID, int *bus, - &f.indent;int *device, int *func)&e.code; - <quote><p> - Takes a &s.code;BusID&e.code; string, and if it is in the correct - format, returns the PCI &s.code;bus&e.code;, &s.code;device&e.code;, - &s.code;func&e.code; values that it indicates. The format of the - string is expected to be "PCI:bus:device:func" where each of `bus', - `device' and `func' are decimal integers. The ":func" part may - be omitted, and the func value assumed to be zero, but this isn't - encouraged. The "PCI" prefix may also be omitted. The prefix - "AGP" is currently equivalent to the "PCI" prefix. If the string - isn't a valid PCI BusID, the return value is &s.code;FALSE&e.code;. - - </quote> - - - &s.code;Bool xf86ComparePciBusString(const char *busID, int bus, - &f.indent;int device, int func)&e.code; - <quote><p> - Compares a &s.code;BusID&e.code; string with PCI &s.code;bus&e.code;, - &s.code;device&e.code;, &s.code;func&e.code; values. If they - match &s.code;TRUE&e.code; is returned, and &s.code;FALSE&e.code; - if they don't. - - </quote> - - &s.code;Bool xf86ParseIsaBusString(const char *busID)&e.code; - <quote><p> - Compares a &s.code;BusID&e.code; string with the ISA bus ID string - ("ISA" or "ISA:"). If they match &s.code;TRUE&e.code; is returned, - and &s.code;FALSE&e.code; if they don't. - - </quote> - - &s.code;Bool xf86CheckPciSlot(int bus, int device, int func)&e.code; - <quote><p> - Checks if the PCI slot &s.code;bus:device:func&e.code; has been - claimed. If so, it returns &s.code;FALSE&e.code;, and otherwise - &s.code;TRUE&e.code;. - - </quote> - - &s.code;int xf86ClaimPciSlot(int bus, int device, int func, DriverPtr drvp, - &f.indent;int chipset, GDevPtr dev, Bool active)&e.code; - <quote><p> - This function is used to claim a PCI slot, allocate the associated - entity record and initialise their data structures. The return - value is the index of the newly allocated entity record, or - &s.code;-1&e.code; if the claim fails. This function should always - succeed if &s.code;xf86CheckPciSlot()&e.code; returned - &s.code;TRUE&e.code; for the same PCI slot. - - </quote> - - &s.code;Bool xf86IsPrimaryPci(void)&e.code; - <quote><p> - This function returns &s.code;TRUE&e.code; if the primary card is - a PCI device, and &s.code;FALSE&e.code; otherwise. - - </quote> - - &s.code;int xf86ClaimIsaSlot(DriverPtr drvp, int chipset, - &f.indent;GDevPtr dev, Bool active)&e.code; - <quote><p> - This allocates an entity record entity and initialise the data - structures. The return value is the index of the newly allocated - entity record. - - </quote> - - &s.code;Bool xf86IsPrimaryIsa(void)&e.code; - <quote><p> - This function returns &s.code;TRUE&e.code; if the primary card is - an ISA (non-PCI) device, and &s.code;FALSE&e.code; otherwise. - - </quote> - </quote> - -Two helper functions are provided to aid configuring entities: - <quote><p> - &s.code;ScrnInfoPtr xf86ConfigPciEntity(ScrnInfoPtr pScrn, - &f.indent;int scrnFlag, int entityIndex, - &f.indent;PciChipsets *p_chip, - &f.indent;resList res, EntityProc init, - &f.indent;EntityProc enter, EntityProc leave, - &f.indent;pointer private)&e.code; - <p> - &s.code;ScrnInfoPtr xf86ConfigIsaEntity(ScrnInfoPtr pScrn, - &f.indent;int scrnFlag, int entityIndex, - &f.indent;IsaChipsets *i_chip, - &f.indent;resList res, EntityProc init, - &f.indent;EntityProc enter, EntityProc leave, - &f.indent;pointer private)&e.code; - <quote><p> - These functions are used to register the non-relocatable resources - for an entity, and the optional entity-specific &s.code;Init&e.code;, &s.code;Enter&e.code; and - &s.code;Leave&e.code; functions. Usually the list of fixed resources is obtained - from the Isa/PciChipsets lists. However an additional list of - resources may be passed. Generally this is not required. - For active entities a &s.code;ScrnInfoRec&e.code; is allocated - if the &s.code;pScrn&e.code; argument is &s.code;NULL&e.code;. -The - return value is &s.code;TRUE&e.code; when successful. The init, enter, leave - functions are defined as follows: - - <quote> - &s.code;typedef void (*EntityProc)(int entityIndex, - &f.indent;pointer private)&e.code; - </quote> - - They are passed the entity index and a pointer to a private scratch - area. This can be set up during &s.code;Probe()&e.code; and - its address can be passed to - &s.code;xf86ConfigIsaEntity()&e.code; and - &s.code;xf86ConfigPciEntity()&e.code; as the last argument. - - </quote> - </quote> - -These two helper functions make use of several core functions that are -available at the driver level: - <quote><p> - &s.code;void xf86ClaimFixedResources(resList list, int entityIndex)&e.code; - <quote><p> - This function registers the non-relocatable resources which cannot - be disabled and which therefore would cause the server to fail - immediately if they were found to conflict. It also records - non-relocatable but sharable resources for processing after the - &s.code;Probe()&e.code; phase. - - </quote> - - &s.code;Bool xf86SetEntityFuncs(int entityIndex, EntityProc init, - &f.indent;EntityProc enter, EntityProc leave, pointer)&e.code; - <quote><p> - This function registers with an entity the &s.code;init&e.code;, - &s.code;enter&e.code;, &s.code;leave&e.code; functions along - with the pointer to their private area. - - </quote> - - &s.code;void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex)&e.code; - <quote><p> - This function associates the entity referenced by - &s.code;entityIndex&e.code; with the screen. - - </quote> - </quote> - -<sect2>PreInit Phase -<p> - -During this phase the remaining resources should be registered. -&s.code;PreInit()&e.code; should call &s.code;xf86GetEntityInfo()&e.code; -to obtain a pointer to an &s.code;EntityInfoRec&e.code; for each entity -it is able to drive and check if any resource are listed in its -&s.code;resources&e.code; field. If resources registered in the Probe -phase have been rejected in the post-Probe phase -(&s.code;resources&e.code; is non-&s.code;NULL&e.code;), then the driver should -decide if it can continue without using these or if it should fail. - - <quote><p> - &s.code;EntityInfoPtr xf86GetEntityInfo(int entityIndex)&e.code; - <quote><p> - This function returns a pointer to the &s.code;EntityInfoRec&e.code; - referenced by &s.code;entityIndex&e.code;. The returned - &s.code;EntityInfoRec&e.code; should be freed with - &s.code;xfree()&e.code; when no longer needed. - - </quote> - </quote> -Several functions are provided to simplify resource registration: - <quote><p> - &s.code;Bool xf86IsEntityPrimary(int entityIndex)&e.code; - <quote><p> - This function returns &s.code;TRUE&e.code; if the entity referenced - by &s.code;entityIndex&e.code; is the primary display device (i.e., - the one initialised at boot time and used in text mode). - - </quote> - - &s.code;Bool xf86IsScreenPrimary(int scrnIndex)&e.code; - <quote><p> - This function returns &s.code;TRUE&e.code; if the primary entity - is registered with the screen referenced by - &s.code;scrnIndex&e.code;. - - </quote> - - &s.code;pciVideoPtr xf86GetPciInfoForEntity(int entityIndex)&e.code; - <quote><p> - This function returns a pointer to the &s.code;pciVideoRec&e.code; - for the specified entity. If the entity is not a PCI device, - &s.code;NULL&e.code; is returned. - - </quote> - </quote> - -The primary function for registration of resources is: - <quote><p> - &s.code;resPtr xf86RegisterResources(int entityIndex, resList list, - &f.indent;int access)&e.code; - <quote><p> - This function tries to register the resources in - &s.code;list&e.code;. If list is &s.code;NULL&e.code; it tries - to determine the resources automatically. This only works for - entities that provide a generic way to read out the resource ranges - they decode. So far this is only the case for PCI devices. By - default the PCI resources are registered as shared - (&s.code;ResShared&e.code;) if the driver wants to set a different - access type it can do so by specifying the access flags in the - third argument. A value of &s.code;0&e.code; means to use the - default settings. If for any reason the resource broker is not - able to register some of the requested resources the function will - return a pointer to a list of the failed ones. In this case the - driver may be able to move the resource to different locations. - In case of PCI bus entities this is done by passing the list of - failed resources to &s.code;xf86ReallocatePciResources()&e.code;. - When the registration succeeds, the return value is - &s.code;NULL&e.code;. - - </quote> - - &s.code;resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes)&e.code; - <quote><p> - This function takes a list of PCI resources that need to be - reallocated and returns &s.code;NULL&e.code when all relocations are - successful. - &s.code;xf86RegisterResources()&e.code; should be called again to - register the relocated resources with the broker. - If the reallocation fails, a list of the resources that could not be - relocated is returned. - - </quote> - </quote> - -Two functions are provided to obtain a resource range of a given type: - <quote><p> - &s.code;resRange xf86GetBlock(long type, memType size, - &f.indent;memType window_start, memType window_end, - &f.indent;memType align_mask, resPtr avoid)&e.code; - <quote><p> - This function tries to find a block range of size - &s.code;size&e.code; and type &s.code;type&e.code; in a window - bound by &s.code;window_start&e.code; and &s.code;window_end&e.code; - with the alignment specified in &s.code;align_mask&e.code;. - Optionally a list of resource ranges which should be avoided within - the window can be supplied. On failure a zero-length range of - type &s.code;ResEnd&e.code; will be returned. - - </quote> - &s.code;resRange xf86GetSparse(long type, memType fixed_bits, - &f.indent;memType decode_mask, memType address_mask, - &f.indent;resPtr avoid)&e.code; - <quote><p> - This function is like the previous one, but attempts to find a - sparse range instead of a block range. Here three values have to - be specified: the &s.code;address_mask&e.code; which marks all - bits of the mask part of the address, the &s.code;decode_mask&e.code; - which masks out the bits which are hardcoded and are therefore - not available for relocation and the values of the fixed bits. - The function tries to find a base that satisfies the given condition. - If the function fails it will return a zero range of type - &s.code;ResEnd&e.code;. Optionally it might be passed a list of - resource ranges to avoid. - - </quote> - </quote> - -Some PCI devices are broken in the sense that they return invalid size -information for a certain resource. In this case the driver can supply -the correct size and make sure that the resource range allocated for -the card is large enough to hold the address range decoded by the card. -The function &s.code;xf86FixPciResource()&e.code; can be used to do this: - <quote><p> - &s.code;Bool xf86FixPciResource(int entityIndex, unsigned int prt, - &f.indent;CARD32 alignment, long type)&e.code; - <quote><p> - This function fixes a PCI resource allocation. The - &s.code;prt&e.code; parameter contains the number of the PCI base - register that needs to be fixed (&s.code;0-5&e.code;, and - &s.code;6&e.code; for the BIOS base register). The size is - specified by the alignment. Since PCI resources need to span an - integral range of size &s.code;2^n&e.code;, the alignment also - specifies the number of addresses that will be decoded. If the - driver specifies a type mask it can override the default type for - PCI resources which is &s.code;ResShared&e.code;. The resource - broker needs to know that to find a matching resource range. This - function should be called before calling - &s.code;xf86RegisterResources()&e.code;. The return value is - &s.code;TRUE&e.code; when the function succeeds. - - </quote> - - &s.code;Bool xf86CheckPciMemBase(pciVideoPtr pPci, memType base)&e.code; - <quote><p> - This function checks that the memory base address specified matches - one of the PCI base address register values for the given PCI - device. This is mostly used to check that an externally provided - base address (e.g., from a config file) matches an actual value - allocated to a device. - - </quote> - </quote> - -The driver may replace the generic access control functions for an entity. -This is done with the &s.code;xf86SetAccessFuncs()&e.code;: - <quote><p> - &s.code;void xf86SetAccessFuncs(EntityInfoPtr pEnt, - &f.indent;xf86SetAccessFuncPtr funcs, - &f.indent;xf86SetAccessFuncPtr oldFuncs)&e.code; - <quote><p> - with: - </quote> - - <verb> - typedef struct { - xf86AccessPtr mem; - xf86AccessPtr io; - xf86AccessPtr io_mem; - } xf86SetAccessFuncRec, *xf86SetAccessFuncPtr; - </verb> - - <quote><p> - The driver can pass three functions: one for I/O access, one for - memory access and one for combined memory and I/O access. If the - memory access and combined access functions are identical the - common level assumes that the memory access cannot be controlled - independently of I/O access, if the I/O access function and the - combined access functions are the same it is assumed that I/O can - not be controlled independently. If memory and I/O have to be - controlled together all three values should be the same. If a - non &s.code;NULL&e.code; value is passed as third argument it is - interpreted as an address where to store the old access record. - If the third argument is &s.code;NULL&e.code; it will be assumed - that the generic access should be enabled before replacing the - access functions. Otherwise it will be disabled. The driver may - enable them itself using the returned values. It should do this - from its replacement access functions as the generic access may - be disabled by the common level on certain occasions. If replacement - functions are specified they must control all resources of the - specific type registered for the entity. - - </quote> - </quote> - -To find out if a specific resource range conflicts with another -resource the &s.code;xf86ChkConflict()&e.code; function may be used: - <quote><p> - &s.code;memType xf86ChkConflict(resRange *rgp, int entityIndex)&e.code; - <quote><p> - This function checks if the resource range &s.code;rgp&e.code; of - for the specified entity conflicts with with another resource. - If a conflict is found, the address of the start of the conflict - is returned. The return value is zero when there is no conflict. - - </quote> - </quote> - -The OPERATING state properties of previously registered fixed resources -can be set with the &s.code;xf86SetOperatingState()&e.code; function: - <quote><p> - &s.code;resPtr xf86SetOperatingState(resList list, int entityIndex, - &f.indent;int mask)&e.code; - <quote><p> - This function is used to set the status of a resource during - OPERATING state. &s.code;list&e.code; holds a list to which - &s.code;mask&e.code; is to be applied. The parameter - &s.code;mask&e.code; may have the value &s.code;ResUnusedOpr&e.code; - and &s.code;ResDisableOpr&e.code;. The first one should be used - if a resource isn't used by the driver during OPERATING state - although it is decoded by the device, while the latter one indicates - that the resource is not decoded during OPERATING state. Note - that the resource ranges have to match those specified during - registration. If a range has been specified starting at - &s.code;A&e.code; and ending at &s.code;B&e.code; and suppose - &s.code;C&e.code; us a value satisfying - &s.code;A < C < B&e.code; one may not - specify the resource range &s.code;(A,B)&e.code; by splitting it - into two ranges &s.code;(A,C)&e.code; and &s.code;(C,B)&e.code;. - - </quote> - </quote> - -The following two functions are provided for special cases: - <quote><p> - &s.code;void xf86RemoveEntityFromScreen(ScrnInfoPtr pScrn, int entityIndex)&e.code; - <quote><p> - This function may be used to remove an entity from a screen. This - only makes sense if a screen has more than one entity assigned or - the screen is to be deleted. No test is made if the screen has - any entities left. - - </quote> - - &s.code;void xf86DeallocateResourcesForEntity(int entityIndex, long type)&e.code; - <quote><p> - This function deallocates all resources of a given type registered - for a certain entity from the resource broker list. - - </quote> - </quote> - -<sect2>ScreenInit Phase -<p> - -All that is required in this phase is to setup the RAC flags. Note that -it is also permissible to set these flags up in the PreInit phase. The -RAC flags are held in the &s.code;racIoFlags&e.code; and &s.code;racMemFlags&e.code; fields of the -&s.code;ScrnInfoRec&e.code; for each screen. They specify which graphics operations -might require the use of shared resources. This can be specified -separately for memory and I/O resources. The available flags are defined -in &s.code;rac/xf86RAC.h&e.code;. They are: - - &s.code;RAC_FB&e.code; - <quote> - for framebuffer operations (including hw acceleration) - </quote> - &s.code;RAC_CURSOR&e.code; - <quote> - for Cursor operations - (??? I'm not sure if we need this for SW cursor it depends - on which level the sw cursor is drawn) - </quote> - &s.code;RAC_COLORMAP&e.code; - <quote> - for colormap operations - </quote> - &s.code;RAC_VIEWPORT&e.code; - <quote> - for the call to &s.code;ChipAdjustFrame()&e.code; </quote> - - -The flags are ORed together. - -<sect>Config file ``Option'' entries<label id="options"> -<p> - -Option entries are permitted in most sections and subsections of the -config file. There are two forms of option entries: - -<descrip> -<tag>Option "option-name"</tag> - A boolean option. -<tag>Option "option-name" "option-value"</tag> - An option with an arbitrary value. -</descrip> - -The option entries are handled by the parser, and a list of the parsed -options is included with each of the appropriate data structures that -the drivers have access to. The data structures used to hold the option -information are opaque to the driver, and a driver must not access the -option data directly. Instead, the common layer provides a set of -functions that may be used to access, check and manipulate the option -data. - -First, the low level option handling functions. In most cases drivers -would not need to use these directly. - - <quote><p> - &s.code;pointer xf86FindOption(pointer options, const char *name)&e.code; - <quote><p> - Takes a list of options and an option name, and returns a handle - for the first option entry in the list matching the name. Returns - &s.code;NULL&e.code; if no match is found. - - </quote> - - &s.code;char *xf86FindOptionValue(pointer options, const char *name)&e.code; - <quote><p> - Takes a list of options and an option name, and returns the value - associated with the first option entry in the list matching the - name. If the matching option has no value, an empty string - (&s.code;""&e.code;) is returned. Returns &s.code;NULL&e.code; - if no match is found. - - </quote> - - &s.code;void xf86MarkOptionUsed(pointer option)&e.code; - <quote><p> - Takes a handle for an option, and marks that option as used. - - </quote> - - &s.code;void xf86MarkOptionUsedByName(pointer options, const char *name)&e.code; - <quote><p> - Takes a list of options and an option name and marks the first - option entry in the list matching the name as used. - - </quote> - </quote> - - -Next, the higher level functions that most drivers would use. - <quote><p> - &s.code;void xf86CollectOptions(ScrnInfoPtr pScrn, pointer extraOpts)&e.code; - <quote><p> - Collect the options from each of the config file sections used by - the screen (&s.code;pScrn&e.code;) and return the merged list as - &s.code;pScrn->options&e.code;. This function requires that - &s.code;pScrn->confScreen&e.code;, &s.code;pScrn->display&e.code;, - &s.code;pScrn->monitor&e.code;, - &s.code;pScrn->numEntities&e.code;, and - &s.code;pScrn->entityList&e.code; are initialised. - &s.code;extraOpts&e.code; may optionally be set to an additional - list of options to be combined with the others. The order of - precedence for options is &s.code;extraOpts&e.code;, display, - confScreen, monitor, device. - - </quote> - - &s.code;void xf86ProcessOptions(int scrnIndex, pointer options, - &f.indent;OptionInfoPtr optinfo)&e.code; - <quote><p> - Processes a list of options according to the information in the - array of &s.code;OptionInfoRecs&e.code; (&s.code;optinfo&e.code;). - The resulting information is stored in the &s.code;value&e.code; - fields of the appropriate &s.code;optinfo&e.code; entries. The - &s.code;found&e.code; fields are set to &s.code;TRUE&e.code; - when an option with a value of the correct type if found, and - &s.code;FALSE&e.code; otherwise. The &s.code;type&e.code; field - is used to determine the expected value type for each option. - Each option in the list of options for which there is a name match - (but not necessarily a value type match) is marked as used. - Warning messages are printed when option values don't match the - types specified in the optinfo data. - - NOTE: If this function is called before a driver's screen number - is known (e.g., from the &s.code;ChipProbe()&e.code; function) a - &s.code;scrnIndex&e.code; value of &s.code;-1&e.code; should be - used. - - NOTE 2: Given that this function stores into the - &s.code;OptionInfoRecs&e.code; pointed to by &s.code;optinfo&e.code, - the caller should ensure the &s.code;OptionInfoRecs&e.code; are - (re-)initialised before the call, especially if the caller expects - to use the predefined option values as defaults. - - The &s.code;OptionInfoRec&e.code; is defined as follows: - - <verb> - typedef struct { - double freq; - int units; - } OptFrequency; - - typedef union { - unsigned long num; - char * str; - double realnum; - Bool bool; - OptFrequency freq; - } ValueUnion; - - typedef enum { - OPTV_NONE = 0, - OPTV_INTEGER, - OPTV_STRING, /* a non-empty string */ - OPTV_ANYSTR, /* Any string, including an empty one */ - OPTV_REAL, - OPTV_BOOLEAN, - OPTV_FREQ - } OptionValueType; - - typedef enum { - OPTUNITS_HZ = 1, - OPTUNITS_KHZ, - OPTUNITS_MHZ - } OptFreqUnits; - - typedef struct { - int token; - const char* name; - OptionValueType type; - ValueUnion value; - Bool found; - } OptionInfoRec, *OptionInfoPtr; - </verb> - - &s.code;OPTV_FREQ&e.code; can be used for options values that are - frequencies. These values are a floating point number with an - optional unit name appended. The unit name can be one of "Hz", - "kHz", "k", "MHz", "M". The multiplier associated with the unit - is stored in &s.code;freq.units&e.code;, and the scaled frequency - is stored in &s.code;freq.freq&e.code;. When no unit is specified, - &s.code;freq.units&e.code; is set to &s.code;0&e.code;, and - &s.code;freq.freq&e.code; is unscaled. - - Typical usage is to setup an array of - &s.code;OptionInfoRecs&e.code; with all fields initialised. - The &s.code;value&e.code; and &s.code;found&e.code; fields get - set by &s.code;xf86ProcessOptions()&e.code;. For cases where the - value parsing is more complex, the driver should specify - &s.code;OPTV_STRING&e.code;, and parse the string itself. An - example of using this option handling is included in the - <ref id="sample" name="Sample Driver"> section. - - </quote> - - &s.code;void xf86ShowUnusedOptions(int scrnIndex, pointer options)&e.code; - <quote><p> - Prints out warning messages for each option in the list of options - that isn't marked as used. This is intended to show options that - the driver hasn't recognised. It would normally be called near - the end of the &s.code;ChipScreenInit()&e.code; function, but only - when &s.code;serverGeneration == 1&e.code;. - - </quote> - - &s.code;OptionInfoPtr xf86TokenToOptinfo(const OptionInfoRec *table, - &f.indent;int token)&e.code; - - <quote><p> - Returns a pointer to the &s.code;OptionInfoRec&e.code; in - &s.code;table&e.code; with a token field matching - &s.code;token&e.code;. Returns &s.code;NULL&e.code; if no match - is found. - - </quote> - - &s.code;Bool xf86IsOptionSet(const OptionInfoRec *table, int token)&e.code; - <quote><p> - Returns the &s.code;found&e.code; field of the - &s.code;OptionInfoRec&e.code; in &s.code;table&e.code; with a - &s.code;token&e.code; field matching &s.code;token&e.code;. This - can be used for options of all types. Note that for options of - type &s.code;OPTV_BOOLEAN&e.code;, it isn't sufficient to check - this to determine the value of the option. Returns - &s.code;FALSE&e.code; if no match is found. - - </quote> - - &s.code;char *xf86GetOptValString(const OptionInfoRec *table, int token)&e.code; - <quote><p> - Returns the &s.code;value.str&e.code; field of the - &s.code;OptionInfoRec&e.code; in &s.code;table&e.code; with a - token field matching &s.code;token&e.code;. Returns - &s.code;NULL&e.code; if no match is found. - - </quote> - - &s.code;Bool xf86GetOptValInteger(const OptionInfoRec *table, int token, - &f.indent;int *value)&e.code; - <quote><p> - Returns via &s.code;*value&e.code; the &s.code;value.num&e.code; - field of the &s.code;OptionInfoRec&e.code; in &s.code;table&e.code; - with a &s.code;token&e.code; field matching &s.code;token&e.code;. - &s.code;*value&e.code; is only changed when a match is found so - it can be safely initialised with a default prior to calling this - function. The function return value is as for - &s.code;xf86IsOptionSet()&e.code;. - - </quote> - - &s.code;Bool xf86GetOptValULong(const OptionInfoRec *table, int token, - &f.indent;unsigned long *value)&e.code; - <quote><p> - Like &s.code;xf86GetOptValInteger()&e.code;, except the value is - treated as an &s.code;unsigned long&e.code;. - - </quote> - - &s.code;Bool xf86GetOptValReal(const OptionInfoRec *table, int token, - &f.indent;double *value)&e.code; - <quote><p> - Like &s.code;xf86GetOptValInteger()&e.code;, except that - &s.code;value.realnum&e.code; is used. - - </quote> - - &s.code;Bool xf86GetOptValFreq(const OptionInfoRec *table, int token, - &f.indent;OptFreqUnits expectedUnits, double *value)&e.code; - <quote><p> - Like &s.code;xf86GetOptValInteger()&e.code;, except that the - &s.code;value.freq&e.code; data is returned. The frequency value - is scaled to the units indicated by &s.code;expectedUnits&e.code;. - The scaling is exact when the units were specified explicitly in - the option's value. Otherwise, the &s.code;expectedUnits&e.code; - field is used as a hint when doing the scaling. In this case, - values larger than &s.code;1000&e.code; are assumed to have be - specified in the next smallest units. For example, if the Option - value is "10000" and expectedUnits is &s.code;OPTUNITS_MHZ&e.code;, - the value returned is &s.code;10&e.code;. - - </quote> - - &s.code;Bool xf86GetOptValBool(const OptionInfoRec *table, int token, Bool *value)&e.code; - <quote><p> - This function is used to check boolean options - (&s.code;OPTV_BOOLEAN&e.code;). If the function return value is - &s.code;FALSE&e.code;, it means the option wasn't set. Otherwise - &s.code;*value&e.code; is set to the boolean value indicated by - the option's value. No option &s.code;value&e.code; is interpreted - as &s.code;TRUE&e.code;. Option values meaning &s.code;TRUE&e.code; - are "1", "yes", "on", "true", and option values meaning - &s.code;FALSE&e.code; are "0", "no", "off", "false". Option names - both with the "no" prefix in their names, and with that prefix - removed are also checked and handled in the obvious way. - &s.code;*value&e.code; is not changed when the option isn't present. - It should normally be set to a default value before calling this - function. - - </quote> - - &s.code;Bool xf86ReturnOptValBool(const OptionInfoRec *table, int token, Bool def)&e.code; - <quote><p> - This function is used to check boolean options - (&s.code;OPTV_BOOLEAN&e.code;). If the option is set, its value - is returned. If the options is not set, the default value specified - by &s.code;def&e.code; is returned. The option interpretation is - the same as for &s.code;xf86GetOptValBool()&e.code;. - - </quote> - - &s.code;int xf86NameCmp(const char *s1, const char *s2)&e.code; - <quote><p> - This function should be used when comparing strings from the config - file with expected values. It works like &s.code;strcmp()&e.code;, - but is not case sensitive and space, tab, and `<tt>_</tt>' characters - are ignored in the comparison. The use of this function isn't - restricted to parsing option values. It may be used anywhere - where this functionality required. - - </quote> - </quote> - -<sect>Modules, Drivers, Include Files and Interface Issues -<p> - -NOTE: this section is incomplete. - - -<sect1>Include files -<p> - -The following include files are typically required by video drivers: - - <quote><p> - All drivers should include these: - <quote> - &s.code;"xf86.h"&nl; - "xf86_OSproc.h"&nl; - "xf86_ansic.h"&nl; - "xf86Resources.h"&e.code; - </quote> - Wherever inb/outb (and related things) are used the following should be - included: - <quote> - &s.code;"compiler.h"&e.code; - </quote> - Note: in drivers, this must be included after &s.code;"xf86_ansic.h"&e.code;. - - Drivers that need to access PCI vendor/device definitions need this: - <quote> - &s.code;"xf86PciInfo.h"&e.code; - </quote> - - Drivers that need to access the PCI config space need this: - <quote> - &s.code;"xf86Pci.h"&e.code; - </quote> - - Drivers that initialise a SW cursor need this: - <quote> - &s.code;"mipointer.h"&e.code; - </quote> - - All drivers implementing backing store need this: - <quote> - &s.code;"mibstore.h"&e.code; - </quote> - - All drivers using the mi colourmap code need this: - <quote> - &s.code;"micmap.h"&e.code; - </quote> - - If a driver uses the vgahw module, it needs this: - <quote> - &s.code;"vgaHW.h"&e.code; - </quote> - - Drivers supporting VGA or Hercules monochrome screens need: - <quote> - &s.code;"xf1bpp.h"&e.code; - </quote> - - Drivers supporting VGA or EGC 16-colour screens need: - <quote> - &s.code;"xf4bpp.h"&e.code; - </quote> - - Drivers using cfb need: - <quote> - &s.code;#define PSZ 8&nl; - #include "cfb.h"&nl; - #undef PSZ&e.code; - </quote> - - Drivers supporting bpp 16, 24 or 32 with cfb need one or more of: - <quote> - &s.code;"cfb16.h"&nl; - "cfb24.h"&nl; - "cfb32.h"&e.code; - </quote> - - If a driver uses XAA, it needs these: - <quote> - &s.code;"xaa.h"&nl; - "xaalocal.h"&e.code; - </quote> - - If a driver uses the fb manager, it needs this: - <quote> - &s.code;"xf86fbman.h"&e.code; - </quote> - </quote> - -Non-driver modules should include &s.code;"xf86_ansic.h"&e.code; to get the correct -wrapping of ANSI C/libc functions. - -All modules must NOT include any system include files, or the following: - - <quote> - &s.code;"xf86Priv.h"&nl; - "xf86Privstr.h"&nl; - "xf86_OSlib.h"&nl; - "Xos.h"&e.code; - </quote> - -In addition, "xf86_libc.h" must not be included explicitly. It is -included implicitly by "xf86_ansic.h". - - -<sect>Offscreen Memory Manager -<p> - -Management of offscreen video memory may be handled by the XFree86 -framebuffer manager. Once the offscreen memory manager is running, -drivers or extensions may allocate, free or resize areas of offscreen -video memory using the following functions (definitions taken from -&s.code;xf86fbman.h&e.code;): - -<code> - typedef struct _FBArea { - ScreenPtr pScreen; - BoxRec box; - int granularity; - void (*MoveAreaCallback)(struct _FBArea*, struct _FBArea*) - void (*RemoveAreaCallback)(struct _FBArea*) - DevUnion devPrivate; - } FBArea, *FBAreaPtr; - - typedef void (*MoveAreaCallbackProcPtr)(FBAreaPtr from, FBAreaPtr to) - typedef void (*RemoveAreaCallbackProcPtr)(FBAreaPtr) - - FBAreaPtr xf86AllocateOffscreenArea ( - ScreenPtr pScreen, - int width, int height, - int granularity, - MoveAreaCallbackProcPtr MoveAreaCallback, - RemoveAreaCallbackProcPtr RemoveAreaCallback, - pointer privData - ) - - void xf86FreeOffscreenArea (FBAreaPtr area) - - Bool xf86ResizeOffscreenArea ( - FBAreaPtr area - int w, int h - ) -</code> - -The function: -<quote> - &s.code;Bool xf86FBManagerRunning(ScreenPtr pScreen)&e.code; -</quote> - -can be used by an extension to check if the driver has initialized -the memory manager. The manager is not available if this returns -&s.code;FALSE&e.code; and the functions above will all fail. - - -&s.code;xf86AllocateOffscreenArea()&e.code; can be used to request a -rectangle of dimensions &s.code;width&e.code; x &s.code;height&e.code; -(in pixels) from unused offscreen memory. &s.code;granularity&e.code; -specifies that the leftmost edge of the rectangle must lie on some -multiple of &s.code;granularity&e.code; pixels. A granularity of zero -means the same thing as a granularity of one - no alignment preference. -A &s.code;MoveAreaCallback&e.code; can be provided to notify the requester -when the offscreen area is moved. If no &s.code;MoveAreaCallback&e.code; -is supplied then the area is considered to be immovable. The -&s.code;privData&e.code; field will be stored in the manager's internal -structure for that allocated area and will be returned to the requester -in the &s.code;FBArea&e.code; passed via the -&s.code;MoveAreaCallback&e.code;. An optional -&s.code;RemoveAreaCallback&e.code; is provided. If the driver provides -this it indicates that the area should be allocated with a lower priority. -Such an area may be removed when a higher priority request (one that -doesn't have a &s.code;RemoveAreaCallback&e.code;) is made. When this -function is called, the driver will have an opportunity to do whatever -cleanup it needs to do to deal with the loss of the area, but it must -finish its cleanup before the function exits since the offscreen memory -manager will free the area immediately after. - -&s.code;xf86AllocateOffscreenArea()&e.code; returns &s.code;NULL&e.code; -if it was unable to allocate the requested area. When no longer needed, -areas should be freed with &s.code;xf86FreeOffscreenArea()&e.code;. - -&s.code;xf86ResizeOffscreenArea()&e.code; resizes an existing -&s.code;FBArea&e.code;. &s.code;xf86ResizeOffscreenArea()&e.code; -returns &s.code;TRUE&e.code; if the resize was successful. If -&s.code;xf86ResizeOffscreenArea()&e.code; returns &s.code;FALSE&e.code;, -the original &s.code;FBArea&e.code; is left unmodified. Resizing an -area maintains the area's original &s.code;granularity&e.code;, -&s.code;devPrivate&e.code;, and &s.code;MoveAreaCallback&e.code;. -&s.code;xf86ResizeOffscreenArea()&e.code; has considerably less overhead -than freeing the old area then reallocating the new size, so it should -be used whenever possible. - -The function: - <quote> - &s.code;Bool xf86QueryLargestOffscreenArea( - &f.indent;ScreenPtr pScreen, - &f.indent;int *width, int *height, - &f.indent;int granularity, - &f.indent;int preferences, - &f.indent;int priority - &nl)&e.code; - </quote> - -is provided to query the width and height of the largest single -&s.code;FBArea&e.code; allocatable given a particular priority. -&s.code;preferences&e.code; can be one of the following to indicate -whether width, height or area should be considered when determining -which is the largest single &s.code;FBArea&e.code; available. - - <quote> - &s.code;FAVOR_AREA_THEN_WIDTH&nl; - FAVOR_AREA_THEN_HEIGHT&nl; - FAVOR_WIDTH_THEN_AREA&nl; - FAVOR_HEIGHT_THEN_AREA&e.code; - </quote> - -&s.code;priority&e.code; is one of the following: - - <quote><p> - &s.code;PRIORITY_LOW&e.code; - <quote><p> - Return the largest block available without stealing anyone else's - space. This corresponds to the priority of allocating a - &s.code;FBArea&e.code; when a &s.code;RemoveAreaCallback&e.code; - is provided. - - </quote> - &s.code;PRIORITY_NORMAL&e.code; - <quote><p> - Return the largest block available if it is acceptable to steal a - lower priority area from someone. This corresponds to the priority - of allocating a &s.code;FBArea&e.code; without providing a - &s.code;RemoveAreaCallback&e.code;. - - </quote> - &s.code;PRIORITY_EXTREME&e.code; - <quote><p> - Return the largest block available if all &s.code;FBAreas&e.code; - that aren't locked down were expunged from memory first. This - corresponds to any allocation made directly after a call to - &s.code;xf86PurgeUnlockedOffscreenAreas()&e.code;. - - </quote> - </quote> - - -The function: - - <quote> - &s.code;Bool xf86PurgeUnlockedOffscreenAreas(ScreenPtr pScreen)&e.code; - </quote> - -is provided as an extreme method to free up offscreen memory. This -will remove all removable &s.code;FBArea&e.code; allocations. - - -Initialization of the XFree86 framebuffer manager is done via - - <quote> - &s.code;Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox)&e.code; - </quote> - -&s.code;FullBox&e.code; represents the area of the framebuffer that the -manager is allowed to manage. This is typically a box with a width of -&s.code;pScrn->displayWidth&e.code; and a height of as many lines as -can be fit within the total video memory, however, the driver can reserve -areas at the extremities by passing a smaller area to the manager. - -&s.code;xf86InitFBManager()&e.code; must be called before XAA is -initialized since XAA uses the manager for it's pixmap cache. - -An alternative function is provided to allow the driver to initialize -the framebuffer manager with a Region rather than a box. - - <quote> - &s.code;Bool xf86InitFBManagerRegion(ScreenPtr pScreen, - &f.indent;RegionPtr FullRegion)&e.code; - </quote> - -&s.code;xf86InitFBManagerRegion()&e.code;, unlike -&s.code;xf86InitFBManager()&e.code;, does not remove the area used for -the visible screen so that area should not be included in the region -passed to the function. &s.code;xf86InitFBManagerRegion()&e.code; is -useful when non-contiguous areas are available to be managed, and is -required when multiple framebuffers are stored in video memory (as in -the case where an overlay of a different depth is stored as a second -framebuffer in offscreen memory). - - -<sect>Colormap Handling<label id="cmap"> -<p> - -A generic colormap handling layer is provided within the XFree86 common -layer. This layer takes care of most of the details, and only requires -a function from the driver that loads the hardware palette when required. -To use the colormap layer, a driver calls the -&s.code;xf86HandleColormaps()&e.code; function. - - <quote><p> - &s.code;Bool xf86HandleColormaps(ScreenPtr pScreen, int maxColors, - &f.indent;int sigRGBbits, LoadPaletteFuncPtr loadPalette, - &f.indent;SetOverscanFuncPtr setOverscan, - unsigned int flags)&e.code; - <quote><p> - This function must be called after the default colormap has been - initialised. The &s.code;pScrn->gamma&e.code; field must also - be initialised, preferably by calling &s.code;xf86SetGamma()&e.code;. - &s.code;maxColors&e.code; is the number of entries in the palette. - &s.code;sigRGBbits&e.code; is the size in bits of each color - component in the DAC's palette. &s.code;loadPalette&e.code; - is a driver-provided function for loading a colormap into the - hardware, and is described below. &s.code;setOverscan&e.code; is - an optional function that may be provided when the overscan color - is an index from the standard LUT and when it needs to be adjusted - to keep it as close to black as possible. The - &s.code;setOverscan&e.code; function programs the overscan index. - It shouldn't normally be used for depths other than 8. - &s.code;setOverscan&e.code; should be set to &s.code;NULL&e.code; - when it isn't needed. &s.code;flags&e.code; may be set to the - following (which may be ORed together): - - &s.code;CMAP_PALETTED_TRUECOLOR&e.code; - <quote><p> - the TrueColor visual is paletted and is - just a special case of DirectColor. - This flag is only valid for - &s.code;bpp > 8&e.code;. - - </quote> - - &s.code;CMAP_RELOAD_ON_MODE_SWITCH&e.code; - <quote><p> - reload the colormap automatically - after mode switches. This is useful - for when the driver is resetting the - hardware during mode switches and - corrupting or erasing the hardware - palette. - - </quote> - - &s.code;CMAP_LOAD_EVEN_IF_OFFSCREEN&e.code; - <quote><p> - reload the colormap even if the screen - is switched out of the server's VC. - The palette is <it>not</it> reloaded when - the screen is switched back in, nor after - mode switches. This is useful when the - driver needs to keep track of palette - changes. - - </quote> - - The colormap layer normally reloads the palette after VT enters so it - is not necessary for the driver to save and restore the palette - when switching VTs. The driver must, however, still save the - initial palette during server start up and restore it during - server exit. - - </quote> - - &s.code;void LoadPalette(ScrnInfoPtr pScrn, int numColors, int *indices, - &f.indent;LOCO *colors, VisualPtr pVisual)&e.code; - <quote><p> - &s.code;LoadPalette()&e.code; is a driver-provided function for - loading a colormap into hardware. &s.code;colors&e.code; is the - array of RGB values that represent the full colormap. - &s.code;indices&e.code; is a list of index values into the colors - array. These indices indicate the entries that need to be updated. - &s.code;numColors&e.code; is the number of the indices to be - updated. - - </quote> - - &s.code;void SetOverscan(ScrnInfoPtr pScrn, int overscan)&e.code; - <quote><p> - &s.code;SetOverscan()&e.code; is a driver-provided function for - programming the &s.code;overscan&e.code; index. As described - above, it is normally only appropriate for LUT modes where all - colormap entries are available for the display, but where one of - them is also used for the overscan (typically 8bpp for VGA compatible - LUTs). It isn't required in cases where the overscan area is - never visible. - - </quote> - </quote> - - -<sect>DPMS Extension -<p> - -Support code for the DPMS extension is included in the XFree86 common layer. -This code provides an interface between the main extension code, and a means -for drivers to initialise DPMS when they support it. One function is -available to drivers to do this initialisation, and it is always available, -even when the DPMS extension is not supported by the core server (in -which case it returns a failure result). - - - <quote><p> - &s.code;Bool xf86DPMSInit(ScreenPtr pScreen, DPMSSetProcPtr set, int flags)&e.code; - <quote><p> - This function registers a driver's DPMS level programming function - &s.code;set&e.code;. It also checks - &s.code;pScrn->options&e.code; for the "dpms" option, and when - present marks DPMS as being enabled for that screen. The - &s.code;set&e.code; function is called whenever the DPMS level - changes, and is used to program the requested level. - &s.code;flags&e.code; is currently not used, and should be - &s.code;0&e.code;. If the initialisation fails for any reason, - including when there is no DPMS support in the core server, the - function returns &s.code;FALSE&e.code;. - - </quote> - </quote> - - -Drivers that implement DPMS support must provide the following function, -that gets called when the DPMS level is changed: - - - <quote><p> - &s.code;void ChipDPMSSet(ScrnInfoPtr pScrn, int level, int flags)&e.code; - <quote><p> - Program the DPMS level specified by &s.code;level&e.code;. Valid - values of &s.code;level&e.code; are &s.code;DPMSModeOn&e.code;, - &s.code;DPMSModeStandby&e.code;, &s.code;DPMSModeSuspend&e.code;, - &s.code;DPMSModeOff&e.code;. These values are defined in - &s.code;"extensions/dpms.h"&e.code;. - - </quote> - </quote> - - -<sect>DGA Extension -<p> - -Drivers can support the XFree86 Direct Graphics Architecture (DGA) by -filling out a structure of function pointers and a list of modes and -passing them to DGAInit. - - <quote><p> - &s.code;Bool DGAInit(ScreenPtr pScreen, DGAFunctionPtr funcs, - &f.indent;DGAModePtr modes, int num)&e.code; - <quote><p> - <verb> -/** The DGAModeRec **/ - -typedef struct { - int num; - DisplayModePtr mode; - int flags; - int imageWidth; - int imageHeight; - int pixmapWidth; - int pixmapHeight; - int bytesPerScanline; - int byteOrder; - int depth; - int bitsPerPixel; - unsigned long red_mask; - unsigned long green_mask; - unsigned long blue_mask; - int viewportWidth; - int viewportHeight; - int xViewportStep; - int yViewportStep; - int maxViewportX; - int maxViewportY; - int viewportFlags; - int offset; - unsigned char *address; - int reserved1; - int reserved2; -} DGAModeRec, *DGAModePtr; -</verb> - - &s.code;num&e.code; - <quote> - Can be ignored. The DGA DDX will assign these numbers. - </quote> - - &s.code;mode&e.code; - <quote> - A pointer to the &s.code;DisplayModeRec&e.code; for this mode. - </quote> - - &s.code;flags&e.code; - <quote><p> - The following flags are defined and may be OR'd together: - - &s.code;DGA_CONCURRENT_ACCESS&e.code; - <quote><p> - Indicates that the driver supports concurrent graphics - accelerator and linear framebuffer access. - - </quote> - - &s.code;DGA_FILL_RECT&nl; - DGA_BLIT_RECT&nl; - DGA_BLIT_RECT_TRANS&e.code; - <quote><p> - Indicates that the driver supports the FillRect, BlitRect - or BlitTransRect functions in this mode. - - </quote> - - &s.code;DGA_PIXMAP_AVAILABLE&e.code; - <quote><p> - Indicates that Xlib may be used on the framebuffer. - This flag will usually be set unless the driver wishes - to prohibit this for some reason. - - </quote> - - &s.code;DGA_INTERLACED&nl; - DGA_DOUBLESCAN&e.code; - <quote><p> - Indicates that these are interlaced or double scan modes. - - </quote> - </quote> - - &s.code;imageWidth&nl; - imageHeight&e.code; - <quote><p> - These are the dimensions of the linear framebuffer - accessible by the client. - - </quote> - - &s.code;pixmapWidth&nl; - pixmapHeight&e.code; - <quote><p> - These are the dimensions of the area of the - framebuffer accessible by the graphics accelerator. - - </quote> - - &s.code;bytesPerScanline&e.code; - <quote><p> - Pitch of the framebuffer in bytes. - - </quote> - - &s.code;byteOrder&e.code; - <quote><p> - Usually the same as - &s.code;pScrn->imageByteOrder&e.code;. - - </quote> - - &s.code;depth&e.code; - <quote><p> - The depth of the framebuffer in this mode. - - </quote> - - &s.code;bitsPerPixel&e.code; - <quote><p> - The number of bits per pixel in this mode. - - </quote> - - &s.code;red_mask&nl; - green_mask&nl; - blue_mask&e.code; - <quote><p> - The RGB masks for this mode, if applicable. - - </quote> - - &s.code;viewportWidth&nl; - viewportHeight&e.code; - <quote><p> - Dimensions of the visible part of the framebuffer. - Usually &s.code;mode->HDisplay&e.code; and - &s.code;mode->VDisplay&e.code;. - - </quote> - - &s.code;xViewportStep&nl; - yViewportStep&e.code; - <quote><p> - The granularity of x and y viewport positions that - the driver supports in this mode. - - </quote> - - &s.code;maxViewportX&nl; - maxViewportY&e.code; - <quote><p> - The maximum viewport position supported by the - driver in this mode. - - </quote> - - &s.code;viewportFlags&e.code; - <quote><p> - The following may be OR'd together: - - &s.code;DGA_FLIP_IMMEDIATE&e.code; - <quote><p> - The driver supports immediate viewport changes. - - </quote> - &s.code;DGA_FLIP_RETRACE&e.code; - <quote<p> - The driver supports viewport changes at retrace. - - </quote> - </quote> - - &s.code;offset&e.code; - <quote><p> - The offset into the linear framebuffer that corresponds to - pixel (0,0) for this mode. - - </quote> - - &s.code;address&e.code; - <quote><p> - The virtual address of the framebuffer as mapped by the driver. - This is needed when DGA_PIXMAP_AVAILABLE is set. - - </quote> - - <verb> -/** The DGAFunctionRec **/ - -typedef struct { - Bool (*OpenFramebuffer)( - ScrnInfoPtr pScrn, - char **name, - unsigned char **mem, - int *size, - int *offset, - int *extra - ); - void (*CloseFramebuffer)(ScrnInfoPtr pScrn); - Bool (*SetMode)(ScrnInfoPtr pScrn, DGAModePtr pMode); - void (*SetViewport)(ScrnInfoPtr pScrn, int x, int y, int flags); - int (*GetViewport)(ScrnInfoPtr pScrn); - void (*Sync)(ScrnInfoPtr); - void (*FillRect)( - ScrnInfoPtr pScrn, - int x, int y, int w, int h, - unsigned long color - ); - void (*BlitRect)( - ScrnInfoPtr pScrn, - int srcx, int srcy, - int w, int h, - int dstx, int dsty - ); - void (*BlitTransRect)( - ScrnInfoPtr pScrn, - int srcx, int srcy, - int w, int h, - int dstx, int dsty, - unsigned long color - ); -} DGAFunctionRec, *DGAFunctionPtr; -</verb> - - </quote> - - &s.code;Bool OpenFramebuffer (pScrn, name, mem, size, offset, extra)&e.code; - <quote><p> - &s.code;OpenFramebuffer()&e.code; should pass the client everything - it needs to know to be able to open the framebuffer. These - parameters are OS specific and their meanings are to be interpreted - by an OS specific client library. - - &s.code;name&e.code; - <quote><p> - The name of the device to open or &s.code;NULL&e.code; if - there is no special device to open. A &s.code;NULL&e.code; - name tells the client that it should open whatever device - one would usually open to access physical memory. - - </quote> - &s.code;mem&e.code; - <quote><p> - The physical address of the start of the framebuffer. - - </quote> - &s.code;size&e.code; - <quote><p> - The size of the framebuffer in bytes. - - </quote> - &s.code;offset&e.code; - <quote><p> - Any offset into the device, if applicable. - - </quote> - &s.code;flags&e.code; - <quote><p> - Any additional information that the client may need. - Currently, only the &s.code;DGA_NEED_ROOT&e.code; flag is - defined. - - </quote> - </quote> - - &s.code;void CloseFramebuffer (pScrn)&e.code; - <quote><p> - &s.code;CloseFramebuffer()&e.code; merely informs the driver (if it - even cares) that client no longer needs to access the framebuffer - directly. This function is optional. - - </quote> - - &s.code;Bool SetMode (pScrn, pMode)&e.code; - <quote><p> - &s.code;SetMode()&e.code; tells the driver to initialize the mode - passed to it. If &s.code;pMode&e.code; is &s.code;NULL&e.code;, - then the driver should restore the original pre-DGA mode. - - </quote> - - &s.code;void SetViewport (pScrn, x, y, flags)&e.code; - <quote><p> - &s.code;SetViewport()&e.code; tells the driver to make the upper - left-hand corner of the visible screen correspond to coordinate - &s.code;(x,y)&e.code; on the framebuffer. &s.code;Flags&e.code; - currently defined are: - - &s.code;DGA_FLIP_IMMEDIATE&e.code; - <quote><p> - The viewport change should occur immediately. - - </quote> - &s.code;DGA_FLIP_RETRACE&e.code; - <quote><p> - The viewport change should occur at the - vertical retrace, but this function should - return sooner if possible. - - </quote> - The &s.code;(x,y)&e.code; locations will be passed as the client - specified them, however, the driver is expected to round these - locations down to the next supported location as specified by the - &s.code;xViewportStep&e.code; and &s.code;yViewportStep&e.code; - for the current mode. - - </quote> - - &s.code;int GetViewport (pScrn)&e.code; - <quote><p> - &s.code;GetViewport()&e.code; gets the current page flip status. - Set bits in the returned int correspond to viewport change requests - still pending. For instance, set bit zero if the last SetViewport - request is still pending, bit one if the one before that is still - pending, etc. - - </quote> - - &s.code;void Sync (pScrn)&e.code; - <quote><p> - This function should ensure that any graphics accelerator operations - have finished. This function should not return until the graphics - accelerator is idle. - - </quote> - - &s.code;void FillRect (pScrn, x, y, w, h, color)&e.code; - <quote><p> - This optional function should fill a rectangle - &s.code;w × h&e.code; located at - &s.code;(x,y)&e.code; in the given color. - - </quote> - - &s.code;void BlitRect (pScrn, srcx, srcy, w, h, dstx, dsty)&e.code; - <quote><p> - This optional function should copy an area - &s.code;w × h&e.code; located at - &s.code;(srcx,srcy)&e.code; to location &s.code;(dstx,dsty)&e.code;. - This function will need to handle copy directions as appropriate. - - </quote> - - &s.code;void BlitTransRect (pScrn, srcx, srcy, w, h, dstx, dsty, color)&e.code; - <quote><p> - This optional function is the same as BlitRect except that pixels - in the source corresponding to the color key &s.code;color&e.code; - should be skipped. - - </quote> - </quote> - -<sect>The XFree86 X Video Extension (Xv) Device Dependent Layer -<p> - -XFree86 offers the X Video Extension which allows clients to treat video -as any another primitive and ``Put'' video into drawables. By default, -the extension reports no video adaptors as being available since the -DDX layer has not been initialized. The driver can initialize the DDX -layer by filling out one or more &s.code;XF86VideoAdaptorRecs&e.code; -as described later in this document and passing a list of -&s.code;XF86VideoAdaptorPtr&e.code; pointers to the following function: - - <quote> - &s.code;Bool xf86XVScreenInit( - &f.indent;ScreenPtr pScreen, - &f.indent;XF86VideoAdaptorPtr *adaptPtrs, - &f.indent;int num)&e.code; - </quote> - -After doing this, the extension will report video adaptors as being -available, providing the data in their respective -&s.code;XF86VideoAdaptorRecs&e.code; was valid. -&s.code;xf86XVScreenInit()&e.code; <em>copies</em> data from the structure -passed to it so the driver may free it after the initialization. At -the moment, the DDX only supports rendering into Window drawables. -Pixmap rendering will be supported after a sufficient survey of suitable -hardware is completed. - -The &s.code;XF86VideoAdaptorRec&e.code;: - -<quote><p> -<verb> -typedef struct { - unsigned int type; - int flags; - char *name; - int nEncodings; - XF86VideoEncodingPtr pEncodings; - int nFormats; - XF86VideoFormatPtr pFormats; - int nPorts; - DevUnion *pPortPrivates; - int nAttributes; - XF86AttributePtr pAttributes; - int nImages; - XF86ImagePtr pImages; - PutVideoFuncPtr PutVideo; - PutStillFuncPtr PutStill; - GetVideoFuncPtr GetVideo; - GetStillFuncPtr GetStill; - StopVideoFuncPtr StopVideo; - SetPortAttributeFuncPtr SetPortAttribute; - GetPortAttributeFuncPtr GetPortAttribute; - QueryBestSizeFuncPtr QueryBestSize; - PutImageFuncPtr PutImage; - QueryImageAttributesFuncPtr QueryImageAttributes; -} XF86VideoAdaptorRec, *XF86VideoAdaptorPtr; -</verb> - - Each adaptor will have its own XF86VideoAdaptorRec. The fields are - as follows: - - &s.code;type&e.code; - <quote><p> - This can be any of the following flags OR'd together. - - &s.code;XvInputMask&e.code; - &s.code;XvOutputMask&e.code; - <quote><p> - These refer to the target drawable and are similar to a Window's - class. &s.code;XvInputMask&e.code; indicates that the adaptor - can put video into a drawable. &s.code;XvOutputMask&e.code; - indicates that the adaptor can get video from a drawable. - </quote> - - &s.code;XvVideoMask&e.code; - &s.code;XvStillMask&e.code; - &s.code;XvImageMask&e.code; - <quote><p> - These indicate that the adaptor supports video, still or - image primitives respectively. - </quote> - - &s.code;XvWindowMask&e.code; - &s.code;XvPixmapMask&e.code; - <quote><p> - These indicate the types of drawables the adaptor is capable - of rendering into. At the moment, Pixmap rendering is not - supported and the &s.code;XvPixmapMask&e.code; flag is ignored. - </quote> - - </quote> - - &s.code;flags&e.code; - <quote><p> - Currently, the following flags are defined: - - &s.code;VIDEO_NO_CLIPPING&e.code; - <quote><p> - This indicates that the video adaptor does not support - clipping. The driver will never receive ``Put'' requests - where less than the entire area determined by - &s.code;drw_x&e.code;, &s.code;drw_y&e.code;, - &s.code;drw_w&e.code; and &s.code;drw_h&e.code; is visible. - This flag does not apply to ``Get'' requests. Hardware - that is incapable of clipping ``Gets'' may punt or get - the extents of the clipping region passed to it. - - </quote> - - &s.code;VIDEO_INVERT_CLIPLIST&e.code; - <quote><p> - This indicates that the video driver requires the clip - list to contain the regions which are obscured rather - than the regions which are are visible. - - </quote> - - &s.code;VIDEO_OVERLAID_STILLS&e.code; - <quote><p> - Implementing PutStill for hardware that does video as an - overlay can be awkward since it's unclear how long to leave - the video up for. When this flag is set, StopVideo will be - called whenever the destination gets clipped or moved so that - the still can be left up until then. - - </quote> - - &s.code;VIDEO_OVERLAID_IMAGES&e.code; - <quote><p> - Same as &s.code;VIDEO_OVERLAID_STILLS&e.code; but for images. - </quote> - - &s.code;VIDEO_CLIP_TO_VIEWPORT&e.code; - <quote><p> - Indicates that the clip region passed to the driver functions - should be clipped to the visible portion of the screen in the - case where the viewport is smaller than the virtual desktop. - </quote> - - </quote> - - &s.code;name&e.code; - <quote><p> - The name of the adaptor. - - </quote> - - &s.code;nEncodings&nl; - pEncodings&e.code; - <quote><p> - The number of encodings the adaptor is capable of and pointer - to the &s.code;XF86VideoEncodingRec&e.code; array. The - &s.code;XF86VideoEncodingRec&e.code; is described later on. - For drivers that only support XvImages there should be an encoding - named "XV_IMAGE" and the width and height should specify - the maximum size source image supported. - - </quote> - - &s.code;nFormats&nl; - pFormats&e.code; - <quote><p> - The number of formats the adaptor is capable of and pointer to - the &s.code;XF86VideoFormatRec&e.code; array. The - &s.code;XF86VideoFormatRec&e.code; is described later on. - - </quote> - - &s.code;nPorts&nl; - pPortPrivates&e.code; - <quote><p> - The number of ports is the number of separate data streams which - the adaptor can handle simultaneously. If you have more than - one port, the adaptor is expected to be able to render into more - than one window at a time. &s.code;pPortPrivates&e.code; is - an array of pointers or ints - one for each port. A port's - private data will be passed to the driver any time the port is - requested to do something like put the video or stop the video. - In the case where there may be many ports, this enables the - driver to know which port the request is intended for. Most - commonly, this will contain a pointer to the data structure - containing information about the port. In Xv, all ports on - a particular adaptor are expected to be identical in their - functionality. - - </quote> - - &s.code;nAttributes&nl; - pAttributes&e.code; - <quote><p> - The number of attributes recognized by the adaptor and a pointer to - the array of &s.code;XF86AttributeRecs&e.code;. The - &s.code;XF86AttributeRec&e.code; is described later on. - - </quote> - - &s.code;nImages&nl; - pImages&e.code; - <quote><p> - The number of &s.code;XF86ImageRecs&e.code; supported by the adaptor - and a pointer to the array of &s.code;XF86ImageRecs&e.code;. The - &s.code;XF86ImageRec&e.code; is described later on. - - </quote> - - - &s.code;PutVideo PutStill GetVideo GetStill StopVideo - SetPortAttribute GetPortAttribute QueryBestSize PutImage - QueryImageAttributes&e.code; - <quote><p> - These functions define the DDX->driver interface. In each - case, the pointer &s.code;data&e.code; is passed to the driver. - This is the port private for that port as described above. All - fields are required except under the following conditions: - - <enum> - <item>&s.code;PutVideo&e.code;, &s.code;PutStill&e.code; and - the image routines &s.code;PutImage&e.code; and - &s.code;QueryImageAttributes&e.code; are not required when the - adaptor type does not contain &s.code;XvInputMask&e.code;. - - <item>&s.code;GetVideo&e.code; and &s.code;GetStill&e.code; - are not required when the adaptor type does not contain - &s.code;XvOutputMask&e.code;. - - <item>&s.code;GetVideo&e.code; and &s.code;PutVideo&e.code; - are not required when the adaptor type does not contain - &s.code;XvVideoMask&e.code;. - - <item>&s.code;GetStill&e.code; and &s.code;PutStill&e.code; - are not required when the adaptor type does not contain - &s.code;XvStillMask&e.code;. - - <item>&s.code;PutImage&e.code; and &s.code;QueryImageAttributes&e.code; - are not required when the adaptor type does not contain - &s.code;XvImageMask&e.code;. - - </enum> - - With the exception of &s.code;QueryImageAttributes&e.code;, these - functions should return &s.code;Success&e.code; if the operation was - completed successfully. They can return &s.code;XvBadAlloc&e.code; - otherwise. &s.code;QueryImageAttributes&e.code; returns the size - of the XvImage queried. - - If the &s.code;VIDEO_NO_CLIPPING&e.code; - flag is set, the &s.code;clipBoxes&e.code; may be ignored by - the driver. &s.code;ClipBoxes&e.code; is an &s.code;X-Y&e.code; - banded region identical to those used throughout the server. - The clipBoxes represent the visible portions of the area determined - by &s.code;drw_x&e.code;, &s.code;drw_y&e.code;, - &s.code;drw_w&e.code; and &s.code;drw_h&e.code; in the Get/Put - function. The boxes are in screen coordinates, are guaranteed - not to overlap and an empty region will never be passed. - If the driver has specified &s.code;VIDEO_INVERT_CLIPLIST&e.code;, - &s.code;clipBoxes&e.code; will indicate the areas of the primitive - which are obscured rather than the areas visible. - - </quote> - - &s.code;typedef int (* PutVideoFuncPtr)( ScrnInfoPtr pScrn, - &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, - &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, - &f.indent;RegionPtr clipBoxes, pointer data )&e.code; - <quote><p> - This indicates that the driver should take a subsection - &s.code;vid_w&e.code; by &s.code;vid_h&e.code; at location - &s.code;(vid_x,vid_y)&e.code; from the video stream and direct - it into the rectangle &s.code;drw_w&e.code; by &s.code;drw_h&e.code; - at location &s.code;(drw_x,drw_y)&e.code; on the screen, scaling as - necessary. Due to the large variations in capabilities of - the various hardware expected to be used with this extension, - it is not expected that all hardware will be able to do this - exactly as described. In that case the driver should just do - ``the best it can,'' scaling as closely to the target rectangle - as it can without rendering outside of it. In the worst case, - the driver can opt to just not turn on the video. - - </quote> - - &s.code;typedef int (* PutStillFuncPtr)( ScrnInfoPtr pScrn, - &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, - &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, - &f.indent;RegionPtr clipBoxes, pointer data )&e.code; - <quote><p> - This is same as &s.code;PutVideo&e.code; except that the driver - should place only one frame from the stream on the screen. - - </quote> - - &s.code;typedef int (* GetVideoFuncPtr)( ScrnInfoPtr pScrn, - &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, - &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, - &f.indent;RegionPtr clipBoxes, pointer data )&e.code; - <quote><p> - This is same as &s.code;PutVideo&e.code; except that the driver - gets video from the screen and outputs it. The driver should - do the best it can to get the requested dimensions correct - without reading from an area larger than requested. - - </quote> - - &s.code;typedef int (* GetStillFuncPtr)( ScrnInfoPtr pScrn, - &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, - &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, - &f.indent;RegionPtr clipBoxes, pointer data )&e.code; - <quote><p> - This is the same as &s.code;GetVideo&e.code; except that the - driver should place only one frame from the screen into the - output stream. - - </quote> - - &s.code;typedef void (* StopVideoFuncPtr)(ScrnInfoPtr pScrn, - &f.indent;pointer data, Bool cleanup)&e.code; - <quote><p> - This indicates the driver should stop displaying the video. - This is used to stop both input and output video. The - &s.code;cleanup&e.code; field indicates that the video is - being stopped because the client requested it to stop or - because the server is exiting the current VT. In that case - the driver should deallocate any offscreen memory areas (if - there are any) being used to put the video to the screen. If - &s.code;cleanup&e.code; is not set, the video is being stopped - temporarily due to clipping or moving of the window, etc... - and video will likely be restarted soon so the driver should - not deallocate any offscreen areas associated with that port. - - </quote> - &s.code;typedef int (* SetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, - &f.indent;Atom attribute,INT32 value, pointer data)&e.code; - - &s.code;typedef int (* GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, - &f.indent;Atom attribute,INT32 *value, pointer data)&e.code; - - <quote><p> - A port may have particular attributes such as hue, - saturation, brightness or contrast. Xv clients set and - get these attribute values by sending attribute strings - (Atoms) to the server. Such requests end up at these - driver functions. It is recommended that the driver provide - at least the following attributes mentioned in the Xv client - library docs: - <quote> - &s.code;XV_ENCODING&nl; - XV_HUE&nl; - XV_SATURATION&nl; - XV_BRIGHTNESS&nl; - XV_CONTRAST&e.code; - </quote> - but the driver may recognize as many atoms as it wishes. If - a requested attribute is unknown by the driver it should return - &s.code;BadMatch&e.code;. &s.code;XV_ENCODING&e.code; is the - attribute intended to let the client specify which video - encoding the particular port should be using (see the description - of &s.code;XF86VideoEncodingRec&e.code; below). If the - requested encoding is unsupported, the driver should return - &s.code;XvBadEncoding&e.code;. If the value lies outside the - advertised range &s.code;BadValue&e.code; may be returned. - &s.code;Success&e.code; should be returned otherwise. - - </quote> - - &s.code;typedef void (* QueryBestSizeFuncPtr)(ScrnInfoPtr pScrn, - &f.indent;Bool motion, short vid_w, short vid_h, - &f.indent;short drw_w, short drw_h, - &f.indent;unsigned int *p_w, unsigned int *p_h, pointer data)&e.code; - <quote><p> - &s.code;QueryBestSize&e.code; provides the client with a way - to query what the destination dimensions would end up being - if they were to request that an area - &s.code;vid_w&e.code by &s.code;vid_h&e.code; from the video - stream be scaled to rectangle of - &s.code;drw_w&e.code; by &s.code;drw_h&e.code; on the screen. - Since it is not expected that all hardware will be able to - get the target dimensions exactly, it is important that the - driver provide this function. - - </quote> - - &s.code;typedef int (* PutImageFuncPtr)( ScrnInfoPtr pScrn, - &f.indent;short src_x, short src_y, short drw_x, short drw_y, - &f.indent;short src_w, short src_h, short drw_w, short drw_h, - &f.indent;int image, char *buf, short width, short height, - &f.indent;Bool sync, RegionPtr clipBoxes, pointer data )&e.code; - <quote><p> - This is similar to &s.code;PutStill&e.code; except that the - source of the video is not a port but the data stored in a system - memory buffer at &s.code;buf&e.code;. The data is in the format - indicated by the &s.code;image&e.code; descriptor and represents a - source of size &s.code;width&e.code; by &s.code;height&e.code;. - If &s.code;sync&e.code; is TRUE the driver should not return - from this function until it is through reading the data - from &s.code;buf&e.code;. Returning when &s.code;sync&e.code; - is TRUE indicates that it is safe for the data at &s.code;buf&e.code; - to be replaced, freed, or modified. - - </quote> - - &s.code;typedef int (* QueryImageAttributesFuncPtr)( ScrnInfoPtr pScrn, - &f.indent;int image, short *width, short *height, - &f.indent;int *pitches, int *offsets)&e.code; - <quote><p> - This function is called to let the driver specify how data for - a particular &s.code;image&e.code; of size &s.code;width&e.code; - by &s.code;height&e.code; should be stored. Sometimes only - the size and corrected width and height are needed. In that - case &s.code;pitches&e.code; and &s.code;offsets&e.code; are - NULL. The size of the memory required for the image is returned - by this function. The &s.code;width&e.code; and - &s.code;height&e.code; of the requested image can be altered by - the driver to reflect format limitations (such as component - sampling periods that are larger than one). If - &s.code;pitches&e.code; and &s.code;offsets&e.code; are not NULL, - these will be arrays with as many elements in them as there - are planes in the &s.code;image&e.code; format. The driver - should specify the pitch (in bytes) of each scanline in the - particular plane as well as the offset to that plane (in bytes) - from the beginning of the image. - - </quote> - - </quote> - -The XF86VideoEncodingRec: -<quote><p> -<verb> -typedef struct { - int id; - char *name; - unsigned short width, height; - XvRationalRec rate; -} XF86VideoEncodingRec, *XF86VideoEncodingPtr; - -</verb> - The &s.code;XF86VideoEncodingRec&e.code; specifies what encodings - the adaptor can support. Most of this data is just informational - and for the client's benefit, and is what will be reported by - &s.code;XvQueryEncodings&e.code;. The &s.code;id&e.code; field is - expected to be a unique identifier to allow the client to request a - certain encoding via the &s.code;XV_ENCODING&e.code; attribute string. - -</quote> - -The XF86VideoFormatRec: - -<quote><p> -<verb> -typedef struct { - char depth; - short class; -} XF86VideoFormatRec, *XF86VideoFormatPtr; -</verb> - - This specifies what visuals the video is viewable in. - &s.code;depth&e.code; is the depth of the visual (not bpp). - &s.code;class&e.code; is the visual class such as - &s.code;TrueColor&e.code;, &s.code;DirectColor&e.code; or - &s.code;PseudoColor&e.code;. Initialization of an adaptor will fail - if none of the visuals on that screen are supported. - -</quote> - -The XF86AttributeRec: - -<quote><p> -<verb> -typedef struct { - int flags; - int min_value; - int max_value; - char *name; -} XF86AttributeListRec, *XF86AttributeListPtr; - -</verb> - - Each adaptor may have an array of these advertising the attributes - for its ports. Currently defined flags are &s.code;XvGettable&e.code; - and &s.code;XvSettable&e.code; which may be OR'd together indicating that - attribute is ``gettable'' or ``settable'' by the client. The - &s.code;min&e.code; and &s.code;max&e.code; field specify the valid range - for the value. &s.code;Name&e.code; is a text string describing the - attribute by name. - -</quote> - -The XF86ImageRec: - -<quote><p> -<verb> -typedef struct { - int id; - int type; - int byte_order; - char guid[16]; - int bits_per_pixel; - int format; - int num_planes; - - /* for RGB formats */ - int depth; - unsigned int red_mask; - unsigned int green_mask; - unsigned int blue_mask; - - /* for YUV formats */ - unsigned int y_sample_bits; - unsigned int u_sample_bits; - unsigned int v_sample_bits; - unsigned int horz_y_period; - unsigned int horz_u_period; - unsigned int horz_v_period; - unsigned int vert_y_period; - unsigned int vert_u_period; - unsigned int vert_v_period; - char component_order[32]; - int scanline_order; -} XF86ImageRec, *XF86ImagePtr; -</verb> - - XF86ImageRec describes how video source data is laid out in memory. - The fields are as follows: - - &s.code;id&e.code; - <quote><p> - This is a unique descriptor for the format. It is often good to - set this value to the FOURCC for the format when applicable. - </quote> - - &s.code;type&e.code; - <quote><p> - This is &s.code;XvRGB&e.code; or &s.code;XvYUV&e.code;. - </quote> - - &s.code;byte_order&e.code; - <quote><p> - This is &s.code;LSBFirst&e.code; or &s.code;MSBFirst&e.code;. - </quote> - - &s.code;guid&e.code; - <quote><p> - This is the Globally Unique IDentifier for the format. When - not applicable, all characters should be NULL. - </quote> - - &s.code;bits_per_pixel&e.code; - <quote><p> - The number of bits taken up (but not necessarily used) by each - pixel. Note that for some planar formats which have fractional - bits per pixel (such as IF09) this number may be rounded _down_. - </quote> - - &s.code;format&e.code; - <quote><p> - This is &s.code;XvPlanar&e.code; or &s.code;XvPacked&e.code;. - </quote> - - &s.code;num_planes&e.code; - <quote><p> - The number of planes in planar formats. This should be set to - one for packed formats. - </quote> - - &s.code;depth&e.code; - <quote><p> - The significant bits per pixel in RGB formats (analgous to the - depth of a pixmap format). - </quote> - - &s.code;red_mask&e.code; - &s.code;green_mask&e.code; - &s.code;blue_mask&e.code; - <quote><p> - The red, green and blue bitmasks for packed RGB formats. - </quote> - - &s.code;y_sample_bits&e.code; - &s.code;u_sample_bits&e.code; - &s.code;v_sample_bits&e.code; - <quote><p> - The y, u and v sample sizes (in bits). - </quote> - - &s.code;horz_y_period&e.code; - &s.code;horz_u_period&e.code; - &s.code;horz_v_period&e.code; - <quote><p> - The y, u and v sampling periods in the horizontal direction. - </quote> - - &s.code;vert_y_period&e.code; - &s.code;vert_u_period&e.code; - &s.code;vert_v_period&e.code; - <quote><p> - The y, u and v sampling periods in the vertical direction. - </quote> - - &s.code;component_order&e.code; - <quote><p> - Uppercase ascii characters representing the order that - samples are stored within packed formats. For planar formats - this represents the ordering of the planes. Unused characters - in the 32 byte string should be set to NULL. - </quote> - - &s.code;scanline_order&e.code; - <quote><p> - This is &s.code;XvTopToBottom&e.code; or &s.code;XvBottomToTop&e.code;. - </quote> - - Since some formats (particular some planar YUV formats) may not -be completely defined by the parameters above, the guid, when -available, should provide the most accurate description of the -format. - -</quote> - -<sect>The Loader -<p> - -This section describes the interfaces to the module loader. The loader -interfaces can be divided into two groups: those that are only available to -the XFree86 common layer, and those that are also available to modules. - -<sect1>Loader Overview -<p> - -The loader is capable of loading modules in a range of object formats, -and knowledge of these formats is built in to the loader. Knowledge of -new object formats can be added to the loader in a straightforward -manner. This makes it possible to provide OS-independent modules (for -a given CPU architecture type). In addition to this, the loader can -load modules via the OS-provided &s.code;dlopen(3)&e.code; service where -available. Such modules are not platform independent, and the semantics -of &s.code;dlopen()&e.code; on most systems results in significant -limitations in the use of modules of this type. Support for -&s.code;dlopen()&e.code; modules in the loader is primarily for -experimental and development purposes. - -Symbols exported by the loader (on behalf of the core X server) to -modules are determined at compile time. Only those symbols explicitly -exported are available to modules. All external symbols of loaded -modules are exported to other modules, and to the core X server. The -loader can be requested to check for unresolved symbols at any time, -and the action to be taken for unresolved symbols can be controlled by -the caller of the loader. Typically the caller identifies which symbols -can safely remain unresolved and which cannot. - -NOTE: Now that ISO-C allows pointers to functions and pointers to data to -have different internal representations, some of the following interfaces -will need to be revisited. - -<sect1>Semi-private Loader Interface -<p> - -The following is the semi-private loader interface that is available to the -XFree86 common layer. - - <quote><p> - &s.code;void LoaderInit(void)&e.code; - <quote><p> - The &s.code;LoaderInit()&e.code; function initialises the loader, - and it must be called once before calling any other loader functions. - This function initialises the tables of exported symbols, and anything - else that might need to be initialised. - - </quote> - - &s.code;void LoaderSetPath(const char *path)&e.code; - <quote><p> - The &s.code;LoaderSetPath()&e.code; function initialises a default - module search path. This must be called if calls to other functions - are to be made without explicitly specifying a module search path. - The search path &s.code;path&e.code; must be a string of one or more - comma separated absolute paths. Modules are expected to be located - below these paths, possibly in subdirectories of these paths. - - </quote> - - &s.code;pointer LoadModule(const char *module, const char *path, - &f.indent;const char **subdirlist, const char **patternlist, - &f.indent;pointer options, const XF86ModReqInfo * modreq, - &f.indent;int *errmaj, int *errmin)&e.code; - <quote><p> - The &s.code;LoadModule()&e.code; function loads the module called - &s.code;module&e.code;. The return value is a module handle, and - may be used in future calls to the loader that require a reference - to a loaded module. The module name &s.code;module&e.code; is - normally the module's canonical name, which doesn't contain any - directory path information, or any object/library file prefixes of - suffixes. Currently a full pathname and/or filename is also accepted. - This might change. The other parameters are: - - &s.code;path&e.code; - <quote><p> - An optional comma-separated list of module search paths. - When &s.code;NULL&e.code;, the default search path is used. - - </quote> - - &s.code;subdirlist&e.code; - <quote><p> - An optional &s.code;NULL&e.code; terminated list of - subdirectories to search. When &s.code;NULL&e.code;, - the default built-in list is used (refer to - &s.code;stdSubdirs&e.code; in &s.code;loadmod.c&e.code;). - The default list is also substituted for entries in - &s.code;subdirlist&e.code; with the value - &s.code;DEFAULT_LIST&e.code;. This makes is possible - to augment the default list instead of replacing it. - Subdir elements must be relative, and must not contain - &s.code;".."&e.code;. If any violate this requirement, - the load fails. - - </quote> - - &s.code;patternlist&e.code; - <quote><p> - An optional &s.code;NULL&e.code; terminated list of - POSIX regular expressions used to connect module - filenames with canonical module names. Each regex - should contain exactly one subexpression that corresponds - to the canonical module name. When &s.code;NULL&e.code;, - the default built-in list is used (refer to - &s.code;stdPatterns&e.code; in - &s.code;loadmod.c&e.code;). The default list is also - substituted for entries in &s.code;patternlist&e.code; - with the value &s.code;DEFAULT_LIST&e.code;. This - makes it possible to augment the default list instead - of replacing it. - - </quote> - - &s.code;options&e.code; - <quote><p> - An optional parameter that is passed to the newly - loaded module's &s.code;SetupProc&e.code; function - (if it has one). This argument is normally a - &s.code;NULL&e.code; terminated list of - &s.code;Options&e.code;, and must be interpreted that - way by modules loaded directly by the XFree86 common - layer. However, it may be used for application-specific - parameter passing in other situations. - - When loading ``external'' modules (modules that don't - have the standard entry point, for example a - special shared library) the options parameter can be - set to &s.code;EXTERN_MODULE&e.code; to tell the - loader not to reject the module when it doesn't find - the standard entry point. - - </quote> - - &s.code;modreq&e.code; - <quote><p> - An optional &s.code;XF86ModReqInfo*&e.code; containing - version/ABI/vendor information to requirements to - check the newly loaded module against. The main - purpose of this is to allow the loader to verify that - a module of the correct type/version before running - its &s.code;SetupProc&e.code; function. - - The &s.code;XF86ModReqInfo&e.code; struct is defined - as follows: -<verb> -typedef struct { - CARD8 majorversion; /* MAJOR_UNSPEC */ - CARD8 minorversion; /* MINOR_UNSPEC */ - CARD16 patchlevel; /* PATCH_UNSPEC */ - const char * abiclass; /* ABI_CLASS_NONE */ - CARD32 abiversion; /* ABI_VERS_UNSPEC */ - const char * moduleclass; /* MOD_CLASS_NONE */ -} XF86ModReqInfo; -</verb> - - The information here is compared against the equivalent - information in the module's - &s.code;XF86ModuleVersionInfo&e.code; record (which - is described below). The values in comments above - indicate ``don't care'' settings for each of the fields. - The comparisons made are as follows: - - &s.code;majorversion&e.code; - <quote><p> - Must match the module's majorversion - exactly. - - </quote> - &s.code;minorversion&e.code; - <quote><p> - The module's minor version must be - no less than this value. This - comparison is only made if - &s.code;majorversion&e.code; is - specified and matches. - - </quote> - &s.code;patchlevel&e.code; - <quote><p> - The module's patchlevel must be no - less than this value. This comparison - is only made if - &s.code;minorversion&e.code; is - specified and matches. - - </quote> - &s.code;abiclass&e.code; - <quote><p> - String must match the module's abiclass - string. - - </quote> - &s.code;abiversion&e.code; - <quote><p> - Must be consistent with the module's - abiversion (major equal, minor no - older). - - </quote> - &s.code;moduleclass&e.code; - <quote><p> - String must match the module's - moduleclass string. - - </quote> - - </quote> - - &s.code;errmaj&e.code; - <quote><p> - An optional pointer to a variable holding the major - part or the error code. When provided, - &s.code;*errmaj&e.code; is filled in when - &s.code;LoadModule()&e.code; fails. - - </quote> - - &s.code;errmin&e.code; - <quote><p> - Like &s.code;errmaj&e.code;, but for the minor part - of the error code. - - </quote> - - </quote> - - &s.code;void UnloadModule(pointer mod)&e.code; - <quote><p> - This function unloads the module referred to by the handle mod. - All child modules are also unloaded recursively. This function must - not be used to directly unload modules that are child modules (i.e., - those that have been loaded with the &s.code;LoadSubModule()&e.code; - described below). - - </quote> - </quote> - -<sect1>Module Requirements -<p> - -Modules must provide information about themselves to the loader, and -may optionally provide entry points for "setup" and "teardown" functions -(those two functions are referred to here as &s.code;SetupProc&e.code; -and &s.code;TearDownProc&e.code;). - -The module information is contained in the -&s.code;XF86ModuleVersionInfo&e.code; struct, which is defined as follows: - -<quote><p><verb> -typedef struct { - const char * modname; /* name of module, e.g. "foo" */ - const char * vendor; /* vendor specific string */ - CARD32 _modinfo1_; /* constant MODINFOSTRING1/2 to find */ - CARD32 _modinfo2_; /* infoarea with a binary editor/sign tool */ - CARD32 xf86version; /* contains XF86_VERSION_CURRENT */ - CARD8 majorversion; /* module-specific major version */ - CARD8 minorversion; /* module-specific minor version */ - CARD16 patchlevel; /* module-specific patch level */ - const char * abiclass; /* ABI class that the module uses */ - CARD32 abiversion; /* ABI version */ - const char * moduleclass; /* module class */ - CARD32 checksum[4]; /* contains a digital signature of the */ - /* version info structure */ -} XF86ModuleVersionInfo; -</verb> - -The fields are used as follows: - - &s.code;modname&e.code; - <quote><p> - The module's name. This field is currently only for - informational purposes, but the loader may be modified - in future to require it to match the module's canonical - name. - - </quote> - - &s.code;vendor&e.code; - <quote><p> - The module vendor. This field is for informational purposes - only. - - </quote> - - &s.code;_modinfo1_&e.code; - <quote><p> - This field holds the first part of a signature that can - be used to locate this structure in the binary. It should - always be initialised to &s.code;MODINFOSTRING1&e.code;. - - </quote> - - &s.code;_modinfo2_&e.code; - <quote><p> - This field holds the second part of a signature that can - be used to locate this structure in the binary. It should - always be initialised to &s.code;MODINFOSTRING2&e.code;. - - </quote> - - &s.code;xf86version&e.code; - <quote><p> - The XFree86 version against which the module was compiled. - This is mostly for informational/diagnostic purposes. It - should be initialised to &s.code;XF86_VERSION_CURRENT&e.code;, which is - defined in &s.code;xf86Version.h&e.code;. - - </quote> - - &s.code;majorversion&e.code; - <quote><p> - The module-specific major version. For modules where this - version is used for more than simply informational - purposes, the major version should only change (be - incremented) when ABI incompatibilities are introduced, - or ABI components are removed. - - </quote> - - &s.code;minorversion&e.code; - <quote><p> - The module-specific minor version. For modules where this - version is used for more than simply informational - purposes, the minor version should only change (be - incremented) when ABI additions are made in a backward - compatible way. It should be reset to zero when the major - version is increased. - - </quote> - - &s.code;patchlevel&e.code; - <quote><p> - The module-specific patch level. The patch level should - increase with new revisions of the module where there - are no ABI changes, and it should be reset to zero when - the minor version is increased. - - </quote> - - &s.code;abiclass&e.code; - <quote><p> - The ABI class that the module requires. The class is - specified as a string for easy extensibility. It should - indicate which (if any) of the X server's built-in ABI - classes that the module relies on, or a third-party ABI - if appropriate. Built-in ABI classes currently defined are: - - <quote> - &s.code;ABI_CLASS_NONE&e.code; - <quote>no class</quote> - &s.code;ABI_CLASS_ANSIC&e.code; - <quote>only requires the ANSI C interfaces</quote> - &s.code;ABI_CLASS_VIDEODRV&e.code; - <quote>requires the video driver ABI</quote> - &s.code;ABI_CLASS_XINPUT&e.code; - <quote>requires the XInput driver ABI</quote> - &s.code;ABI_CLASS_EXTENSION&e.code; - <quote>requires the extension module ABI</quote> - &s.code;ABI_CLASS_FONT&e.code; - <quote>requires the font module ABI</quote> - </quote> - - </quote> - - &s.code;abiversion&e.code; - <quote><p> - The version of abiclass that the module requires. The - version consists of major and minor components. The - major version must match and the minor version must be - no newer than that provided by the server or parent - module. Version identifiers for the built-in classes - currently defined are: - - <quote> - &s.code;ABI_ANSIC_VERSION&nl; - ABI_VIDEODRV_VERSION&nl; - ABI_XINPUT_VERSION&nl; - ABI_EXTENSION_VERSION&nl; - ABI_FONT_VERSION&e.code; - </quote> - - </quote> - - &s.code;moduleclass&e.code; - <quote><p> - This is similar to the abiclass field, except that it - defines the type of module rather than the ABI it - requires. For example, although all video drivers require - the video driver ABI, not all modules that require the - video driver ABI are video drivers. This distinction - can be made with the moduleclass. Currently pre-defined - module classes are: - - <quote> - &s.code;MOD_CLASS_NONE&nl; - MOD_CLASS_VIDEODRV&nl; - MOD_CLASS_XINPUT&nl; - MOD_CLASS_FONT&nl; - MOD_CLASS_EXTENSION&e.code; - </quote> - - </quote> - - &s.code;checksum&e.code; - <quote><p> - Not currently used. - - </quote> - -</quote> - -The module version information, and the optional &s.code;SetupProc&e.code; -and &s.code;TearDownProc&e.code; entry points are found by the loader -by locating a data object in the module called "modnameModuleData", -where "modname" is the canonical name of the module. Modules must -contain such a data object, and it must be declared with global scope, -be compile-time initialised, and is of the following type: - -<quote> -<verb> -typedef struct { - XF86ModuleVersionInfo * vers; - ModuleSetupProc setup; - ModuleTearDownProc teardown; -} XF86ModuleData; -</verb> -</quote> - -The vers parameter must be initialised to a pointer to a correctly -initialised &s.code;XF86ModuleVersionInfo&e.code; struct. The other -two parameter are optional, and should be initialised to -&s.code;NULL&e.code; when not required. The other parameters are defined -as - - <quote><p> - &s.code;typedef pointer (*ModuleSetupProc)(pointer, pointer, int *, int *)&e.code; - - &s.code;typedef void (*ModuleTearDownProc)(pointer)&e.code; - - - &s.code;pointer SetupProc(pointer module, pointer options, - &f.indent;int *errmaj, int *errmin)&e.code; - <quote><p> - When defined, this function is called by the loader after successfully - loading a module. module is a handle for the newly loaded module, - and maybe used by the &s.code;SetupProc&e.code; if it calls other - loader functions that require a reference to it. The remaining - arguments are those that were passed to the - &s.code;LoadModule()&e.code; (or &s.code;LoadSubModule()&e.code;), - and are described above. When the &s.code;SetupProc&e.code; is - successful it must return a non-&s.code;NULL&e.code; value. The - loader checks this, and if it is &s.code;NULL&e.code; it unloads - the module and reports the failure to the caller of - &s.code;LoadModule()&e.code;. If the &s.code;SetupProc&e.code; - does things that need to be undone when the module is unloaded, - it should define a &s.code;TearDownProc&e.code;, and return a - pointer that the &s.code;TearDownProc&e.code; can use to undo what - has been done. - - When a module is loaded multiple times, the &s.code;SetupProc&e.code; - is called once for each time it is loaded. - - </quote> - - &s.code;void TearDownProc(pointer tearDownData)&e.code; - <quote><p> - When defined, this function is called when the loader unloads a - module. The &s.code;tearDownData&e.code; parameter is the return - value of the &s.code;SetupProc()&e.code; that was called when the - module was loaded. The purpose of this function is to clean up - before the module is unloaded (for example, by freeing allocated - resources). - - </quote> - </quote> - -<sect1>Public Loader Interface -<p> - -The following is the Loader interface that is available to any part of -the server, and may also be used from within modules. - - <quote><p> - &s.code;pointer LoadSubModule(pointer parent, const char *module, - &f.indent;const char **subdirlist, const char **patternlist, - &f.indent;pointer options, const XF86ModReqInfo * modreq, - &f.indent;int *errmaj, int *errmin)&e.code; - <quote><p> - This function is like the &s.code;LoadModule()&e.code; function - described above, except that the module loaded is registered as a - child of the calling module. The &s.code;parent&e.code; parameter - is the calling module's handle. Modules loaded with this function - are automatically unloaded when the parent module is unloaded. The - other difference is that the path parameter may not be specified. - The module search path used for modules loaded with this function - is the default search path as initialised with - &s.code;LoaderSetPath()&e.code;. - - </quote> - - &s.code;void UnloadSubModule(pointer module)&e.code; - <quote><p> - This function unloads the module with handle &s.code;module&e.code;. - If that module itself has children, they are also unloaded. It is - like &s.code;UnloadModule()&e.code;, except that it is safe to use - for unloading child modules. - - </quote> - - &s.code;pointer LoaderSymbol(const char *symbol)&e.code; - <quote><p> - This function returns the address of the symbol with name - &s.code;symbol&e.code;. This may be used to locate a module entry - point with a known name. - - </quote> - - &s.code;char **LoaderlistDirs(const char **subdirlist, - &f.indent;const char **patternlist)&e.code; - <quote><p> - This function returns a &s.code;NULL&e.code; terminated list of - canonical modules names for modules found in the default module - search path. The &s.code;subdirlist&e.code; and - &s.code;patternlist&e.code; parameters are as described above, and - can be used to control the locations and names that are searched. - If no modules are found, the return value is &s.code;NULL&e.code;. - The returned list should be freed by calling - &s.code;LoaderFreeDirList()&e.code; when it is no longer needed. - - </quote> - - &s.code;void LoaderFreeDirList(char **list)&e.code; - <quote><p> - This function frees a module list created by - &s.code;LoaderlistDirs()&e.code;. - - </quote> - - &s.code;void LoaderReqSymLists(const char **list0, ...)&e.code; - <quote><p> - This function allows the registration of required symbols with the - loader. It is normally used by a caller of - &s.code;LoadSubModule()&e.code;. If any symbols registered in this - way are found to be unresolved when - &s.code;LoaderCheckUnresolved()&e.code; is called then - &s.code;LoaderCheckUnresolved()&e.code; will report a failure. - The function takes one or more &s.code;NULL&e.code; terminated - lists of symbols. The end of the argument list is indicated by a - &s.code;NULL&e.code; argument. - - </quote> - - &s.code;void LoaderReqSymbols(const char *sym0, ...)&e.code; - <quote><p> - This function is like &s.code;LoaderReqSymLists()&e.code; except - that its arguments are symbols rather than lists of symbols. This - function is more convenient when single functions are to be registered, - especially when the single function might depend on runtime factors. - The end of the argument list is indicated by a &s.code;NULL&e.code; - argument. - - </quote> - - &s.code;void LoaderRefSymLists(const char **list0, ...)&e.code; - <quote><p> - This function allows the registration of possibly unresolved symbols - with the loader. When &s.code;LoaderCheckUnresolved()&e.code; is - run it won't generate warnings for symbols registered in this way - unless they were also registered as required symbols. - The function takes one or more &s.code;NULL&e.code; terminated - lists of symbols. The end of the argument list is indicated by a - &s.code;NULL&e.code; argument. - - </quote> - - &s.code;void LoaderRefSymbols(const char *sym0, ...)&e.code; - <quote><p> - This function is like &s.code;LoaderRefSymLists()&e.code; except - that its arguments are symbols rather than lists of symbols. This - function is more convenient when single functions are to be registered, - especially when the single function might depend on runtime factors. - The end of the argument list is indicated by a &s.code;NULL&e.code; - argument. - - </quote> - - &s.code;int LoaderCheckUnresolved(int delayflag)&e.code; - <quote><p> - This function checks for unresolved symbols. It generates warnings - for unresolved symbols that have not been registered with - &s.code;LoaderRefSymLists()&e.code;, and maps them to a dummy - function. This behaviour may change in future. If unresolved - symbols are found that have been registered with - &s.code;LoaderReqSymLists()&e.code; or - &s.code;LoaderReqSymbols()&e.code; then this function returns a - non-zero value. If none of these symbols are unresolved the return - value is zero, indicating success. - - The &s.code;delayflag&e.code; parameter should normally be set to - &s.code;LD_RESOLV_IFDONE&e.code;. - - </quote> - - &s.code;LoaderErrorMsg(const char *name, const char *modname, - &f.indent;int errmaj, int errmin)&e.code; - <quote><p> - This function prints an error message that includes the text ``Failed - to load module'', the module name &s.code;modname&e.code;, a message - specific to the &s.code;errmaj&e.code; value, and the value if - &s.code;errmin&e.code;. If &s.code;name&e.code; is - non-&s.code;NULL&e.code;, it is printed as an identifying prefix - to the message (followed by a `:'). - - </quote> - </quote> - -<sect1>Special Registration Functions -<p> - -The loader contains some functions for registering some classes of modules. -These may be moved out of the loader at some point. - - <quote><p> - &s.code;void LoadExtension(ExtensionModule *ext)&e.code; - <quote><p> - This registers the entry points for the extension identified by - &s.code;ext&e.code;. The &s.code;ExtensionModule&e.code; struct is - defined as: - -<quote> -<verb> -typedef struct { - InitExtension initFunc; - char * name; - Bool *disablePtr; - InitExtension setupFunc; -} ExtensionModule; -</verb> -</quote> - - </quote> - - &s.code;void LoadFont(FontModule *font)&e.code; - <quote><p> - This registers the entry points for the font rasteriser module - identified by &s.code;font&e.code;. The &s.code;FontModule&e.code; - struct is defined as: - -<quote> -<verb> -typedef struct { - InitFont initFunc; - char * name; - pointer module; -} FontModule; -</verb> -</quote> - - </quote> - </quote> - -</sect> - - -<sect>Helper Functions -<p> - -This section describe ``helper'' functions that video driver -might find useful. While video drivers are not required to use any of -these to be considered ``compliant'', the use of appropriate helpers is -strongly encouraged to improve the consistency of driver behaviour. - -<sect1>Functions for printing messages -<p> - - <quote><p> - &s.code;ErrorF(const char *format, ...)&e.code; - <quote><p> - This is the basic function for writing to the error log (typically - stderr and/or a log file). Video drivers should usually avoid - using this directly in favour of the more specialised functions - described below. This function is useful for printing messages - while debugging a driver. - - </quote> - - &s.code;FatalError(const char *format, ...)&e.code; - <quote><p> - This prints a message and causes the Xserver to abort. It should - rarely be used within a video driver, as most error conditions - should be flagged by the return values of the driver functions. - This allows the higher layers to decide how to proceed. In rare - cases, this can be used within a driver if a fatal unexpected - condition is found. - - </quote> - - &s.code;xf86ErrorF(const char *format, ...)&e.code; - <quote><p> - This is like &s.code;ErrorF()&e.code;, except that the message is - only printed when the Xserver's verbosity level is set to the - default (&s.code;1&e.code;) or higher. It means that the messages - are not printed when the server is started with the - &s.cmd;-quiet&e.cmd; flag. Typically this function would only be - used for continuing messages started with one of the more specialised - functions described below. - - </quote> - - &s.code;xf86ErrorFVerb(int verb, const char *format, ...)&e.code; - <quote><p> - Like &s.code;xf86ErrorF()&e.code;, except the minimum verbosity - level for which the message is to be printed is given explicitly. - Passing a &s.code;verb&e.code; value of zero means the message - is always printed. A value higher than &s.code;1&e.code; can be - used for information would normally not be needed, but which might - be useful when diagnosing problems. - - </quote> - - &s.code;xf86Msg(MessageType type, const char *format, ...)&e.code; - <quote><p> - This is like &s.code;xf86ErrorF()&e.code;, except that the message - is prefixed with a marker determined by the value of - &s.code;type&e.code;. The marker is used to indicate the type of - message (warning, error, probed value, config value, etc). Note - the &s.code;xf86Verbose&e.code; value is ignored for messages of - type &s.code;X_ERROR&e.code;. - - The marker values are: - - <quote> - &s.code;X_PROBED&e.code; - <quote>Value was probed.</quote> - &s.code;X_CONFIG&e.code; - <quote>Value was given in the config file.</quote> - &s.code;X_DEFAULT&e.code; - <quote>Value is a default.</quote> - &s.code;X_CMDLINE&e.code; - <quote>Value was given on the command line.</quote> - &s.code;X_NOTICE&e.code; - <quote>Notice.</quote> - &s.code;X_ERROR&e.code; - <quote>Error message.</quote> - &s.code;X_WARNING&e.code; - <quote>Warning message.</quote> - &s.code;X_INFO&e.code; - <quote>Informational message.</quote> - &s.code;X_NONE&e.code; - <quote>No prefix.</quote> - &s.code;X_NOT_IMPLEMENTED&e.code; - <quote>The message relates to functionality that is not yet - implemented.</quote> - </quote> - - - </quote> - - &s.code;xf86MsgVerb(MessageType type, int verb, const char *format, ...)&e.code; - <quote><p> - Like &s.code;xf86Msg()&e.code;, but with the verbosity level given - explicitly. - - </quote> - - &s.code;xf86DrvMsg(int scrnIndex, MessageType type, const char *format, ...)&e.code; - <quote><p> - This is like &s.code;xf86Msg()&e.code; except that the driver's - name (the &s.code;name&e.code; field of the - &s.code;ScrnInfoRec&e.code;) followed by the - &s.code;scrnIndex&e.code; in parentheses is printed following the - prefix. This should be used by video drivers in most cases as it - clearly indicates which driver/screen the message is for. If - &s.code;scrnIndex&e.code; is negative, this function behaves - exactly like &s.code;xf86Msg()&e.code;. - - NOTE: This function can only be used after the - &s.code;ScrnInfoRec&e.code; and its &s.code;name&e.code; field - have been allocated. Normally, this means that it can not be - used before the END of the &s.code;ChipProbe()&e.code; function. - Prior to that, use &s.code;xf86Msg()&e.code;, providing the - driver's name explicitly. No screen number can be supplied at - that point. - - </quote> - - &s.code;xf86DrvMsgVerb(int scrnIndex, MessageType type, int verb, - &f.indent;const char *format, ...)&e.code; - <quote><p> - Like &s.code;xf86DrvMsg()&e.code;, but with the verbosity level - given explicitly. - - </quote> - </quote> - - -<sect1>Functions for setting values based on command line and config file -<p> - - <quote><p> - &s.code;Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp, - &f.indent;int fbbpp, int depth24flags)&e.code; - <quote><p> - This function sets the &s.code;depth&e.code;, &s.code;pixmapBPP&e.code; and &s.code;bitsPerPixel&e.code; fields - of the &s.code;ScrnInfoRec&e.code;. It also determines the defaults for display-wide - attributes and pixmap formats the screen will support, and finds - the Display subsection that matches the depth/bpp. This function - should normally be called very early from the - &s.code;ChipPreInit()&e.code; function. - - It requires that the &s.code;confScreen&e.code; field of the &s.code;ScrnInfoRec&e.code; be - initialised prior to calling it. This is done by the XFree86 - common layer prior to calling &s.code;ChipPreInit()&e.code;. - - The parameters passed are: - - &s.code;depth&e.code; - <quote><p> - driver's preferred default depth if no other is given. - If zero, use the overall server default. - - </quote> - &s.code;bpp&e.code; - <quote><p> - Same, but for the pixmap bpp. - - </quote> - &s.code;fbbpp&e.code; - <quote><p> - Same, but for the framebuffer bpp. - - </quote> - &s.code;depth24flags&e.code; - <quote><p> - Flags that indicate the level of 24/32bpp support - and whether conversion between different framebuffer - and pixmap formats is supported. The flags for this - argument are defined as follows, and multiple flags - may be ORed together: - - &s.code;NoDepth24Support&e.code; - <quote>No depth 24 formats supported</quote> - &s.code;Support24bppFb&e.code; - <quote>24bpp framebuffer supported</quote> - &s.code;Support32bppFb&e.code; - <quote>32bpp framebuffer supported</quote> - &s.code;SupportConvert24to32&e.code; - <quote>Can convert 24bpp pixmap to 32bpp fb</quote> - &s.code;SupportConvert32to24&e.code; - <quote>Can convert 32bpp pixmap to 24bpp fb</quote> - &s.code;ForceConvert24to32&e.code; - <quote>Force 24bpp pixmap to 32bpp fb conversion</quote> - &s.code;ForceConvert32to24&e.code; - <quote>Force 32bpp pixmap to 24bpp fb conversion</quote> - - </quote> - - It uses the command line, config file, and default values in the - correct order of precedence to determine the depth and bpp values. - It is up to the driver to check the results to see that it supports - them. If not the &s.code;ChipPreInit()&e.code; function should - return &s.code;FALSE&e.code;. - - If only one of depth/bpp is given, the other is set to a reasonable - (and consistent) default. - - If a driver finds that the initial &s.code;depth24flags&e.code; - it uses later results in a fb format that requires more video - memory than is available it may call this function a second time - with a different &s.code;depth24flags&e.code; setting. - - On success, the return value is &s.code;TRUE&e.code;. On failure - it prints an error message and returns &s.code;FALSE&e.code;. - - The following fields of the &s.code;ScrnInfoRec&e.code; are - initialised by this function: - - <quote> - &s.code;depth&e.code;, &s.code;bitsPerPixel&e.code;, - &s.code;display&e.code;, &s.code;imageByteOrder&e.code;, - &s.code;bitmapScanlinePad&e.code;, - &s.code;bitmapScanlineUnit&e.code;, &s.code;bitmapBitOrder&e.code;, - &s.code;numFormats&e.code;, &s.code;formats&e.code;, - &s.code;fbFormat&e.code;. - </quote> - - </quote> - - &s.code;void xf86PrintDepthBpp(scrnInfoPtr scrp)&e.code; - <quote><p> - This function can be used to print out the depth and bpp settings. - It should be called after the final call to - &s.code;xf86SetDepthBpp()&e.code;. - - </quote> - - &s.code;Bool xf86SetWeight(ScrnInfoPtr scrp, rgb weight, rgb mask)&e.code; - <quote><p> - This function sets the &s.code;weight&e.code;, &s.code;mask&e.code;, - &s.code;offset&e.code; and &s.code;rgbBits&e.code; fields of the - &s.code;ScrnInfoRec&e.code;. It would normally be called fairly - early in the &s.code;ChipPreInit()&e.code; function for - depths > 8bpp. - - It requires that the &s.code;depth&e.code; and - &s.code;display&e.code; fields of the &s.code;ScrnInfoRec&e.code; - be initialised prior to calling it. - - The parameters passed are: - - &s.code;weight&e.code; - <quote><p> - driver's preferred default weight if no other is given. - If zero, use the overall server default. - - </quote> - - &s.code;mask&e.code; - <quote><p> - Same, but for mask. - - </quote> - - It uses the command line, config file, and default values in the - correct order of precedence to determine the weight value. It - derives the mask and offset values from the weight and the defaults. - It is up to the driver to check the results to see that it supports - them. If not the &s.code;ChipPreInit()&e.code; function should - return &s.code;FALSE&e.code;. - - On success, this function prints a message showing the weight - values selected, and returns &s.code;TRUE&e.code;. - - On failure it prints an error message and returns &s.code;FALSE&e.code;. - - The following fields of the &s.code;ScrnInfoRec&e.code; are - initialised by this function: - - <quote> - &s.code;weight&e.code;, &s.code;mask&e.code;, &s.code;offset&e.code;. - </quote> - - </quote> - - &s.code;Bool xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual)&e.code; - <quote><p> - This function sets the &s.code;defaultVisual&e.code; field of the - &s.code;ScrnInfoRec&e.code;. It would normally be called fairly - early from the &s.code;ChipPreInit()&e.code; function. - - It requires that the &s.code;depth&e.code; and - &s.code;display&e.code; fields of the &s.code;ScrnInfoRec&e.code; - be initialised prior to calling it. - - The parameters passed are: - - &s.code;visual&e.code; - <quote><p> - driver's preferred default visual if no other is given. - If &s.code;-1&e.code;, use the overall server default. - - </quote> - - It uses the command line, config file, and default values in the - correct order of precedence to determine the default visual value. - It is up to the driver to check the result to see that it supports - it. If not the &s.code;ChipPreInit()&e.code; function should - return &s.code;FALSE&e.code;. - - On success, this function prints a message showing the default visual - selected, and returns &s.code;TRUE&e.code;. - - On failure it prints an error message and returns &s.code;FALSE&e.code;. - - </quote> - - &s.code;Bool xf86SetGamma(ScrnInfoPtr scrp, Gamma gamma)&e.code; - <quote><p> - This function sets the &s.code;gamma&e.code; field of the - &s.code;ScrnInfoRec&e.code;. It would normally be called fairly - early from the &s.code;ChipPreInit()&e.code; function in cases - where the driver supports gamma correction. - - It requires that the &s.code;monitor&e.code; field of the - &s.code;ScrnInfoRec&e.code; be initialised prior to calling it. - - The parameters passed are: - - &s.code;gamma&e.code; - <quote><p> - driver's preferred default gamma if no other is given. - If zero (&s.code;< 0.01&e.code;), use the overall server - default. - - </quote> - - It uses the command line, config file, and default values in the - correct order of precedence to determine the gamma value. It is - up to the driver to check the results to see that it supports - them. If not the &s.code;ChipPreInit()&e.code; function should - return &s.code;FALSE&e.code;. - - On success, this function prints a message showing the gamma - value selected, and returns &s.code;TRUE&e.code;. - - On failure it prints an error message and returns &s.code;FALSE&e.code;. - - </quote> - - &s.code;void xf86SetDpi(ScrnInfoPtr pScrn, int x, int y)&e.code; - <quote><p> - This function sets the &s.code;xDpi&e.code; and &s.code;yDpi&e.code; - fields of the &s.code;ScrnInfoRec&e.code;. The driver can specify - preferred defaults by setting &s.code;x&e.code; and &s.code;y&e.code; - to non-zero values. The &s.cmd;-dpi&e.cmd; command line option - overrides all other settings. Otherwise, if the - &s.key;DisplaySize&e.key; entry is present in the screen's &k.monitor; - config file section, it is used together with the virtual size to - calculate the dpi values. This function should be called after - all the mode resolution has been done. - - </quote> - - &s.code;void xf86SetBlackWhitePixels(ScrnInfoPtr pScrn)&e.code; - <quote><p> - This functions sets the &s.code;blackPixel&e.code; and - &s.code;whitePixel&e.code; fields of the &s.code;ScrnInfoRec&e.code; - according to whether or not the &s.cmd;-flipPixels&e.cmd; command - line options is present. - - </quote> - - &s.code;const char *xf86GetVisualName(int visual)&e.code; - <quote><p> - Returns a printable string with the visual name matching the - numerical visual class provided. If the value is outside the - range of valid visual classes, &s.code;NULL&e.code; is returned. - - </quote> - </quote> - - -<sect1>Primary Mode functions -<p> - -The primary mode helper functions are those which would normally be -used by a driver, unless it has unusual requirements which cannot -be catered for the by the helpers. - - <quote><p> - &s.code;int xf86ValidateModes(ScrnInfoPtr scrp, DisplayModePtr availModes, - &f.indent;char **modeNames, ClockRangePtr clockRanges, - &f.indent;int *linePitches, int minPitch, int maxPitch, - &f.indent;int pitchInc, int minHeight, int maxHeight, - &f.indent;int virtualX, int virtualY, - &f.indent;unsigned long apertureSize, - &f.indent;LookupModeFlags strategy)&e.code; - <quote><p> - This function basically selects the set of modes to use based on - those available and the various constraints. It also sets some - other related parameters. It is normally called near the end of - the &s.code;ChipPreInit()&e.code; function. - - The parameters passed to the function are: - - &s.code;availModes&e.code; - <quote><p> - List of modes available for the monitor. - - </quote> - &s.code;modeNames&e.code; - <quote><p> - List of mode names that the screen is requesting. - - </quote> - &s.code;clockRanges&e.code; - <quote><p> - A list of clock ranges allowed by the driver. Each - range includes whether interlaced or multiscan modes - are supported for that range. See below for more on - &s.code;clockRanges&e.code;. - - </quote> - &s.code;linePitches&e.code; - <quote><p> - List of line pitches supported by the driver. - This is optional and should be &s.code;NULL&e.code; when - not used. - - </quote> - &s.code;minPitch&e.code; - <quote><p> - Minimum line pitch supported by the driver. This must - be supplied when &s.code;linePitches&e.code; is - &s.code;NULL&e.code;, and is ignored otherwise. - - </quote> - &s.code;maxPitch&e.code; - <quote><p> - Maximum line pitch supported by the driver. This is - required when &s.code;minPitch&e.code; is required. - - </quote> - &s.code;pitchInc&e.code; - <quote><p> - Granularity of horizontal pitch values as supported by - the chipset. This is expressed in bits. This must be - supplied. - - </quote> - &s.code;minHeight&e.code; - <quote><p> - minimum virtual height allowed. If zero, no limit is - imposed. - - </quote> - &s.code;maxHeight&e.code; - <quote><p> - maximum virtual height allowed. If zero, no limit is - imposed. - - </quote> - &s.code;virtualX&e.code; - <quote><p> - If greater than zero, this is the virtual width value - that will be used. Otherwise, the virtual width is - chosen to be the smallest that can accommodate the modes - selected. - - </quote> - &s.code;virtualY&e.code; - <quote><p> - If greater than zero, this is the virtual height value - that will be used. Otherwise, the virtual height is - chosen to be the smallest that can accommodate the modes - selected. - - </quote> - &s.code;apertureSize&e.code; - <quote><p> - The size (in bytes) of the aperture used to access video - memory. - - </quote> - &s.code;strategy&e.code; - <quote><p> - The strategy to use when choosing from multiple modes - with the same name. The options are: - - &s.code;LOOKUP_DEFAULT&e.code; - <quote>???</quote> - &s.code;LOOKUP_BEST_REFRESH&e.code; - <quote>mode with best refresh rate</quote> - &s.code;LOOKUP_CLOSEST_CLOCK&e.code; - <quote>mode with closest matching clock</quote> - &s.code;LOOKUP_LIST_ORDER&e.code; - <quote>first usable mode in list</quote> - - The following options can also be combined (OR'ed) with - one of the above: - - &s.code;LOOKUP_CLKDIV2&e.code; - <quote>Allow halved clocks</quote> - &s.code;LOOKUP_OPTIONAL_TOLERANCES&e.code; - <quote>Allow missing horizontal sync and/or vertical refresh - ranges in the xorg.conf Monitor section</quote> - - &s.code;LOOKUP_OPTIONAL_TOLERANCES&e.code; should only be - specified when the driver can ensure all modes it generates - can sync on, or at least not damage, the monitor or digital - flat panel. Horizontal sync and/or vertical refresh ranges - specified by the user will still be honoured (and acted upon). - - </quote> - - This function requires that the following fields of the - &s.code;ScrnInfoRec&e.code; are initialised prior to calling it: - - &s.code;clock[]&e.code; - <quote>List of discrete clocks (when non-programmable)</quote> - &s.code;numClocks&e.code; - <quote>Number of discrete clocks (when non-programmable)</quote> - &s.code;progClock&e.code; - <quote>Whether the clock is programmable or not</quote> - &s.code;monitor&e.code; - <quote>Pointer to the applicable xorg.conf monitor section</quote> - &s.code;fdFormat&e.code; - <quote>Format of the screen buffer</quote> - &s.code;videoRam&e.code; - <quote>total video memory size (in bytes)</quote> - &s.code;maxHValue&e.code; - <quote>Maximum horizontal timing value allowed</quote> - &s.code;maxVValue&e.code; - <quote>Maximum vertical timing value allowed</quote> - &s.code;xInc&e.code; - <quote>Horizontal timing increment in pixels (defaults to 8)</quote> - - This function fills in the following &s.code;ScrnInfoRec&e.code; - fields: - - &s.code;modePool&e.code; - <quote><p> - A subset of the modes available to the monitor which - are compatible with the driver. - - </quote> - &s.code;modes&e.code; - <quote><p> - One mode entry for each of the requested modes, with - the status field of each filled in to indicate if - the mode has been accepted or not. This list of - modes is a circular list. - - </quote> - &s.code;virtualX&e.code; - <quote><p> - The resulting virtual width. - - </quote> - &s.code;virtualY&e.code; - <quote><p> - The resulting virtual height. - - </quote> - &s.code;displayWidth&e.code; - <quote><p> - The resulting line pitch. - - </quote> - &s.code;virtualFrom&e.code; - <quote><p> - Where the virtual size was determined from. - - </quote> - - The first stage of this function checks that the - &s.code;virtualX&e.code; and &s.code;virtualY&e.code; values - supplied (if greater than zero) are consistent with the line pitch - and &s.code;maxHeight&e.code; limitations. If not, an error - message is printed, and the return value is &s.code;-1&e.code;. - - The second stage sets up the mode pool, eliminating immediately - any modes that exceed the driver's line pitch limits, and also - the virtual width and height limits (if greater than zero). For - each mode removed an informational message is printed at verbosity - level &s.code;2&e.code;. If the mode pool ends up being empty, - a warning message is printed, and the return value is - &s.code;0&e.code;. - - The final stage is to lookup each mode name, and fill in the remaining - parameters. If an error condition is encountered, a message is - printed, and the return value is &s.code;-1&e.code;. Otherwise, - the return value is the number of valid modes found - (&s.code;0&e.code; if none are found). - - Even if the supplied mode names include duplicates, no two names will - ever match the same mode. Furthermore, if the supplied mode names do not - yield a valid mode (including the case where no names are passed at all), - the function will continue looking through the mode pool until it finds - a mode that survives all checks, or until the mode pool is exhausted. - - A message is only printed by this function when a fundamental - problem is found. It is intended that this function may be called - more than once if there is more than one set of constraints that - the driver can work within. - - If this function returns &s.code;-1&e.code;, the - &s.code;ChipPreInit()&e.code; function should return - &s.code;FALSE&e.code;. - - &s.code;clockRanges&e.code; is a linked list of clock ranges - allowed by the driver. If a mode doesn't fit in any of the defined - &s.code;clockRanges&e.code;, it is rejected. The first - &s.code;clockRange&e.code; that matches all requirements is used. - This structure needs to be initialized to NULL when allocated. - - &s.code;clockRanges&e.code; contains the following fields: - - &s.code;minClock&nl; - maxClock&e.code; - <quote><p> - The lower and upper mode clock bounds for which the rest - of the &s.code;clockRange&e.code; parameters apply. - Since these are the mode clocks, they are not scaled - with the &s.code;ClockMulFactor&e.code; and - &s.code;ClockDivFactor&e.code;. It is up to the driver - to adjust these values if they depend on the clock - scaling factors. - - </quote> - &s.code;clockIndex&e.code; - <quote><p> - (not used yet) &s.code;-1&e.code; for programmable clocks - - </quote> - &s.code;interlaceAllowed&e.code; - <quote><p> - &s.code;TRUE&e.code; if interlacing is allowed for this - range - - </quote> - &s.code;doubleScanAllowed&e.code; - <quote><p> - &s.code;TRUE&e.code; if doublescan or multiscan is allowed - for this range - - </quote> - &s.code;ClockMulFactor&nl; - ClockDivFactor&e.code; - <quote><p> - Scaling factors that are applied to the mode clocks ONLY - before selecting a clock index (when there is no - programmable clock) or a &s.code;SynthClock&e.code; - value. This is useful for drivers that support pixel - multiplexing or that need to scale the clocks because - of hardware restrictions (like sending 24bpp data to an - 8 bit RAMDAC using a tripled clock). - - Note that these parameters describe what must be done - to the mode clock to achieve the data transport clock - between graphics controller and RAMDAC. For example - for &s.code;2:1&e.code; pixel multiplexing, two pixels - are sent to the RAMDAC on each clock. This allows the - RAMDAC clock to be half of the actual pixel clock. - Hence, &s.code;ClockMulFactor=1&e.code; and - &s.code;ClockDivFactor=2&e.code;. This means that the - clock used for clock selection (ie, determining the - correct clock index from the list of discrete clocks) - or for the &s.code;SynthClock&e.code; field in case of - a programmable clock is: (&s.code;mode->Clock * - ClockMulFactor) / ClockDivFactor&e.code;. - - </quote> - &s.code;PrivFlags&e.code; - <quote><p> - This field is copied into the - &s.code;mode->PrivFlags&e.code; field when this - &s.code;clockRange&e.code; is selected by - &s.code;xf86ValidateModes()&e.code;. It allows the - driver to find out what clock range was selected, so it - knows it needs to set up pixel multiplexing or any other - range-dependent feature. This field is purely - driver-defined: it may contain flag bits, an index or - anything else (as long as it is an &s.code;INT&e.code;). - </quote> - - Note that the &s.code;mode->SynthClock&e.code; field is always - filled in by &s.code;xf86ValidateModes()&e.code;: it will contain - the ``data transport clock'', which is the clock that will have - to be programmed in the chip when it has a programmable clock, or - the clock that will be picked from the clocks list when it is not - a programmable one. Thus: - - &s.code;mode->SynthClock = - &f.indent;(mode->Clock * ClockMulFactor) / ClockDivFactor&e.code; - - </quote> - - &s.code;void xf86PruneDriverModes(ScrnInfoPtr scrp)&e.code; - <quote><p> - This function deletes modes in the modes field of the - &s.code;ScrnInfoRec&e.code; that have been marked as invalid. - This is normally run after having run - &s.code;xf86ValidateModes()&e.code; for the last time. For each - mode that is deleted, a warning message is printed out indicating - the reason for it being deleted. - - </quote> - - &s.code;void xf86SetCrtcForModes(ScrnInfoPtr scrp, int adjustFlags)&e.code; - <quote><p> - This function fills in the &s.code;Crtc*&e.code; fields for all - the modes in the &s.code;modes&e.code; field of the - &s.code;ScrnInfoRec&e.code;. The &s.code;adjustFlags&e.code; - parameter determines how the vertical CRTC values are scaled for - interlaced modes. They are halved if it is - &s.code;INTERLACE_HALVE_V&e.code;. The vertical CRTC values are - doubled for doublescan modes, and are further multiplied by the - &s.code;VScan&e.code; value. - - This function is normally called after calling - &s.code;xf86PruneDriverModes()&e.code;. - - </quote> - - &s.code;void xf86PrintModes(ScrnInfoPtr scrp)&e.code; - <quote><p> - This function prints out the virtual size setting, and the line - pitch being used. It also prints out two lines for each mode being - used. The first line includes the mode's pixel clock, horizontal sync - rate, refresh rate, and whether it is interlaced, doublescanned and/or - multi-scanned. The second line is the mode's Modeline. - - This function is normally called after calling - &s.code;xf86SetCrtcForModes()&e.code;. - - </quote> - </quote> - - -<sect1>Secondary Mode functions -<p> - -The secondary mode helper functions are functions which are normally -used by the primary mode helper functions, and which are not normally -called directly by a driver. If a driver has unusual requirements -and needs to do its own mode validation, it might be able to make -use of some of these secondary mode helper functions. - - <quote><p> - &s.code;int xf86GetNearestClock(ScrnInfoPtr scrp, int freq, Bool allowDiv2, - &f.indent;int *divider)&e.code; - <quote><p> - This function returns the index of the closest clock to the - frequency &s.code;freq&e.code; given (in kHz). It assumes that - the number of clocks is greater than zero. It requires that the - &s.code;numClocks&e.code; and &s.code;clock&e.code; fields of the - &s.code;ScrnInfoRec&e.code; are initialised. The - &s.code;allowDiv2&e.code; field determines if the clocks can be - halved. The &s.code;*divider&e.code; return value indicates - whether clock division is used when determining the clock returned. - - This function is only for non-programmable clocks. - - </quote> - - &s.code;const char *xf86ModeStatusToString(ModeStatus status)&e.code; - <quote><p> - This function converts the &s.code;status&e.code; value to a - descriptive printable string. - - </quote> - - &s.code;ModeStatus xf86LookupMode(ScrnInfoPtr scrp, DisplayModePtr modep, - &f.indent;ClockRangePtr clockRanges, LookupModeFlags strategy)&e.code; - <quote><p> - This function takes a pointer to a mode with the name filled in, - and looks for a mode in the &s.code;modePool&e.code; list which - matches. The parameters of the matching mode are filled in to - &s.code;*modep&e.code;. The &s.code;clockRanges&e.code; and - &s.code;strategy&e.code; parameters are as for the - &s.code;xf86ValidateModes()&e.code; function above. - - This function requires the &s.code;modePool&e.code;, - &s.code;clock[]&e.code;, &s.code;numClocks&e.code; and - &s.code;progClock&e.code; fields of the &s.code;ScrnInfoRec&e.code; - to be initialised before being called. - - The return value is &s.code;MODE_OK&e.code; if a mode was found. - Otherwise it indicates why a matching mode could not be found. - - </quote> - - &s.code;ModeStatus xf86InitialCheckModeForDriver(ScrnInfoPtr scrp, - &f.indent;DisplayModePtr mode, ClockRangePtr clockRanges, - &f.indent;LookupModeFlags strategy, int maxPitch, - &f.indent;int virtualX, int virtualY)&e.code; - <quote><p> - This function checks the passed mode against some basic driver - constraints. Apart from the ones passed explicitly, the - &s.code;maxHValue&e.code; and &s.code;maxVValue&e.code; fields of - the &s.code;ScrnInfoRec&e.code; are also used. If the - &s.code;ValidMode&e.code; field of the &s.code;ScrnInfoRec&e.code; - is set, that function is also called to check the mode. Next, the - mode is checked against the monitor's constraints. - - If the mode is consistent with all constraints, the return value - is &s.code;MODE_OK&e.code;. Otherwise the return value indicates - which constraint wasn't met. - - </quote> - - &s.code;void xf86DeleteMode(DisplayModePtr *modeList, DisplayModePtr mode)&e.code; - <quote><p> - This function deletes the &s.code;mode&e.code; given from the - &s.code;modeList&e.code;. It never prints any messages, so it is - up to the caller to print a message if required. - - </quote> - </quote> - -<sect1>Functions for handling strings and tokens -<p> - - Tables associating strings and numerical tokens combined with the - following functions provide a compact way of handling strings from - the config file, and for converting tokens into printable strings. - The table data structure is: - -<quote><verb> -typedef struct { - int token; - const char * name; -} SymTabRec, *SymTabPtr; -</verb></quote> - - A table is an initialised array of &s.code;SymTabRec&e.code;. The - tokens must be non-negative integers. Multiple names may be mapped - to a single token. The table is terminated with an element with a - &s.code;token&e.code; value of &s.code;-1&e.code; and - &s.code;NULL&e.code; for the &s.code;name&e.code;. - - - <quote><p> - &s.code;const char *xf86TokenToString(SymTabPtr table, int token)&e.code; - <quote><p> - This function returns the first string in &s.code;table&e.code; - that matches &s.code;token&e.code;. If no match is found, - &s.code;NULL&e.code; is returned (NOTE, older versions of this - function would return the string "unknown" when no match is found). - - </quote> - - &s.code;int xf86StringToToken(SymTabPtr table, const char *string)&e.code; - <quote><p> - This function returns the first token in &s.code;table&e.code; - that matches &s.code;string&e.code;. The - &s.code;xf86NameCmp()&e.code; function is used to determine the - match. If no match is found, &s.code;-1&e.code; is returned. - - </quote> - </quote> - - -<sect1>Functions for finding which config file entries to use -<p> - - These functions can be used to select the appropriate config file - entries that match the detected hardware. They are described above - in the <ref id="probe" name="Probe"> and - <ref id="avail" name="Available Functions"> sections. - - -<sect1>Probing discrete clocks on old hardware -<p> - - The &s.code;xf86GetClocks()&e.code; function may be used to assist - in finding the discrete pixel clock values on older hardware. - - - <quote><p> - &s.code;void xf86GetClocks(ScrnInfoPtr pScrn, int num, - &f.indent;Bool (*ClockFunc)(ScrnInfoPtr, int), - &f.indent;void (*ProtectRegs)(ScrnInfoPtr, Bool), - &f.indent;void (*BlankScreen)(ScrnInfoPtr, Bool), - &f.indent;int vertsyncreg, int maskval, int knownclkindex, - &f.indent;int knownclkvalue)&e.code; - <quote><p> - This function uses a comparative sampling method to measure the - discrete pixel clock values. The number of discrete clocks to - measure is given by &s.code;num&e.code;. &s.code;clockFunc&e.code; - is a function that selects the &s.code;n&e.code;'th clock. It - should also save or restore any state affected by programming the - clocks when the index passed is &s.code;CLK_REG_SAVE&e.code; or - &s.code;CLK_REG_RESTORE&e.code;. &s.code;ProtectRegs&e.code; is - a function that does whatever is required to protect the hardware - state while selecting a new clock. &s.code;BlankScreen&e.code; - is a function that blanks the screen. &s.code;vertsyncreg&e.code; - and &s.code;maskval&e.code; are the register and bitmask to - check for the presence of vertical sync pulses. - &s.code;knownclkindex&e.code; and &s.code;knownclkvalue&e.code; - are the index and value of a known clock. These are the known - references on which the comparative measurements are based. The - number of clocks probed is set in &s.code;pScrn->numClocks&e.code;, - and the probed clocks are set in the &s.code;pScrn->clock[]&e.code; - array. All of the clock values are in units of kHz. - - </quote> - - &s.code;void xf86ShowClocks(ScrnInfoPtr scrp, MessageType from)&e.code; - <quote><p> - Print out the pixel clocks &s.code;scrp->clock[]&e.code;. - &s.code;from&e.code; indicates whether the clocks were probed - or from the config file. - - </quote> - </quote> - -<sect1>Other helper functions -<p> - <quote><p> - &s.code;Bool xf86IsUnblank(int mode)&e.code; - <quote><p> - Returns &s.code;TRUE&e.code; when the screen saver mode specified - by &s.code;mode&e.code; requires the screen be unblanked, - and &s.code;FALSE&e.code; otherwise. The screen saver modes that - require blanking are &s.code;SCREEN_SAVER_ON&e.code; and - &s.code;SCREEN_SAVER_CYCLE&e.code;, and the screen saver modes that - require unblanking are &s.code;SCREEN_SAVER_OFF&e.code; and - &s.code;SCREEN_SAVER_FORCER&e.code;. Drivers may call this helper - from their &s.code;SaveScreen()&e.code; function to interpret the - screen saver modes. - - </quote> - </quote> - -<sect>The vgahw module -<p> - -The vgahw modules provides an interface for saving, restoring and -programming the standard VGA registers, and for handling VGA colourmaps. - -<sect1>Data Structures -<p> - - The public data structures used by the vgahw module are - &s.code;vgaRegRec&e.code; and &s.code;vgaHWRec&e.code;. They are - defined in &s.code;vgaHW.h.&e.code; - - -<sect1>General vgahw Functions -<p> - - <quote><p> - &s.code;Bool vgaHWGetHWRec(ScrnInfoPtr pScrn)&e.code; - <quote><p> - This function allocates a &s.code;vgaHWRec&e.code; structure, and - hooks it into the &s.code;ScrnInfoRec&e.code;'s - &s.code;privates&e.code;. Like all information hooked into the - &s.code;privates&e.code;, it is persistent, and only needs to be - allocated once per screen. This function should normally be called - from the driver's &s.code;ChipPreInit()&e.code; function. The - &s.code;vgaHWRec&e.code; is zero-allocated, and the following - fields are explicitly initialised: - - &s.code;ModeReg.DAC[]&e.code; - <quote>initialised with a default colourmap</quote> - &s.code;ModeReg.Attribute[0x11]&e.code; - <quote>initialised with the default overscan index</quote> - &s.code;ShowOverscan&e.code; - <quote>initialised according to the "ShowOverscan" option</quote> - &s.code;paletteEnabled&e.code; - <quote>initialised to FALSE</quote> - &s.code;cmapSaved&e.code; - <quote>initialised to FALSE</quote> - &s.code;pScrn&e.code; - <quote>initialised to pScrn</quote> - - In addition to the above, &s.code;vgaHWSetStdFuncs()&e.code; is - called to initialise the register access function fields with the - standard VGA set of functions. - - Once allocated, a pointer to the &s.code;vgaHWRec&e.code; can be - obtained from the &s.code;ScrnInfoPtr&e.code; with the - &s.code;VGAHWPTR(pScrn)&e.code; macro. - - </quote> - - &s.code;void vgaHWFreeHWRec(ScrnInfoPtr pScrn)&e.code; - <quote><p> - This function frees a &s.code;vgaHWRec&e.code; structure. It - should be called from a driver's &s.code;ChipFreeScreen()&e.code; - function. - - </quote> - - &s.code;Bool vgaHWSetRegCounts(ScrnInfoPtr pScrn, int numCRTC, - &f.indent;int numSequencer, int numGraphics, int numAttribute)&e.code; - <quote><p> - This function allows the number of CRTC, Sequencer, Graphics and - Attribute registers to be changed. This makes it possible for - extended registers to be saved and restored with - &s.code;vgaHWSave()&e.code; and &s.code;vgaHWRestore()&e.code;. - This function should be called after a &s.code;vgaHWRec&e.code; - has been allocated with &s.code;vgaHWGetHWRec()&e.code;. The - default values are defined in &s.code;vgaHW.h&e.code; as follows: - - <quote><verb> -#define VGA_NUM_CRTC 25 -#define VGA_NUM_SEQ 5 -#define VGA_NUM_GFX 9 -#define VGA_NUM_ATTR 21 - </verb></quote> - - </quote> - - &s.code;Bool vgaHWCopyReg(vgaRegPtr dst, vgaRegPtr src)&e.code; - <quote><p> - This function copies the contents of the VGA saved registers in - &s.code;src&e.code; to &s.code;dst&e.code;. Note that it isn't - possible to simply do this with &s.code;memcpy()&e.code; (or - similar). This function returns &s.code;TRUE&e.code; unless there - is a problem allocating space for the &s.code;CRTC&e.code and - related fields in &s.code;dst&e.code;. - - </quote> - - &s.code;void vgaHWSetStdFuncs(vgaHWPtr hwp)&e.code; - <quote><p> - This function initialises the register access function fields of - &s.code;hwp&e.code; with the standard VGA set of functions. This - is called by &s.code;vgaHWGetHWRec()&e.code;, so there is usually - no need to call this explicitly. The register access functions - are described below. If the registers are shadowed in some other - port I/O space (for example a PCI I/O region), these functions - can be used to access the shadowed registers if - &s.code;hwp->PIOOffset&e.code; is initialised with - &s.code;offset&e.code;, calculated in such a way that when the - standard VGA I/O port value is added to it the correct offset into - the PIO area results. This value is initialised to zero in - &s.code;vgaHWGetHWRec()&e.code;. (Note: the PIOOffset functionality - is present in XFree86 4.1.0 and later.) - - </quote> - - &s.code;void vgaHWSetMmioFuncs(vgaHWPtr hwp, CARD8 *base, int offset)&e.code; - <quote><p> - This function initialised the register access function fields of - hwp with a generic MMIO set of functions. - &s.code;hwp->MMIOBase&e.code; is initialised with - &s.code;base&e.code;, which must be the virtual address that the - start of MMIO area is mapped to. &s.code;hwp->MMIOOffset&e.code; - is initialised with &s.code;offset&e.code;, which must be calculated - in such a way that when the standard VGA I/O port value is added - to it the correct offset into the MMIO area results. That means - that these functions are only suitable when the VGA I/O ports are - made available in a direct mapping to the MMIO space. If that is - not the case, the driver will need to provide its own register - access functions. The register access functions are described - below. - - </quote> - - &s.code;Bool vgaHWMapMem(ScrnInfoPtr pScrn)&e.code; - <quote><p> - This function maps the VGA memory window. It requires that the - &s.code;vgaHWRec&e.code; be allocated. If a driver requires - non-default &s.code;MapPhys&e.code; or &s.code;MapSize&e.code; - settings (the physical location and size of the VGA memory window) - then those fields of the &s.code;vgaHWRec&e.code; must be initialised - before calling this function. Otherwise, this function initialiases - the default values of &s.code;0xA0000&e.code; for - &s.code;MapPhys&e.code; and &s.code;(64 * 1024)&e.code; for - &s.code;MapSize&e.code;. This function must be called before - attempting to save or restore the VGA state. If the driver doesn't - call it explicitly, the &s.code;vgaHWSave()&e.code; and - &s.code;vgaHWRestore()&e.code; functions may call it if they need - to access the VGA memory (in which case they will also call - &s.code;vgaHWUnmapMem()&e.code; to unmap the VGA memory before - exiting). - - </quote> - - &s.code;void vgaHWUnmapMem(ScrnInfoPtr pScrn)&e.code; - <quote><p> - This function unmaps the VGA memory window. It must only be called - after the memory has been mapped. The &s.code;Base&e.code; field - of the &s.code;vgaHWRec&e.code; field is set to &s.code;NULL&e.code; - to indicate that the memory is no longer mapped. - - </quote> - - &s.code;void vgaHWGetIOBase(vgaHWPtr hwp)&e.code; - <quote><p> - This function initialises the &s.code;IOBase&e.code; field of the - &s.code;vgaHWRec&e.code;. This function must be called before - using any other functions that access the video hardware. - - A macro &s.code;VGAHW_GET_IOBASE()&e.code; is also available in - &s.code;vgaHW.h&e.code; that returns the I/O base, and this may - be used when the vgahw module is not loaded (for example, in the - &s.code;ChipProbe()&e.code; function). - - </quote> - - &s.code;void vgaHWUnlock(vgaHWPtr hwp)&e.code; - <quote><p> - This function unlocks the VGA &s.code;CRTC[0-7]&e.code; registers, - and must be called before attempting to write to those registers. - - </quote> - - &s.code;void vgaHWLock(vgaHWPtr hwp)&e.code; - <quote><p> - This function locks the VGA &s.code;CRTC[0-7]&e.code; registers. - - </quote> - - &s.code;void vgaHWEnable(vgaHWPtr hwp)&e.code; - <quote><p> - This function enables the VGA subsystem. (Note, this function is - present in XFree86 4.1.0 and later.). - - </quote> - - &s.code;void vgaHWDisable(vgaHWPtr hwp)&e.code; - <quote><p> - This function disables the VGA subsystem. (Note, this function is - present in XFree86 4.1.0 and later.). - - </quote> - - &s.code;void vgaHWSave(ScrnInfoPtr pScrn, vgaRegPtr save, int flags)&e.code; - <quote><p> - This function saves the VGA state. The state is written to the - &s.code;vgaRegRec&e.code; pointed to by &s.code;save&e.code;. - &s.code;flags&e.code; is set to one or more of the following flags - ORed together: - - &s.code;VGA_SR_MODE&e.code; - <quote>the mode setting registers are saved</quote> - &s.code;VGA_SR_FONTS&e.code; - <quote>the text mode font/text data is saved</quote> - &s.code;VGA_SR_CMAP&e.code; - <quote>the colourmap (LUT) is saved</quote> - &s.code;VGA_SR_ALL&e.code; - <quote>all of the above are saved</quote> - - The &s.code;vgaHWRec&e.code; and its &s.code;IOBase&e.code; fields - must be initialised before this function is called. If - &s.code;VGA_SR_FONTS&e.code; is set in &s.code;flags&e.code;, the - VGA memory window must be mapped. If it isn't then - &s.code;vgaHWMapMem()&e.code; will be called to map it, and - &s.code;vgaHWUnmapMem()&e.code; will be called to unmap it - afterwards. &s.code;vgaHWSave()&e.code; uses the three functions - below in the order &s.code;vgaHWSaveColormap()&e.code;, - &s.code;vgaHWSaveMode()&e.code;, &s.code;vgaHWSaveFonts()&e.code; to - carry out the different save phases. It is undecided at this - stage whether they will remain part of the vgahw module's public - interface or not. - - </quote> - - &s.code;void vgaHWSaveMode(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code; - <quote><p> - This function saves the VGA mode registers. They are saved to - the &s.code;vgaRegRec&e.code; pointed to by &s.code;save&e.code;. - The registers saved are: - - <quote> - &s.code;MiscOut&nl; - CRTC[0-0x18]&nl; - Attribute[0-0x14]&nl; - Graphics[0-8]&nl; - Sequencer[0-4]&e.code; - </quote> - - The number of registers actually saved may be modified by a prior call - to &s.code;vgaHWSetRegCounts()&e.code;. - - </quote> - - &s.code;void vgaHWSaveFonts(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code; - <quote><p> - This function saves the text mode font and text data held in the - video memory. If called while in a graphics mode, no save is - done. The VGA memory window must be mapped with - &s.code;vgaHWMapMem()&e.code; before to calling this function. - - On some platforms, one or more of the font/text plane saves may be - no-ops. This is the case when the platform's VC driver already - takes care of this. - - </quote> - - &s.code;void vgaHWSaveColormap(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code; - <quote><p> - This function saves the VGA colourmap (LUT). Before saving it, it - attempts to verify that the colourmap is readable. In rare cases - where it isn't readable, a default colourmap is saved instead. - - </quote> - - &s.code;void vgaHWRestore(ScrnInfoPtr pScrn, vgaRegPtr restore, int flags)&e.code; - <quote><p> - This function programs the VGA state. The state programmed is - that contained in the &s.code;vgaRegRec&e.code; pointed to by - &s.code;restore&e.code;. &s.code;flags&e.code; is the same - as described above for the &s.code;vgaHWSave()&e.code; function. - - The &s.code;vgaHWRec&e.code; and its &s.code;IOBase&e.code; fields - must be initialised before this function is called. If - &s.code;VGA_SR_FONTS&e.code; is set in &s.code;flags&e.code;, the - VGA memory window must be mapped. If it isn't then - &s.code;vgaHWMapMem()&e.code; will be called to map it, and - &s.code;vgaHWUnmapMem()&e.code; will be called to unmap it - afterwards. &s.code;vgaHWRestore()&e.code; uses the three functions - below in the order &s.code;vgaHWRestoreFonts()&e.code;, - &s.code;vgaHWRestoreMode()&e.code;, - &s.code;vgaHWRestoreColormap()&e.code; to carry out the different - restore phases. It is undecided at this stage whether they will - remain part of the vgahw module's public interface or not. - - </quote> - - &s.code;void vgaHWRestoreMode(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code; - <quote><p> - This function restores the VGA mode registers. They are restored - from the data in the &s.code;vgaRegRec&e.code; pointed to by - &s.code;restore&e.code;. The registers restored are: - - <quote> - &s.code;MiscOut&nl; - CRTC[0-0x18]&nl; - Attribute[0-0x14]&nl; - Graphics[0-8]&nl; - Sequencer[0-4]&e.code; - </quote> - - The number of registers actually restored may be modified by a prior call - to &s.code;vgaHWSetRegCounts()&e.code;. - - </quote> - - &s.code;void vgaHWRestoreFonts(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code; - <quote><p> - This function restores the text mode font and text data to the - video memory. The VGA memory window must be mapped with - &s.code;vgaHWMapMem()&e.code; before to calling this function. - - On some platforms, one or more of the font/text plane restores - may be no-ops. This is the case when the platform's VC driver - already takes care of this. - - </quote> - - &s.code;void vgaHWRestoreColormap(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code; - <quote><p> - This function restores the VGA colourmap (LUT). - - </quote> - - &s.code;void vgaHWInit(ScrnInfoPtr pScrn, DisplayModePtr mode)&e.code; - <quote><p> - This function fills in the &s.code;vgaHWRec&e.code;'s - &s.code;ModeReg&e.code; field with the values appropriate for - programming the given video mode. It requires that the - &s.code;ScrnInfoRec&e.code;'s &s.code;depth&e.code; field is - initialised, which determines how the registers are programmed. - - </quote> - - &s.code;void vgaHWSeqReset(vgaHWPtr hwp, Bool start)&e.code; - <quote><p> - Do a VGA sequencer reset. If start is &s.code;TRUE&e.code;, the - reset is started. If start is &s.code;FALSE&e.code;, the reset - is ended. - - </quote> - - &s.code;void vgaHWProtect(ScrnInfoPtr pScrn, Bool on)&e.code; - <quote><p> - This function protects VGA registers and memory from corruption - during loads. It is typically called with on set to - &s.code;TRUE&e.code; before programming, and with on set to - &s.code;FALSE&e.code; after programming. - - </quote> - - &s.code;Bool vgaHWSaveScreen(ScreenPtr pScreen, int mode)&e.code; - <quote><p> - This function blanks and unblanks the screen. It is blanked when - &s.code;mode&e.code; is &s.code;SCREEN_SAVER_ON&e.code; or - &s.code;SCREEN_SAVER_CYCLE&e.code;, and unblanked when - &s.code;mode&e.code; is &s.code;SCREEN_SAVER_OFF&e.code; or - &s.code;SCREEN_SAVER_FORCER&e.code;. - - </quote> - - &s.code;void vgaHWBlankScreen(ScrnInfoPtr pScrn, Bool on)&e.code; - <quote><p> - This function blanks and unblanks the screen. It is blanked when - &s.code;on&e.code; is &s.code;FALSE&e.code;, and unblanked when - &s.code;on&e.code; is &s.code;TRUE&e.code;. This function is - provided for use in cases where the &s.code;ScrnInfoRec&e.code; - can't be derived from the &s.code;ScreenRec&e.code; (while probing - for clocks, for example). - - </quote> - </quote> - -<sect1>VGA Colormap Functions -<p> - - The vgahw module uses the standard colormap support (see the - <ref id="cmap" name="Colormap Handling"> section. This is initialised - with the following function: - - <quote> - &s.code;Bool vgaHWHandleColormaps(ScreenPtr pScreen)&e.code; - </quote> - - -<sect1>VGA Register Access Functions -<p> - - The vgahw module abstracts access to the standard VGA registers by - using a set of functions held in the &s.code;vgaHWRec&e.code;. When - the &s.code;vgaHWRec&e.code; is created these function pointers are - initialised with the set of standard VGA I/O register access functions. - In addition to these, the vgahw module includes a basic set of MMIO - register access functions, and the &s.code;vgaHWRec&e.code; function - pointers can be initialised to these by calling the - &s.code;vgaHWSetMmioFuncs()&e.code; function described above. Some - drivers/platforms may require a different set of functions for VGA - access. The access functions are described here. - - - <quote><p> - &s.code;void writeCrtc(vgaHWPtr hwp, CARD8 index, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to CRTC register &s.code;index&e.code;. - - </quote> - - &s.code;CARD8 readCrtc(vgaHWPtr hwp, CARD8 index)&e.code; - <quote><p> - Return the value read from CRTC register &s.code;index&e.code;. - - </quote> - - &s.code;void writeGr(vgaHWPtr hwp, CARD8 index, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to Graphics Controller register - &s.code;index&e.code;. - - </quote> - - &s.code;CARD8 readGR(vgaHWPtr hwp, CARD8 index)&e.code; - <quote><p> - Return the value read from Graphics Controller register - &s.code;index&e.code;. - - </quote> - - &s.code;void writeSeq(vgaHWPtr hwp, CARD8 index, CARD8, value)&e.code; - <quote><p> - Write &s.code;value&e.code; to Sequencer register - &s.code;index&e.code;. - - </quote> - - &s.code;CARD8 readSeq(vgaHWPtr hwp, CARD8 index)&e.code; - <quote><p> - Return the value read from Sequencer register &s.code;index&e.code;. - - </quote> - - &s.code;void writeAttr(vgaHWPtr hwp, CARD8 index, CARD8, value)&e.code; - <quote><p> - Write &s.code;value&e.code; to Attribute Controller register - &s.code;index&e.code;. When writing out the index value this - function should set bit 5 (&s.code;0x20&e.code;) according to the - setting of &s.code;hwp->paletteEnabled&e.code; in order to - preserve the palette access state. It should be cleared when - &s.code;hwp->paletteEnabled&e.code; is &s.code;TRUE&e.code; - and set when it is &s.code;FALSE&e.code;. - - </quote> - - &s.code;CARD8 readAttr(vgaHWPtr hwp, CARD8 index)&e.code; - <quote><p> - Return the value read from Attribute Controller register - &s.code;index&e.code;. When writing out the index value this - function should set bit 5 (&s.code;0x20&e.code;) according to the - setting of &s.code;hwp->paletteEnabled&e.code; in order to - preserve the palette access state. It should be cleared when - &s.code;hwp->paletteEnabled&e.code; is &s.code;TRUE&e.code; - and set when it is &s.code;FALSE&e.code;. - - </quote> - - &s.code;void writeMiscOut(vgaHWPtr hwp, CARD8 value)&e.code; - <quote><p> - Write `&s.code;value&e.code;' to the Miscellaneous Output register. - - </quote> - - &s.code;CARD8 readMiscOut(vgwHWPtr hwp)&e.code; - <quote><p> - Return the value read from the Miscellaneous Output register. - - </quote> - - &s.code;void enablePalette(vgaHWPtr hwp)&e.code; - <quote><p> - Clear the palette address source bit in the Attribute Controller - index register and set &s.code;hwp->paletteEnabled&e.code; to - &s.code;TRUE&e.code;. - - </quote> - - &s.code;void disablePalette(vgaHWPtr hwp)&e.code; - <quote><p> - Set the palette address source bit in the Attribute Controller - index register and set &s.code;hwp->paletteEnabled&e.code; to - &s.code;FALSE&e.code;. - - </quote> - - &s.code;void writeDacMask(vgaHWPtr hwp, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to the DAC Mask register. - - </quote> - - &s.code;CARD8 readDacMask(vgaHWptr hwp)&e.code; - <quote><p> - Return the value read from the DAC Mask register. - - </quote> - - &s.code;void writeDacReadAddress(vgaHWPtr hwp, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to the DAC Read Address register. - - </quote> - - &s.code;void writeDacWriteAddress(vgaHWPtr hwp, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to the DAC Write Address register. - - </quote> - - &s.code;void writeDacData(vgaHWPtr hwp, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to the DAC Data register. - - </quote> - - &s.code;CARD8 readDacData(vgaHWptr hwp)&e.code; - <quote><p> - Return the value read from the DAC Data register. - - </quote> - - &s.code;CARD8 readEnable(vgaHWptr hwp)&e.code; - <quote><p> - Return the value read from the VGA Enable register. (Note: This - function is present in XFree86 4.1.0 and later.) - - </quote> - - &s.code;void writeEnable(vgaHWPtr hwp, CARD8 value)&e.code; - <quote><p> - Write &s.code;value&e.code; to the VGA Enable register. (Note: This - function is present in XFree86 4.1.0 and later.) - - </quote> - </quote> - -<sect>Some notes about writing a driver<label id="sample"> -<p> - -<em>NOTE: some parts of this are not up to date</em> - -The following is an outline for writing a basic unaccelerated driver -for a PCI video card with a linear mapped framebuffer, and which has a -VGA core. It is includes some general information that is relevant to -most drivers (even those which don't fit that basic description). - -The information here is based on the initial conversion of the Matrox -Millennium driver to the ``new design''. For a fleshing out and sample -implementation of some of the bits outlined here, refer to that driver. -Note that this is an example only. The approach used here will not be -appropriate for all drivers. - -Each driver must reserve a unique driver name, and a string that is used -to prefix all of its externally visible symbols. This is to avoid name -space clashes when loading multiple drivers. The examples here are for -the ``ZZZ'' driver, which uses the ``ZZZ'' or ``zzz'' prefix for its externally -visible symbols. - - -<sect1>Include files -<p> - - All drivers normally include the following headers: - <quote> - &s.code;"xf86.h"&nl; - "xf86_OSproc.h"&nl; - "xf86_ansic.h"&nl; - "xf86Resources.h"&e.code; - </quote> - Wherever inb/outb (and related things) are used the following should be - included: - <quote> - &s.code;"compiler.h"&e.code; - </quote> - Note: in drivers, this must be included after &s.code;"xf86_ansic.h"&e.code;. - - Drivers that need to access PCI vendor/device definitions need this: - <quote> - &s.code;"xf86PciInfo.h"&e.code; - </quote> - - Drivers that need to access the PCI config space need this: - <quote> - &s.code;"xf86Pci.h"&e.code; - </quote> - - Drivers using the mi banking wrapper need: - - <quote> - &s.code;"mibank.h"&e.code; - </quote> - - Drivers that initialise a SW cursor need this: - <quote> - &s.code;"mipointer.h"&e.code; - </quote> - - All drivers implementing backing store need this: - <quote> - &s.code;"mibstore.h"&e.code; - </quote> - - All drivers using the mi colourmap code need this: - <quote> - &s.code;"micmap.h"&e.code; - </quote> - - If a driver uses the vgahw module, it needs this: - <quote> - &s.code;"vgaHW.h"&e.code; - </quote> - - Drivers supporting VGA or Hercules monochrome screens need: - <quote> - &s.code;"xf1bpp.h"&e.code; - </quote> - - Drivers supporting VGA or EGC 16-colour screens need: - <quote> - &s.code;"xf4bpp.h"&e.code; - </quote> - - Drivers using cfb need: - <quote> - &s.code;#define PSZ 8&nl; - #include "cfb.h"&nl; - #undef PSZ&e.code; - </quote> - - Drivers supporting bpp 16, 24 or 32 with cfb need one or more of: - <quote> - &s.code;"cfb16.h"&nl; - "cfb24.h"&nl; - "cfb32.h"&e.code; - </quote> - - The driver's own header file: - <quote> - &s.code;"zzz.h"&e.code; - </quote> - - Drivers must NOT include the following: - - <quote> - &s.code;"xf86Priv.h"&nl; - "xf86Privstr.h"&nl; - "xf86_libc.h"&nl; - "xf86_OSlib.h"&nl; - "Xos.h"&e.code;&nl; - any OS header - </quote> - - -<sect1>Data structures and initialisation -<p> - -<itemize> - <item>The following macros should be defined: - <code> -#define VERSION <version-as-an-int> -#define ZZZ_NAME "ZZZ" /* the name used to prefix messages */ -#define ZZZ_DRIVER_NAME "zzz" /* the driver name as used in config file */ -#define ZZZ_MAJOR_VERSION <int> -#define ZZZ_MINOR_VERSION <int> -#define ZZZ_PATCHLEVEL <int> - </code> -<p> - NOTE: &s.code;ZZZ_DRIVER_NAME&e.code; should match the name of the - driver module without things like the "lib" prefix, the "_drv" suffix - or filename extensions. -<p> - - <item>A DriverRec must be defined, which includes the functions required - at the pre-probe phase. The name of this DriverRec must be an - upper-case version of ZZZ_DRIVER_NAME (for the purposes of static - linking). -<p> - <code> -DriverRec ZZZ = { - VERSION, - ZZZ_DRIVER_NAME, - ZZZIdentify, - ZZZProbe, - ZZZAvailableOptions, - NULL, - 0 -}; - </code> - - <item>Define list of supported chips and their matching ID: -<p> - <code> -static SymTabRec ZZZChipsets[] = { - { PCI_CHIP_ZZZ1234, "zzz1234a" }, - { PCI_CHIP_ZZZ5678, "zzz5678a" }, - { -1, NULL } -}; - </code> -<p> - The token field may be any integer value that the driver may use to - uniquely identify the supported chipsets. For drivers that support - only PCI devices using the PCI device IDs might be a natural choice, - but this isn't mandatory. For drivers that support both PCI and other - devices (like ISA), some other ID should probably used. When other - IDs are used as the tokens it is recommended that the names be - defined as an &s.code;enum&e.code; type. -<p> - <item>If the driver uses the &s.code;xf86MatchPciInstances(&e.code;) - helper (recommended for drivers that support PCI cards) a list that - maps PCI IDs to chip IDs and fixed resources must be defined: -<p> - <code> -static PciChipsets ZZZPciChipsets[] = { - { PCI_CHIP_ZZZ1234, PCI_CHIP_ZZZ1234, RES_SHARED_VGA }, - { PCI_CHIP_ZZZ5678, PCI_CHIP_ZZZ5678, RES_SHARED_VGA }, - { -1, -1, RES_UNDEFINED } -} - </code> -<p> - <item>Define the &s.code;XF86ModuleVersionInfo&e.code; struct for the - driver. This is required for the dynamically loaded version: -<p> - <code> -static XF86ModuleVersionInfo zzzVersRec = -{ - "zzz", - MODULEVENDORSTRING, - MODINFOSTRING1, - MODINFOSTRING2, - XF86_VERSION_CURRENT, - ZZZ_MAJOR_VERSION, ZZZ_MINOR_VERSION, ZZZ_PATCHLEVEL, - ABI_CLASS_VIDEODRV, - ABI_VIDEODRV_VERSION, - MOD_CLASS_VIDEODRV, - {0,0,0,0} -}; - </code> -<p> - <item>Define a data structure to hold the driver's screen-specific data. - This must be used instead of global variables. This would be defined - in the &s.code;"zzz.h"&e.code; file, something like: -<p> - <code> -typedef struct { - type1 field1; - type2 field2; - int fooHack; - Bool pciRetry; - Bool noAccel; - Bool hwCursor; - CloseScreenProcPtr CloseScreen; - OptionInfoPtr Options; - ... -} ZZZRec, *ZZZPtr; - </code> -<p> - <item>Define the list of config file Options that the driver accepts. For - consistency between drivers those in the list of ``standard'' options - should be used where appropriate before inventing new options. -<p> - <code> -typedef enum { - OPTION_FOO_HACK, - OPTION_PCI_RETRY, - OPTION_HW_CURSOR, - OPTION_NOACCEL -} ZZZOpts; - -static const OptionInfoRec ZZZOptions[] = { - { OPTION_FOO_HACK, "FooHack", OPTV_INTEGER, {0}, FALSE }, - { OPTION_PCI_RETRY, "PciRetry", OPTV_BOOLEAN, {0}, FALSE }, - { OPTION_HW_CURSOR, "HWcursor", OPTV_BOOLEAN, {0}, FALSE }, - { OPTION_NOACCEL, "NoAccel", OPTV_BOOLEAN, {0}, FALSE }, - { -1, NULL, OPTV_NONE, {0}, FALSE } -}; - </code> -<p> -</itemize> - -<sect1>Functions -<p> - - -<sect2>SetupProc -<p> - - For dynamically loaded modules, a &s.code;ModuleData&e.code; - variable is required. It is should be the name of the driver - prepended to "ModuleData". A &s.code;Setup()&e.code; function is - also required, which calls &s.code;xf86AddDriver()&e.code; to add - the driver to the main list of drivers. - - <code> -static MODULESETUPPROTO(zzzSetup); - -XF86ModuleData zzzModuleData = { &zzzVersRec, zzzSetup, NULL }; - -static pointer -zzzSetup(pointer module, pointer opts, int *errmaj, int *errmin) -{ - static Bool setupDone = FALSE; - - /* This module should be loaded only once, but check to be sure. */ - - if (!setupDone) { - /* - * Modules that this driver always requires may be loaded - * here by calling LoadSubModule(). - */ - - setupDone = TRUE; - xf86AddDriver(&MGA, module, 0); - - /* - * The return value must be non-NULL on success even though - * there is no TearDownProc. - */ - return (pointer)1; - } else { - if (errmaj) *errmaj = LDR_ONCEONLY; - return NULL; - } -} - </code> - -<sect2>GetRec, FreeRec -<p> - - A function is usually required to allocate the driver's - screen-specific data structure and hook it into the - &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; field. - The &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; is - initialised to &s.code;NULL&e.code;, so it is easy to check if the - initialisation has already been done. After allocating it, initialise - the fields. By using &s.code;xnfcalloc()&e.code; to do the allocation - it is zeroed, and if the allocation fails the server exits. -<p> - NOTE: - When allocating structures from inside the driver which are defined - on the common level it is important to initialize the structure to - zero. - Only this guarantees that the server remains source compatible to - future changes in common level structures. - - <code> -static Bool -ZZZGetRec(ScrnInfoPtr pScrn) -{ - if (pScrn->driverPrivate != NULL) - return TRUE; - pScrn->driverPrivate = xnfcalloc(sizeof(ZZZRec), 1); - /* Initialise as required */ - ... - return TRUE; -} - </code> - - Define a macro in &s.code;"zzz.h"&e.code; which gets a pointer to - the &s.code;ZZZRec&e.code; when given &s.code;pScrn&e.code;: - - <code> -#define ZZZPTR(p) ((ZZZPtr)((p)->driverPrivate)) - </code> - - Define a function to free the above, setting it to &s.code;NULL&e.code; - once it has been freed: - - <code> -static void -ZZZFreeRec(ScrnInfoPtr pScrn) -{ - if (pScrn->driverPrivate == NULL) - return; - xfree(pScrn->driverPrivate); - pScrn->driverPrivate = NULL; -} - </code> - -<sect2>Identify -<p> - - Define the &s.code;Identify()&e.code; function. It is run before - the Probe, and typically prints out an identifying message, which - might include the chipsets it supports. This function is mandatory: - - <code> -static void -ZZZIdentify(int flags) -{ - xf86PrintChipsets(ZZZ_NAME, "driver for ZZZ Tech chipsets", - ZZZChipsets); -} - </code> - -<sect2>Probe -<p> - - Define the &s.code;Probe()&e.code; function. The purpose of this - is to find all instances of the hardware that the driver supports, - and for the ones not already claimed by another driver, claim the - slot, and allocate a &s.code;ScrnInfoRec&e.code;. This should be - a minimal probe, and it should under no circumstances leave the - state of the hardware changed. Because a device is found, don't - assume that it will be used. Don't do any initialisations other - than the required &s.code;ScrnInfoRec&e.code; initialisations. - Don't allocate any new data structures. - - This function is mandatory. - - NOTE: The &s.code;xf86DrvMsg()&e.code; functions cannot be used from - the Probe. - - <code> -static Bool -ZZZProbe(DriverPtr drv, int flags) -{ - Bool foundScreen = FALSE; - int numDevSections, numUsed; - GDevPtr *devSections; - int *usedChips; - int i; - - /* - * Find the config file Device sections that match this - * driver, and return if there are none. - */ - if ((numDevSections = xf86MatchDevice(ZZZ_DRIVER_NAME, - &devSections)) <= 0) { - return FALSE; - } - - /* - * Since this is a PCI card, "probing" just amounts to checking - * the PCI data that the server has already collected. If there - * is none, return. - * - * Although the config file is allowed to override things, it - * is reasonable to not allow it to override the detection - * of no PCI video cards. - * - * The provided xf86MatchPciInstances() helper takes care of - * the details. - */ - /* test if PCI bus present */ - if (xf86GetPciVideoInfo()) { - - numUsed = xf86MatchPciInstances(ZZZ_NAME, PCI_VENDOR_ZZZ, - ZZZChipsets, ZZZPciChipsets, devSections, - numDevSections, drv, &usedChips); - - for (i = 0; i < numUsed; i++) { - ScrnInfoPtr pScrn = NULL; - if ((pScrn = xf86ConfigPciEntity(pScrn, flags, usedChips[i], - ZZZPciChipsets, NULL, NULL, - NULL, NULL, NULL))) { - /* Allocate a ScrnInfoRec */ - pScrn->driverVersion = VERSION; - pScrn->driverName = ZZZ_DRIVER_NAME; - pScrn->name = ZZZ_NAME; - pScrn->Probe = ZZZProbe; - pScrn->PreInit = ZZZPreInit; - pScrn->ScreenInit = ZZZScreenInit; - pScrn->SwitchMode = ZZZSwitchMode; - pScrn->AdjustFrame = ZZZAdjustFrame; - pScrn->EnterVT = ZZZEnterVT; - pScrn->LeaveVT = ZZZLeaveVT; - pScrn->FreeScreen = ZZZFreeScreen; - pScrn->ValidMode = ZZZValidMode; - foundScreen = TRUE; - /* add screen to entity */ - } - } - xfree(usedChips); - } - -#ifdef HAS_ISA_DEVS - /* - * If the driver supports ISA hardware, the following block - * can be included too. - */ - numUsed = xf86MatchIsaInstances(ZZZ_NAME, ZZZChipsets, - ZZZIsaChipsets, drv, ZZZFindIsaDevice, - devSections, numDevSections, &usedChips); - for (i = 0; i < numUsed; i++) { - ScrnInfoPtr pScrn = NULL; - if ((pScrn = xf86ConfigIsaEntity(pScrn, flags, usedChips[i], - ZZZIsaChipsets, NULL, NULL, NULL, - NULL, NULL))) { - pScrn->driverVersion = VERSION; - pScrn->driverName = ZZZ_DRIVER_NAME; - pScrn->name = ZZZ_NAME; - pScrn->Probe = ZZZProbe; - pScrn->PreInit = ZZZPreInit; - pScrn->ScreenInit = ZZZScreenInit; - pScrn->SwitchMode = ZZZSwitchMode; - pScrn->AdjustFrame = ZZZAdjustFrame; - pScrn->EnterVT = ZZZEnterVT; - pScrn->LeaveVT = ZZZLeaveVT; - pScrn->FreeScreen = ZZZFreeScreen; - pScrn->ValidMode = ZZZValidMode; - foundScreen = TRUE; - } - } - xfree(usedChips); -#endif /* HAS_ISA_DEVS */ - - xfree(devSections); - return foundScreen; - </code> - -<sect2>AvailableOptions -<p> - - Define the &s.code;AvailableOptions()&e.code; function. The purpose - of this is to return the available driver options back to the - -configure option, so that an xorg.conf file can be built and the - user can see which options are available for them to use. - -<sect2>PreInit -<p> - - Define the &s.code;PreInit()&e.code; function. The purpose of - this is to find all the information required to determine if the - configuration is usable, and to initialise those parts of the - &s.code;ScrnInfoRec&e.code; that can be set once at the beginning - of the first server generation. The information should be found in - the least intrusive way possible. - - This function is mandatory. - - NOTES: - <enum> - <item>The &s.code;PreInit()&e.code; function is only called once - during the life of the X server (at the start of the first - generation). - - <item>Data allocated here must be of the type that persists for - the life of the X server. This means that data that hooks into - the &s.code;ScrnInfoRec&e.code;'s &s.code;privates&e.code; - field should be allocated here, but data that hooks into the - &s.code;ScreenRec&e.code;'s &s.code;devPrivates&e.code; field - should not be allocated here. The &s.code;driverPrivate&e.code; - field should also be allocated here. - - <item>Although the &s.code;ScrnInfoRec&e.code; has been allocated - before this function is called, the &s.code;ScreenRec&e.code; - has not been allocated. That means that things requiring it - cannot be used in this function. - - <item>Very little of the &s.code;ScrnInfoRec&e.code; has been - initialised when this function is called. It is important to - get the order of doing things right in this function. - - </enum> - - <code> -static Bool -ZZZPreInit(ScrnInfoPtr pScrn, int flags) -{ - /* Fill in the monitor field */ - pScrn->monitor = pScrn->confScreen->monitor; - - /* - * If using the vgahw module, it will typically be loaded - * here by calling xf86LoadSubModule(pScrn, "vgahw"); - */ - - /* - * Set the depth/bpp. Use the globally preferred depth/bpp. If the - * driver has special default depth/bpp requirements, the defaults should - * be specified here explicitly. - * We support both 24bpp and 32bpp framebuffer layouts. - * This sets pScrn->display also. - */ - if (!xf86SetDepthBpp(pScrn, 0, 0, 0, - Support24bppFb | Support32bppFb)) { - return FALSE; - } else { - if (depth/bpp isn't one we support) { - print error message; - return FALSE; - } - } - /* Print out the depth/bpp that was set */ - xf86PrintDepthBpp(pScrn); - - /* Set bits per RGB for 8bpp */ - if (pScrn->depth <= 8) { - /* Take into account a dac_6_bit option here */ - pScrn->rgbBits = 6 or 8; - } - - /* - * xf86SetWeight() and xf86SetDefaultVisual() must be called - * after pScrn->display is initialised. - */ - - /* Set weight/mask/offset for depth > 8 */ - if (pScrn->depth > 8) { - if (!xf86SetWeight(pScrn, defaultWeight, defaultMask)) { - return FALSE; - } else { - if (weight isn't one we support) { - print error message; - return FALSE; - } - } - } - - /* Set the default visual. */ - if (!xf86SetDefaultVisual(pScrn, -1)) { - return FALSE; - } else { - if (visual isn't one we support) { - print error message; - return FALSE; - } - } - - /* If the driver supports gamma correction, set the gamma. */ - if (!xf86SetGamma(pScrn, default_gamma)) { - return FALSE; - } - - /* This driver uses a programmable clock */ - pScrn->progClock = TRUE; - - /* Allocate the ZZZRec driverPrivate */ - if (!ZZZGetRec(pScrn)) { - return FALSE; - } - - pZzz = ZZZPTR(pScrn); - - /* Collect all of the option flags (fill in pScrn->options) */ - xf86CollectOptions(pScrn, NULL); - - /* - * Process the options based on the information in ZZZOptions. - * The results are written to pZzz->Options. If all of the options - * processing is done within this function a local variable "options" - * can be used instead of pZzz->Options. - */ - if (!(pZzz->Options = xalloc(sizeof(ZZZOptions)))) - return FALSE; - (void)memcpy(pZzz->Options, ZZZOptions, sizeof(ZZZOptions)); - xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, pZzz->Options); - - /* - * Set various fields of ScrnInfoRec and/or ZZZRec based on - * the options found. - */ - from = X_DEFAULT; - pZzz->hwCursor = FALSE; - if (xf86IsOptionSet(pZzz->Options, OPTION_HW_CURSOR)) { - from = X_CONFIG; - pZzz->hwCursor = TRUE; - } - xf86DrvMsg(pScrn->scrnIndex, from, "Using %s cursor\n", - pZzz->hwCursor ? "HW" : "SW"); - if (xf86IsOptionSet(pZzz->Options, OPTION_NOACCEL)) { - pZzz->noAccel = TRUE; - xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, - "Acceleration disabled\n"); - } else { - pZzz->noAccel = FALSE; - } - if (xf86IsOptionSet(pZzz->Options, OPTION_PCI_RETRY)) { - pZzz->UsePCIRetry = TRUE; - xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "PCI retry enabled\n"); - } - pZzz->fooHack = 0; - if (xf86GetOptValInteger(pZzz->Options, OPTION_FOO_HACK, - &pZzz->fooHack)) { - xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Foo Hack set to %d\n", - pZzz->fooHack); - } - - /* - * Find the PCI slot(s) that this screen claimed in the probe. - * In this case, exactly one is expected, so complain otherwise. - * Note in this case we're not interested in the card types so - * that parameter is set to NULL. - */ - if ((i = xf86GetPciInfoForScreen(pScrn->scrnIndex, &pciList, NULL)) - != 1) { - print error message; - ZZZFreeRec(pScrn); - if (i > 0) - xfree(pciList); - return FALSE; - } - /* Note that pciList should be freed below when no longer needed */ - - /* - * Determine the chipset, allowing config file chipset and - * chipid values to override the probed information. The config - * chipset value has precedence over its chipid value if both - * are present. - * - * It isn't necessary to fill in pScrn->chipset if the driver - * keeps track of the chipset in its ZZZRec. - */ - - ... - - /* - * Determine video memory, fb base address, I/O addresses, etc, - * allowing the config file to override probed values. - * - * Set the appropriate pScrn fields (videoRam is probably the - * most important one that other code might require), and - * print out the settings. - */ - - ... - - /* Initialise a clockRanges list. */ - - ... - - /* Set any other chipset specific things in the ZZZRec */ - - ... - - /* Select valid modes from those available */ - - i = xf86ValidateModes(pScrn, pScrn->monitor->Modes, - pScrn->display->modes, clockRanges, - NULL, minPitch, maxPitch, rounding, - minHeight, maxHeight, - pScrn->display->virtualX, - pScrn->display->virtualY, - pScrn->videoRam * 1024, - LOOKUP_BEST_REFRESH); - if (i == -1) { - ZZZFreeRec(pScrn); - return FALSE; - } - - /* Prune the modes marked as invalid */ - - xf86PruneDriverModes(pScrn); - - /* If no valid modes, return */ - - if (i == 0 || pScrn->modes == NULL) { - print error message; - ZZZFreeRec(pScrn); - return FALSE; - } - - /* - * Initialise the CRTC fields for the modes. This driver expects - * vertical values to be halved for interlaced modes. - */ - xf86SetCrtcForModes(pScrn, INTERLACE_HALVE_V); - - /* Set the current mode to the first in the list. */ - pScrn->currentMode = pScrn->modes; - - /* Print the list of modes being used. */ - xf86PrintModes(pScrn); - - /* Set the DPI */ - xf86SetDpi(pScrn, 0, 0); - - /* Load bpp-specific modules */ - switch (pScrn->bitsPerPixel) { - case 1: - mod = "xf1bpp"; - break; - case 4: - mod = "xf4bpp"; - break; - case 8: - mod = "cfb"; - break; - case 16: - mod = "cfb16"; - break; - case 24: - mod = "cfb24"; - break; - case 32: - mod = "cfb32"; - break; - } - if (mod && !xf86LoadSubModule(pScrn, mod)) - ZZZFreeRec(pScrn); - return FALSE; - - /* Load XAA if needed */ - if (!pZzz->noAccel || pZzz->hwCursor) - if (!xf86LoadSubModule(pScrn, "xaa")) { - ZZZFreeRec(pScrn); - return FALSE; - } - - /* Done */ - return TRUE; -} - </code> - -<sect2>MapMem, UnmapMem -<p> - - Define functions to map and unmap the video memory and any other - memory apertures required. These functions are not mandatory, but - it is often useful to have such functions. - - <code> -static Bool -ZZZMapMem(ScrnInfoPtr pScrn) -{ - /* Call xf86MapPciMem() to map each PCI memory area */ - ... - return TRUE or FALSE; -} - -static Bool -ZZZUnmapMem(ScrnInfoPtr pScrn) -{ - /* Call xf86UnMapVidMem() to unmap each memory area */ - ... - return TRUE or FALSE; -} - </code> - -<sect2>Save, Restore -<p> - - Define functions to save and restore the original video state. These - functions are not mandatory, but are often useful. - - <code> -static void -ZZZSave(ScrnInfoPtr pScrn) -{ - /* - * Save state into per-screen data structures. - * If using the vgahw module, vgaHWSave will typically be - * called here. - */ - ... -} - -static void -ZZZRestore(ScrnInfoPtr pScrn) -{ - /* - * Restore state from per-screen data structures. - * If using the vgahw module, vgaHWRestore will typically be - * called here. - */ - ... -} - </code> - -<sect2>ModeInit -<p> - - Define a function to initialise a new video mode. This function isn't - mandatory, but is often useful. - - <code> -static Bool -ZZZModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode) -{ - /* - * Program a video mode. If using the vgahw module, - * vgaHWInit and vgaRestore will typically be called here. - * Once up to the point where there can't be a failure - * set pScrn->vtSema to TRUE. - */ - ... -} - </code> - -<sect2>ScreenInit -<p> - - Define the &s.code;ScreenInit()&e.code; function. This is called - at the start of each server generation, and should fill in as much - of the &s.code;ScreenRec&e.code; as possible as well as any other - data that is initialised once per generation. It should initialise - the framebuffer layers it is using, and initialise the initial video - mode. - - This function is mandatory. - - NOTE: The &s.code;ScreenRec&e.code; (&s.code;pScreen&e.code;) is - passed to this driver, but it and the - &s.code;ScrnInfoRecs&e.code; are not yet hooked into each - other. This means that in this function, and functions it - calls, one cannot be found from the other. - - <code> -static Bool -ZZZScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) -{ - /* Get the ScrnInfoRec */ - pScrn = xf86Screens[pScreen->myNum]; - - /* - * If using the vgahw module, its data structures and related - * things are typically initialised/mapped here. - */ - - /* Save the current video state */ - ZZZSave(pScrn); - - /* Initialise the first mode */ - ZZZModeInit(pScrn, pScrn->currentMode); - - /* Set the viewport if supported */ - - ZZZAdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0); - - /* - * Setup the screen's visuals, and initialise the framebuffer - * code. - */ - - /* Reset the visual list */ - miClearVisualTypes(); - - /* - * Setup the visuals supported. This driver only supports - * TrueColor for bpp > 8, so the default set of visuals isn't - * acceptable. To deal with this, call miSetVisualTypes with - * the appropriate visual mask. - */ - - if (pScrn->bitsPerPixel > 8) { - if (!miSetVisualTypes(pScrn->depth, TrueColorMask, - pScrn->rgbBits, pScrn->defaultVisual)) - return FALSE; - } else { - if (!miSetVisualTypes(pScrn->depth, - miGetDefaultVisualMask(pScrn->depth), - pScrn->rgbBits, pScrn->defaultVisual)) - return FALSE; - } - - /* - * Initialise the framebuffer. - */ - - switch (pScrn->bitsPerPixel) { - case 1: - ret = xf1bppScreenInit(pScreen, FbBase, - pScrn->virtualX, pScrn->virtualY, - pScrn->xDpi, pScrn->yDpi, - pScrn->displayWidth); - break; - case 4: - ret = xf4bppScreenInit(pScreen, FbBase, - pScrn->virtualX, pScrn->virtualY, - pScrn->xDpi, pScrn->yDpi, - pScrn->displayWidth); - break; - case 8: - ret = cfbScreenInit(pScreen, FbBase, - pScrn->virtualX, pScrn->virtualY, - pScrn->xDpi, pScrn->yDpi, - pScrn->displayWidth); - break; - case 16: - ret = cfb16ScreenInit(pScreen, FbBase, - pScrn->virtualX, pScrn->virtualY, - pScrn->xDpi, pScrn->yDpi, - pScrn->displayWidth); - break; - case 24: - ret = cfb24ScreenInit(pScreen, FbBase, - pScrn->virtualX, pScrn->virtualY, - pScrn->xDpi, pScrn->yDpi, - pScrn->displayWidth); - break; - case 32: - ret = cfb32ScreenInit(pScreen, FbBase, - pScrn->virtualX, pScrn->virtualY, - pScrn->xDpi, pScrn->yDpi, - pScrn->displayWidth); - break; - default: - print a message about an internal error; - ret = FALSE; - break; - } - - if (!ret) - return FALSE; - - /* Override the default mask/offset settings */ - if (pScrn->bitsPerPixel > 8) { - for (i = 0, visual = pScreen->visuals; - i < pScreen->numVisuals; i++, visual++) { - if ((visual->class | DynamicClass) == DirectColor) { - visual->offsetRed = pScrn->offset.red; - visual->offsetGreen = pScrn->offset.green; - visual->offsetBlue = pScrn->offset.blue; - visual->redMask = pScrn->mask.red; - visual->greenMask = pScrn->mask.green; - visual->blueMask = pScrn->mask.blue; - } - } - } - - /* - * If banking is needed, initialise an miBankInfoRec (defined in - * "mibank.h"), and call miInitializeBanking(). - */ - if (!miInitializeBanking(pScreen, pScrn->virtualX, pScrn->virtualY, - pScrn->displayWidth, pBankInfo)) - return FALSE; - - /* - * If backing store is to be supported (as is usually the case), - * initialise it. - */ - miInitializeBackingStore(pScreen); - - /* - * Set initial black & white colourmap indices. - */ - xf86SetBlackWhitePixels(pScreen); - - /* - * Install colourmap functions. If using the vgahw module, - * vgaHandleColormaps would usually be called here. - */ - - ... - - /* - * Initialise cursor functions. This example is for the mi - * software cursor. - */ - miDCInitialize(pScreen, xf86GetPointerScreenFuncs()); - - /* Initialise the default colourmap */ - switch (pScrn->depth) { - case 1: - if (!xf1bppCreateDefColormap(pScreen)) - return FALSE; - break; - case 4: - if (!xf4bppCreateDefColormap(pScreen)) - return FALSE; - break; - default: - if (!cfbCreateDefColormap(pScreen)) - return FALSE; - break; - } - - /* - * Wrap the CloseScreen vector and set SaveScreen. - */ - ZZZPTR(pScrn)->CloseScreen = pScreen->CloseScreen; - pScreen->CloseScreen = ZZZCloseScreen; - pScreen->SaveScreen = ZZZSaveScreen; - - /* Report any unused options (only for the first generation) */ - if (serverGeneration == 1) { - xf86ShowUnusedOptions(pScrn->scrnIndex, pScrn->options); - } - - /* Done */ - return TRUE; -} - </code> - - -<sect2>SwitchMode -<p> - - Define the &s.code;SwitchMode()&e.code; function if mode switching - is supported by the driver. - - <code> -static Bool -ZZZSwitchMode(int scrnIndex, DisplayModePtr mode, int flags) -{ - return ZZZModeInit(xf86Screens[scrnIndex], mode); -} - </code> - - -<sect2>AdjustFrame -<p> - - Define the &s.code;AdjustFrame()&e.code; function if the driver - supports this. - - <code> -static void -ZZZAdjustFrame(int scrnIndex, int x, int y, int flags) -{ - /* Adjust the viewport */ -} - </code> - - -<sect2>EnterVT, LeaveVT -<p> - - Define the &s.code;EnterVT()&e.code; and &s.code;LeaveVT()&e.code; - functions. - - These functions are mandatory. - - <code> -static Bool -ZZZEnterVT(int scrnIndex, int flags) -{ - ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; - return ZZZModeInit(pScrn, pScrn->currentMode); -} - -static void -ZZZLeaveVT(int scrnIndex, int flags) -{ - ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; - ZZZRestore(pScrn); -} - </code> - -<sect2>CloseScreen -<p> - - Define the &s.code;CloseScreen()&e.code; function: - - This function is mandatory. Note that it unwraps the previously - wrapped &s.code;pScreen->CloseScreen&e.code;, and finishes by - calling it. - - <code> -static Bool -ZZZCloseScreen(int scrnIndex, ScreenPtr pScreen) -{ - ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; - if (pScrn->vtSema) { - ZZZRestore(pScrn); - ZZZUnmapMem(pScrn); - } - pScrn->vtSema = FALSE; - pScreen->CloseScreen = ZZZPTR(pScrn)->CloseScreen; - return (*pScreen->CloseScreen)(scrnIndex, pScreen); -} - </code> - -<sect2>SaveScreen -<p> - - Define the &s.code;SaveScreen()&e.code; function (the screen - blanking function). When using the vgahw module, this will typically - be: - - <code> -static Bool -ZZZSaveScreen(ScreenPtr pScreen, int mode) -{ - return vgaHWSaveScreen(pScreen, mode); -} - </code> - - This function is mandatory. Before modifying any hardware register - directly this function needs to make sure that the Xserver is active - by checking if &s.code;pScrn&e.code; is non-NULL and for - &s.code;pScrn->vtSema == TRUE&e.code;. - -<sect2>FreeScreen -<p> - - Define the &s.code;FreeScreen()&e.code; function. This function - is optional. It should be defined if the &s.code;ScrnInfoRec&e.code; - &s.code;driverPrivate&e.code; field is used so that it can be freed - when a screen is deleted by the common layer for reasons possibly - beyond the driver's control. This function is not used in during - normal (error free) operation. The per-generation data is freed by - the &s.code;CloseScreen()&e.code; function. - - <code> -static void -ZZZFreeScreen(int scrnIndex, int flags) -{ - /* - * If the vgahw module is used vgaHWFreeHWRec() would be called - * here. - */ - ZZZFreeRec(xf86Screens[scrnIndex]); -} - </code> - - -</article> +<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN" [
+ <!ENTITY % defs SYSTEM "X11/defs.ent"> %defs;
+ <!-- config file keyword markup -->
+ <!ENTITY s.key STARTTAG "bf">
+ <!ENTITY e.key ENDTAG "bf">
+ <!-- specific config file keywords -->
+ <!ENTITY k.device "&s.key;Device&e.key;">
+ <!ENTITY k.monitor "&s.key;Monitor&e.key;">
+ <!ENTITY k.display "&s.key;Display&e.key;">
+ <!ENTITY k.inputdevice "&s.key;InputDevice&e.key;">
+ <!ENTITY k.screen "&s.key;Screen&e.key;">
+ <!ENTITY k.serverlayout "&s.key;ServerLayout&e.key;">
+ <!ENTITY k.driver "&s.key;Driver&e.key;">
+ <!ENTITY k.module "&s.key;Module&e.key;">
+ <!ENTITY k.identifier "&s.key;Identifier&e.key;">
+ <!ENTITY k.serverflags "&s.key;ServerFlags&e.key;">
+ <!-- command line markup -->
+ <!ENTITY s.cmd STARTTAG "tt">
+ <!ENTITY e.cmd ENDTAG "tt">
+ <!-- inline code markup -->
+ <!ENTITY s.code STARTTAG "tt">
+ <!ENTITY e.code ENDTAG "tt">
+ <!-- function indent -->
+ <!ENTITY f.indent "&nl          ">
+] >
+
+<article>
+
+<title>XFree86 server 4.x Design (DRAFT)
+<author>The XFree86 Project, Inc
+<and>Updates for X11R&relvers; by Jim Gettys
+<date>19 December 2003
+
+
+
+
+
+
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.53 2003/08/23 14:10:14 dawes Exp $
+</ident>
+
+
+<p>
+<bf>NOTE</bf>: This is a DRAFT document, and the interfaces described here
+are subject to change without notice.
+
+
+<sect>Preface
+<p>
+
+The broad design principles are:
+<itemize>
+ <item>keep it reasonable
+ <itemize>
+ <item>We cannot rewrite the complete server
+ <item>We don't want to re-invent the wheel
+ </itemize>
+ <item>keep it modular
+ <itemize>
+ <item>As many things as possible should go into modules
+ <item>The basic loader binary should be minimal
+ <item>A clean design with well defined layering is important
+ <item>DDX specific global variables are a nono
+ <item>The structure should be flexible enough to allow
+ future extensions
+ <item> The structure should minimize duplication of common code
+ </itemize>
+ <item>keep important features in mind
+ <itemize>
+ <item>multiple screens, including multiple instances of drivers
+ <item>mixing different color depths and visuals on different
+ and ideally even on the same screen
+ <item>better control of the PCI device used
+ <item>better config file parser
+ <item>get rid of all VGA compatibility assumptions
+ </itemize>
+</itemize>
+
+Unless we find major deficiencies in the DIX layer, we should avoid
+making changes there.
+
+<sect>The xorg.conf File
+<p>
+
+The xorg.conf file format is similar to the old format, with the following
+changes:
+
+<sect1>&k.device; section
+<p>
+
+ The &k.device; sections are similar to what they used to be, and
+ describe hardware-specific information for a single video card.
+ &k.device;
+ Some new keywords are added:
+
+
+ <descrip>
+ <tag>Driver "drivername"</tag>
+ Specifies the name of the driver to be used for the card. This
+ is mandatory.
+ <tag>BusID "busslot"</tag>
+ Specifies uniquely the location of the card on the bus. The
+ purpose is to identify particular cards in a multi-headed
+ configuration. The format of the argument is intentionally
+ vague, and may be architecture dependent. For a PCI bus, it
+ is something like "bus:slot:func".
+ </descrip>
+
+ A &k.device; section is considered ``active'' if there is a reference
+ to it in an active &k.screen; section.
+
+<sect1>&k.screen; section
+<p>
+
+ The &k.screen; sections are similar to what they used to be. They
+ no longer have a &k.driver; keyword, but an &k.identifier; keyword
+ is added. (The &k.driver; keyword may be accepted in place of the
+ &k.identifier; keyword for compatibility purposes.) The identifier
+ can be used to identify which screen is to be active when multiple
+ &k.screen sections are present. It is possible to specify the active
+ screen from the command line. A default is chosen in the absence
+ of one being specified. A &k.screen; section is considered ``active''
+ if there is a reference to it either from the command line, or from
+ an active &k.serverlayout; section.
+
+<sect1>&k.inputdevice; section
+<p>
+
+ The &k.inputdevice; section is a new section that describes
+ configuration information for input devices. It replaces the old
+ &s.key;Keyboard&e.key;, &s.key;Pointer&e.key; and &s.key;XInput&e.key;
+ sections. Like the &k.device; section, it has two mandatory keywords:
+ &k.identifier; and &k.driver;. For compatibility purposes the old
+ &s.key;Keyboard&e.key; and &s.key;Pointer&e.key; sections are
+ converted by the parser into &k.inputdevice; sections as follows:
+
+ <descrip>
+ <tag>&s.key;Keyboard&e.key;</tag>
+ &k.identifier; "Implicit Core Keyboard"<newline>
+ &k.driver; "keyboard"
+ <tag>&s.key;Pointer&e.key;</tag>
+ &k.identifier; "Implicit Core Pointer"<newline>
+ &k.driver; "mouse"
+ </descrip>
+
+ An &k.inputdevice; section is considered active if there is a
+ reference to it in an active &k.serverlayout; section. An
+ &k.inputdevice; section may also be referenced implicitly if there
+ is no &k.serverlayout; section, if the &s.cmd;-screen&e.cmd; command
+ line options is used, or if the &k.serverlayout; section doesn't
+ reference any &k.inputdevice; sections. In this case, the first
+ sections with drivers "keyboard" and "mouse" are used as the core
+ keyboard and pointer respectively.
+
+<sect1>&k.serverlayout; section
+<p>
+
+ The &k.serverlayout; section is a new section that is used to identify
+ which &k.screen; sections are to be used in a multi-headed configuration,
+ and the relative layout of those screens. It also identifies which
+ &k.inputdevice; sections are to be used. Each &k.serverlayout section
+ has an identifier, a list of &k.screen; section identifiers, and a list of
+ &k.inputdevice; section identifiers. &k.serverflags; options may also be
+ included in a &k.serverlayout; section, making it possible to override
+ the global values in the &k.serverflags; section.
+
+ A &k.serverlayout; section can be made active by being referenced on
+ the command line. In the absence of this, a default will be chosen
+ (the first one found). The screen names may optionally be followed
+ by a number specifying the preferred screen number, and optionally
+ by information specifying the physical positioning of the screen,
+ either in absolute terms or relative to another screen (or screens).
+ When no screen number is specified, they are numbered according to
+ the order in which they are listed. The old (now obsolete) method
+ of providing the positioning information is to give the names of
+ the four adjacent screens. The order of these is top, bottom, left,
+ right. Here is an example of a &k.serverlayout; section for two
+ screens using the old method, with the second located to the right
+ of the first:
+
+ <code>
+ Section "ServerLayout"
+ Identifier "Main Layout"
+ Screen 0 "Screen 1" "" "" "" "Screen 2"
+ Screen 1 "Screen 2"
+ Screen "Screen 3"
+ EndSection
+ </code>
+
+ The preferred way of specifying the layout is to explicitly specify
+ the screen's location in absolute terms or relative to another
+ screen.
+
+ In the absolute case, the upper left corner's coordinates are given
+ after the &s.key;Absolute&e.key; keyword. If the coordinates are
+ omitted, a value of &s.code;(0,0)&e.code; is assumed. An example
+ of absolute positioning follows:
+
+ <code>
+ Section "ServerLayout"
+ Identifier "Main Layout"
+ Screen 0 "Screen 1" Absolute 0 0
+ Screen 1 "Screen 2" Absolute 1024 0
+ Screen "Screen 3" Absolute 2048 0
+ EndSection
+ </code>
+
+ In the relative case, the position is specified by either using one of
+ the following keywords followed by the name of the reference screen:
+
+ <quote>
+ &s.key;RightOf&nl;
+ LeftOf&nl;
+ Above&nl;
+ Below&nl;
+ Relative&e.key;
+ </quote>
+
+ When the &s.key;Relative&e.key; keyword is used, the reference screen
+ name is followed by the coordinates of the new screen's origin
+ relative to reference screen. The following example shows how to use
+ some of the relative positioning options.
+
+ <code>
+ Section "ServerLayout"
+ Identifier "Main Layout"
+ Screen 0 "Screen 1"
+ Screen 1 "Screen 2" RightOf "Screen 1"
+ Screen "Screen 3" Relative "Screen 1" 2048 0
+ EndSection
+ </code>
+
+<sect1>Options
+<p>
+
+ Options are used more extensively. They may appear in most sections
+ now. Options related to drivers can be present in the &k.screen;,
+ &k.device; and &k.monitor; sections and the &k.display; subsections.
+ The order of precedence is &k.display;, &k.screen;, &k.monitor;,
+ &k.device;. Options have been extended to allow an optional value
+ to be specified in addition to the option name. For more details
+ about options, see the <ref id="options" name="Options"> section
+ for details.
+
+<sect>Driver Interface
+<p>
+
+The driver interface consists of a minimal set of entry points that are
+required based on the external events that the driver must react to.
+No non-essential structure is imposed on the way they are used beyond
+that. This is a significant difference compared with the old design.
+
+The entry points for drawing operations are already taken care of by
+the framebuffer code (including, XAA). Extensions and enhancements to
+framebuffer code are outside the scope of this document.
+
+This approach to the driver interface provides good flexibility, but does
+increase the complexity of drivers. To help address this, the XFree86
+common layer provides a set of ``helper'' functions to take care of things
+that most drivers need. These helpers help minimise the amount of code
+duplication between drivers. The use of helper functions by drivers is
+however optional, though encouraged. The basic philosophy behind the
+helper functions is that they should be useful to many drivers, that
+they should balance this against the complexity of their interface. It
+is inevitable that some drivers may find some helpers unsuitable and
+need to provide their own code.
+
+Events that a driver needs to react to are:
+
+ <descrip>
+ <tag>ScreenInit</tag>
+
+ An initialisation function is called from the DIX layer for each
+ screen at the start of each server generation.
+
+ <tag>Enter VT</tag>
+
+ The server takes control of the console.
+
+ <tag>Leave VT</tag>
+
+ The server releases control of the console.
+
+ <tag>Mode Switch</tag>
+
+ Change video mode.
+
+ <tag>ViewPort change</tag>
+
+ Change the origin of the physical view port.
+
+ <tag>ScreenSaver state change</tag>
+
+ Screen saver activation/deactivation.
+
+ <tag>CloseScreen</tag>
+
+ A close screen function is called from the DIX layer for each screen
+ at the end of each server generation.
+ </descrip>
+
+
+In addition to these events, the following functions are required by
+the XFree86 common layer:
+
+ <descrip>
+ <tag>Identify</tag>
+
+ Print a driver identifying message.
+
+ <tag>Probe</tag>
+
+ This is how a driver identifies if there is any hardware present that
+ it knows how to drive.
+
+ <tag>PreInit</tag>
+
+ Process information from the xorg.conf file, determine the
+ full characteristics of the hardware, and determine if a valid
+ configuration is present.
+ </descrip>
+
+The VidMode extension also requires:
+
+ <descrip>
+ <tag>ValidMode</tag>
+
+ Identify if a new mode is usable with the current configuration.
+ The PreInit function (and/or helpers it calls) may also make use
+ of the ValidMode function or something similar.
+ </descrip>
+
+
+Other extensions may require other entry points. The drivers will
+inform the common layer of these in such cases.
+
+<sect>Resource Access Control Introduction
+<p>
+
+Graphics devices are accessed through ranges in I/O or memory space.
+While most modern graphics devices allow relocation of such ranges many
+of them still require the use of well established interfaces such as
+VGA memory and IO ranges or 8514/A IO ranges. With modern buses (like
+PCI) it is possible for multiple video devices to share access to these
+resources. The RAC (Resource Access Control) subsystem provides a
+mechanism for this.
+
+<sect1>Terms and Definitions
+<p>
+
+<sect2>Bus
+<p>
+
+ ``Bus'' is ambiguous as it is used for different things: it may refer
+ to physical incompatible extension connectors in a computer system.
+ The RAC system knows two such systems: The ISA bus and the PCI bus.
+ (On the software level EISA, MCA and VL buses are currently treated
+ like ISA buses). ``Bus'' may also refer to logically different
+ entities on a single bus system which are connected via bridges. A
+ PCI system may have several distinct PCI buses connecting each other
+ by PCI-PCI bridges or to the host CPU by HOST-PCI bridges.
+
+ Systems that host more than one bus system link these together using
+ bridges. Bridges are a concern to RAC as they might block or pass
+ specific resources. PCI-PCI bridges may be set up to pass VGA
+ resources to the secondary bus. PCI-ISA buses pass any resources not
+ decoded on the primary PCI bus to the ISA bus. This way VGA resources
+ (although exclusive on the ISA bus) can be shared by ISA and PCI
+ cards. Currently HOST-PCI bridges are not yet handled by RAC as they
+ require specific drivers.
+
+<sect2>Entity
+<p>
+
+ The smallest independently addressable unit on a system bus is
+ referred to as an entity. So far we know ISA and PCI entities. PCI
+ entities can be located on the PCI bus by an unique ID consisting of
+ the bus, card and function number.
+
+<sect2>Resource
+<p>
+
+ ``Resource'' refers to a range of memory or I/O addresses an entity
+ can decode.
+
+ If a device is capable of disabling this decoding the resource is
+ called sharable. For PCI devices a generic method is provided to
+ control resource decoding. Other devices will have to provide a
+ device specific function to control decoding.
+
+ If the entity is capable of decoding this range at a different
+ location this resource is considered relocatable.
+
+ Resources which start at a specific address and occupy a single
+ continuous range are called block resources.
+
+ Alternatively resource addresses can be decoded in a way that they
+ satisfy the conditions:
+ <quote><verb>
+ address & mask == base
+ </verb></quote>
+ and
+ <quote><verb>
+ base & mask == base
+ </verb></quote>
+ Resources addressed in such a way are called sparse resources.
+
+<sect2>Server States
+<p>
+
+ The resource access control system knows two server states: the
+ SETUP and the OPERATING state. The SETUP state is entered whenever
+ a mode change takes place or the server exits or does VT switching.
+ During this state all entity resources are under resource access
+ control. During OPERATING state only those entities are controlled
+ which actually have shared resources that conflict with others.
+
+<sect>Control Flow in the Server and Mandatory Driver Functions
+<p>
+
+At the start of each server generation, &s.code;main()&e.code;
+(&s.code;dix/main.c&e.code;) calls the DDX function
+&s.code;InitOutput()&e.code;. This is the first place that the DDX gets
+control. &s.code;InitOutput()&e.code; is expected to fill in the global
+&s.code;screenInfo&e.code; struct, and one
+&s.code;screenInfo.screen[]&e.code; entry for each screen present. Here
+is what &s.code;InitOutput()&e.code; does:
+
+<sect1>Parse the xorg.conf file
+<p>
+
+ This is done at the start of the first server generation only.
+
+ The xorg.conf file is read in full, and the resulting information
+ stored in data structures. None of the parsed information is
+ processed at this point. The parser data structures are opaque to
+ the video drivers and to most of the common layer code.
+
+ The entire file is parsed first to remove any section ordering
+ requirements.
+
+
+<sect1>Initial processing of parsed information and command line options
+<p>
+
+ This is done at the start of the first server generation only.
+
+ The initial processing is to determine paths like the
+ &s.key;ModulePath&e.key;, etc, and to determine which &k.serverlayout;,
+ &k.screen; and &k.device; sections are active.
+
+
+<sect1>Enable port I/O access
+<p>
+
+ Port I/O access is controlled from the XFree86 common layer, and is
+ ``all or nothing''. It is enabled prior to calling driver probes, at
+ the start of subsequent server generations, and when VT switching
+ back to the Xserver. It is disabled at the end of server generations,
+ and when VT switching away from the Xserver.
+
+ The implementation details of this may vary on different platforms.
+
+
+<sect1>General bus probe
+<p>
+
+ This is done at the start of the first server generation only.
+
+ In the case of ix86 machines, this will be a general PCI probe.
+ The full information obtained here will be available to the drivers.
+ This information persists for the life of the Xserver. In the PCI
+ case, the PCI information for all video cards found is available by
+ calling &s.code;xf86GetPciVideoInfo()&e.code;.
+
+ <quote>
+ &s.code;pciVideoPtr *xf86GetPciVideoInfo(void)&e.code;
+ <quote><p>
+ returns a pointer to a list of pointers to
+ &s.code;pciVideoRec&e.code; entries, of which there is one for
+ each detected PCI video card. The list is terminated with a
+ &s.code;NULL&e.code; pointer. If no PCI video cards were
+ detected, the return value is &s.code;NULL&e.code;.
+
+ </quote>
+ </quote>
+
+ After the bus probe, the resource broker is initialised.
+
+
+<sect1>Load initial set of modules
+<p>
+
+ This is done at the start of the first server generation only.
+
+ The core server contains a list of mandatory modules. These are loaded
+ first. Currently the only module on this list is the bitmap font module.
+
+ The next set of modules loaded are those specified explicitly in the
+ &k.module; section of the config file.
+
+ The final set of initial modules are the driver modules referenced
+ by the active &k.device; and &k.inputdevice; sections in the config
+ file. Each of these modules is loaded exactly once.
+
+
+<sect1>Register Video and Input Drivers
+<p>
+
+ This is done at the start of the first server generation only.
+
+ When a driver module is loaded, the loader calls its
+ &s.code;Setup&e.code; function. For video drivers, this function
+ calls &s.code;xf86AddDriver()&e.code; to register the driver's
+ &s.code;DriverRec&e.code;, which contains a small set of essential
+ details and driver entry points required during the early phase of
+ &s.code;InitOutput()&e.code;. &s.code;xf86AddDriver()&e.code; adds
+ it to the global &s.code;xf86DriverList[]&e.code; array.
+
+ The &s.code;DriverRec&e.code; contains the driver canonical name,
+ the &s.code;Identify()&e.code;,
+ &s.code;Probe()&e.code; and &s.code;AvailableOptions()&e.code;
+ function entry points as well as a pointer
+ to the driver's module (as returned from the loader when the driver
+ was loaded) and a reference count which keeps track of how many
+ screens are using the driver. The entry driver entry points are
+ those required prior to the driver allocating and filling in its
+ &s.code;ScrnInfoRec&e.code;.
+
+ For a static server, the &s.code;xf86DriverList[]&e.code; array is
+ initialised at build time, and the loading of modules is not done.
+
+ A similar procedure is used for input drivers. The input driver's
+ &s.code;Setup&e.code; function calls
+ &s.code;xf86AddInputDriver()&e.code; to register the driver's
+ &s.code;InputDriverRec&e.code;, which contains a small set of
+ essential details and driver entry points required during the early
+ phase of &s.code;InitInput()&e.code;.
+ &s.code;xf86AddInputDriver()&e.code; adds it to the global
+ &s.code;xf86InputDriverList[]&e.code; array. For a static server,
+ the &s.code;xf86InputDriverList[]&e.code; array is initialised at
+ build time.
+
+ Both the &s.code;xf86DriverList[]&e.code; and
+ &s.code;xf86InputDriverList[]&e.code; arrays have been initialised
+ by the end of this stage.
+
+ Once all the drivers are registered, their
+ &s.code;ChipIdentify()&e.code; functions are called.
+
+ <quote>
+ &s.code;void ChipIdentify(int flags)&e.code;
+ <quote>
+ This is expected to print a message indicating the driver name,
+ a short summary of what it supports, and a list of the chipset
+ names that it supports. It may use the xf86PrintChipsets() helper
+ to do this.
+ </quote>
+ </quote>
+
+ <quote>
+ &s.code;void xf86PrintChipsets(const char *drvname, const char *drvmsg,
+ &f.indent;SymTabPtr chips)&e.code;
+ <quote>
+ This function provides an easy way for a driver's ChipIdentify
+ function to format the identification message.
+ </quote>
+ </quote>
+
+<sect1>Initialise Access Control
+<p>
+
+ This is done at the start of the first server generation only.
+
+ The Resource Access Control (RAC) subsystem is initialised before
+ calling any driver functions that may access hardware. All generic
+ bus information is probed and saved (for restoration later). All
+ (shared resource) video devices are disabled at the generic bus
+ level, and a probe is done to find the ``primary'' video device. These
+ devices remain disabled for the next step.
+
+
+<sect1>Video Driver Probe<label id="probe">
+<p>
+ This is done at the start of the first server generation only. The
+ &s.code;ChipProbe()&e.code; function of each registered video driver
+ is called.
+
+ <quote><p>
+ &s.code;Bool ChipProbe(DriverPtr drv, int flags)&e.code;
+ <quote><p>
+ The purpose of this is to identify all instances of hardware
+ supported by the driver. The flags value is currently either 0,
+ &s.code;PROBE_DEFAULT&e.code; or &s.code;PROBE_DETECT&e.code;.
+ &s.code;PROBE_DETECT&e.code; is used if "-configure" or "-probe"
+ command line arguments are given and indicates to the
+ &s.code;Probe()&e.code; function that it should not configure the
+ bus entities and that no xorg.conf information is available.
+
+ The probe must find the active device sections that match the
+ driver by calling &s.code;xf86MatchDevice()&e.code;. The number
+ of matches found limits the maximum number of instances for this
+ driver. If no matches are found, the function should return
+ &s.code;FALSE&e.code; immediately.
+
+ Devices that cannot be identified by using device-independent
+ methods should be probed at this stage (keeping in mind that access
+ to all resources that can be disabled in a device-independent way
+ are disabled during this phase). The probe must be a minimal
+ probe. It should just determine if there is a card present that
+ the driver can drive. It should use the least intrusive probe
+ methods possible. It must not do anything that is not essential,
+ like probing for other details such as the amount of memory
+ installed, etc. It is recommended that the
+ &s.code;xf86MatchPciInstances()&e.code; helper function be used
+ for identifying matching PCI devices, and similarly the
+ &s.code;xf86MatchIsaInstances()&e.code; for ISA (non-PCI) devices
+ (see the <ref id="rac" name="RAC"> section). These helpers also
+ checks and claims the appropriate entity. When not using the
+ helper, that should be done with &s.code;xf86CheckPciSlot()&e.code;
+ and &s.code;xf86ClaimPciSlot()&e.code; for PCI devices and
+ &s.code;xf86ClaimIsaSlot()&e.code; for ISA devices (see the
+ <ref id="rac" name="RAC"> section).
+
+ The probe must register all non-relocatable resources at this
+ stage. If a resource conflict is found between exclusive resources
+ the driver will fail immediately. This is usually best done with
+ the &s.code;xf86ConfigPciEntity()&e.code; helper function
+ for PCI and &s.code;xf86ConfigIsaEntity()&e.code; for ISA
+ (see the <ref id="rac" name="RAC"> section). It is possible to
+ register some entity specific functions with those helpers. When
+ not using the helpers, the &s.code;xf86AddEntityToScreen()&e.code;
+ &s.code;xf86ClaimFixedResources()&e.code; and
+ &s.code;xf86SetEntityFuncs()&e.code; should be used instead (see
+ the <ref id="rac" name="RAC"> section).
+
+ If a chipset is specified in an active device section which the
+ driver considers relevant (ie it has no driver specified, or the
+ driver specified matches the driver doing the probe), the Probe
+ must return &s.code;FALSE&e.code; if the chipset doesn't match
+ one supported by the driver.
+
+ If there are no active device sections that the driver considers
+ relevant, it must return &s.code;FALSE&e.code;.
+
+ Allocate a &s.code;ScrnInfoRec&e.code; for each active instance of the
+ hardware found, and fill in the basic information, including the
+ other driver entry points. This is best done with the
+ &s.code;xf86ConfigIsaEntity()&e.code; helper function for ISA
+ instances or &s.code;xf86ConfigPciEntity()&e.code; for PCI instances.
+ These functions allocate a &s.code;ScrnInfoRec&e.code; for active
+ entities. Optionally &s.code;xf86AllocateScreen()&e.code;
+ function may also be used to allocate the &s.code;ScrnInfoRec&e.code;.
+ Any of these functions take care of initialising fields to defined
+ ``unused'' values.
+
+ Claim the entities for each instance of the hardware found. This
+ prevents other drivers from claiming the same hardware.
+
+ Must leave hardware in the same state it found it in, and must not
+ do any hardware initialisation.
+
+ All detection can be overridden via the config file, and that
+ parsed information is available to the driver at this stage.
+
+ Returns &s.code;TRUE&e.code; if one or more instances are found,
+ and &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;int xf86MatchDevice(const char *drivername,
+ &f.indent;GDevPtr **driversectlist)&e.code;
+ <quote><p>
+
+ This function takes the name of the driver and returns via
+ &s.code;driversectlist&e.code; a list of device sections that
+ match the driver name. The function return value is the number
+ of matches found. If a fatal error is encountered the return
+ value is &s.code;-1&e.code;.
+
+ The caller should use &s.code;xfree()&e.code; to free
+ &s.code;*driversectlist&e.code; when it is no longer needed.
+
+ </quote>
+
+ &s.code;ScrnInfoPtr xf86AllocateScreen(DriverPtr drv, int flags)&e.code;
+ <quote><p>
+ This function allocates a new &s.code;ScrnInfoRec&e.code; in the
+ &s.code;xf86Screens[]&e.code; array. This function is normally
+ called by the video driver &s.code;ChipProbe()&e.code; functions.
+ The return value is a pointer to the newly allocated
+ &s.code;ScrnInfoRec&e.code;. The &s.code;scrnIndex&e.code;,
+ &s.code;origIndex&e.code;, &s.code;module&e.code; and
+ &s.code;drv&e.code; fields are initialised. The reference count
+ in &s.code;drv&e.code; is incremented. The storage for any
+ currently allocated ``privates'' pointers is also allocated and
+ the &s.code;privates&e.code; field initialised (the privates data
+ is of course not allocated or initialised). This function never
+ returns on failure. If the allocation fails, the server exits
+ with a fatal error. The flags value is not currently used, and
+ should be set to zero.
+ </quote>
+ </quote>
+
+ At the completion of this, a list of &s.code;ScrnInfoRecs&e.code;
+ have been allocated in the &s.code;xf86Screens[]&e.code; array, and
+ the associated entities and fixed resources have been claimed. The
+ following &s.code;ScrnInfoRec&e.code; fields must be initialised at
+ this point:
+
+ <quote><verb>
+ driverVersion
+ driverName
+ scrnIndex(*)
+ origIndex(*)
+ drv(*)
+ module(*)
+ name
+ Probe
+ PreInit
+ ScreenInit
+ EnterVT
+ LeaveVT
+ numEntities
+ entityList
+ access
+ </verb></quote>
+
+ <tt>(*)</tt> These are initialised when the &s.code;ScrnInfoRec&e.code;
+ is allocated, and not explicitly by the driver.
+
+ The following &s.code;ScrnInfoRec&e.code; fields must be initialised
+ if the driver is going to use them:
+
+ <quote><verb>
+ SwitchMode
+ AdjustFrame
+ FreeScreen
+ ValidMode
+ </verb></quote>
+
+<sect1>Matching Screens
+<p>
+
+ This is done at the start of the first server generation only.
+
+ After the Probe phase is finished, there will be some number of
+ &s.code;ScrnInfoRecs&e.code;. These are then matched with the active
+ &k.screen; sections in the xorg.conf, and those not having an active
+ &k.screen; section are deleted. If the number of remaining screens
+ is 0, &s.code;InitOutput()&e.code; sets
+ &s.code;screenInfo.numScreens&e.code; to &s.code;0&e.code; and
+ returns.
+
+ At this point the following fields of the &s.code;ScrnInfoRecs&e.code;
+ must be initialised:
+
+ <quote><verb>
+ confScreen
+ </verb></quote>
+
+
+<sect1>Allocate non-conflicting resources
+<p>
+
+ This is done at the start of the first server generation only.
+
+ Before calling the drivers again, the resource information collected
+ from the Probe phase is processed. This includes checking the extent
+ of PCI resources for the probed devices, and resolving any conflicts
+ in the relocatable PCI resources. It also reports conflicts, checks
+ bus routing issues, and anything else that is needed to enable the
+ entities for the next phase.
+
+ If any drivers registered an &s.code;EntityInit()&e.code; function
+ during the Probe phase, then they are called here.
+
+
+<sect1>Sort the Screens and pre-check Monitor Information
+<p>
+
+ This is done at the start of the first server generation only.
+
+ The list of screens is sorted to match the ordering requested in the
+ config file.
+
+ The list of modes for each active monitor is checked against the
+ monitor's parameters. Invalid modes are pruned.
+
+
+<sect1>PreInit
+<p>
+
+ This is done at the start of the first server generation only.
+
+ For each &s.code;ScrnInfoRec&e.code;, enable access to the screens entities and call
+ the &s.code;ChipPreInit()&e.code; function.
+
+ <quote><p>
+ &s.code;Bool ChipPreInit(ScrnInfoRec screen, int flags)&e.code;
+ <quote><p>
+ The purpose of this function is to find out all the information
+ required to determine if the configuration is usable, and to
+ initialise those parts of the &s.code;ScrnInfoRec&e.code; that
+ can be set once at the beginning of the first server generation.
+
+ The number of entities registered for the screen should be checked
+ against the expected number (most drivers expect only one). The
+ entity information for each of them should be retrieved (with
+ &s.code;xf86GetEntityInfo()&e.code;) and checked for the correct
+ bus type and that none of the sharable resources registered during
+ the Probe phase was rejected.
+
+ Access to resources for the entities that can be controlled in a
+ device-independent way are enabled before this function is called.
+ If the driver needs to access any resources that it has disabled
+ in an &s.code;EntityInit()&e.code; function that it registered,
+ then it may enable them here providing that it disables them before
+ this function returns.
+
+ This includes probing for video memory, clocks, ramdac, and all
+ other HW info that is needed. It includes determining the
+ depth/bpp/visual and related info. It includes validating and
+ determining the set of video modes that will be used (and anything
+ that is required to determine that).
+
+ This information should be determined in the least intrusive way
+ possible. The state of the HW must remain unchanged by this
+ function. Although video memory (including MMIO) may be mapped
+ within this function, it must be unmapped before returning. Driver
+ specific information should be stored in a structure hooked into
+ the &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code;
+ field. Any other modules which require persistent data (ie data
+ that persists across server generations) should be initialised in
+ this function, and they should allocate a ``privates'' index to
+ hook their data into by calling
+ &s.code;xf86AllocateScrnInfoPrivateIndex().&e.code; The ``privates''
+ data is persistent.
+
+ Helper functions for some of these things are provided at the
+ XFree86 common level, and the driver can choose to make use of
+ them.
+
+ All additional resources that the screen needs must be registered
+ here. This should be done with
+ &s.code;xf86RegisterResources()&e.code;. If some of the fixed
+ resources registered in the Probe phase are not needed or not
+ decoded by the hardware when in the OPERATING server state, their
+ status should be updated with
+ &s.code;xf86SetOperatingState()&e.code;.
+
+ Modules may be loaded at any point in this function, and all
+ modules that the driver will need must be loaded before the end
+ of this function. Either the &s.code;xf86LoadSubModule()&e.code;
+ or the &s.code;xf86LoadDrvSubModule()&e.code; function should be
+ used to load modules depending on whether a
+ &s.code;ScrnInfoRec&e.code; has been set up. A driver may unload
+ a module within this function if it was only needed temporarily,
+ and the &s.code;xf86UnloadSubModule()&e.code; function should be used
+ to do that. Otherwise there is no need to explicitly unload modules
+ because the loader takes care of module dependencies and will
+ unload submodules automatically if/when the driver module is
+ unloaded.
+
+ The bulk of the &s.code;ScrnInfoRec&e.code; fields should be filled
+ out in this function.
+
+ &s.code;ChipPreInit()&e.code; returns &s.code;FALSE&e.code; when
+ the configuration is unusable in some way (unsupported depth, no
+ valid modes, not enough video memory, etc), and &s.code;TRUE&e.code;
+ if it is usable.
+
+ It is expected that if the &s.code;ChipPreInit()&e.code; function
+ returns &s.code;TRUE&e.code;, then the only reasons that subsequent
+ stages in the driver might fail are lack or resources (like xalloc
+ failures). All other possible reasons for failure should be
+ determined by the &s.code;ChipPreInit()&e.code; function.
+
+ </quote>
+ </quote>
+
+ The &s.code;ScrnInfoRecs&e.code; for screens where the &s.code;ChipPreInit()&e.code; fails are removed.
+ If none remain, &s.code;InitOutput()&e.code; sets &s.code;screenInfo.numScreens&e.code; to &s.code;0&e.code; and returns.
+
+ At this point, further fields of the &s.code;ScrnInfoRecs&e.code; would normally be
+ filled in. Most are not strictly mandatory, but many are required
+ by other layers and/or helper functions that the driver may choose
+ to use. The documentation for those layers and helper functions
+ indicates which they require.
+
+ The following fields of the &s.code;ScrnInfoRecs&e.code; should be filled in if the
+ driver is going to use them:
+
+ <quote><verb>
+ monitor
+ display
+ depth
+ pixmapBPP
+ bitsPerPixel
+ weight (>8bpp only)
+ mask (>8bpp only)
+ offset (>8bpp only)
+ rgbBits (8bpp only)
+ gamma
+ defaultVisual
+ maxHValue
+ maxVValue
+ virtualX
+ virtualY
+ displayWidth
+ frameX0
+ frameY0
+ frameX1
+ frameY1
+ zoomLocked
+ modePool
+ modes
+ currentMode
+ progClock (TRUE if clock is programmable)
+ chipset
+ ramdac
+ clockchip
+ numClocks (if not programmable)
+ clock[] (if not programmable)
+ videoRam
+ biosBase
+ memBase
+ memClk
+ driverPrivate
+ chipID
+ chipRev
+ </verb></quote>
+
+ <quote><p>
+ &s.code;pointer xf86LoadSubModule(ScrnInfoPtr pScrn, const char *name)&e.code:
+ and
+ &s.code;pointer xf86LoadDrvSubModule(DriverPtr drv, const char *name)&e.code:
+ <quote><p>
+ Load a module that a driver depends on. This function loads the
+ module &s.code;name&e.code; as a sub module of the driver. The
+ return value is a handle identifying the new module. If the load
+ fails, the return value will be &s.code;NULL&e.code;. If a driver
+ needs to explicitly unload a module it has loaded in this way,
+ the return value must be saved and passed to
+ &s.code;xf86UnloadSubModule()&e.code; when unloading.
+
+ </quote>
+
+ &s.code;void xf86UnloadSubModule(pointer module)&e.code;
+ <quote><p>
+ Unloads the module referenced by &s.code;module&e.code;.
+ &s.code;module&e.code; should be a pointer returned previously
+ by &s.code;xf86LoadSubModule()&e.code; or
+ &s.code;xf86LoadDrvSubModule()&e.code; .
+
+ </quote>
+ </quote>
+
+<sect1>Cleaning up Unused Drivers
+<p>
+
+ At this point it is known which screens will be in use, and which
+ drivers are being used. Unreferenced drivers (and modules they
+ may have loaded) are unloaded here.
+
+
+<sect1>Consistency Checks
+<p>
+
+ The parameters that must be global to the server, like pixmap formats,
+ bitmap bit order, bitmap scanline unit and image byte order are
+ compared for each of the screens. If a mismatch is found, the server
+ exits with an appropriate message.
+
+
+<sect1>Check if Resource Control is Needed
+<p>
+
+ Determine if resource access control is needed. This is the case
+ if more than one screen is used. If necessary the RAC wrapper module
+ is loaded.
+
+<sect1>AddScreen (ScreenInit)
+<p>
+
+ At this point, the valid screens are known.
+ &s.code;AddScreen()&e.code; is called for each of them, passing
+ &s.code;ChipScreenInit()&e.code; as the argument.
+ &s.code;AddScreen()&e.code; is a DIX function that allocates a new
+ &s.code;screenInfo.screen[]&e.code; entry (aka
+ &s.code;pScreen&e.code;), and does some basic initialisation of it.
+ It then calls the &s.code;ChipScreenInit()&e.code; function, with
+ &s.code;pScreen&e.code; as one of its arguments. If
+ &s.code;ChipScreenInit()&e.code; returns &s.code;FALSE&e.code;,
+ &s.code;AddScreen()&e.code; returns &s.code;-1&e.code;. Otherwise
+ it returns the index of the screen. &s.code;AddScreen()&e.code;
+ should only fail because of programming errors or failure to allocate
+ resources (like memory). All configuration problems should be
+ detected BEFORE this point.
+
+ <quote><p>
+ &s.code;Bool ChipScreenInit(int index, ScreenPtr pScreen,
+ &f.indent;int argc, char **argv)&e.code;
+ <quote><p>
+ This is called at the start of each server generation.
+
+ Fill in all of &s.code;pScreen&e.code;, possibly doing some of
+ this by calling ScreenInit functions from other layers like mi,
+ framebuffers (cfb, etc), and extensions.
+
+ Decide which operations need to be placed under resource access
+ control. The classes of operations are the frame buffer operations
+ (&s.code;RAC_FB&e.code;), the pointer operations
+ (&s.code;RAC_CURSOR&e.code;), the viewport change operations
+ (&s.code;RAC_VIEWPORT&e.code;) and the colormap operations
+ (&s.code;RAC_COLORMAP&e.code;). Any operation that requires
+ resources which might be disabled during OPERATING state should
+ be set to use RAC. This can be specified separately for memory
+ and IO resources (the &s.code;racMemFlags&e.code; and
+ &s.code;racIoFlags&e.code; fields of the &s.code;ScrnInfoRec&e.code;
+ respectively).
+
+ Map any video memory or other memory regions.
+
+ Save the video card state. Enough state must be saved so that
+ the original state can later be restored.
+
+ Initialise the initial video mode. The &s.code;ScrnInfoRec&e.code;'s
+ &s.code;vtSema&e.code; field should be set to &s.code;TRUE&e.code;
+ just prior to changing the video hardware's state.
+
+ </quote>
+ </quote>
+
+
+ The &s.code;ChipScreenInit()&e.code; function (or functions from other
+ layers that it calls) should allocate entries in the
+ &s.code;ScreenRec&e.code;'s &s.code;devPrivates&e.code; area by
+ calling &s.code;AllocateScreenPrivateIndex()&e.code; if it needs
+ per-generation storage. Since the &s.code;ScreenRec&e.code;'s
+ &s.code;devPrivates&e.code; information is cleared for each server
+ generation, this is the correct place to initialise it.
+
+ After &s.code;AddScreen()&e.code; has successfully returned, the
+ following &s.code;ScrnInfoRec&e.code; fields are initialised:
+
+ <quote><verb>
+ pScreen
+ racMemFlags
+ racIoFlags
+ </verb></quote>
+
+ The &s.code;ChipScreenInit()&e.code; function should initialise the
+ &s.code;CloseScreen&e.code; and &s.code;SaveScreen&e.code; fields
+ of &s.code;pScreen&e.code;. The old value of
+ &s.code;pScreen->CloseScreen&e.code; should be saved as part of
+ the driver's per-screen private data, allowing it to be called from
+ &s.code;ChipCloseScreen()&e.code;. This means that the existing
+ &s.code;CloseScreen()&e.code; function is wrapped.
+
+<sect1>Finalising RAC Initialisation
+<p>
+
+ After all the &s.code;ChipScreenInit()&e.code; functions have been
+ called, each screen has registered its RAC requirements. This
+ information is used to determine which shared resources are requested
+ by more than one driver and set the access functions accordingly.
+ This is done following these rules:
+
+ <enum>
+ <item>The sharable resources registered by each entity are compared.
+ If a resource is registered by more than one entity the entity
+ will be marked to indicate that it needs to share this resources
+ type (IO or MEM).
+
+ <item>A resource marked ``disabled'' during OPERATING state will be
+ ignored entirely.
+
+ <item>A resource marked ``unused'' will only conflict with an overlapping
+ resource of an other entity if the second is actually in use
+ during OPERATING state.
+
+ <item>If an ``unused'' resource was found to conflict but the entity
+ does not use any other resource of this type the entire resource
+ type will be disabled for that entity.
+ </enum>
+
+
+<sect1>Finishing InitOutput()
+<p>
+
+ At this point &s.code;InitOutput()&e.code; is finished, and all the
+ screens have been setup in their initial video mode.
+
+
+<sect1>Mode Switching
+<p>
+
+ When a SwitchMode event is received, &s.code;ChipSwitchMode()&e.code;
+ is called (when it exists):
+
+ <quote><p>
+ &s.code;Bool ChipSwitchMode(int index, DisplayModePtr mode, int flags)&e.code;
+ <quote><p>
+ Initialises the new mode for the screen identified by
+ &s.code;index;&e.code;. The viewport may need to be adjusted
+ also.
+
+ </quote>
+ </quote>
+
+
+<sect1>Changing Viewport
+<p>
+
+ When a Change Viewport event is received,
+ &s.code;ChipAdjustFrame()&e.code; is called (when it exists):
+
+ <quote><p>
+ &s.code;void ChipAdjustFrame(int index, int x, int y, int flags)&e.code;
+ <quote><p>
+ Changes the viewport for the screen identified by
+ &s.code;index;&e.code;.
+
+ It should be noted that many chipsets impose restrictions on where the
+ viewport may be placed in the virtual resolution, either for alignment
+ reasons, or to prevent the start of the viewport from being positioned
+ within a pixel (as can happen in a 24bpp mode). After calculating the
+ value the chipset's panning registers need to be set to for non-DGA
+ modes, this function should recalculate the ScrnInfoRec's
+ &s.code;frameX0&e.code;, &s.code;frameY0&e.code, &s.code;frameX1&e.code;
+ and &s.code;frameY1&e.code; fields to correspond to that value. If
+ this is not done, switching to another mode might cause the position
+ of a hardware cursor to change.
+
+ </quote>
+ </quote>
+
+
+<sect1>VT Switching
+<p>
+
+ When a VT switch event is received, &s.code;xf86VTSwitch()&e.code;
+ is called. &s.code;xf86VTSwitch()&e.code; does the following:
+
+ <descrip>
+ <tag>On ENTER:</tag>
+ <itemize>
+ <item>enable port I/O access
+
+ <item>save and initialise the bus/resource state
+
+ <item>enter the SETUP server state
+
+ <item>calls &s.code;ChipEnterVT()&e.code; for each screen
+
+ <item>enter the OPERATING server state
+
+ <item>validate GCs
+
+ <item>Restore fb from saved pixmap for each screen
+
+ <item>Enable all input devices
+ </itemize>
+ <tag>On LEAVE:</tag>
+ <itemize>
+ <item>Save fb to pixmap for each screen
+
+ <item>validate GCs
+
+ <item>enter the SETUP server state
+
+ <item>calls &s.code;ChipLeaveVT()&e.code; for each screen
+
+ <item>disable all input devices
+
+ <item>restore bus/resource state
+
+ <item>disables port I/O access
+ </itemize>
+ </descrip>
+
+ <quote><p>
+ &s.code;Bool ChipEnterVT(int index, int flags)&e.code;
+ <quote><p>
+ This function should initialise the current video mode and
+ initialise the viewport, turn on the HW cursor if appropriate,
+ etc.
+
+ Should it re-save the video state before initialising the video
+ mode?
+
+ </quote>
+
+ &s.code;void ChipLeaveVT(int index, int flags)&e.code;
+ <quote><p>
+ This function should restore the saved video state. If
+ appropriate it should also turn off the HW cursor, and invalidate
+ any pixmap/font caches.
+
+ </quote>
+
+ Optionally, &s.code;ChipLeaveVT()&e.code; may also unmap memory
+ regions. If so, &s.code;ChipEnterVT()&e.code; will need to remap
+ them. Additionally, if an aperture used to access video memory is
+ unmapped and remapped in this fashion, &s.code;ChipEnterVT()&e.code;
+ will also need to notify the framebuffer layers of the aperture's new
+ location in virtual memory. This is done with a call to the screen's
+ &s.code;ModifyPixmapHeader()&e.code; function, as follows
+
+ <quote><p>
+ &s.code;(*pScreen->ModifyPixmapHeader)(pScrn->ppix,
+ &f.indent;-1, -1, -1, -1, -1, <it>NewApertureAddress</it>);&e.code;
+ <quote><p>
+ where the &s.code``ppix''&e.code; field in a ScrnInfoRec
+ points to the pixmap used by the screen's
+ &s.code;SaveRestoreImage()&e.code; function to hold the screen's
+ contents while switched out.
+
+ </quote>
+ </quote>
+
+ Currently, aperture remapping, as described here, should not be
+ attempted if the driver uses the &s.code;xf8_16bpp&e.code; or
+ &s.code;xf8_32bpp&e.code; framebuffer layers. A pending
+ restructuring of VT switching will address this restriction in
+ the near future.
+
+ </quote>
+
+ Other layers may wrap the &s.code;ChipEnterVT()&e.code; and
+ &s.code;ChipLeaveVT()&e.code; functions if they need to take some
+ action when these events are received.
+
+<sect1>End of server generation
+<p>
+
+ At the end of each server generation, the DIX layer calls
+ &s.code;ChipCloseScreen()&e.code; for each screen:
+
+ <quote><p>
+ &s.code;Bool ChipCloseScreen(int index, ScreenPtr pScreen)&e.code;
+ <quote><p>
+ This function should restore the saved video state and unmap the
+ memory regions.
+
+ It should also free per-screen data structures allocated by the
+ driver. Note that the persistent data held in the
+ &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; field
+ should not be freed here because it is needed by subsequent server
+ generations.
+
+ The &s.code;ScrnInfoRec&e.code;'s &s.code;vtSema&e.code; field
+ should be set to &s.code;FALSE&e.code; once the video HW state
+ has been restored.
+
+ Before freeing the per-screen driver data the saved
+ &s.code;CloseScreen&e.code; value should be restored to
+ &s.code;pScreen->CloseScreen&e.code;, and that function should
+ be called after freeing the data.
+
+ </quote>
+ </quote>
+
+<sect>Optional Driver Functions
+<p>
+
+The functions outlined here can be called from the XFree86 common layer,
+but their presence is optional.
+
+<sect1>Mode Validation
+<p>
+
+ When a mode validation helper supplied by the XFree86-common layer is
+ being used, it can be useful to provide a function to check for hw
+ specific mode constraints:
+
+ <quote><p>
+ &s.code;ModeStatus ChipValidMode(int index, DisplayModePtr mode,
+ &f.indent;Bool verbose, int flags)&e.code;
+ <quote><p>
+ Check the passed mode for hw-specific constraints, and return the
+ appropriate status value.
+
+ </quote>
+ </quote>
+
+<p>
+This function may also modify the effective timings and clock of the passed
+mode. These have been stored in the mode's &s.code;Crtc*&e.code; and
+&s.code;SynthClock&e.code; elements, and have already been adjusted for
+interlacing, doublescanning, multiscanning and clock multipliers and dividers.
+The function should not modify any other mode field, unless it wants to modify
+the mode timings reported to the user by &s.code;xf86PrintModes()&e.code;.
+
+<p>
+The function is called once for every mode in the xorg.conf Monitor section
+assigned to the screen, with &s.code;flags&e.code; set to
+&s.code;MODECHECK_INITIAL&e.code;. It is subsequently called for every mode
+in the xorg.conf Display subsection assigned to the screen, with
+&s.code;flags&e.code; set to &s.code;MODECHECK_FINAL&e.code;. In the second
+case, the mode will have successfully passed all other tests. In addition,
+the &s.code;ScrnInfoRec&e.code;'s &s.code;virtualX&e.code;,
+&s.code;virtualY&e.code; and &s.code;displayWidth&e.code; fields will have been
+set as if the mode to be validated were to be the last mode accepted.
+
+<p>
+In effect, calls with MODECHECK_INITIAL are intended for checks that do not
+depend on any mode other than the one being validated, while calls with
+MODECHECK_FINAL are intended for checks that may involve more than one mode.
+
+<sect1>Free screen data
+<p>
+
+ When a screen is deleted prior to the completion of the ScreenInit
+ phase the &s.code;ChipFreeScreen()&e.code; function is called when defined.
+
+ <quote><p>
+ &s.code;void ChipFreeScreen(int scrnindex, int flags)&e.code;
+ <quote><p>
+ Free any driver-allocated data that may have been allocated up to
+ and including an unsuccessful &s.code;ChipScreenInit()&e.code;
+ call. This would predominantly be data allocated by
+ &s.code;ChipPreInit()&e.code; that persists across server
+ generations. It would include the &s.code;driverPrivate&e.code;,
+ and any ``privates'' entries that modules may have allocated.
+
+ </quote>
+ </quote>
+
+
+<sect>Recommended driver functions
+<p>
+
+The functions outlined here are for internal use by the driver only.
+They are entirely optional, and are never accessed directly from higher
+layers. The sample function declarations shown here are just examples.
+The interface (if any) used is up to the driver.
+
+<sect1>Save
+<p>
+
+ Save the video state. This could be called from &s.code;ChipScreenInit()&e.code; and
+ (possibly) &s.code;ChipEnterVT()&e.code;.
+
+ <quote><p>
+ &s.code;void ChipSave(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ Saves the current state. This will only be saving pre-server
+ states or states before returning to the server. There is only
+ one current saved state per screen and it is stored in private
+ storage in the screen.
+
+ </quote>
+ </quote>
+
+<sect1>Restore
+<p>
+
+ Restore the original video state. This could be called from the
+ &s.code;ChipLeaveVT()&e.code; and &s.code;ChipCloseScreen()&e.code;
+ functions.
+
+ <quote><p>
+ &s.code;void ChipRestore(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ Restores the saved state from the private storage. Usually only
+ used for restoring text modes.
+
+ </quote>
+ </quote>
+
+
+<sect1>Initialise Mode
+<p>
+
+ Initialise a video mode. This could be called from the
+ &s.code;ChipScreenInit()&e.code;, &s.code;ChipSwitchMode()&e.code;
+ and &s.code;ChipEnterVT()&e.code; functions.
+
+ <quote><p>
+ &s.code;Bool ChipModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)&e.code;
+ <quote><p>
+ Programs the hardware for the given video mode.
+
+ </quote>
+ </quote>
+
+
+<sect>Data and Data Structures
+<p>
+
+<sect1>Command line data
+<p>
+
+Command line options are typically global, and are stored in global
+variables. These variables are read-only and are available to drivers
+via a function call interface. Most of these command line values are
+processed via helper functions to ensure that they are treated consistently
+by all drivers. The other means of access is provided for cases where
+the supplied helper functions might not be appropriate.
+
+Some of them are:
+
+<quote><verb>
+ xf86Verbose verbosity level
+ xf86Bpp -bpp from the command line
+ xf86Depth -depth from the command line
+ xf86Weight -weight from the command line
+ xf86Gamma -{r,g,b,}gamma from the command line
+ xf86FlipPixels -flippixels from the command line
+ xf86ProbeOnly -probeonly from the command line
+ defaultColorVisualClass -cc from the command line
+</verb></quote>
+
+If we ever do allow for screen-specific command line options, we may
+need to rethink this.
+
+These can be accessed in a read-only manner by drivers with the following
+functions:
+
+ <quote><p>
+ &s.code;int xf86GetVerbosity()&e.code;
+ <quote><p>
+ Returns the value of &s.code;xf86Verbose&e.code;.
+
+ </quote>
+
+ &s.code;int xf86GetDepth()&e.code;
+ <quote><p>
+ Returns the &s.cmd;-depth&e.cmd; command line setting. If not
+ set on the command line, &s.code;-1&e.code; is returned.
+
+ </quote>
+
+ &s.code;rgb xf86GetWeight()&e.code;
+ <quote><p>
+ Returns the &s.cmd;-weight&e.cmd; command line setting. If not
+ set on the command line, &s.code;{0, 0, 0}&e.code; is returned.
+
+ </quote>
+
+ &s.code;Gamma xf86GetGamma()&e.code;
+ <quote><p>
+ Returns the &s.cmd;-gamma&e.cmd; or &s.cmd;-rgamma&e.cmd;,
+ &s.cmd;-ggamma&e.cmd;, &s.cmd;-bgamma&e.cmd; command line settings.
+ If not set on the command line, &s.code;{0.0, 0.0, 0.0}&e.code;
+ is returned.
+
+ </quote>
+
+ &s.code;Bool xf86GetFlipPixels()&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; if &s.cmd;-flippixels&e.cmd; is
+ present on the command line, and &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;const char *xf86GetServerName()&e.code;
+ <quote><p>
+ Returns the name of the X server from the command line.
+
+ </quote>
+ </quote>
+
+<sect1>Data handling
+<p>
+
+Config file data contains parts that are global, and parts that are
+Screen specific. All of it is parsed into data structures that neither
+the drivers or most other parts of the server need to know about.
+
+The global data is typically not required by drivers, and as such, most
+of it is stored in the private &s.code;xf86InfoRec&e.code;.
+
+The screen-specific data collected from the config file is stored in
+screen, device, display, monitor-specific data structures that are separate
+from the &s.code;ScrnInfoRecs&e.code;, with the appropriate elements/fields
+hooked into the &s.code;ScrnInfoRecs&e.code; as required. The screen
+config data is held in &s.code;confScreenRec&e.code;, device data in
+the &s.code;GDevRec&e.code;, monitor data in the &s.code;MonRec&e.code;,
+and display data in the &s.code;DispRec&e.code;.
+
+The XFree86 common layer's screen specific data (the actual data in use
+for each screen) is held in the &s.code;ScrnInfoRecs&e.code;. As has
+been outlined above, the &s.code;ScrnInfoRecs&e.code; are allocated at probe
+time, and it is the responsibility of the Drivers' &s.code;Probe()&e.code;
+and &s.code;PreInit()&e.code; functions to finish filling them in based
+on both data provided on the command line and data provided from the
+Config file. The precedence for this is:
+
+ <quote>
+ command line -> config file -> probed/default data
+ </quote>
+
+For most things in this category there are helper functions that the
+drivers can use to ensure that the above precedence is consistently
+used.
+
+As well as containing screen-specific data that the XFree86 common layer
+(including essential parts of the server infrastructure as well as helper
+functions) needs to access, it also contains some data that drivers use
+internally. When considering whether to add a new field to the
+&s.code;ScrnInfoRec&e.code;, consider the balance between the convenience
+of things that lots of drivers need and the size/obscurity of the
+&s.code;ScrnInfoRec&e.code;.
+
+Per-screen driver specific data that cannot be accommodated with the
+static &s.code;ScrnInfoRec&e.code; fields is held in a driver-defined
+data structure, a pointer to which is assigned to the
+&s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; field. This
+is per-screen data that persists across server generations (as does the
+bulk of the static &s.code;ScrnInfoRec&e.code; data). It would typically
+also include the video card's saved state.
+
+Per-screen data for other modules that the driver uses (for example,
+the XAA module) that is reset for each server generation is hooked into
+the &s.code;ScrnInfoRec&e.code; through it's &s.code;privates&e.code;
+field.
+
+Once it has stabilised, the data structures and variables accessible to
+video drivers will be documented here. In the meantime, those things
+defined in the &s.code;xf86.h&e.code; and &s.code;xf86str.h&e.code;
+files are visible to video drivers. Things defined in
+&s.code;xf86Priv.h&e.code; and &s.code;xf86Privstr.h&e.code; are NOT
+intended to be visible to video drivers, and it is an error for a driver
+to include those files.
+
+
+<sect1>Accessing global data
+<p>
+
+Some other global state information that the drivers may access via
+functions is as follows:
+
+ <quote><p>
+ &s.code;Bool xf86ServerIsExiting()&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; if the server is at the end of a
+ generation and is in the process of exiting, and
+ &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;Bool xf86ServerIsResetting()&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; if the server is at the end of a
+ generation and is in the process of resetting, and
+ &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;Bool xf86ServerIsInitialising()&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; if the server is at the beginning of
+ a generation and is in the process of initialising, and
+ &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;Bool xf86ServerIsOnlyProbing()&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; if the -probeonly command line flag
+ was specified, and &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;Bool xf86CaughtSignal()&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; if the server has caught a signal,
+ and &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+ </quote>
+
+<sect1>Allocating private data
+<p>
+
+A driver and any module it uses may allocate per-screen private storage
+in either the &s.code;ScreenRec&e.code; (DIX level) or
+&s.code;ScrnInfoRec&e.code; (XFree86 common layer level).
+&s.code;ScreenRec&e.code; storage persists only for a single server
+generation, and &s.code;ScrnInfoRec&e.code; storage persists across
+generations for the lifetime of the server.
+
+The &s.code;ScreenRec&e.code; &s.code;devPrivates&e.code; data must be
+reallocated/initialised at the start of each new generation. This is
+normally done from the &s.code;ChipScreenInit()&e.code; function, and
+Init functions for other modules that it calls. Data allocated in this
+way should be freed by the driver's &s.code;ChipCloseScreen()&e.code;
+functions, and Close functions for other modules that it calls. A new
+&s.code;devPrivates&e.code; entry is allocated by calling the
+&s.code;AllocateScreenPrivateIndex()&e.code; function.
+
+ <quote><p>
+ &s.code;int AllocateScreenPrivateIndex()&e.code;
+ <quote><p>
+ This function allocates a new element in the
+ &s.code;devPrivates&e.code; field of all currently existing
+ &s.code;ScreenRecs&e.code;. The return value is the index of this
+ new element in the &s.code;devPrivates&e.code; array. The
+ &s.code;devPrivates&e.code; field is of type
+ &s.code;DevUnion&e.code;:
+
+ <verb>
+ typedef union _DevUnion {
+ pointer ptr;
+ long val;
+ unsigned long uval;
+ pointer (*fptr)(void);
+ } DevUnion;
+ </verb>
+
+ which allows the element to be used for any of the above types.
+ It is commonly used as a pointer to data that the caller allocates
+ after the new index has been allocated.
+
+ This function will return &s.code;-1&e.code; when there is an
+ error allocating the new index.
+
+ </quote>
+ </quote>
+
+The &s.code;ScrnInfoRec&e.code; &s.code;privates&e.code; data persists
+for the life of the server, so only needs to be allocated once. This
+should be done from the &s.code;ChipPreInit()&e.code; function, and Init
+functions for other modules that it calls. Data allocated in this way
+should be freed by the driver's &s.code;ChipFreeScreen()&e.code; functions,
+and Free functions for other modules that it calls. A new
+&s.code;privates&e.code; entry is allocated by calling the
+&s.code;xf86AllocateScrnInfoPrivateIndex()&e.code; function.
+
+
+ <quote><p>
+ &s.code;int xf86AllocateScrnInfoPrivateIndex()&e.code;
+ <quote><p>
+ This function allocates a new element in the &s.code;privates&e.code;
+ field of all currently existing &s.code;ScrnInfoRecs&e.code;.
+ The return value is the index of this new element in the
+ &s.code;privates&e.code; array. The &s.code;privates&e.code;
+ field is of type &s.code;DevUnion&e.code;:
+
+ <verb>
+ typedef union _DevUnion {
+ pointer ptr;
+ long val;
+ unsigned long uval;
+ pointer (*fptr)(void);
+ } DevUnion;
+ </verb>
+
+ which allows the element to be used for any of the above types.
+ It is commonly used as a pointer to data that the caller allocates
+ after the new index has been allocated.
+
+ This function will not return when there is an error allocating
+ the new index. When there is an error it will cause the server
+ to exit with a fatal error. The similar function for allocation
+ privates in the &s.code;ScreenRec&e.code;
+ (&s.code;AllocateScreenPrivateIndex()&e.code;) differs in this
+ respect by returning &s.code;-1&e.code; when the allocation fails.
+
+ </quote>
+ </quote>
+
+<sect>Keeping Track of Bus Resources<label id="rac">
+<p>
+
+<sect1>Theory of Operation
+<p>
+
+The XFree86 common layer has knowledge of generic access control mechanisms
+for devices on certain bus systems (currently the PCI bus) as well as
+of methods to enable or disable access to the buses itself. Furthermore
+it can access information on resources decoded by these devices and if
+necessary modify it.
+
+When first starting the Xserver collects all this information, saves it
+for restoration, checks it for consistency, and if necessary, corrects
+it. Finally it disables all resources on a generic level prior to
+calling any driver function.
+
+When the &s.code;Probe()&e.code; function of each driver is called the
+device sections are matched against the devices found in the system.
+The driver may probe devices at this stage that cannot be identified by
+using device independent methods. Access to all resources that can be
+controlled in a device independent way is disabled. The
+&s.code;Probe()&e.code; function should register all non-relocatable
+resources at this stage. If a resource conflict is found between
+exclusive resources the driver will fail immediately. Optionally the
+driver might specify an &s.code;EntityInit()&e.code;,
+&s.code;EntityLeave()&e.code; and &s.code;EntityEnter()&e.code; function.
+
+&s.code;EntityInit()&e.code; can be used to disable any shared resources
+that are not controlled by the generic access control functions. It is
+called prior to the PreInit phase regardless if an entity is active or
+not. When calling the &s.code;EntityInit()&e.code;,
+&s.code;EntityEnter()&e.code; and &s.code;EntityLeave()&e.code; functions
+the common level will disable access to all other entities on a generic
+level. Since the common level has no knowledge of device specific
+methods to disable access to resources it cannot be guaranteed that
+certain resources are not decoded by any other entity until the
+&s.code;EntityInit()&e.code; or &s.code;EntityEnter()&e.code; phase is
+finished. Device drivers should therefore register all those resources
+which they are going to disable. If these resources are never to be
+used by any driver function they may be flagged &s.code;ResInit&e.code;
+so that they can be removed from the resource list after processing all
+&s.code;EntityInit()&e.code; functions. &s.code;EntityEnter()&e.code;
+should disable decoding of all resources which are not registered as
+exclusive and which are not handled by the generic access control in
+the common level. The difference to &s.code;EntityInit()&e.code; is
+that the latter one is only called once during lifetime of the server.
+It can therefore be used to set up variables prior to disabling resources.
+&s.code;EntityLeave()&e.code; should restore the original state when
+exiting the server or switching to a different VT. It also needs to
+disable device specific access functions if they need to be disabled on
+server exit or VT switch. The default state is to enable them before
+giving up the VT.
+
+In &s.code;PreInit()&e.code; phase each driver should check if any
+sharable resources it has registered during &s.code;Probe()&e.code; has
+been denied and take appropriate action which could simply be to fail.
+If it needs to access resources it has disabled during
+&s.code;EntitySetup()&e.code; it can do so provided it has registered
+these and will disable them before returning from
+&s.code;PreInit()&e.code;. This also applies to all other driver
+functions. Several functions are provided to request resource ranges,
+register these, correct PCI config space and add replacements for the
+generic access functions. Resources may be marked ``disabled'' or
+``unused'' during OPERATING stage. Although these steps could also be
+performed in &s.code;ScreenInit()&e.code;, this is not desirable.
+
+Following &s.code;PreInit()&e.code; phase the common level determines
+if resource access control is needed. This is the case if more than
+one screen is used. If necessary the RAC wrapper module is loaded. In
+&s.code;ScreenInit()&e.code; the drivers can decide which operations
+need to be placed under RAC. Available are the frame buffer operations,
+the pointer operations and the colormap operations. Any operation that
+requires resources which might be disabled during OPERATING state should
+be set to use RAC. This can be specified separately for memory and IO
+resources.
+
+When &s.code;ScreenInit()&e.code; phase is done the common level will
+determine which shared resources are requested by more than one driver
+and set the access functions accordingly. This is done following these
+rules:
+
+<enum>
+<item>The sharable resources registered by each entity are compared. If
+ a resource is registered by more than one entity the entity will be
+ marked to need to share this resources type (&s.code;IO&e.code; or
+ &s.code;MEM&e.code;).
+
+<item>A resource marked ``disabled'' during OPERATING state will be ignored
+ entirely.
+
+<item>A resource marked ``unused'' will only conflicts with an overlapping
+ resource of an other entity if the second is actually in use during
+ OPERATING state.
+
+<item>If an ``unused'' resource was found to conflict however the entity
+ does not use any other resource of this type the entire resource type
+ will be disabled for that entity.
+</enum>
+
+The driver has the choice among different ways to control access to
+certain resources:
+
+<enum>
+<item>It can rely on the generic access functions. This is probably the
+ most common case. Here the driver only needs to register any resource
+ it is going to use.
+
+<item>It can replace the generic access functions by driver specific
+ ones. This will mostly be used in cases where no generic access
+ functions are available. In this case the driver has to make sure
+ these resources are disabled when entering the &s.code;PreInit()&e.code;
+ stage. Since the replacement functions are registered in
+ &s.code;PreInit()&e.code; the driver will have to enable these
+ resources itself if it needs to access them during this state. The
+ driver can specify if the replacement functions can control memory
+ and/or I/O resources separately.
+
+<item>The driver can enable resources itself when it needs them. Each
+ driver function enabling them needs to disable them before it will
+ return. This should be used if a resource which can be controlled
+ in a device dependent way is only required during SETUP state. This
+ way it can be marked ``unused'' during OPERATING state.
+</enum>
+
+A resource which is decoded during OPERATING state however never accessed
+by the driver should be marked unused.
+
+Since access switching latencies are an issue during Xserver operation,
+the common level attempts to minimize the number of entities that need
+to be placed under RAC control. When a wrapped operation is called,
+the &s.code;EnableAccess()&e.code; function is called before control is
+passed on. &s.code;EnableAccess()&e.code; checks if a screen is under
+access control. If not it just establishes bus routing and returns.
+If the screen needs to be under access control,
+&s.code;EnableAccess()&e.code; determines which resource types
+(&s.code;MEM&e.code;, &s.code;IO&e.code;) are required. Then it tests
+if this access is already established. If so it simply returns. If
+not it disables the currently established access, fixes bus routing and
+enables access to all entities registered for this screen.
+
+Whenever a mode switch or a VT-switch is performed the common level will
+return to SETUP state.
+
+<sect1>Resource Types
+<p>
+
+Resource have certain properties. When registering resources each range
+is accompanied by a flag consisting of the ORed flags of the different
+properties the resource has. Each resource range may be classified
+according to
+
+<itemize>
+ <item>its physical properties i.e., if it addresses
+ memory (&s.code;ResMem&e.code;) or
+ I/O space (&s.code;ResIo&e.code;),
+ <item>if it addresses a
+ block (&s.code;ResBlock&e.code;) or
+ sparse (&s.code;ResSparse&e.code;)
+ range,
+ <item>its access properties.
+</itemize>
+
+There are two known access properties:
+
+<itemize>
+ <item>&s.code;ResExclusive&e.code;
+ for resources which may not be shared with any other device and
+ <item>&s.code;ResShared&e.code;
+ for resources which can be disabled and therefore can be shared.
+</itemize>
+
+If it is necessary to test a resource against any type a generic access
+type &s.code;ResAny&e.code; is provided. If this is set the resource
+will conflict with any resource of a different entity intersecting its
+range. Further it can be specified that a resource is decoded however
+never used during any stage (&s.code;ResUnused&e.code;) or during
+OPERATING state (&s.code;ResUnusedOpr&e.code;). A resource only visible
+during the init functions (ie. &s.code;EntityInit()&e.code;,
+&s.code;EntityEnter()&e.code; and &s.code;EntityLeave()&e.code; should
+be registered with the flag &s.code;ResInit&e.code;. A resource that
+might conflict with background resource ranges may be flagged with
+&s.code;ResBios&e.code;. This might be useful when registering resources
+ranges that were assigned by the system Bios.
+
+Several predefined resource lists are available for VGA and 8514/A
+resources in &s.code;common/xf86Resources.h&e.code;.
+
+<sect1>Available Functions<label id="avail">
+<p>
+
+The functions provided for resource management are listed in their order
+of use in the driver.
+
+
+<sect2>Probe Phase
+<p>
+
+In this phase each driver detects those resources it is able to drive,
+creates an entity record for each of them, registers non-relocatable
+resources and allocates screens and adds the resources to screens.
+
+Two helper functions are provided for matching device sections in the
+xorg.conf file to the devices:
+
+ <quote><p>
+ &s.code;int xf86MatchPciInstances(const char *driverName, int vendorID,
+ &f.indent;SymTabPtr chipsets, PciChipsets *PCIchipsets,
+ &f.indent;GDevPtr *devList, int numDevs, DriverPtr drvp,
+ &f.indent;int **foundEntities)&e.code;
+ <quote><p>
+ This function finds matches between PCI cards that a driver supports
+ and config file device sections. It is intended for use in the
+ &s.code;ChipProbe()&e.code; function of drivers for PCI cards.
+ Only probed PCI devices with a vendor ID matching
+ &s.code;vendorID&e.code; are considered. &s.code;devList&e.code;
+ and &s.code;numDevs&e.code; are typically those found from
+ calling &s.code;xf86MatchDevice()&e.code;, and represent the active
+ config file device sections relevant to the driver.
+ &s.code;PCIchipsets&e.code; is a table that provides a mapping
+ between the PCI device IDs, the driver's internal chipset tokens
+ and a list of fixed resources.
+
+ When a device section doesn't have a &s.key;BusID&e.key; entry it
+ can only match the primary video device. Secondary devices are
+ only matched with device sections that have a matching
+ &s.key;BusID&e.key; entry.
+
+ Once the preliminary matches have been found, a final match is
+ confirmed by checking if the chipset override, ChipID override or
+ probed PCI chipset type match one of those given in the
+ &s.code;chipsets&e.code; and &s.code;PCIchipsets&e.code; lists.
+ The &s.code;PCIchipsets&e.code; list includes a list of the PCI
+ device IDs supported by the driver. The list should be terminated
+ with an entry with PCI ID &s.code;-1&e.code;". The
+ &s.code;chipsets&e.code; list is a table mapping the driver's
+ internal chipset tokens to names, and should be terminated with
+ a &s.code;NULL&e.code; entry. Only those entries with a
+ corresponding entry in the &s.code;PCIchipsets&e.code; list are
+ considered. The order of precedence is: config file chipset,
+ config file ChipID, probed PCI device ID.
+
+ In cases where a driver handles PCI chipsets with more than one
+ vendor ID, it may set &s.code;vendorID&e.code; to
+ &s.code;0&e.code;, and OR each devID in the list with (the
+ vendor ID << 16).
+
+ Entity index numbers for confirmed matches are returned as an
+ array via &s.code;foundEntities&e.code;. The PCI information,
+ chipset token and device section for each match are found in the
+ &s.code;EntityInfoRec&e.code; referenced by the indices.
+
+ The function return value is the number of confirmed matches. A
+ return value of &s.code;-1&e.code; indicates an internal error.
+ The returned &s.code;foundEntities&e.code; array should be freed
+ by the driver with &s.code;xfree()&e.code; when it is no longer
+ needed in cases where the return value is greater than zero.
+
+ </quote>
+
+ &s.code;int xf86MatchIsaInstances(const char *driverName,
+ &f.indent;SymTabPtr chipsets, IsaChipsets *ISAchipsets,
+ &f.indent;DriverPtr drvp, FindIsaDevProc FindIsaDevice,
+ &f.indent;GDevPtr *devList, int numDevs,
+ int **foundEntities)&e.code;
+ <quote><p>
+ This function finds matches between ISA cards that a driver supports
+ and config file device sections. It is intended for use in the
+ &s.code;ChipProbe()&e.code; function of drivers for ISA cards.
+ &s.code;devList&e.code; and &s.code;numDevs&e.code; are
+ typically those found from calling &s.code;xf86MatchDevice()&e.code;,
+ and represent the active config file device sections relevant to
+ the driver. &s.code;ISAchipsets&e.code; is a table that provides
+ a mapping between the driver's internal chipset tokens and the
+ resource classes. &s.code;FindIsaDevice&e.code; is a
+ driver-provided function that probes the hardware and returns the
+ chipset token corresponding to what was detected, and
+ &s.code;-1&e.code; if nothing was detected.
+
+ If the config file device section contains a chipset entry, then
+ it is checked against the &s.code;chipsets&e.code; list. When
+ no chipset entry is present, the &s.code;FindIsaDevice&e.code;
+ function is called instead.
+
+ Entity index numbers for confirmed matches are returned as an
+ array via &s.code;foundEntities&e.code;. The chipset token and
+ device section for each match are found in the
+ &s.code;EntityInfoRec&e.code; referenced by the indices.
+
+ The function return value is the number of confirmed matches. A
+ return value of &s.code;-1&e.code; indicates an internal error.
+ The returned &s.code;foundEntities&e.code; array should be freed
+ by the driver with &s.code;xfree()&e.code; when it is no longer
+ needed in cases where the return value is greater than zero.
+
+ </quote>
+ </quote>
+
+These two helper functions make use of several core functions that are
+available at the driver level:
+
+ <quote><p>
+ &s.code;Bool xf86ParsePciBusString(const char *busID, int *bus,
+ &f.indent;int *device, int *func)&e.code;
+ <quote><p>
+ Takes a &s.code;BusID&e.code; string, and if it is in the correct
+ format, returns the PCI &s.code;bus&e.code;, &s.code;device&e.code;,
+ &s.code;func&e.code; values that it indicates. The format of the
+ string is expected to be "PCI:bus:device:func" where each of `bus',
+ `device' and `func' are decimal integers. The ":func" part may
+ be omitted, and the func value assumed to be zero, but this isn't
+ encouraged. The "PCI" prefix may also be omitted. The prefix
+ "AGP" is currently equivalent to the "PCI" prefix. If the string
+ isn't a valid PCI BusID, the return value is &s.code;FALSE&e.code;.
+
+ </quote>
+
+
+ &s.code;Bool xf86ComparePciBusString(const char *busID, int bus,
+ &f.indent;int device, int func)&e.code;
+ <quote><p>
+ Compares a &s.code;BusID&e.code; string with PCI &s.code;bus&e.code;,
+ &s.code;device&e.code;, &s.code;func&e.code; values. If they
+ match &s.code;TRUE&e.code; is returned, and &s.code;FALSE&e.code;
+ if they don't.
+
+ </quote>
+
+ &s.code;Bool xf86ParseIsaBusString(const char *busID)&e.code;
+ <quote><p>
+ Compares a &s.code;BusID&e.code; string with the ISA bus ID string
+ ("ISA" or "ISA:"). If they match &s.code;TRUE&e.code; is returned,
+ and &s.code;FALSE&e.code; if they don't.
+
+ </quote>
+
+ &s.code;Bool xf86CheckPciSlot(int bus, int device, int func)&e.code;
+ <quote><p>
+ Checks if the PCI slot &s.code;bus:device:func&e.code; has been
+ claimed. If so, it returns &s.code;FALSE&e.code;, and otherwise
+ &s.code;TRUE&e.code;.
+
+ </quote>
+
+ &s.code;int xf86ClaimPciSlot(int bus, int device, int func, DriverPtr drvp,
+ &f.indent;int chipset, GDevPtr dev, Bool active)&e.code;
+ <quote><p>
+ This function is used to claim a PCI slot, allocate the associated
+ entity record and initialise their data structures. The return
+ value is the index of the newly allocated entity record, or
+ &s.code;-1&e.code; if the claim fails. This function should always
+ succeed if &s.code;xf86CheckPciSlot()&e.code; returned
+ &s.code;TRUE&e.code; for the same PCI slot.
+
+ </quote>
+
+ &s.code;Bool xf86IsPrimaryPci(void)&e.code;
+ <quote><p>
+ This function returns &s.code;TRUE&e.code; if the primary card is
+ a PCI device, and &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+
+ &s.code;int xf86ClaimIsaSlot(DriverPtr drvp, int chipset,
+ &f.indent;GDevPtr dev, Bool active)&e.code;
+ <quote><p>
+ This allocates an entity record entity and initialise the data
+ structures. The return value is the index of the newly allocated
+ entity record.
+
+ </quote>
+
+ &s.code;Bool xf86IsPrimaryIsa(void)&e.code;
+ <quote><p>
+ This function returns &s.code;TRUE&e.code; if the primary card is
+ an ISA (non-PCI) device, and &s.code;FALSE&e.code; otherwise.
+
+ </quote>
+ </quote>
+
+Two helper functions are provided to aid configuring entities:
+ <quote><p>
+ &s.code;ScrnInfoPtr xf86ConfigPciEntity(ScrnInfoPtr pScrn,
+ &f.indent;int scrnFlag, int entityIndex,
+ &f.indent;PciChipsets *p_chip,
+ &f.indent;resList res, EntityProc init,
+ &f.indent;EntityProc enter, EntityProc leave,
+ &f.indent;pointer private)&e.code;
+ <p>
+ &s.code;ScrnInfoPtr xf86ConfigIsaEntity(ScrnInfoPtr pScrn,
+ &f.indent;int scrnFlag, int entityIndex,
+ &f.indent;IsaChipsets *i_chip,
+ &f.indent;resList res, EntityProc init,
+ &f.indent;EntityProc enter, EntityProc leave,
+ &f.indent;pointer private)&e.code;
+ <quote><p>
+ These functions are used to register the non-relocatable resources
+ for an entity, and the optional entity-specific &s.code;Init&e.code;, &s.code;Enter&e.code; and
+ &s.code;Leave&e.code; functions. Usually the list of fixed resources is obtained
+ from the Isa/PciChipsets lists. However an additional list of
+ resources may be passed. Generally this is not required.
+ For active entities a &s.code;ScrnInfoRec&e.code; is allocated
+ if the &s.code;pScrn&e.code; argument is &s.code;NULL&e.code;.
+The
+ return value is &s.code;TRUE&e.code; when successful. The init, enter, leave
+ functions are defined as follows:
+
+ <quote>
+ &s.code;typedef void (*EntityProc)(int entityIndex,
+ &f.indent;pointer private)&e.code;
+ </quote>
+
+ They are passed the entity index and a pointer to a private scratch
+ area. This can be set up during &s.code;Probe()&e.code; and
+ its address can be passed to
+ &s.code;xf86ConfigIsaEntity()&e.code; and
+ &s.code;xf86ConfigPciEntity()&e.code; as the last argument.
+
+ </quote>
+ </quote>
+
+These two helper functions make use of several core functions that are
+available at the driver level:
+ <quote><p>
+ &s.code;void xf86ClaimFixedResources(resList list, int entityIndex)&e.code;
+ <quote><p>
+ This function registers the non-relocatable resources which cannot
+ be disabled and which therefore would cause the server to fail
+ immediately if they were found to conflict. It also records
+ non-relocatable but sharable resources for processing after the
+ &s.code;Probe()&e.code; phase.
+
+ </quote>
+
+ &s.code;Bool xf86SetEntityFuncs(int entityIndex, EntityProc init,
+ &f.indent;EntityProc enter, EntityProc leave, pointer)&e.code;
+ <quote><p>
+ This function registers with an entity the &s.code;init&e.code;,
+ &s.code;enter&e.code;, &s.code;leave&e.code; functions along
+ with the pointer to their private area.
+
+ </quote>
+
+ &s.code;void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex)&e.code;
+ <quote><p>
+ This function associates the entity referenced by
+ &s.code;entityIndex&e.code; with the screen.
+
+ </quote>
+ </quote>
+
+<sect2>PreInit Phase
+<p>
+
+During this phase the remaining resources should be registered.
+&s.code;PreInit()&e.code; should call &s.code;xf86GetEntityInfo()&e.code;
+to obtain a pointer to an &s.code;EntityInfoRec&e.code; for each entity
+it is able to drive and check if any resource are listed in its
+&s.code;resources&e.code; field. If resources registered in the Probe
+phase have been rejected in the post-Probe phase
+(&s.code;resources&e.code; is non-&s.code;NULL&e.code;), then the driver should
+decide if it can continue without using these or if it should fail.
+
+ <quote><p>
+ &s.code;EntityInfoPtr xf86GetEntityInfo(int entityIndex)&e.code;
+ <quote><p>
+ This function returns a pointer to the &s.code;EntityInfoRec&e.code;
+ referenced by &s.code;entityIndex&e.code;. The returned
+ &s.code;EntityInfoRec&e.code; should be freed with
+ &s.code;xfree()&e.code; when no longer needed.
+
+ </quote>
+ </quote>
+Several functions are provided to simplify resource registration:
+ <quote><p>
+ &s.code;Bool xf86IsEntityPrimary(int entityIndex)&e.code;
+ <quote><p>
+ This function returns &s.code;TRUE&e.code; if the entity referenced
+ by &s.code;entityIndex&e.code; is the primary display device (i.e.,
+ the one initialised at boot time and used in text mode).
+
+ </quote>
+
+ &s.code;Bool xf86IsScreenPrimary(int scrnIndex)&e.code;
+ <quote><p>
+ This function returns &s.code;TRUE&e.code; if the primary entity
+ is registered with the screen referenced by
+ &s.code;scrnIndex&e.code;.
+
+ </quote>
+
+ &s.code;pciVideoPtr xf86GetPciInfoForEntity(int entityIndex)&e.code;
+ <quote><p>
+ This function returns a pointer to the &s.code;pciVideoRec&e.code;
+ for the specified entity. If the entity is not a PCI device,
+ &s.code;NULL&e.code; is returned.
+
+ </quote>
+ </quote>
+
+The primary function for registration of resources is:
+ <quote><p>
+ &s.code;resPtr xf86RegisterResources(int entityIndex, resList list,
+ &f.indent;int access)&e.code;
+ <quote><p>
+ This function tries to register the resources in
+ &s.code;list&e.code;. If list is &s.code;NULL&e.code; it tries
+ to determine the resources automatically. This only works for
+ entities that provide a generic way to read out the resource ranges
+ they decode. So far this is only the case for PCI devices. By
+ default the PCI resources are registered as shared
+ (&s.code;ResShared&e.code;) if the driver wants to set a different
+ access type it can do so by specifying the access flags in the
+ third argument. A value of &s.code;0&e.code; means to use the
+ default settings. If for any reason the resource broker is not
+ able to register some of the requested resources the function will
+ return a pointer to a list of the failed ones. In this case the
+ driver may be able to move the resource to different locations.
+ In case of PCI bus entities this is done by passing the list of
+ failed resources to &s.code;xf86ReallocatePciResources()&e.code;.
+ When the registration succeeds, the return value is
+ &s.code;NULL&e.code;.
+
+ </quote>
+
+ &s.code;resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes)&e.code;
+ <quote><p>
+ This function takes a list of PCI resources that need to be
+ reallocated and returns &s.code;NULL&e.code when all relocations are
+ successful.
+ &s.code;xf86RegisterResources()&e.code; should be called again to
+ register the relocated resources with the broker.
+ If the reallocation fails, a list of the resources that could not be
+ relocated is returned.
+
+ </quote>
+ </quote>
+
+Two functions are provided to obtain a resource range of a given type:
+ <quote><p>
+ &s.code;resRange xf86GetBlock(long type, memType size,
+ &f.indent;memType window_start, memType window_end,
+ &f.indent;memType align_mask, resPtr avoid)&e.code;
+ <quote><p>
+ This function tries to find a block range of size
+ &s.code;size&e.code; and type &s.code;type&e.code; in a window
+ bound by &s.code;window_start&e.code; and &s.code;window_end&e.code;
+ with the alignment specified in &s.code;align_mask&e.code;.
+ Optionally a list of resource ranges which should be avoided within
+ the window can be supplied. On failure a zero-length range of
+ type &s.code;ResEnd&e.code; will be returned.
+
+ </quote>
+ &s.code;resRange xf86GetSparse(long type, memType fixed_bits,
+ &f.indent;memType decode_mask, memType address_mask,
+ &f.indent;resPtr avoid)&e.code;
+ <quote><p>
+ This function is like the previous one, but attempts to find a
+ sparse range instead of a block range. Here three values have to
+ be specified: the &s.code;address_mask&e.code; which marks all
+ bits of the mask part of the address, the &s.code;decode_mask&e.code;
+ which masks out the bits which are hardcoded and are therefore
+ not available for relocation and the values of the fixed bits.
+ The function tries to find a base that satisfies the given condition.
+ If the function fails it will return a zero range of type
+ &s.code;ResEnd&e.code;. Optionally it might be passed a list of
+ resource ranges to avoid.
+
+ </quote>
+ </quote>
+
+Some PCI devices are broken in the sense that they return invalid size
+information for a certain resource. In this case the driver can supply
+the correct size and make sure that the resource range allocated for
+the card is large enough to hold the address range decoded by the card.
+The function &s.code;xf86FixPciResource()&e.code; can be used to do this:
+ <quote><p>
+ &s.code;Bool xf86FixPciResource(int entityIndex, unsigned int prt,
+ &f.indent;CARD32 alignment, long type)&e.code;
+ <quote><p>
+ This function fixes a PCI resource allocation. The
+ &s.code;prt&e.code; parameter contains the number of the PCI base
+ register that needs to be fixed (&s.code;0-5&e.code;, and
+ &s.code;6&e.code; for the BIOS base register). The size is
+ specified by the alignment. Since PCI resources need to span an
+ integral range of size &s.code;2^n&e.code;, the alignment also
+ specifies the number of addresses that will be decoded. If the
+ driver specifies a type mask it can override the default type for
+ PCI resources which is &s.code;ResShared&e.code;. The resource
+ broker needs to know that to find a matching resource range. This
+ function should be called before calling
+ &s.code;xf86RegisterResources()&e.code;. The return value is
+ &s.code;TRUE&e.code; when the function succeeds.
+
+ </quote>
+
+ &s.code;Bool xf86CheckPciMemBase(pciVideoPtr pPci, memType base)&e.code;
+ <quote><p>
+ This function checks that the memory base address specified matches
+ one of the PCI base address register values for the given PCI
+ device. This is mostly used to check that an externally provided
+ base address (e.g., from a config file) matches an actual value
+ allocated to a device.
+
+ </quote>
+ </quote>
+
+The driver may replace the generic access control functions for an entity.
+This is done with the &s.code;xf86SetAccessFuncs()&e.code;:
+ <quote><p>
+ &s.code;void xf86SetAccessFuncs(EntityInfoPtr pEnt,
+ &f.indent;xf86SetAccessFuncPtr funcs,
+ &f.indent;xf86SetAccessFuncPtr oldFuncs)&e.code;
+ <quote><p>
+ with:
+ </quote>
+
+ <verb>
+ typedef struct {
+ xf86AccessPtr mem;
+ xf86AccessPtr io;
+ xf86AccessPtr io_mem;
+ } xf86SetAccessFuncRec, *xf86SetAccessFuncPtr;
+ </verb>
+
+ <quote><p>
+ The driver can pass three functions: one for I/O access, one for
+ memory access and one for combined memory and I/O access. If the
+ memory access and combined access functions are identical the
+ common level assumes that the memory access cannot be controlled
+ independently of I/O access, if the I/O access function and the
+ combined access functions are the same it is assumed that I/O can
+ not be controlled independently. If memory and I/O have to be
+ controlled together all three values should be the same. If a
+ non &s.code;NULL&e.code; value is passed as third argument it is
+ interpreted as an address where to store the old access record.
+ If the third argument is &s.code;NULL&e.code; it will be assumed
+ that the generic access should be enabled before replacing the
+ access functions. Otherwise it will be disabled. The driver may
+ enable them itself using the returned values. It should do this
+ from its replacement access functions as the generic access may
+ be disabled by the common level on certain occasions. If replacement
+ functions are specified they must control all resources of the
+ specific type registered for the entity.
+
+ </quote>
+ </quote>
+
+To find out if a specific resource range conflicts with another
+resource the &s.code;xf86ChkConflict()&e.code; function may be used:
+ <quote><p>
+ &s.code;memType xf86ChkConflict(resRange *rgp, int entityIndex)&e.code;
+ <quote><p>
+ This function checks if the resource range &s.code;rgp&e.code; of
+ for the specified entity conflicts with with another resource.
+ If a conflict is found, the address of the start of the conflict
+ is returned. The return value is zero when there is no conflict.
+
+ </quote>
+ </quote>
+
+The OPERATING state properties of previously registered fixed resources
+can be set with the &s.code;xf86SetOperatingState()&e.code; function:
+ <quote><p>
+ &s.code;resPtr xf86SetOperatingState(resList list, int entityIndex,
+ &f.indent;int mask)&e.code;
+ <quote><p>
+ This function is used to set the status of a resource during
+ OPERATING state. &s.code;list&e.code; holds a list to which
+ &s.code;mask&e.code; is to be applied. The parameter
+ &s.code;mask&e.code; may have the value &s.code;ResUnusedOpr&e.code;
+ and &s.code;ResDisableOpr&e.code;. The first one should be used
+ if a resource isn't used by the driver during OPERATING state
+ although it is decoded by the device, while the latter one indicates
+ that the resource is not decoded during OPERATING state. Note
+ that the resource ranges have to match those specified during
+ registration. If a range has been specified starting at
+ &s.code;A&e.code; and ending at &s.code;B&e.code; and suppose
+ &s.code;C&e.code; us a value satisfying
+ &s.code;A < C < B&e.code; one may not
+ specify the resource range &s.code;(A,B)&e.code; by splitting it
+ into two ranges &s.code;(A,C)&e.code; and &s.code;(C,B)&e.code;.
+
+ </quote>
+ </quote>
+
+The following two functions are provided for special cases:
+ <quote><p>
+ &s.code;void xf86RemoveEntityFromScreen(ScrnInfoPtr pScrn, int entityIndex)&e.code;
+ <quote><p>
+ This function may be used to remove an entity from a screen. This
+ only makes sense if a screen has more than one entity assigned or
+ the screen is to be deleted. No test is made if the screen has
+ any entities left.
+
+ </quote>
+
+ &s.code;void xf86DeallocateResourcesForEntity(int entityIndex, long type)&e.code;
+ <quote><p>
+ This function deallocates all resources of a given type registered
+ for a certain entity from the resource broker list.
+
+ </quote>
+ </quote>
+
+<sect2>ScreenInit Phase
+<p>
+
+All that is required in this phase is to setup the RAC flags. Note that
+it is also permissible to set these flags up in the PreInit phase. The
+RAC flags are held in the &s.code;racIoFlags&e.code; and &s.code;racMemFlags&e.code; fields of the
+&s.code;ScrnInfoRec&e.code; for each screen. They specify which graphics operations
+might require the use of shared resources. This can be specified
+separately for memory and I/O resources. The available flags are defined
+in &s.code;rac/xf86RAC.h&e.code;. They are:
+
+ &s.code;RAC_FB&e.code;
+ <quote>
+ for framebuffer operations (including hw acceleration)
+ </quote>
+ &s.code;RAC_CURSOR&e.code;
+ <quote>
+ for Cursor operations
+ (??? I'm not sure if we need this for SW cursor it depends
+ on which level the sw cursor is drawn)
+ </quote>
+ &s.code;RAC_COLORMAP&e.code;
+ <quote>
+ for colormap operations
+ </quote>
+ &s.code;RAC_VIEWPORT&e.code;
+ <quote>
+ for the call to &s.code;ChipAdjustFrame()&e.code; </quote>
+
+
+The flags are ORed together.
+
+<sect>Config file ``Option'' entries<label id="options">
+<p>
+
+Option entries are permitted in most sections and subsections of the
+config file. There are two forms of option entries:
+
+<descrip>
+<tag>Option "option-name"</tag>
+ A boolean option.
+<tag>Option "option-name" "option-value"</tag>
+ An option with an arbitrary value.
+</descrip>
+
+The option entries are handled by the parser, and a list of the parsed
+options is included with each of the appropriate data structures that
+the drivers have access to. The data structures used to hold the option
+information are opaque to the driver, and a driver must not access the
+option data directly. Instead, the common layer provides a set of
+functions that may be used to access, check and manipulate the option
+data.
+
+First, the low level option handling functions. In most cases drivers
+would not need to use these directly.
+
+ <quote><p>
+ &s.code;pointer xf86FindOption(pointer options, const char *name)&e.code;
+ <quote><p>
+ Takes a list of options and an option name, and returns a handle
+ for the first option entry in the list matching the name. Returns
+ &s.code;NULL&e.code; if no match is found.
+
+ </quote>
+
+ &s.code;char *xf86FindOptionValue(pointer options, const char *name)&e.code;
+ <quote><p>
+ Takes a list of options and an option name, and returns the value
+ associated with the first option entry in the list matching the
+ name. If the matching option has no value, an empty string
+ (&s.code;""&e.code;) is returned. Returns &s.code;NULL&e.code;
+ if no match is found.
+
+ </quote>
+
+ &s.code;void xf86MarkOptionUsed(pointer option)&e.code;
+ <quote><p>
+ Takes a handle for an option, and marks that option as used.
+
+ </quote>
+
+ &s.code;void xf86MarkOptionUsedByName(pointer options, const char *name)&e.code;
+ <quote><p>
+ Takes a list of options and an option name and marks the first
+ option entry in the list matching the name as used.
+
+ </quote>
+ </quote>
+
+
+Next, the higher level functions that most drivers would use.
+ <quote><p>
+ &s.code;void xf86CollectOptions(ScrnInfoPtr pScrn, pointer extraOpts)&e.code;
+ <quote><p>
+ Collect the options from each of the config file sections used by
+ the screen (&s.code;pScrn&e.code;) and return the merged list as
+ &s.code;pScrn->options&e.code;. This function requires that
+ &s.code;pScrn->confScreen&e.code;, &s.code;pScrn->display&e.code;,
+ &s.code;pScrn->monitor&e.code;,
+ &s.code;pScrn->numEntities&e.code;, and
+ &s.code;pScrn->entityList&e.code; are initialised.
+ &s.code;extraOpts&e.code; may optionally be set to an additional
+ list of options to be combined with the others. The order of
+ precedence for options is &s.code;extraOpts&e.code;, display,
+ confScreen, monitor, device.
+
+ </quote>
+
+ &s.code;void xf86ProcessOptions(int scrnIndex, pointer options,
+ &f.indent;OptionInfoPtr optinfo)&e.code;
+ <quote><p>
+ Processes a list of options according to the information in the
+ array of &s.code;OptionInfoRecs&e.code; (&s.code;optinfo&e.code;).
+ The resulting information is stored in the &s.code;value&e.code;
+ fields of the appropriate &s.code;optinfo&e.code; entries. The
+ &s.code;found&e.code; fields are set to &s.code;TRUE&e.code;
+ when an option with a value of the correct type if found, and
+ &s.code;FALSE&e.code; otherwise. The &s.code;type&e.code; field
+ is used to determine the expected value type for each option.
+ Each option in the list of options for which there is a name match
+ (but not necessarily a value type match) is marked as used.
+ Warning messages are printed when option values don't match the
+ types specified in the optinfo data.
+
+ NOTE: If this function is called before a driver's screen number
+ is known (e.g., from the &s.code;ChipProbe()&e.code; function) a
+ &s.code;scrnIndex&e.code; value of &s.code;-1&e.code; should be
+ used.
+
+ NOTE 2: Given that this function stores into the
+ &s.code;OptionInfoRecs&e.code; pointed to by &s.code;optinfo&e.code,
+ the caller should ensure the &s.code;OptionInfoRecs&e.code; are
+ (re-)initialised before the call, especially if the caller expects
+ to use the predefined option values as defaults.
+
+ The &s.code;OptionInfoRec&e.code; is defined as follows:
+
+ <verb>
+ typedef struct {
+ double freq;
+ int units;
+ } OptFrequency;
+
+ typedef union {
+ unsigned long num;
+ char * str;
+ double realnum;
+ Bool bool;
+ OptFrequency freq;
+ } ValueUnion;
+
+ typedef enum {
+ OPTV_NONE = 0,
+ OPTV_INTEGER,
+ OPTV_STRING, /* a non-empty string */
+ OPTV_ANYSTR, /* Any string, including an empty one */
+ OPTV_REAL,
+ OPTV_BOOLEAN,
+ OPTV_PERCENT,
+ OPTV_FREQ
+ } OptionValueType;
+
+ typedef enum {
+ OPTUNITS_HZ = 1,
+ OPTUNITS_KHZ,
+ OPTUNITS_MHZ
+ } OptFreqUnits;
+
+ typedef struct {
+ int token;
+ const char* name;
+ OptionValueType type;
+ ValueUnion value;
+ Bool found;
+ } OptionInfoRec, *OptionInfoPtr;
+ </verb>
+
+ &s.code;OPTV_FREQ&e.code; can be used for options values that are
+ frequencies. These values are a floating point number with an
+ optional unit name appended. The unit name can be one of "Hz",
+ "kHz", "k", "MHz", "M". The multiplier associated with the unit
+ is stored in &s.code;freq.units&e.code;, and the scaled frequency
+ is stored in &s.code;freq.freq&e.code;. When no unit is specified,
+ &s.code;freq.units&e.code; is set to &s.code;0&e.code;, and
+ &s.code;freq.freq&e.code; is unscaled.
+
+ &s.code;OPTV_PERCENT&e.code; can be used for option values that are
+ specified in percent (e.g. "20%"). These values are a floating point
+ number with a percent sign appended. If the percent sign is missing,
+ the parser will fail to match the value.
+
+ Typical usage is to setup an array of
+ &s.code;OptionInfoRecs&e.code; with all fields initialised.
+ The &s.code;value&e.code; and &s.code;found&e.code; fields get
+ set by &s.code;xf86ProcessOptions()&e.code;. For cases where the
+ value parsing is more complex, the driver should specify
+ &s.code;OPTV_STRING&e.code;, and parse the string itself. An
+ example of using this option handling is included in the
+ <ref id="sample" name="Sample Driver"> section.
+
+ </quote>
+
+ &s.code;void xf86ShowUnusedOptions(int scrnIndex, pointer options)&e.code;
+ <quote><p>
+ Prints out warning messages for each option in the list of options
+ that isn't marked as used. This is intended to show options that
+ the driver hasn't recognised. It would normally be called near
+ the end of the &s.code;ChipScreenInit()&e.code; function, but only
+ when &s.code;serverGeneration == 1&e.code;.
+
+ </quote>
+
+ &s.code;OptionInfoPtr xf86TokenToOptinfo(const OptionInfoRec *table,
+ &f.indent;int token)&e.code;
+
+ <quote><p>
+ Returns a pointer to the &s.code;OptionInfoRec&e.code; in
+ &s.code;table&e.code; with a token field matching
+ &s.code;token&e.code;. Returns &s.code;NULL&e.code; if no match
+ is found.
+
+ </quote>
+
+ &s.code;Bool xf86IsOptionSet(const OptionInfoRec *table, int token)&e.code;
+ <quote><p>
+ Returns the &s.code;found&e.code; field of the
+ &s.code;OptionInfoRec&e.code; in &s.code;table&e.code; with a
+ &s.code;token&e.code; field matching &s.code;token&e.code;. This
+ can be used for options of all types. Note that for options of
+ type &s.code;OPTV_BOOLEAN&e.code;, it isn't sufficient to check
+ this to determine the value of the option. Returns
+ &s.code;FALSE&e.code; if no match is found.
+
+ </quote>
+
+ &s.code;char *xf86GetOptValString(const OptionInfoRec *table, int token)&e.code;
+ <quote><p>
+ Returns the &s.code;value.str&e.code; field of the
+ &s.code;OptionInfoRec&e.code; in &s.code;table&e.code; with a
+ token field matching &s.code;token&e.code;. Returns
+ &s.code;NULL&e.code; if no match is found.
+
+ </quote>
+
+ &s.code;Bool xf86GetOptValInteger(const OptionInfoRec *table, int token,
+ &f.indent;int *value)&e.code;
+ <quote><p>
+ Returns via &s.code;*value&e.code; the &s.code;value.num&e.code;
+ field of the &s.code;OptionInfoRec&e.code; in &s.code;table&e.code;
+ with a &s.code;token&e.code; field matching &s.code;token&e.code;.
+ &s.code;*value&e.code; is only changed when a match is found so
+ it can be safely initialised with a default prior to calling this
+ function. The function return value is as for
+ &s.code;xf86IsOptionSet()&e.code;.
+
+ </quote>
+
+ &s.code;Bool xf86GetOptValULong(const OptionInfoRec *table, int token,
+ &f.indent;unsigned long *value)&e.code;
+ <quote><p>
+ Like &s.code;xf86GetOptValInteger()&e.code;, except the value is
+ treated as an &s.code;unsigned long&e.code;.
+
+ </quote>
+
+ &s.code;Bool xf86GetOptValReal(const OptionInfoRec *table, int token,
+ &f.indent;double *value)&e.code;
+ <quote><p>
+ Like &s.code;xf86GetOptValInteger()&e.code;, except that
+ &s.code;value.realnum&e.code; is used.
+
+ </quote>
+
+ &s.code;Bool xf86GetOptValFreq(const OptionInfoRec *table, int token,
+ &f.indent;OptFreqUnits expectedUnits, double *value)&e.code;
+ <quote><p>
+ Like &s.code;xf86GetOptValInteger()&e.code;, except that the
+ &s.code;value.freq&e.code; data is returned. The frequency value
+ is scaled to the units indicated by &s.code;expectedUnits&e.code;.
+ The scaling is exact when the units were specified explicitly in
+ the option's value. Otherwise, the &s.code;expectedUnits&e.code;
+ field is used as a hint when doing the scaling. In this case,
+ values larger than &s.code;1000&e.code; are assumed to have be
+ specified in the next smallest units. For example, if the Option
+ value is "10000" and expectedUnits is &s.code;OPTUNITS_MHZ&e.code;,
+ the value returned is &s.code;10&e.code;.
+
+ </quote>
+
+ &s.code;Bool xf86GetOptValBool(const OptionInfoRec *table, int token, Bool *value)&e.code;
+ <quote><p>
+ This function is used to check boolean options
+ (&s.code;OPTV_BOOLEAN&e.code;). If the function return value is
+ &s.code;FALSE&e.code;, it means the option wasn't set. Otherwise
+ &s.code;*value&e.code; is set to the boolean value indicated by
+ the option's value. No option &s.code;value&e.code; is interpreted
+ as &s.code;TRUE&e.code;. Option values meaning &s.code;TRUE&e.code;
+ are "1", "yes", "on", "true", and option values meaning
+ &s.code;FALSE&e.code; are "0", "no", "off", "false". Option names
+ both with the "no" prefix in their names, and with that prefix
+ removed are also checked and handled in the obvious way.
+ &s.code;*value&e.code; is not changed when the option isn't present.
+ It should normally be set to a default value before calling this
+ function.
+
+ </quote>
+
+ &s.code;Bool xf86ReturnOptValBool(const OptionInfoRec *table, int token, Bool def)&e.code;
+ <quote><p>
+ This function is used to check boolean options
+ (&s.code;OPTV_BOOLEAN&e.code;). If the option is set, its value
+ is returned. If the options is not set, the default value specified
+ by &s.code;def&e.code; is returned. The option interpretation is
+ the same as for &s.code;xf86GetOptValBool()&e.code;.
+
+ </quote>
+
+ &s.code;int xf86NameCmp(const char *s1, const char *s2)&e.code;
+ <quote><p>
+ This function should be used when comparing strings from the config
+ file with expected values. It works like &s.code;strcmp()&e.code;,
+ but is not case sensitive and space, tab, and `<tt>_</tt>' characters
+ are ignored in the comparison. The use of this function isn't
+ restricted to parsing option values. It may be used anywhere
+ where this functionality required.
+
+ </quote>
+ </quote>
+
+<sect>Modules, Drivers, Include Files and Interface Issues
+<p>
+
+NOTE: this section is incomplete.
+
+
+<sect1>Include files
+<p>
+
+The following include files are typically required by video drivers:
+
+ <quote><p>
+ All drivers should include these:
+ <quote>
+ &s.code;"xf86.h"&nl;
+ "xf86_OSproc.h"&nl;
+ "xf86_ansic.h"&nl;
+ "xf86Resources.h"&e.code;
+ </quote>
+ Wherever inb/outb (and related things) are used the following should be
+ included:
+ <quote>
+ &s.code;"compiler.h"&e.code;
+ </quote>
+ Note: in drivers, this must be included after &s.code;"xf86_ansic.h"&e.code;.
+
+ Drivers that need to access PCI vendor/device definitions need this:
+ <quote>
+ &s.code;"xf86PciInfo.h"&e.code;
+ </quote>
+
+ Drivers that need to access the PCI config space need this:
+ <quote>
+ &s.code;"xf86Pci.h"&e.code;
+ </quote>
+
+ Drivers that initialise a SW cursor need this:
+ <quote>
+ &s.code;"mipointer.h"&e.code;
+ </quote>
+
+ All drivers implementing backing store need this:
+ <quote>
+ &s.code;"mibstore.h"&e.code;
+ </quote>
+
+ All drivers using the mi colourmap code need this:
+ <quote>
+ &s.code;"micmap.h"&e.code;
+ </quote>
+
+ If a driver uses the vgahw module, it needs this:
+ <quote>
+ &s.code;"vgaHW.h"&e.code;
+ </quote>
+
+ Drivers supporting VGA or Hercules monochrome screens need:
+ <quote>
+ &s.code;"xf1bpp.h"&e.code;
+ </quote>
+
+ Drivers supporting VGA or EGC 16-colour screens need:
+ <quote>
+ &s.code;"xf4bpp.h"&e.code;
+ </quote>
+
+ Drivers using cfb need:
+ <quote>
+ &s.code;#define PSZ 8&nl;
+ #include "cfb.h"&nl;
+ #undef PSZ&e.code;
+ </quote>
+
+ Drivers supporting bpp 16, 24 or 32 with cfb need one or more of:
+ <quote>
+ &s.code;"cfb16.h"&nl;
+ "cfb24.h"&nl;
+ "cfb32.h"&e.code;
+ </quote>
+
+ If a driver uses XAA, it needs these:
+ <quote>
+ &s.code;"xaa.h"&nl;
+ "xaalocal.h"&e.code;
+ </quote>
+
+ If a driver uses the fb manager, it needs this:
+ <quote>
+ &s.code;"xf86fbman.h"&e.code;
+ </quote>
+ </quote>
+
+Non-driver modules should include &s.code;"xf86_ansic.h"&e.code; to get the correct
+wrapping of ANSI C/libc functions.
+
+All modules must NOT include any system include files, or the following:
+
+ <quote>
+ &s.code;"xf86Priv.h"&nl;
+ "xf86Privstr.h"&nl;
+ "xf86_OSlib.h"&nl;
+ "Xos.h"&e.code;
+ </quote>
+
+In addition, "xf86_libc.h" must not be included explicitly. It is
+included implicitly by "xf86_ansic.h".
+
+
+<sect>Offscreen Memory Manager
+<p>
+
+Management of offscreen video memory may be handled by the XFree86
+framebuffer manager. Once the offscreen memory manager is running,
+drivers or extensions may allocate, free or resize areas of offscreen
+video memory using the following functions (definitions taken from
+&s.code;xf86fbman.h&e.code;):
+
+<code>
+ typedef struct _FBArea {
+ ScreenPtr pScreen;
+ BoxRec box;
+ int granularity;
+ void (*MoveAreaCallback)(struct _FBArea*, struct _FBArea*)
+ void (*RemoveAreaCallback)(struct _FBArea*)
+ DevUnion devPrivate;
+ } FBArea, *FBAreaPtr;
+
+ typedef void (*MoveAreaCallbackProcPtr)(FBAreaPtr from, FBAreaPtr to)
+ typedef void (*RemoveAreaCallbackProcPtr)(FBAreaPtr)
+
+ FBAreaPtr xf86AllocateOffscreenArea (
+ ScreenPtr pScreen,
+ int width, int height,
+ int granularity,
+ MoveAreaCallbackProcPtr MoveAreaCallback,
+ RemoveAreaCallbackProcPtr RemoveAreaCallback,
+ pointer privData
+ )
+
+ void xf86FreeOffscreenArea (FBAreaPtr area)
+
+ Bool xf86ResizeOffscreenArea (
+ FBAreaPtr area
+ int w, int h
+ )
+</code>
+
+The function:
+<quote>
+ &s.code;Bool xf86FBManagerRunning(ScreenPtr pScreen)&e.code;
+</quote>
+
+can be used by an extension to check if the driver has initialized
+the memory manager. The manager is not available if this returns
+&s.code;FALSE&e.code; and the functions above will all fail.
+
+
+&s.code;xf86AllocateOffscreenArea()&e.code; can be used to request a
+rectangle of dimensions &s.code;width&e.code; x &s.code;height&e.code;
+(in pixels) from unused offscreen memory. &s.code;granularity&e.code;
+specifies that the leftmost edge of the rectangle must lie on some
+multiple of &s.code;granularity&e.code; pixels. A granularity of zero
+means the same thing as a granularity of one - no alignment preference.
+A &s.code;MoveAreaCallback&e.code; can be provided to notify the requester
+when the offscreen area is moved. If no &s.code;MoveAreaCallback&e.code;
+is supplied then the area is considered to be immovable. The
+&s.code;privData&e.code; field will be stored in the manager's internal
+structure for that allocated area and will be returned to the requester
+in the &s.code;FBArea&e.code; passed via the
+&s.code;MoveAreaCallback&e.code;. An optional
+&s.code;RemoveAreaCallback&e.code; is provided. If the driver provides
+this it indicates that the area should be allocated with a lower priority.
+Such an area may be removed when a higher priority request (one that
+doesn't have a &s.code;RemoveAreaCallback&e.code;) is made. When this
+function is called, the driver will have an opportunity to do whatever
+cleanup it needs to do to deal with the loss of the area, but it must
+finish its cleanup before the function exits since the offscreen memory
+manager will free the area immediately after.
+
+&s.code;xf86AllocateOffscreenArea()&e.code; returns &s.code;NULL&e.code;
+if it was unable to allocate the requested area. When no longer needed,
+areas should be freed with &s.code;xf86FreeOffscreenArea()&e.code;.
+
+&s.code;xf86ResizeOffscreenArea()&e.code; resizes an existing
+&s.code;FBArea&e.code;. &s.code;xf86ResizeOffscreenArea()&e.code;
+returns &s.code;TRUE&e.code; if the resize was successful. If
+&s.code;xf86ResizeOffscreenArea()&e.code; returns &s.code;FALSE&e.code;,
+the original &s.code;FBArea&e.code; is left unmodified. Resizing an
+area maintains the area's original &s.code;granularity&e.code;,
+&s.code;devPrivate&e.code;, and &s.code;MoveAreaCallback&e.code;.
+&s.code;xf86ResizeOffscreenArea()&e.code; has considerably less overhead
+than freeing the old area then reallocating the new size, so it should
+be used whenever possible.
+
+The function:
+ <quote>
+ &s.code;Bool xf86QueryLargestOffscreenArea(
+ &f.indent;ScreenPtr pScreen,
+ &f.indent;int *width, int *height,
+ &f.indent;int granularity,
+ &f.indent;int preferences,
+ &f.indent;int priority
+ &nl)&e.code;
+ </quote>
+
+is provided to query the width and height of the largest single
+&s.code;FBArea&e.code; allocatable given a particular priority.
+&s.code;preferences&e.code; can be one of the following to indicate
+whether width, height or area should be considered when determining
+which is the largest single &s.code;FBArea&e.code; available.
+
+ <quote>
+ &s.code;FAVOR_AREA_THEN_WIDTH&nl;
+ FAVOR_AREA_THEN_HEIGHT&nl;
+ FAVOR_WIDTH_THEN_AREA&nl;
+ FAVOR_HEIGHT_THEN_AREA&e.code;
+ </quote>
+
+&s.code;priority&e.code; is one of the following:
+
+ <quote><p>
+ &s.code;PRIORITY_LOW&e.code;
+ <quote><p>
+ Return the largest block available without stealing anyone else's
+ space. This corresponds to the priority of allocating a
+ &s.code;FBArea&e.code; when a &s.code;RemoveAreaCallback&e.code;
+ is provided.
+
+ </quote>
+ &s.code;PRIORITY_NORMAL&e.code;
+ <quote><p>
+ Return the largest block available if it is acceptable to steal a
+ lower priority area from someone. This corresponds to the priority
+ of allocating a &s.code;FBArea&e.code; without providing a
+ &s.code;RemoveAreaCallback&e.code;.
+
+ </quote>
+ &s.code;PRIORITY_EXTREME&e.code;
+ <quote><p>
+ Return the largest block available if all &s.code;FBAreas&e.code;
+ that aren't locked down were expunged from memory first. This
+ corresponds to any allocation made directly after a call to
+ &s.code;xf86PurgeUnlockedOffscreenAreas()&e.code;.
+
+ </quote>
+ </quote>
+
+
+The function:
+
+ <quote>
+ &s.code;Bool xf86PurgeUnlockedOffscreenAreas(ScreenPtr pScreen)&e.code;
+ </quote>
+
+is provided as an extreme method to free up offscreen memory. This
+will remove all removable &s.code;FBArea&e.code; allocations.
+
+
+Initialization of the XFree86 framebuffer manager is done via
+
+ <quote>
+ &s.code;Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox)&e.code;
+ </quote>
+
+&s.code;FullBox&e.code; represents the area of the framebuffer that the
+manager is allowed to manage. This is typically a box with a width of
+&s.code;pScrn->displayWidth&e.code; and a height of as many lines as
+can be fit within the total video memory, however, the driver can reserve
+areas at the extremities by passing a smaller area to the manager.
+
+&s.code;xf86InitFBManager()&e.code; must be called before XAA is
+initialized since XAA uses the manager for it's pixmap cache.
+
+An alternative function is provided to allow the driver to initialize
+the framebuffer manager with a Region rather than a box.
+
+ <quote>
+ &s.code;Bool xf86InitFBManagerRegion(ScreenPtr pScreen,
+ &f.indent;RegionPtr FullRegion)&e.code;
+ </quote>
+
+&s.code;xf86InitFBManagerRegion()&e.code;, unlike
+&s.code;xf86InitFBManager()&e.code;, does not remove the area used for
+the visible screen so that area should not be included in the region
+passed to the function. &s.code;xf86InitFBManagerRegion()&e.code; is
+useful when non-contiguous areas are available to be managed, and is
+required when multiple framebuffers are stored in video memory (as in
+the case where an overlay of a different depth is stored as a second
+framebuffer in offscreen memory).
+
+
+<sect>Colormap Handling<label id="cmap">
+<p>
+
+A generic colormap handling layer is provided within the XFree86 common
+layer. This layer takes care of most of the details, and only requires
+a function from the driver that loads the hardware palette when required.
+To use the colormap layer, a driver calls the
+&s.code;xf86HandleColormaps()&e.code; function.
+
+ <quote><p>
+ &s.code;Bool xf86HandleColormaps(ScreenPtr pScreen, int maxColors,
+ &f.indent;int sigRGBbits, LoadPaletteFuncPtr loadPalette,
+ &f.indent;SetOverscanFuncPtr setOverscan,
+ unsigned int flags)&e.code;
+ <quote><p>
+ This function must be called after the default colormap has been
+ initialised. The &s.code;pScrn->gamma&e.code; field must also
+ be initialised, preferably by calling &s.code;xf86SetGamma()&e.code;.
+ &s.code;maxColors&e.code; is the number of entries in the palette.
+ &s.code;sigRGBbits&e.code; is the size in bits of each color
+ component in the DAC's palette. &s.code;loadPalette&e.code;
+ is a driver-provided function for loading a colormap into the
+ hardware, and is described below. &s.code;setOverscan&e.code; is
+ an optional function that may be provided when the overscan color
+ is an index from the standard LUT and when it needs to be adjusted
+ to keep it as close to black as possible. The
+ &s.code;setOverscan&e.code; function programs the overscan index.
+ It shouldn't normally be used for depths other than 8.
+ &s.code;setOverscan&e.code; should be set to &s.code;NULL&e.code;
+ when it isn't needed. &s.code;flags&e.code; may be set to the
+ following (which may be ORed together):
+
+ &s.code;CMAP_PALETTED_TRUECOLOR&e.code;
+ <quote><p>
+ the TrueColor visual is paletted and is
+ just a special case of DirectColor.
+ This flag is only valid for
+ &s.code;bpp > 8&e.code;.
+
+ </quote>
+
+ &s.code;CMAP_RELOAD_ON_MODE_SWITCH&e.code;
+ <quote><p>
+ reload the colormap automatically
+ after mode switches. This is useful
+ for when the driver is resetting the
+ hardware during mode switches and
+ corrupting or erasing the hardware
+ palette.
+
+ </quote>
+
+ &s.code;CMAP_LOAD_EVEN_IF_OFFSCREEN&e.code;
+ <quote><p>
+ reload the colormap even if the screen
+ is switched out of the server's VC.
+ The palette is <it>not</it> reloaded when
+ the screen is switched back in, nor after
+ mode switches. This is useful when the
+ driver needs to keep track of palette
+ changes.
+
+ </quote>
+
+ The colormap layer normally reloads the palette after VT enters so it
+ is not necessary for the driver to save and restore the palette
+ when switching VTs. The driver must, however, still save the
+ initial palette during server start up and restore it during
+ server exit.
+
+ </quote>
+
+ &s.code;void LoadPalette(ScrnInfoPtr pScrn, int numColors, int *indices,
+ &f.indent;LOCO *colors, VisualPtr pVisual)&e.code;
+ <quote><p>
+ &s.code;LoadPalette()&e.code; is a driver-provided function for
+ loading a colormap into hardware. &s.code;colors&e.code; is the
+ array of RGB values that represent the full colormap.
+ &s.code;indices&e.code; is a list of index values into the colors
+ array. These indices indicate the entries that need to be updated.
+ &s.code;numColors&e.code; is the number of the indices to be
+ updated.
+
+ </quote>
+
+ &s.code;void SetOverscan(ScrnInfoPtr pScrn, int overscan)&e.code;
+ <quote><p>
+ &s.code;SetOverscan()&e.code; is a driver-provided function for
+ programming the &s.code;overscan&e.code; index. As described
+ above, it is normally only appropriate for LUT modes where all
+ colormap entries are available for the display, but where one of
+ them is also used for the overscan (typically 8bpp for VGA compatible
+ LUTs). It isn't required in cases where the overscan area is
+ never visible.
+
+ </quote>
+ </quote>
+
+
+<sect>DPMS Extension
+<p>
+
+Support code for the DPMS extension is included in the XFree86 common layer.
+This code provides an interface between the main extension code, and a means
+for drivers to initialise DPMS when they support it. One function is
+available to drivers to do this initialisation, and it is always available,
+even when the DPMS extension is not supported by the core server (in
+which case it returns a failure result).
+
+
+ <quote><p>
+ &s.code;Bool xf86DPMSInit(ScreenPtr pScreen, DPMSSetProcPtr set, int flags)&e.code;
+ <quote><p>
+ This function registers a driver's DPMS level programming function
+ &s.code;set&e.code;. It also checks
+ &s.code;pScrn->options&e.code; for the "dpms" option, and when
+ present marks DPMS as being enabled for that screen. The
+ &s.code;set&e.code; function is called whenever the DPMS level
+ changes, and is used to program the requested level.
+ &s.code;flags&e.code; is currently not used, and should be
+ &s.code;0&e.code;. If the initialisation fails for any reason,
+ including when there is no DPMS support in the core server, the
+ function returns &s.code;FALSE&e.code;.
+
+ </quote>
+ </quote>
+
+
+Drivers that implement DPMS support must provide the following function,
+that gets called when the DPMS level is changed:
+
+
+ <quote><p>
+ &s.code;void ChipDPMSSet(ScrnInfoPtr pScrn, int level, int flags)&e.code;
+ <quote><p>
+ Program the DPMS level specified by &s.code;level&e.code;. Valid
+ values of &s.code;level&e.code; are &s.code;DPMSModeOn&e.code;,
+ &s.code;DPMSModeStandby&e.code;, &s.code;DPMSModeSuspend&e.code;,
+ &s.code;DPMSModeOff&e.code;. These values are defined in
+ &s.code;"extensions/dpms.h"&e.code;.
+
+ </quote>
+ </quote>
+
+
+<sect>DGA Extension
+<p>
+
+Drivers can support the XFree86 Direct Graphics Architecture (DGA) by
+filling out a structure of function pointers and a list of modes and
+passing them to DGAInit.
+
+ <quote><p>
+ &s.code;Bool DGAInit(ScreenPtr pScreen, DGAFunctionPtr funcs,
+ &f.indent;DGAModePtr modes, int num)&e.code;
+ <quote><p>
+ <verb>
+/** The DGAModeRec **/
+
+typedef struct {
+ int num;
+ DisplayModePtr mode;
+ int flags;
+ int imageWidth;
+ int imageHeight;
+ int pixmapWidth;
+ int pixmapHeight;
+ int bytesPerScanline;
+ int byteOrder;
+ int depth;
+ int bitsPerPixel;
+ unsigned long red_mask;
+ unsigned long green_mask;
+ unsigned long blue_mask;
+ int viewportWidth;
+ int viewportHeight;
+ int xViewportStep;
+ int yViewportStep;
+ int maxViewportX;
+ int maxViewportY;
+ int viewportFlags;
+ int offset;
+ unsigned char *address;
+ int reserved1;
+ int reserved2;
+} DGAModeRec, *DGAModePtr;
+</verb>
+
+ &s.code;num&e.code;
+ <quote>
+ Can be ignored. The DGA DDX will assign these numbers.
+ </quote>
+
+ &s.code;mode&e.code;
+ <quote>
+ A pointer to the &s.code;DisplayModeRec&e.code; for this mode.
+ </quote>
+
+ &s.code;flags&e.code;
+ <quote><p>
+ The following flags are defined and may be OR'd together:
+
+ &s.code;DGA_CONCURRENT_ACCESS&e.code;
+ <quote><p>
+ Indicates that the driver supports concurrent graphics
+ accelerator and linear framebuffer access.
+
+ </quote>
+
+ &s.code;DGA_FILL_RECT&nl;
+ DGA_BLIT_RECT&nl;
+ DGA_BLIT_RECT_TRANS&e.code;
+ <quote><p>
+ Indicates that the driver supports the FillRect, BlitRect
+ or BlitTransRect functions in this mode.
+
+ </quote>
+
+ &s.code;DGA_PIXMAP_AVAILABLE&e.code;
+ <quote><p>
+ Indicates that Xlib may be used on the framebuffer.
+ This flag will usually be set unless the driver wishes
+ to prohibit this for some reason.
+
+ </quote>
+
+ &s.code;DGA_INTERLACED&nl;
+ DGA_DOUBLESCAN&e.code;
+ <quote><p>
+ Indicates that these are interlaced or double scan modes.
+
+ </quote>
+ </quote>
+
+ &s.code;imageWidth&nl;
+ imageHeight&e.code;
+ <quote><p>
+ These are the dimensions of the linear framebuffer
+ accessible by the client.
+
+ </quote>
+
+ &s.code;pixmapWidth&nl;
+ pixmapHeight&e.code;
+ <quote><p>
+ These are the dimensions of the area of the
+ framebuffer accessible by the graphics accelerator.
+
+ </quote>
+
+ &s.code;bytesPerScanline&e.code;
+ <quote><p>
+ Pitch of the framebuffer in bytes.
+
+ </quote>
+
+ &s.code;byteOrder&e.code;
+ <quote><p>
+ Usually the same as
+ &s.code;pScrn->imageByteOrder&e.code;.
+
+ </quote>
+
+ &s.code;depth&e.code;
+ <quote><p>
+ The depth of the framebuffer in this mode.
+
+ </quote>
+
+ &s.code;bitsPerPixel&e.code;
+ <quote><p>
+ The number of bits per pixel in this mode.
+
+ </quote>
+
+ &s.code;red_mask&nl;
+ green_mask&nl;
+ blue_mask&e.code;
+ <quote><p>
+ The RGB masks for this mode, if applicable.
+
+ </quote>
+
+ &s.code;viewportWidth&nl;
+ viewportHeight&e.code;
+ <quote><p>
+ Dimensions of the visible part of the framebuffer.
+ Usually &s.code;mode->HDisplay&e.code; and
+ &s.code;mode->VDisplay&e.code;.
+
+ </quote>
+
+ &s.code;xViewportStep&nl;
+ yViewportStep&e.code;
+ <quote><p>
+ The granularity of x and y viewport positions that
+ the driver supports in this mode.
+
+ </quote>
+
+ &s.code;maxViewportX&nl;
+ maxViewportY&e.code;
+ <quote><p>
+ The maximum viewport position supported by the
+ driver in this mode.
+
+ </quote>
+
+ &s.code;viewportFlags&e.code;
+ <quote><p>
+ The following may be OR'd together:
+
+ &s.code;DGA_FLIP_IMMEDIATE&e.code;
+ <quote><p>
+ The driver supports immediate viewport changes.
+
+ </quote>
+ &s.code;DGA_FLIP_RETRACE&e.code;
+ <quote<p>
+ The driver supports viewport changes at retrace.
+
+ </quote>
+ </quote>
+
+ &s.code;offset&e.code;
+ <quote><p>
+ The offset into the linear framebuffer that corresponds to
+ pixel (0,0) for this mode.
+
+ </quote>
+
+ &s.code;address&e.code;
+ <quote><p>
+ The virtual address of the framebuffer as mapped by the driver.
+ This is needed when DGA_PIXMAP_AVAILABLE is set.
+
+ </quote>
+
+ <verb>
+/** The DGAFunctionRec **/
+
+typedef struct {
+ Bool (*OpenFramebuffer)(
+ ScrnInfoPtr pScrn,
+ char **name,
+ unsigned char **mem,
+ int *size,
+ int *offset,
+ int *extra
+ );
+ void (*CloseFramebuffer)(ScrnInfoPtr pScrn);
+ Bool (*SetMode)(ScrnInfoPtr pScrn, DGAModePtr pMode);
+ void (*SetViewport)(ScrnInfoPtr pScrn, int x, int y, int flags);
+ int (*GetViewport)(ScrnInfoPtr pScrn);
+ void (*Sync)(ScrnInfoPtr);
+ void (*FillRect)(
+ ScrnInfoPtr pScrn,
+ int x, int y, int w, int h,
+ unsigned long color
+ );
+ void (*BlitRect)(
+ ScrnInfoPtr pScrn,
+ int srcx, int srcy,
+ int w, int h,
+ int dstx, int dsty
+ );
+ void (*BlitTransRect)(
+ ScrnInfoPtr pScrn,
+ int srcx, int srcy,
+ int w, int h,
+ int dstx, int dsty,
+ unsigned long color
+ );
+} DGAFunctionRec, *DGAFunctionPtr;
+</verb>
+
+ </quote>
+
+ &s.code;Bool OpenFramebuffer (pScrn, name, mem, size, offset, extra)&e.code;
+ <quote><p>
+ &s.code;OpenFramebuffer()&e.code; should pass the client everything
+ it needs to know to be able to open the framebuffer. These
+ parameters are OS specific and their meanings are to be interpreted
+ by an OS specific client library.
+
+ &s.code;name&e.code;
+ <quote><p>
+ The name of the device to open or &s.code;NULL&e.code; if
+ there is no special device to open. A &s.code;NULL&e.code;
+ name tells the client that it should open whatever device
+ one would usually open to access physical memory.
+
+ </quote>
+ &s.code;mem&e.code;
+ <quote><p>
+ The physical address of the start of the framebuffer.
+
+ </quote>
+ &s.code;size&e.code;
+ <quote><p>
+ The size of the framebuffer in bytes.
+
+ </quote>
+ &s.code;offset&e.code;
+ <quote><p>
+ Any offset into the device, if applicable.
+
+ </quote>
+ &s.code;flags&e.code;
+ <quote><p>
+ Any additional information that the client may need.
+ Currently, only the &s.code;DGA_NEED_ROOT&e.code; flag is
+ defined.
+
+ </quote>
+ </quote>
+
+ &s.code;void CloseFramebuffer (pScrn)&e.code;
+ <quote><p>
+ &s.code;CloseFramebuffer()&e.code; merely informs the driver (if it
+ even cares) that client no longer needs to access the framebuffer
+ directly. This function is optional.
+
+ </quote>
+
+ &s.code;Bool SetMode (pScrn, pMode)&e.code;
+ <quote><p>
+ &s.code;SetMode()&e.code; tells the driver to initialize the mode
+ passed to it. If &s.code;pMode&e.code; is &s.code;NULL&e.code;,
+ then the driver should restore the original pre-DGA mode.
+
+ </quote>
+
+ &s.code;void SetViewport (pScrn, x, y, flags)&e.code;
+ <quote><p>
+ &s.code;SetViewport()&e.code; tells the driver to make the upper
+ left-hand corner of the visible screen correspond to coordinate
+ &s.code;(x,y)&e.code; on the framebuffer. &s.code;Flags&e.code;
+ currently defined are:
+
+ &s.code;DGA_FLIP_IMMEDIATE&e.code;
+ <quote><p>
+ The viewport change should occur immediately.
+
+ </quote>
+ &s.code;DGA_FLIP_RETRACE&e.code;
+ <quote><p>
+ The viewport change should occur at the
+ vertical retrace, but this function should
+ return sooner if possible.
+
+ </quote>
+ The &s.code;(x,y)&e.code; locations will be passed as the client
+ specified them, however, the driver is expected to round these
+ locations down to the next supported location as specified by the
+ &s.code;xViewportStep&e.code; and &s.code;yViewportStep&e.code;
+ for the current mode.
+
+ </quote>
+
+ &s.code;int GetViewport (pScrn)&e.code;
+ <quote><p>
+ &s.code;GetViewport()&e.code; gets the current page flip status.
+ Set bits in the returned int correspond to viewport change requests
+ still pending. For instance, set bit zero if the last SetViewport
+ request is still pending, bit one if the one before that is still
+ pending, etc.
+
+ </quote>
+
+ &s.code;void Sync (pScrn)&e.code;
+ <quote><p>
+ This function should ensure that any graphics accelerator operations
+ have finished. This function should not return until the graphics
+ accelerator is idle.
+
+ </quote>
+
+ &s.code;void FillRect (pScrn, x, y, w, h, color)&e.code;
+ <quote><p>
+ This optional function should fill a rectangle
+ &s.code;w × h&e.code; located at
+ &s.code;(x,y)&e.code; in the given color.
+
+ </quote>
+
+ &s.code;void BlitRect (pScrn, srcx, srcy, w, h, dstx, dsty)&e.code;
+ <quote><p>
+ This optional function should copy an area
+ &s.code;w × h&e.code; located at
+ &s.code;(srcx,srcy)&e.code; to location &s.code;(dstx,dsty)&e.code;.
+ This function will need to handle copy directions as appropriate.
+
+ </quote>
+
+ &s.code;void BlitTransRect (pScrn, srcx, srcy, w, h, dstx, dsty, color)&e.code;
+ <quote><p>
+ This optional function is the same as BlitRect except that pixels
+ in the source corresponding to the color key &s.code;color&e.code;
+ should be skipped.
+
+ </quote>
+ </quote>
+
+<sect>The XFree86 X Video Extension (Xv) Device Dependent Layer
+<p>
+
+XFree86 offers the X Video Extension which allows clients to treat video
+as any another primitive and ``Put'' video into drawables. By default,
+the extension reports no video adaptors as being available since the
+DDX layer has not been initialized. The driver can initialize the DDX
+layer by filling out one or more &s.code;XF86VideoAdaptorRecs&e.code;
+as described later in this document and passing a list of
+&s.code;XF86VideoAdaptorPtr&e.code; pointers to the following function:
+
+ <quote>
+ &s.code;Bool xf86XVScreenInit(
+ &f.indent;ScreenPtr pScreen,
+ &f.indent;XF86VideoAdaptorPtr *adaptPtrs,
+ &f.indent;int num)&e.code;
+ </quote>
+
+After doing this, the extension will report video adaptors as being
+available, providing the data in their respective
+&s.code;XF86VideoAdaptorRecs&e.code; was valid.
+&s.code;xf86XVScreenInit()&e.code; <em>copies</em> data from the structure
+passed to it so the driver may free it after the initialization. At
+the moment, the DDX only supports rendering into Window drawables.
+Pixmap rendering will be supported after a sufficient survey of suitable
+hardware is completed.
+
+The &s.code;XF86VideoAdaptorRec&e.code;:
+
+<quote><p>
+<verb>
+typedef struct {
+ unsigned int type;
+ int flags;
+ char *name;
+ int nEncodings;
+ XF86VideoEncodingPtr pEncodings;
+ int nFormats;
+ XF86VideoFormatPtr pFormats;
+ int nPorts;
+ DevUnion *pPortPrivates;
+ int nAttributes;
+ XF86AttributePtr pAttributes;
+ int nImages;
+ XF86ImagePtr pImages;
+ PutVideoFuncPtr PutVideo;
+ PutStillFuncPtr PutStill;
+ GetVideoFuncPtr GetVideo;
+ GetStillFuncPtr GetStill;
+ StopVideoFuncPtr StopVideo;
+ SetPortAttributeFuncPtr SetPortAttribute;
+ GetPortAttributeFuncPtr GetPortAttribute;
+ QueryBestSizeFuncPtr QueryBestSize;
+ PutImageFuncPtr PutImage;
+ QueryImageAttributesFuncPtr QueryImageAttributes;
+} XF86VideoAdaptorRec, *XF86VideoAdaptorPtr;
+</verb>
+
+ Each adaptor will have its own XF86VideoAdaptorRec. The fields are
+ as follows:
+
+ &s.code;type&e.code;
+ <quote><p>
+ This can be any of the following flags OR'd together.
+
+ &s.code;XvInputMask&e.code;
+ &s.code;XvOutputMask&e.code;
+ <quote><p>
+ These refer to the target drawable and are similar to a Window's
+ class. &s.code;XvInputMask&e.code; indicates that the adaptor
+ can put video into a drawable. &s.code;XvOutputMask&e.code;
+ indicates that the adaptor can get video from a drawable.
+ </quote>
+
+ &s.code;XvVideoMask&e.code;
+ &s.code;XvStillMask&e.code;
+ &s.code;XvImageMask&e.code;
+ <quote><p>
+ These indicate that the adaptor supports video, still or
+ image primitives respectively.
+ </quote>
+
+ &s.code;XvWindowMask&e.code;
+ &s.code;XvPixmapMask&e.code;
+ <quote><p>
+ These indicate the types of drawables the adaptor is capable
+ of rendering into. At the moment, Pixmap rendering is not
+ supported and the &s.code;XvPixmapMask&e.code; flag is ignored.
+ </quote>
+
+ </quote>
+
+ &s.code;flags&e.code;
+ <quote><p>
+ Currently, the following flags are defined:
+
+ &s.code;VIDEO_NO_CLIPPING&e.code;
+ <quote><p>
+ This indicates that the video adaptor does not support
+ clipping. The driver will never receive ``Put'' requests
+ where less than the entire area determined by
+ &s.code;drw_x&e.code;, &s.code;drw_y&e.code;,
+ &s.code;drw_w&e.code; and &s.code;drw_h&e.code; is visible.
+ This flag does not apply to ``Get'' requests. Hardware
+ that is incapable of clipping ``Gets'' may punt or get
+ the extents of the clipping region passed to it.
+
+ </quote>
+
+ &s.code;VIDEO_INVERT_CLIPLIST&e.code;
+ <quote><p>
+ This indicates that the video driver requires the clip
+ list to contain the regions which are obscured rather
+ than the regions which are are visible.
+
+ </quote>
+
+ &s.code;VIDEO_OVERLAID_STILLS&e.code;
+ <quote><p>
+ Implementing PutStill for hardware that does video as an
+ overlay can be awkward since it's unclear how long to leave
+ the video up for. When this flag is set, StopVideo will be
+ called whenever the destination gets clipped or moved so that
+ the still can be left up until then.
+
+ </quote>
+
+ &s.code;VIDEO_OVERLAID_IMAGES&e.code;
+ <quote><p>
+ Same as &s.code;VIDEO_OVERLAID_STILLS&e.code; but for images.
+ </quote>
+
+ &s.code;VIDEO_CLIP_TO_VIEWPORT&e.code;
+ <quote><p>
+ Indicates that the clip region passed to the driver functions
+ should be clipped to the visible portion of the screen in the
+ case where the viewport is smaller than the virtual desktop.
+ </quote>
+
+ </quote>
+
+ &s.code;name&e.code;
+ <quote><p>
+ The name of the adaptor.
+
+ </quote>
+
+ &s.code;nEncodings&nl;
+ pEncodings&e.code;
+ <quote><p>
+ The number of encodings the adaptor is capable of and pointer
+ to the &s.code;XF86VideoEncodingRec&e.code; array. The
+ &s.code;XF86VideoEncodingRec&e.code; is described later on.
+ For drivers that only support XvImages there should be an encoding
+ named "XV_IMAGE" and the width and height should specify
+ the maximum size source image supported.
+
+ </quote>
+
+ &s.code;nFormats&nl;
+ pFormats&e.code;
+ <quote><p>
+ The number of formats the adaptor is capable of and pointer to
+ the &s.code;XF86VideoFormatRec&e.code; array. The
+ &s.code;XF86VideoFormatRec&e.code; is described later on.
+
+ </quote>
+
+ &s.code;nPorts&nl;
+ pPortPrivates&e.code;
+ <quote><p>
+ The number of ports is the number of separate data streams which
+ the adaptor can handle simultaneously. If you have more than
+ one port, the adaptor is expected to be able to render into more
+ than one window at a time. &s.code;pPortPrivates&e.code; is
+ an array of pointers or ints - one for each port. A port's
+ private data will be passed to the driver any time the port is
+ requested to do something like put the video or stop the video.
+ In the case where there may be many ports, this enables the
+ driver to know which port the request is intended for. Most
+ commonly, this will contain a pointer to the data structure
+ containing information about the port. In Xv, all ports on
+ a particular adaptor are expected to be identical in their
+ functionality.
+
+ </quote>
+
+ &s.code;nAttributes&nl;
+ pAttributes&e.code;
+ <quote><p>
+ The number of attributes recognized by the adaptor and a pointer to
+ the array of &s.code;XF86AttributeRecs&e.code;. The
+ &s.code;XF86AttributeRec&e.code; is described later on.
+
+ </quote>
+
+ &s.code;nImages&nl;
+ pImages&e.code;
+ <quote><p>
+ The number of &s.code;XF86ImageRecs&e.code; supported by the adaptor
+ and a pointer to the array of &s.code;XF86ImageRecs&e.code;. The
+ &s.code;XF86ImageRec&e.code; is described later on.
+
+ </quote>
+
+
+ &s.code;PutVideo PutStill GetVideo GetStill StopVideo
+ SetPortAttribute GetPortAttribute QueryBestSize PutImage
+ QueryImageAttributes&e.code;
+ <quote><p>
+ These functions define the DDX->driver interface. In each
+ case, the pointer &s.code;data&e.code; is passed to the driver.
+ This is the port private for that port as described above. All
+ fields are required except under the following conditions:
+
+ <enum>
+ <item>&s.code;PutVideo&e.code;, &s.code;PutStill&e.code; and
+ the image routines &s.code;PutImage&e.code; and
+ &s.code;QueryImageAttributes&e.code; are not required when the
+ adaptor type does not contain &s.code;XvInputMask&e.code;.
+
+ <item>&s.code;GetVideo&e.code; and &s.code;GetStill&e.code;
+ are not required when the adaptor type does not contain
+ &s.code;XvOutputMask&e.code;.
+
+ <item>&s.code;GetVideo&e.code; and &s.code;PutVideo&e.code;
+ are not required when the adaptor type does not contain
+ &s.code;XvVideoMask&e.code;.
+
+ <item>&s.code;GetStill&e.code; and &s.code;PutStill&e.code;
+ are not required when the adaptor type does not contain
+ &s.code;XvStillMask&e.code;.
+
+ <item>&s.code;PutImage&e.code; and &s.code;QueryImageAttributes&e.code;
+ are not required when the adaptor type does not contain
+ &s.code;XvImageMask&e.code;.
+
+ </enum>
+
+ With the exception of &s.code;QueryImageAttributes&e.code;, these
+ functions should return &s.code;Success&e.code; if the operation was
+ completed successfully. They can return &s.code;XvBadAlloc&e.code;
+ otherwise. &s.code;QueryImageAttributes&e.code; returns the size
+ of the XvImage queried.
+
+ If the &s.code;VIDEO_NO_CLIPPING&e.code;
+ flag is set, the &s.code;clipBoxes&e.code; may be ignored by
+ the driver. &s.code;ClipBoxes&e.code; is an &s.code;X-Y&e.code;
+ banded region identical to those used throughout the server.
+ The clipBoxes represent the visible portions of the area determined
+ by &s.code;drw_x&e.code;, &s.code;drw_y&e.code;,
+ &s.code;drw_w&e.code; and &s.code;drw_h&e.code; in the Get/Put
+ function. The boxes are in screen coordinates, are guaranteed
+ not to overlap and an empty region will never be passed.
+ If the driver has specified &s.code;VIDEO_INVERT_CLIPLIST&e.code;,
+ &s.code;clipBoxes&e.code; will indicate the areas of the primitive
+ which are obscured rather than the areas visible.
+
+ </quote>
+
+ &s.code;typedef int (* PutVideoFuncPtr)( ScrnInfoPtr pScrn,
+ &f.indent;short vid_x, short vid_y, short drw_x, short drw_y,
+ &f.indent;short vid_w, short vid_h, short drw_w, short drw_h,
+ &f.indent;RegionPtr clipBoxes, pointer data )&e.code;
+ <quote><p>
+ This indicates that the driver should take a subsection
+ &s.code;vid_w&e.code; by &s.code;vid_h&e.code; at location
+ &s.code;(vid_x,vid_y)&e.code; from the video stream and direct
+ it into the rectangle &s.code;drw_w&e.code; by &s.code;drw_h&e.code;
+ at location &s.code;(drw_x,drw_y)&e.code; on the screen, scaling as
+ necessary. Due to the large variations in capabilities of
+ the various hardware expected to be used with this extension,
+ it is not expected that all hardware will be able to do this
+ exactly as described. In that case the driver should just do
+ ``the best it can,'' scaling as closely to the target rectangle
+ as it can without rendering outside of it. In the worst case,
+ the driver can opt to just not turn on the video.
+
+ </quote>
+
+ &s.code;typedef int (* PutStillFuncPtr)( ScrnInfoPtr pScrn,
+ &f.indent;short vid_x, short vid_y, short drw_x, short drw_y,
+ &f.indent;short vid_w, short vid_h, short drw_w, short drw_h,
+ &f.indent;RegionPtr clipBoxes, pointer data )&e.code;
+ <quote><p>
+ This is same as &s.code;PutVideo&e.code; except that the driver
+ should place only one frame from the stream on the screen.
+
+ </quote>
+
+ &s.code;typedef int (* GetVideoFuncPtr)( ScrnInfoPtr pScrn,
+ &f.indent;short vid_x, short vid_y, short drw_x, short drw_y,
+ &f.indent;short vid_w, short vid_h, short drw_w, short drw_h,
+ &f.indent;RegionPtr clipBoxes, pointer data )&e.code;
+ <quote><p>
+ This is same as &s.code;PutVideo&e.code; except that the driver
+ gets video from the screen and outputs it. The driver should
+ do the best it can to get the requested dimensions correct
+ without reading from an area larger than requested.
+
+ </quote>
+
+ &s.code;typedef int (* GetStillFuncPtr)( ScrnInfoPtr pScrn,
+ &f.indent;short vid_x, short vid_y, short drw_x, short drw_y,
+ &f.indent;short vid_w, short vid_h, short drw_w, short drw_h,
+ &f.indent;RegionPtr clipBoxes, pointer data )&e.code;
+ <quote><p>
+ This is the same as &s.code;GetVideo&e.code; except that the
+ driver should place only one frame from the screen into the
+ output stream.
+
+ </quote>
+
+ &s.code;typedef void (* StopVideoFuncPtr)(ScrnInfoPtr pScrn,
+ &f.indent;pointer data, Bool cleanup)&e.code;
+ <quote><p>
+ This indicates the driver should stop displaying the video.
+ This is used to stop both input and output video. The
+ &s.code;cleanup&e.code; field indicates that the video is
+ being stopped because the client requested it to stop or
+ because the server is exiting the current VT. In that case
+ the driver should deallocate any offscreen memory areas (if
+ there are any) being used to put the video to the screen. If
+ &s.code;cleanup&e.code; is not set, the video is being stopped
+ temporarily due to clipping or moving of the window, etc...
+ and video will likely be restarted soon so the driver should
+ not deallocate any offscreen areas associated with that port.
+
+ </quote>
+ &s.code;typedef int (* SetPortAttributeFuncPtr)(ScrnInfoPtr pScrn,
+ &f.indent;Atom attribute,INT32 value, pointer data)&e.code;
+
+ &s.code;typedef int (* GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn,
+ &f.indent;Atom attribute,INT32 *value, pointer data)&e.code;
+
+ <quote><p>
+ A port may have particular attributes such as hue,
+ saturation, brightness or contrast. Xv clients set and
+ get these attribute values by sending attribute strings
+ (Atoms) to the server. Such requests end up at these
+ driver functions. It is recommended that the driver provide
+ at least the following attributes mentioned in the Xv client
+ library docs:
+ <quote>
+ &s.code;XV_ENCODING&nl;
+ XV_HUE&nl;
+ XV_SATURATION&nl;
+ XV_BRIGHTNESS&nl;
+ XV_CONTRAST&e.code;
+ </quote>
+ but the driver may recognize as many atoms as it wishes. If
+ a requested attribute is unknown by the driver it should return
+ &s.code;BadMatch&e.code;. &s.code;XV_ENCODING&e.code; is the
+ attribute intended to let the client specify which video
+ encoding the particular port should be using (see the description
+ of &s.code;XF86VideoEncodingRec&e.code; below). If the
+ requested encoding is unsupported, the driver should return
+ &s.code;XvBadEncoding&e.code;. If the value lies outside the
+ advertised range &s.code;BadValue&e.code; may be returned.
+ &s.code;Success&e.code; should be returned otherwise.
+
+ </quote>
+
+ &s.code;typedef void (* QueryBestSizeFuncPtr)(ScrnInfoPtr pScrn,
+ &f.indent;Bool motion, short vid_w, short vid_h,
+ &f.indent;short drw_w, short drw_h,
+ &f.indent;unsigned int *p_w, unsigned int *p_h, pointer data)&e.code;
+ <quote><p>
+ &s.code;QueryBestSize&e.code; provides the client with a way
+ to query what the destination dimensions would end up being
+ if they were to request that an area
+ &s.code;vid_w&e.code by &s.code;vid_h&e.code; from the video
+ stream be scaled to rectangle of
+ &s.code;drw_w&e.code; by &s.code;drw_h&e.code; on the screen.
+ Since it is not expected that all hardware will be able to
+ get the target dimensions exactly, it is important that the
+ driver provide this function.
+
+ </quote>
+
+ &s.code;typedef int (* PutImageFuncPtr)( ScrnInfoPtr pScrn,
+ &f.indent;short src_x, short src_y, short drw_x, short drw_y,
+ &f.indent;short src_w, short src_h, short drw_w, short drw_h,
+ &f.indent;int image, char *buf, short width, short height,
+ &f.indent;Bool sync, RegionPtr clipBoxes, pointer data )&e.code;
+ <quote><p>
+ This is similar to &s.code;PutStill&e.code; except that the
+ source of the video is not a port but the data stored in a system
+ memory buffer at &s.code;buf&e.code;. The data is in the format
+ indicated by the &s.code;image&e.code; descriptor and represents a
+ source of size &s.code;width&e.code; by &s.code;height&e.code;.
+ If &s.code;sync&e.code; is TRUE the driver should not return
+ from this function until it is through reading the data
+ from &s.code;buf&e.code;. Returning when &s.code;sync&e.code;
+ is TRUE indicates that it is safe for the data at &s.code;buf&e.code;
+ to be replaced, freed, or modified.
+
+ </quote>
+
+ &s.code;typedef int (* QueryImageAttributesFuncPtr)( ScrnInfoPtr pScrn,
+ &f.indent;int image, short *width, short *height,
+ &f.indent;int *pitches, int *offsets)&e.code;
+ <quote><p>
+ This function is called to let the driver specify how data for
+ a particular &s.code;image&e.code; of size &s.code;width&e.code;
+ by &s.code;height&e.code; should be stored. Sometimes only
+ the size and corrected width and height are needed. In that
+ case &s.code;pitches&e.code; and &s.code;offsets&e.code; are
+ NULL. The size of the memory required for the image is returned
+ by this function. The &s.code;width&e.code; and
+ &s.code;height&e.code; of the requested image can be altered by
+ the driver to reflect format limitations (such as component
+ sampling periods that are larger than one). If
+ &s.code;pitches&e.code; and &s.code;offsets&e.code; are not NULL,
+ these will be arrays with as many elements in them as there
+ are planes in the &s.code;image&e.code; format. The driver
+ should specify the pitch (in bytes) of each scanline in the
+ particular plane as well as the offset to that plane (in bytes)
+ from the beginning of the image.
+
+ </quote>
+
+ </quote>
+
+The XF86VideoEncodingRec:
+<quote><p>
+<verb>
+typedef struct {
+ int id;
+ char *name;
+ unsigned short width, height;
+ XvRationalRec rate;
+} XF86VideoEncodingRec, *XF86VideoEncodingPtr;
+
+</verb>
+ The &s.code;XF86VideoEncodingRec&e.code; specifies what encodings
+ the adaptor can support. Most of this data is just informational
+ and for the client's benefit, and is what will be reported by
+ &s.code;XvQueryEncodings&e.code;. The &s.code;id&e.code; field is
+ expected to be a unique identifier to allow the client to request a
+ certain encoding via the &s.code;XV_ENCODING&e.code; attribute string.
+
+</quote>
+
+The XF86VideoFormatRec:
+
+<quote><p>
+<verb>
+typedef struct {
+ char depth;
+ short class;
+} XF86VideoFormatRec, *XF86VideoFormatPtr;
+</verb>
+
+ This specifies what visuals the video is viewable in.
+ &s.code;depth&e.code; is the depth of the visual (not bpp).
+ &s.code;class&e.code; is the visual class such as
+ &s.code;TrueColor&e.code;, &s.code;DirectColor&e.code; or
+ &s.code;PseudoColor&e.code;. Initialization of an adaptor will fail
+ if none of the visuals on that screen are supported.
+
+</quote>
+
+The XF86AttributeRec:
+
+<quote><p>
+<verb>
+typedef struct {
+ int flags;
+ int min_value;
+ int max_value;
+ char *name;
+} XF86AttributeListRec, *XF86AttributeListPtr;
+
+</verb>
+
+ Each adaptor may have an array of these advertising the attributes
+ for its ports. Currently defined flags are &s.code;XvGettable&e.code;
+ and &s.code;XvSettable&e.code; which may be OR'd together indicating that
+ attribute is ``gettable'' or ``settable'' by the client. The
+ &s.code;min&e.code; and &s.code;max&e.code; field specify the valid range
+ for the value. &s.code;Name&e.code; is a text string describing the
+ attribute by name.
+
+</quote>
+
+The XF86ImageRec:
+
+<quote><p>
+<verb>
+typedef struct {
+ int id;
+ int type;
+ int byte_order;
+ char guid[16];
+ int bits_per_pixel;
+ int format;
+ int num_planes;
+
+ /* for RGB formats */
+ int depth;
+ unsigned int red_mask;
+ unsigned int green_mask;
+ unsigned int blue_mask;
+
+ /* for YUV formats */
+ unsigned int y_sample_bits;
+ unsigned int u_sample_bits;
+ unsigned int v_sample_bits;
+ unsigned int horz_y_period;
+ unsigned int horz_u_period;
+ unsigned int horz_v_period;
+ unsigned int vert_y_period;
+ unsigned int vert_u_period;
+ unsigned int vert_v_period;
+ char component_order[32];
+ int scanline_order;
+} XF86ImageRec, *XF86ImagePtr;
+</verb>
+
+ XF86ImageRec describes how video source data is laid out in memory.
+ The fields are as follows:
+
+ &s.code;id&e.code;
+ <quote><p>
+ This is a unique descriptor for the format. It is often good to
+ set this value to the FOURCC for the format when applicable.
+ </quote>
+
+ &s.code;type&e.code;
+ <quote><p>
+ This is &s.code;XvRGB&e.code; or &s.code;XvYUV&e.code;.
+ </quote>
+
+ &s.code;byte_order&e.code;
+ <quote><p>
+ This is &s.code;LSBFirst&e.code; or &s.code;MSBFirst&e.code;.
+ </quote>
+
+ &s.code;guid&e.code;
+ <quote><p>
+ This is the Globally Unique IDentifier for the format. When
+ not applicable, all characters should be NULL.
+ </quote>
+
+ &s.code;bits_per_pixel&e.code;
+ <quote><p>
+ The number of bits taken up (but not necessarily used) by each
+ pixel. Note that for some planar formats which have fractional
+ bits per pixel (such as IF09) this number may be rounded _down_.
+ </quote>
+
+ &s.code;format&e.code;
+ <quote><p>
+ This is &s.code;XvPlanar&e.code; or &s.code;XvPacked&e.code;.
+ </quote>
+
+ &s.code;num_planes&e.code;
+ <quote><p>
+ The number of planes in planar formats. This should be set to
+ one for packed formats.
+ </quote>
+
+ &s.code;depth&e.code;
+ <quote><p>
+ The significant bits per pixel in RGB formats (analgous to the
+ depth of a pixmap format).
+ </quote>
+
+ &s.code;red_mask&e.code;
+ &s.code;green_mask&e.code;
+ &s.code;blue_mask&e.code;
+ <quote><p>
+ The red, green and blue bitmasks for packed RGB formats.
+ </quote>
+
+ &s.code;y_sample_bits&e.code;
+ &s.code;u_sample_bits&e.code;
+ &s.code;v_sample_bits&e.code;
+ <quote><p>
+ The y, u and v sample sizes (in bits).
+ </quote>
+
+ &s.code;horz_y_period&e.code;
+ &s.code;horz_u_period&e.code;
+ &s.code;horz_v_period&e.code;
+ <quote><p>
+ The y, u and v sampling periods in the horizontal direction.
+ </quote>
+
+ &s.code;vert_y_period&e.code;
+ &s.code;vert_u_period&e.code;
+ &s.code;vert_v_period&e.code;
+ <quote><p>
+ The y, u and v sampling periods in the vertical direction.
+ </quote>
+
+ &s.code;component_order&e.code;
+ <quote><p>
+ Uppercase ascii characters representing the order that
+ samples are stored within packed formats. For planar formats
+ this represents the ordering of the planes. Unused characters
+ in the 32 byte string should be set to NULL.
+ </quote>
+
+ &s.code;scanline_order&e.code;
+ <quote><p>
+ This is &s.code;XvTopToBottom&e.code; or &s.code;XvBottomToTop&e.code;.
+ </quote>
+
+ Since some formats (particular some planar YUV formats) may not
+be completely defined by the parameters above, the guid, when
+available, should provide the most accurate description of the
+format.
+
+</quote>
+
+<sect>The Loader
+<p>
+
+This section describes the interfaces to the module loader. The loader
+interfaces can be divided into two groups: those that are only available to
+the XFree86 common layer, and those that are also available to modules.
+
+<sect1>Loader Overview
+<p>
+
+The loader is capable of loading modules in a range of object formats,
+and knowledge of these formats is built in to the loader. Knowledge of
+new object formats can be added to the loader in a straightforward
+manner. This makes it possible to provide OS-independent modules (for
+a given CPU architecture type). In addition to this, the loader can
+load modules via the OS-provided &s.code;dlopen(3)&e.code; service where
+available. Such modules are not platform independent, and the semantics
+of &s.code;dlopen()&e.code; on most systems results in significant
+limitations in the use of modules of this type. Support for
+&s.code;dlopen()&e.code; modules in the loader is primarily for
+experimental and development purposes.
+
+Symbols exported by the loader (on behalf of the core X server) to
+modules are determined at compile time. Only those symbols explicitly
+exported are available to modules. All external symbols of loaded
+modules are exported to other modules, and to the core X server. The
+loader can be requested to check for unresolved symbols at any time,
+and the action to be taken for unresolved symbols can be controlled by
+the caller of the loader. Typically the caller identifies which symbols
+can safely remain unresolved and which cannot.
+
+NOTE: Now that ISO-C allows pointers to functions and pointers to data to
+have different internal representations, some of the following interfaces
+will need to be revisited.
+
+<sect1>Semi-private Loader Interface
+<p>
+
+The following is the semi-private loader interface that is available to the
+XFree86 common layer.
+
+ <quote><p>
+ &s.code;void LoaderInit(void)&e.code;
+ <quote><p>
+ The &s.code;LoaderInit()&e.code; function initialises the loader,
+ and it must be called once before calling any other loader functions.
+ This function initialises the tables of exported symbols, and anything
+ else that might need to be initialised.
+
+ </quote>
+
+ &s.code;void LoaderSetPath(const char *path)&e.code;
+ <quote><p>
+ The &s.code;LoaderSetPath()&e.code; function initialises a default
+ module search path. This must be called if calls to other functions
+ are to be made without explicitly specifying a module search path.
+ The search path &s.code;path&e.code; must be a string of one or more
+ comma separated absolute paths. Modules are expected to be located
+ below these paths, possibly in subdirectories of these paths.
+
+ </quote>
+
+ &s.code;pointer LoadModule(const char *module, const char *path,
+ &f.indent;const char **subdirlist, const char **patternlist,
+ &f.indent;pointer options, const XF86ModReqInfo * modreq,
+ &f.indent;int *errmaj, int *errmin)&e.code;
+ <quote><p>
+ The &s.code;LoadModule()&e.code; function loads the module called
+ &s.code;module&e.code;. The return value is a module handle, and
+ may be used in future calls to the loader that require a reference
+ to a loaded module. The module name &s.code;module&e.code; is
+ normally the module's canonical name, which doesn't contain any
+ directory path information, or any object/library file prefixes of
+ suffixes. Currently a full pathname and/or filename is also accepted.
+ This might change. The other parameters are:
+
+ &s.code;path&e.code;
+ <quote><p>
+ An optional comma-separated list of module search paths.
+ When &s.code;NULL&e.code;, the default search path is used.
+
+ </quote>
+
+ &s.code;subdirlist&e.code;
+ <quote><p>
+ An optional &s.code;NULL&e.code; terminated list of
+ subdirectories to search. When &s.code;NULL&e.code;,
+ the default built-in list is used (refer to
+ &s.code;stdSubdirs&e.code; in &s.code;loadmod.c&e.code;).
+ The default list is also substituted for entries in
+ &s.code;subdirlist&e.code; with the value
+ &s.code;DEFAULT_LIST&e.code;. This makes is possible
+ to augment the default list instead of replacing it.
+ Subdir elements must be relative, and must not contain
+ &s.code;".."&e.code;. If any violate this requirement,
+ the load fails.
+
+ </quote>
+
+ &s.code;patternlist&e.code;
+ <quote><p>
+ An optional &s.code;NULL&e.code; terminated list of
+ POSIX regular expressions used to connect module
+ filenames with canonical module names. Each regex
+ should contain exactly one subexpression that corresponds
+ to the canonical module name. When &s.code;NULL&e.code;,
+ the default built-in list is used (refer to
+ &s.code;stdPatterns&e.code; in
+ &s.code;loadmod.c&e.code;). The default list is also
+ substituted for entries in &s.code;patternlist&e.code;
+ with the value &s.code;DEFAULT_LIST&e.code;. This
+ makes it possible to augment the default list instead
+ of replacing it.
+
+ </quote>
+
+ &s.code;options&e.code;
+ <quote><p>
+ An optional parameter that is passed to the newly
+ loaded module's &s.code;SetupProc&e.code; function
+ (if it has one). This argument is normally a
+ &s.code;NULL&e.code; terminated list of
+ &s.code;Options&e.code;, and must be interpreted that
+ way by modules loaded directly by the XFree86 common
+ layer. However, it may be used for application-specific
+ parameter passing in other situations.
+
+ When loading ``external'' modules (modules that don't
+ have the standard entry point, for example a
+ special shared library) the options parameter can be
+ set to &s.code;EXTERN_MODULE&e.code; to tell the
+ loader not to reject the module when it doesn't find
+ the standard entry point.
+
+ </quote>
+
+ &s.code;modreq&e.code;
+ <quote><p>
+ An optional &s.code;XF86ModReqInfo*&e.code; containing
+ version/ABI/vendor information to requirements to
+ check the newly loaded module against. The main
+ purpose of this is to allow the loader to verify that
+ a module of the correct type/version before running
+ its &s.code;SetupProc&e.code; function.
+
+ The &s.code;XF86ModReqInfo&e.code; struct is defined
+ as follows:
+<verb>
+typedef struct {
+ CARD8 majorversion; /* MAJOR_UNSPEC */
+ CARD8 minorversion; /* MINOR_UNSPEC */
+ CARD16 patchlevel; /* PATCH_UNSPEC */
+ const char * abiclass; /* ABI_CLASS_NONE */
+ CARD32 abiversion; /* ABI_VERS_UNSPEC */
+ const char * moduleclass; /* MOD_CLASS_NONE */
+} XF86ModReqInfo;
+</verb>
+
+ The information here is compared against the equivalent
+ information in the module's
+ &s.code;XF86ModuleVersionInfo&e.code; record (which
+ is described below). The values in comments above
+ indicate ``don't care'' settings for each of the fields.
+ The comparisons made are as follows:
+
+ &s.code;majorversion&e.code;
+ <quote><p>
+ Must match the module's majorversion
+ exactly.
+
+ </quote>
+ &s.code;minorversion&e.code;
+ <quote><p>
+ The module's minor version must be
+ no less than this value. This
+ comparison is only made if
+ &s.code;majorversion&e.code; is
+ specified and matches.
+
+ </quote>
+ &s.code;patchlevel&e.code;
+ <quote><p>
+ The module's patchlevel must be no
+ less than this value. This comparison
+ is only made if
+ &s.code;minorversion&e.code; is
+ specified and matches.
+
+ </quote>
+ &s.code;abiclass&e.code;
+ <quote><p>
+ String must match the module's abiclass
+ string.
+
+ </quote>
+ &s.code;abiversion&e.code;
+ <quote><p>
+ Must be consistent with the module's
+ abiversion (major equal, minor no
+ older).
+
+ </quote>
+ &s.code;moduleclass&e.code;
+ <quote><p>
+ String must match the module's
+ moduleclass string.
+
+ </quote>
+
+ </quote>
+
+ &s.code;errmaj&e.code;
+ <quote><p>
+ An optional pointer to a variable holding the major
+ part or the error code. When provided,
+ &s.code;*errmaj&e.code; is filled in when
+ &s.code;LoadModule()&e.code; fails.
+
+ </quote>
+
+ &s.code;errmin&e.code;
+ <quote><p>
+ Like &s.code;errmaj&e.code;, but for the minor part
+ of the error code.
+
+ </quote>
+
+ </quote>
+
+ &s.code;void UnloadModule(pointer mod)&e.code;
+ <quote><p>
+ This function unloads the module referred to by the handle mod.
+ All child modules are also unloaded recursively. This function must
+ not be used to directly unload modules that are child modules (i.e.,
+ those that have been loaded with the &s.code;LoadSubModule()&e.code;
+ described below).
+
+ </quote>
+ </quote>
+
+<sect1>Module Requirements
+<p>
+
+Modules must provide information about themselves to the loader, and
+may optionally provide entry points for "setup" and "teardown" functions
+(those two functions are referred to here as &s.code;SetupProc&e.code;
+and &s.code;TearDownProc&e.code;).
+
+The module information is contained in the
+&s.code;XF86ModuleVersionInfo&e.code; struct, which is defined as follows:
+
+<quote><p><verb>
+typedef struct {
+ const char * modname; /* name of module, e.g. "foo" */
+ const char * vendor; /* vendor specific string */
+ CARD32 _modinfo1_; /* constant MODINFOSTRING1/2 to find */
+ CARD32 _modinfo2_; /* infoarea with a binary editor/sign tool */
+ CARD32 xf86version; /* contains XF86_VERSION_CURRENT */
+ CARD8 majorversion; /* module-specific major version */
+ CARD8 minorversion; /* module-specific minor version */
+ CARD16 patchlevel; /* module-specific patch level */
+ const char * abiclass; /* ABI class that the module uses */
+ CARD32 abiversion; /* ABI version */
+ const char * moduleclass; /* module class */
+ CARD32 checksum[4]; /* contains a digital signature of the */
+ /* version info structure */
+} XF86ModuleVersionInfo;
+</verb>
+
+The fields are used as follows:
+
+ &s.code;modname&e.code;
+ <quote><p>
+ The module's name. This field is currently only for
+ informational purposes, but the loader may be modified
+ in future to require it to match the module's canonical
+ name.
+
+ </quote>
+
+ &s.code;vendor&e.code;
+ <quote><p>
+ The module vendor. This field is for informational purposes
+ only.
+
+ </quote>
+
+ &s.code;_modinfo1_&e.code;
+ <quote><p>
+ This field holds the first part of a signature that can
+ be used to locate this structure in the binary. It should
+ always be initialised to &s.code;MODINFOSTRING1&e.code;.
+
+ </quote>
+
+ &s.code;_modinfo2_&e.code;
+ <quote><p>
+ This field holds the second part of a signature that can
+ be used to locate this structure in the binary. It should
+ always be initialised to &s.code;MODINFOSTRING2&e.code;.
+
+ </quote>
+
+ &s.code;xf86version&e.code;
+ <quote><p>
+ The XFree86 version against which the module was compiled.
+ This is mostly for informational/diagnostic purposes. It
+ should be initialised to &s.code;XF86_VERSION_CURRENT&e.code;, which is
+ defined in &s.code;xf86Version.h&e.code;.
+
+ </quote>
+
+ &s.code;majorversion&e.code;
+ <quote><p>
+ The module-specific major version. For modules where this
+ version is used for more than simply informational
+ purposes, the major version should only change (be
+ incremented) when ABI incompatibilities are introduced,
+ or ABI components are removed.
+
+ </quote>
+
+ &s.code;minorversion&e.code;
+ <quote><p>
+ The module-specific minor version. For modules where this
+ version is used for more than simply informational
+ purposes, the minor version should only change (be
+ incremented) when ABI additions are made in a backward
+ compatible way. It should be reset to zero when the major
+ version is increased.
+
+ </quote>
+
+ &s.code;patchlevel&e.code;
+ <quote><p>
+ The module-specific patch level. The patch level should
+ increase with new revisions of the module where there
+ are no ABI changes, and it should be reset to zero when
+ the minor version is increased.
+
+ </quote>
+
+ &s.code;abiclass&e.code;
+ <quote><p>
+ The ABI class that the module requires. The class is
+ specified as a string for easy extensibility. It should
+ indicate which (if any) of the X server's built-in ABI
+ classes that the module relies on, or a third-party ABI
+ if appropriate. Built-in ABI classes currently defined are:
+
+ <quote>
+ &s.code;ABI_CLASS_NONE&e.code;
+ <quote>no class</quote>
+ &s.code;ABI_CLASS_ANSIC&e.code;
+ <quote>only requires the ANSI C interfaces</quote>
+ &s.code;ABI_CLASS_VIDEODRV&e.code;
+ <quote>requires the video driver ABI</quote>
+ &s.code;ABI_CLASS_XINPUT&e.code;
+ <quote>requires the XInput driver ABI</quote>
+ &s.code;ABI_CLASS_EXTENSION&e.code;
+ <quote>requires the extension module ABI</quote>
+ &s.code;ABI_CLASS_FONT&e.code;
+ <quote>requires the font module ABI</quote>
+ </quote>
+
+ </quote>
+
+ &s.code;abiversion&e.code;
+ <quote><p>
+ The version of abiclass that the module requires. The
+ version consists of major and minor components. The
+ major version must match and the minor version must be
+ no newer than that provided by the server or parent
+ module. Version identifiers for the built-in classes
+ currently defined are:
+
+ <quote>
+ &s.code;ABI_ANSIC_VERSION&nl;
+ ABI_VIDEODRV_VERSION&nl;
+ ABI_XINPUT_VERSION&nl;
+ ABI_EXTENSION_VERSION&nl;
+ ABI_FONT_VERSION&e.code;
+ </quote>
+
+ </quote>
+
+ &s.code;moduleclass&e.code;
+ <quote><p>
+ This is similar to the abiclass field, except that it
+ defines the type of module rather than the ABI it
+ requires. For example, although all video drivers require
+ the video driver ABI, not all modules that require the
+ video driver ABI are video drivers. This distinction
+ can be made with the moduleclass. Currently pre-defined
+ module classes are:
+
+ <quote>
+ &s.code;MOD_CLASS_NONE&nl;
+ MOD_CLASS_VIDEODRV&nl;
+ MOD_CLASS_XINPUT&nl;
+ MOD_CLASS_FONT&nl;
+ MOD_CLASS_EXTENSION&e.code;
+ </quote>
+
+ </quote>
+
+ &s.code;checksum&e.code;
+ <quote><p>
+ Not currently used.
+
+ </quote>
+
+</quote>
+
+The module version information, and the optional &s.code;SetupProc&e.code;
+and &s.code;TearDownProc&e.code; entry points are found by the loader
+by locating a data object in the module called "modnameModuleData",
+where "modname" is the canonical name of the module. Modules must
+contain such a data object, and it must be declared with global scope,
+be compile-time initialised, and is of the following type:
+
+<quote>
+<verb>
+typedef struct {
+ XF86ModuleVersionInfo * vers;
+ ModuleSetupProc setup;
+ ModuleTearDownProc teardown;
+} XF86ModuleData;
+</verb>
+</quote>
+
+The vers parameter must be initialised to a pointer to a correctly
+initialised &s.code;XF86ModuleVersionInfo&e.code; struct. The other
+two parameter are optional, and should be initialised to
+&s.code;NULL&e.code; when not required. The other parameters are defined
+as
+
+ <quote><p>
+ &s.code;typedef pointer (*ModuleSetupProc)(pointer, pointer, int *, int *)&e.code;
+
+ &s.code;typedef void (*ModuleTearDownProc)(pointer)&e.code;
+
+
+ &s.code;pointer SetupProc(pointer module, pointer options,
+ &f.indent;int *errmaj, int *errmin)&e.code;
+ <quote><p>
+ When defined, this function is called by the loader after successfully
+ loading a module. module is a handle for the newly loaded module,
+ and maybe used by the &s.code;SetupProc&e.code; if it calls other
+ loader functions that require a reference to it. The remaining
+ arguments are those that were passed to the
+ &s.code;LoadModule()&e.code; (or &s.code;LoadSubModule()&e.code;),
+ and are described above. When the &s.code;SetupProc&e.code; is
+ successful it must return a non-&s.code;NULL&e.code; value. The
+ loader checks this, and if it is &s.code;NULL&e.code; it unloads
+ the module and reports the failure to the caller of
+ &s.code;LoadModule()&e.code;. If the &s.code;SetupProc&e.code;
+ does things that need to be undone when the module is unloaded,
+ it should define a &s.code;TearDownProc&e.code;, and return a
+ pointer that the &s.code;TearDownProc&e.code; can use to undo what
+ has been done.
+
+ When a module is loaded multiple times, the &s.code;SetupProc&e.code;
+ is called once for each time it is loaded.
+
+ </quote>
+
+ &s.code;void TearDownProc(pointer tearDownData)&e.code;
+ <quote><p>
+ When defined, this function is called when the loader unloads a
+ module. The &s.code;tearDownData&e.code; parameter is the return
+ value of the &s.code;SetupProc()&e.code; that was called when the
+ module was loaded. The purpose of this function is to clean up
+ before the module is unloaded (for example, by freeing allocated
+ resources).
+
+ </quote>
+ </quote>
+
+<sect1>Public Loader Interface
+<p>
+
+The following is the Loader interface that is available to any part of
+the server, and may also be used from within modules.
+
+ <quote><p>
+ &s.code;pointer LoadSubModule(pointer parent, const char *module,
+ &f.indent;const char **subdirlist, const char **patternlist,
+ &f.indent;pointer options, const XF86ModReqInfo * modreq,
+ &f.indent;int *errmaj, int *errmin)&e.code;
+ <quote><p>
+ This function is like the &s.code;LoadModule()&e.code; function
+ described above, except that the module loaded is registered as a
+ child of the calling module. The &s.code;parent&e.code; parameter
+ is the calling module's handle. Modules loaded with this function
+ are automatically unloaded when the parent module is unloaded. The
+ other difference is that the path parameter may not be specified.
+ The module search path used for modules loaded with this function
+ is the default search path as initialised with
+ &s.code;LoaderSetPath()&e.code;.
+
+ </quote>
+
+ &s.code;void UnloadSubModule(pointer module)&e.code;
+ <quote><p>
+ This function unloads the module with handle &s.code;module&e.code;.
+ If that module itself has children, they are also unloaded. It is
+ like &s.code;UnloadModule()&e.code;, except that it is safe to use
+ for unloading child modules.
+
+ </quote>
+
+ &s.code;pointer LoaderSymbol(const char *symbol)&e.code;
+ <quote><p>
+ This function returns the address of the symbol with name
+ &s.code;symbol&e.code;. This may be used to locate a module entry
+ point with a known name.
+
+ </quote>
+
+ &s.code;char **LoaderlistDirs(const char **subdirlist,
+ &f.indent;const char **patternlist)&e.code;
+ <quote><p>
+ This function returns a &s.code;NULL&e.code; terminated list of
+ canonical modules names for modules found in the default module
+ search path. The &s.code;subdirlist&e.code; and
+ &s.code;patternlist&e.code; parameters are as described above, and
+ can be used to control the locations and names that are searched.
+ If no modules are found, the return value is &s.code;NULL&e.code;.
+ The returned list should be freed by calling
+ &s.code;LoaderFreeDirList()&e.code; when it is no longer needed.
+
+ </quote>
+
+ &s.code;void LoaderFreeDirList(char **list)&e.code;
+ <quote><p>
+ This function frees a module list created by
+ &s.code;LoaderlistDirs()&e.code;.
+
+ </quote>
+
+ &s.code;void LoaderReqSymLists(const char **list0, ...)&e.code;
+ <quote><p>
+ This function allows the registration of required symbols with the
+ loader. It is normally used by a caller of
+ &s.code;LoadSubModule()&e.code;. If any symbols registered in this
+ way are found to be unresolved when
+ &s.code;LoaderCheckUnresolved()&e.code; is called then
+ &s.code;LoaderCheckUnresolved()&e.code; will report a failure.
+ The function takes one or more &s.code;NULL&e.code; terminated
+ lists of symbols. The end of the argument list is indicated by a
+ &s.code;NULL&e.code; argument.
+
+ </quote>
+
+ &s.code;void LoaderReqSymbols(const char *sym0, ...)&e.code;
+ <quote><p>
+ This function is like &s.code;LoaderReqSymLists()&e.code; except
+ that its arguments are symbols rather than lists of symbols. This
+ function is more convenient when single functions are to be registered,
+ especially when the single function might depend on runtime factors.
+ The end of the argument list is indicated by a &s.code;NULL&e.code;
+ argument.
+
+ </quote>
+
+ &s.code;void LoaderRefSymLists(const char **list0, ...)&e.code;
+ <quote><p>
+ This function allows the registration of possibly unresolved symbols
+ with the loader. When &s.code;LoaderCheckUnresolved()&e.code; is
+ run it won't generate warnings for symbols registered in this way
+ unless they were also registered as required symbols.
+ The function takes one or more &s.code;NULL&e.code; terminated
+ lists of symbols. The end of the argument list is indicated by a
+ &s.code;NULL&e.code; argument.
+
+ </quote>
+
+ &s.code;void LoaderRefSymbols(const char *sym0, ...)&e.code;
+ <quote><p>
+ This function is like &s.code;LoaderRefSymLists()&e.code; except
+ that its arguments are symbols rather than lists of symbols. This
+ function is more convenient when single functions are to be registered,
+ especially when the single function might depend on runtime factors.
+ The end of the argument list is indicated by a &s.code;NULL&e.code;
+ argument.
+
+ </quote>
+
+ &s.code;int LoaderCheckUnresolved(int delayflag)&e.code;
+ <quote><p>
+ This function checks for unresolved symbols. It generates warnings
+ for unresolved symbols that have not been registered with
+ &s.code;LoaderRefSymLists()&e.code;, and maps them to a dummy
+ function. This behaviour may change in future. If unresolved
+ symbols are found that have been registered with
+ &s.code;LoaderReqSymLists()&e.code; or
+ &s.code;LoaderReqSymbols()&e.code; then this function returns a
+ non-zero value. If none of these symbols are unresolved the return
+ value is zero, indicating success.
+
+ The &s.code;delayflag&e.code; parameter should normally be set to
+ &s.code;LD_RESOLV_IFDONE&e.code;.
+
+ </quote>
+
+ &s.code;LoaderErrorMsg(const char *name, const char *modname,
+ &f.indent;int errmaj, int errmin)&e.code;
+ <quote><p>
+ This function prints an error message that includes the text ``Failed
+ to load module'', the module name &s.code;modname&e.code;, a message
+ specific to the &s.code;errmaj&e.code; value, and the value if
+ &s.code;errmin&e.code;. If &s.code;name&e.code; is
+ non-&s.code;NULL&e.code;, it is printed as an identifying prefix
+ to the message (followed by a `:').
+
+ </quote>
+ </quote>
+
+<sect1>Special Registration Functions
+<p>
+
+The loader contains some functions for registering some classes of modules.
+These may be moved out of the loader at some point.
+
+ <quote><p>
+ &s.code;void LoadExtension(ExtensionModule *ext)&e.code;
+ <quote><p>
+ This registers the entry points for the extension identified by
+ &s.code;ext&e.code;. The &s.code;ExtensionModule&e.code; struct is
+ defined as:
+
+<quote>
+<verb>
+typedef struct {
+ InitExtension initFunc;
+ char * name;
+ Bool *disablePtr;
+ InitExtension setupFunc;
+} ExtensionModule;
+</verb>
+</quote>
+
+ </quote>
+
+ &s.code;void LoadFont(FontModule *font)&e.code;
+ <quote><p>
+ This registers the entry points for the font rasteriser module
+ identified by &s.code;font&e.code;. The &s.code;FontModule&e.code;
+ struct is defined as:
+
+<quote>
+<verb>
+typedef struct {
+ InitFont initFunc;
+ char * name;
+ pointer module;
+} FontModule;
+</verb>
+</quote>
+
+ </quote>
+ </quote>
+
+</sect>
+
+
+<sect>Helper Functions
+<p>
+
+This section describe ``helper'' functions that video driver
+might find useful. While video drivers are not required to use any of
+these to be considered ``compliant'', the use of appropriate helpers is
+strongly encouraged to improve the consistency of driver behaviour.
+
+<sect1>Functions for printing messages
+<p>
+
+ <quote><p>
+ &s.code;ErrorF(const char *format, ...)&e.code;
+ <quote><p>
+ This is the basic function for writing to the error log (typically
+ stderr and/or a log file). Video drivers should usually avoid
+ using this directly in favour of the more specialised functions
+ described below. This function is useful for printing messages
+ while debugging a driver.
+
+ </quote>
+
+ &s.code;FatalError(const char *format, ...)&e.code;
+ <quote><p>
+ This prints a message and causes the Xserver to abort. It should
+ rarely be used within a video driver, as most error conditions
+ should be flagged by the return values of the driver functions.
+ This allows the higher layers to decide how to proceed. In rare
+ cases, this can be used within a driver if a fatal unexpected
+ condition is found.
+
+ </quote>
+
+ &s.code;xf86ErrorF(const char *format, ...)&e.code;
+ <quote><p>
+ This is like &s.code;ErrorF()&e.code;, except that the message is
+ only printed when the Xserver's verbosity level is set to the
+ default (&s.code;1&e.code;) or higher. It means that the messages
+ are not printed when the server is started with the
+ &s.cmd;-quiet&e.cmd; flag. Typically this function would only be
+ used for continuing messages started with one of the more specialised
+ functions described below.
+
+ </quote>
+
+ &s.code;xf86ErrorFVerb(int verb, const char *format, ...)&e.code;
+ <quote><p>
+ Like &s.code;xf86ErrorF()&e.code;, except the minimum verbosity
+ level for which the message is to be printed is given explicitly.
+ Passing a &s.code;verb&e.code; value of zero means the message
+ is always printed. A value higher than &s.code;1&e.code; can be
+ used for information would normally not be needed, but which might
+ be useful when diagnosing problems.
+
+ </quote>
+
+ &s.code;xf86Msg(MessageType type, const char *format, ...)&e.code;
+ <quote><p>
+ This is like &s.code;xf86ErrorF()&e.code;, except that the message
+ is prefixed with a marker determined by the value of
+ &s.code;type&e.code;. The marker is used to indicate the type of
+ message (warning, error, probed value, config value, etc). Note
+ the &s.code;xf86Verbose&e.code; value is ignored for messages of
+ type &s.code;X_ERROR&e.code;.
+
+ The marker values are:
+
+ <quote>
+ &s.code;X_PROBED&e.code;
+ <quote>Value was probed.</quote>
+ &s.code;X_CONFIG&e.code;
+ <quote>Value was given in the config file.</quote>
+ &s.code;X_DEFAULT&e.code;
+ <quote>Value is a default.</quote>
+ &s.code;X_CMDLINE&e.code;
+ <quote>Value was given on the command line.</quote>
+ &s.code;X_NOTICE&e.code;
+ <quote>Notice.</quote>
+ &s.code;X_ERROR&e.code;
+ <quote>Error message.</quote>
+ &s.code;X_WARNING&e.code;
+ <quote>Warning message.</quote>
+ &s.code;X_INFO&e.code;
+ <quote>Informational message.</quote>
+ &s.code;X_NONE&e.code;
+ <quote>No prefix.</quote>
+ &s.code;X_NOT_IMPLEMENTED&e.code;
+ <quote>The message relates to functionality that is not yet
+ implemented.</quote>
+ </quote>
+
+
+ </quote>
+
+ &s.code;xf86MsgVerb(MessageType type, int verb, const char *format, ...)&e.code;
+ <quote><p>
+ Like &s.code;xf86Msg()&e.code;, but with the verbosity level given
+ explicitly.
+
+ </quote>
+
+ &s.code;xf86DrvMsg(int scrnIndex, MessageType type, const char *format, ...)&e.code;
+ <quote><p>
+ This is like &s.code;xf86Msg()&e.code; except that the driver's
+ name (the &s.code;name&e.code; field of the
+ &s.code;ScrnInfoRec&e.code;) followed by the
+ &s.code;scrnIndex&e.code; in parentheses is printed following the
+ prefix. This should be used by video drivers in most cases as it
+ clearly indicates which driver/screen the message is for. If
+ &s.code;scrnIndex&e.code; is negative, this function behaves
+ exactly like &s.code;xf86Msg()&e.code;.
+
+ NOTE: This function can only be used after the
+ &s.code;ScrnInfoRec&e.code; and its &s.code;name&e.code; field
+ have been allocated. Normally, this means that it can not be
+ used before the END of the &s.code;ChipProbe()&e.code; function.
+ Prior to that, use &s.code;xf86Msg()&e.code;, providing the
+ driver's name explicitly. No screen number can be supplied at
+ that point.
+
+ </quote>
+
+ &s.code;xf86DrvMsgVerb(int scrnIndex, MessageType type, int verb,
+ &f.indent;const char *format, ...)&e.code;
+ <quote><p>
+ Like &s.code;xf86DrvMsg()&e.code;, but with the verbosity level
+ given explicitly.
+
+ </quote>
+ </quote>
+
+
+<sect1>Functions for setting values based on command line and config file
+<p>
+
+ <quote><p>
+ &s.code;Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp,
+ &f.indent;int fbbpp, int depth24flags)&e.code;
+ <quote><p>
+ This function sets the &s.code;depth&e.code;, &s.code;pixmapBPP&e.code; and &s.code;bitsPerPixel&e.code; fields
+ of the &s.code;ScrnInfoRec&e.code;. It also determines the defaults for display-wide
+ attributes and pixmap formats the screen will support, and finds
+ the Display subsection that matches the depth/bpp. This function
+ should normally be called very early from the
+ &s.code;ChipPreInit()&e.code; function.
+
+ It requires that the &s.code;confScreen&e.code; field of the &s.code;ScrnInfoRec&e.code; be
+ initialised prior to calling it. This is done by the XFree86
+ common layer prior to calling &s.code;ChipPreInit()&e.code;.
+
+ The parameters passed are:
+
+ &s.code;depth&e.code;
+ <quote><p>
+ driver's preferred default depth if no other is given.
+ If zero, use the overall server default.
+
+ </quote>
+ &s.code;bpp&e.code;
+ <quote><p>
+ Same, but for the pixmap bpp.
+
+ </quote>
+ &s.code;fbbpp&e.code;
+ <quote><p>
+ Same, but for the framebuffer bpp.
+
+ </quote>
+ &s.code;depth24flags&e.code;
+ <quote><p>
+ Flags that indicate the level of 24/32bpp support
+ and whether conversion between different framebuffer
+ and pixmap formats is supported. The flags for this
+ argument are defined as follows, and multiple flags
+ may be ORed together:
+
+ &s.code;NoDepth24Support&e.code;
+ <quote>No depth 24 formats supported</quote>
+ &s.code;Support24bppFb&e.code;
+ <quote>24bpp framebuffer supported</quote>
+ &s.code;Support32bppFb&e.code;
+ <quote>32bpp framebuffer supported</quote>
+ &s.code;SupportConvert24to32&e.code;
+ <quote>Can convert 24bpp pixmap to 32bpp fb</quote>
+ &s.code;SupportConvert32to24&e.code;
+ <quote>Can convert 32bpp pixmap to 24bpp fb</quote>
+ &s.code;ForceConvert24to32&e.code;
+ <quote>Force 24bpp pixmap to 32bpp fb conversion</quote>
+ &s.code;ForceConvert32to24&e.code;
+ <quote>Force 32bpp pixmap to 24bpp fb conversion</quote>
+
+ </quote>
+
+ It uses the command line, config file, and default values in the
+ correct order of precedence to determine the depth and bpp values.
+ It is up to the driver to check the results to see that it supports
+ them. If not the &s.code;ChipPreInit()&e.code; function should
+ return &s.code;FALSE&e.code;.
+
+ If only one of depth/bpp is given, the other is set to a reasonable
+ (and consistent) default.
+
+ If a driver finds that the initial &s.code;depth24flags&e.code;
+ it uses later results in a fb format that requires more video
+ memory than is available it may call this function a second time
+ with a different &s.code;depth24flags&e.code; setting.
+
+ On success, the return value is &s.code;TRUE&e.code;. On failure
+ it prints an error message and returns &s.code;FALSE&e.code;.
+
+ The following fields of the &s.code;ScrnInfoRec&e.code; are
+ initialised by this function:
+
+ <quote>
+ &s.code;depth&e.code;, &s.code;bitsPerPixel&e.code;,
+ &s.code;display&e.code;, &s.code;imageByteOrder&e.code;,
+ &s.code;bitmapScanlinePad&e.code;,
+ &s.code;bitmapScanlineUnit&e.code;, &s.code;bitmapBitOrder&e.code;,
+ &s.code;numFormats&e.code;, &s.code;formats&e.code;,
+ &s.code;fbFormat&e.code;.
+ </quote>
+
+ </quote>
+
+ &s.code;void xf86PrintDepthBpp(scrnInfoPtr scrp)&e.code;
+ <quote><p>
+ This function can be used to print out the depth and bpp settings.
+ It should be called after the final call to
+ &s.code;xf86SetDepthBpp()&e.code;.
+
+ </quote>
+
+ &s.code;Bool xf86SetWeight(ScrnInfoPtr scrp, rgb weight, rgb mask)&e.code;
+ <quote><p>
+ This function sets the &s.code;weight&e.code;, &s.code;mask&e.code;,
+ &s.code;offset&e.code; and &s.code;rgbBits&e.code; fields of the
+ &s.code;ScrnInfoRec&e.code;. It would normally be called fairly
+ early in the &s.code;ChipPreInit()&e.code; function for
+ depths > 8bpp.
+
+ It requires that the &s.code;depth&e.code; and
+ &s.code;display&e.code; fields of the &s.code;ScrnInfoRec&e.code;
+ be initialised prior to calling it.
+
+ The parameters passed are:
+
+ &s.code;weight&e.code;
+ <quote><p>
+ driver's preferred default weight if no other is given.
+ If zero, use the overall server default.
+
+ </quote>
+
+ &s.code;mask&e.code;
+ <quote><p>
+ Same, but for mask.
+
+ </quote>
+
+ It uses the command line, config file, and default values in the
+ correct order of precedence to determine the weight value. It
+ derives the mask and offset values from the weight and the defaults.
+ It is up to the driver to check the results to see that it supports
+ them. If not the &s.code;ChipPreInit()&e.code; function should
+ return &s.code;FALSE&e.code;.
+
+ On success, this function prints a message showing the weight
+ values selected, and returns &s.code;TRUE&e.code;.
+
+ On failure it prints an error message and returns &s.code;FALSE&e.code;.
+
+ The following fields of the &s.code;ScrnInfoRec&e.code; are
+ initialised by this function:
+
+ <quote>
+ &s.code;weight&e.code;, &s.code;mask&e.code;, &s.code;offset&e.code;.
+ </quote>
+
+ </quote>
+
+ &s.code;Bool xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual)&e.code;
+ <quote><p>
+ This function sets the &s.code;defaultVisual&e.code; field of the
+ &s.code;ScrnInfoRec&e.code;. It would normally be called fairly
+ early from the &s.code;ChipPreInit()&e.code; function.
+
+ It requires that the &s.code;depth&e.code; and
+ &s.code;display&e.code; fields of the &s.code;ScrnInfoRec&e.code;
+ be initialised prior to calling it.
+
+ The parameters passed are:
+
+ &s.code;visual&e.code;
+ <quote><p>
+ driver's preferred default visual if no other is given.
+ If &s.code;-1&e.code;, use the overall server default.
+
+ </quote>
+
+ It uses the command line, config file, and default values in the
+ correct order of precedence to determine the default visual value.
+ It is up to the driver to check the result to see that it supports
+ it. If not the &s.code;ChipPreInit()&e.code; function should
+ return &s.code;FALSE&e.code;.
+
+ On success, this function prints a message showing the default visual
+ selected, and returns &s.code;TRUE&e.code;.
+
+ On failure it prints an error message and returns &s.code;FALSE&e.code;.
+
+ </quote>
+
+ &s.code;Bool xf86SetGamma(ScrnInfoPtr scrp, Gamma gamma)&e.code;
+ <quote><p>
+ This function sets the &s.code;gamma&e.code; field of the
+ &s.code;ScrnInfoRec&e.code;. It would normally be called fairly
+ early from the &s.code;ChipPreInit()&e.code; function in cases
+ where the driver supports gamma correction.
+
+ It requires that the &s.code;monitor&e.code; field of the
+ &s.code;ScrnInfoRec&e.code; be initialised prior to calling it.
+
+ The parameters passed are:
+
+ &s.code;gamma&e.code;
+ <quote><p>
+ driver's preferred default gamma if no other is given.
+ If zero (&s.code;< 0.01&e.code;), use the overall server
+ default.
+
+ </quote>
+
+ It uses the command line, config file, and default values in the
+ correct order of precedence to determine the gamma value. It is
+ up to the driver to check the results to see that it supports
+ them. If not the &s.code;ChipPreInit()&e.code; function should
+ return &s.code;FALSE&e.code;.
+
+ On success, this function prints a message showing the gamma
+ value selected, and returns &s.code;TRUE&e.code;.
+
+ On failure it prints an error message and returns &s.code;FALSE&e.code;.
+
+ </quote>
+
+ &s.code;void xf86SetDpi(ScrnInfoPtr pScrn, int x, int y)&e.code;
+ <quote><p>
+ This function sets the &s.code;xDpi&e.code; and &s.code;yDpi&e.code;
+ fields of the &s.code;ScrnInfoRec&e.code;. The driver can specify
+ preferred defaults by setting &s.code;x&e.code; and &s.code;y&e.code;
+ to non-zero values. The &s.cmd;-dpi&e.cmd; command line option
+ overrides all other settings. Otherwise, if the
+ &s.key;DisplaySize&e.key; entry is present in the screen's &k.monitor;
+ config file section, it is used together with the virtual size to
+ calculate the dpi values. This function should be called after
+ all the mode resolution has been done.
+
+ </quote>
+
+ &s.code;void xf86SetBlackWhitePixels(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ This functions sets the &s.code;blackPixel&e.code; and
+ &s.code;whitePixel&e.code; fields of the &s.code;ScrnInfoRec&e.code;
+ according to whether or not the &s.cmd;-flipPixels&e.cmd; command
+ line options is present.
+
+ </quote>
+
+ &s.code;const char *xf86GetVisualName(int visual)&e.code;
+ <quote><p>
+ Returns a printable string with the visual name matching the
+ numerical visual class provided. If the value is outside the
+ range of valid visual classes, &s.code;NULL&e.code; is returned.
+
+ </quote>
+ </quote>
+
+
+<sect1>Primary Mode functions
+<p>
+
+The primary mode helper functions are those which would normally be
+used by a driver, unless it has unusual requirements which cannot
+be catered for the by the helpers.
+
+ <quote><p>
+ &s.code;int xf86ValidateModes(ScrnInfoPtr scrp, DisplayModePtr availModes,
+ &f.indent;char **modeNames, ClockRangePtr clockRanges,
+ &f.indent;int *linePitches, int minPitch, int maxPitch,
+ &f.indent;int pitchInc, int minHeight, int maxHeight,
+ &f.indent;int virtualX, int virtualY,
+ &f.indent;unsigned long apertureSize,
+ &f.indent;LookupModeFlags strategy)&e.code;
+ <quote><p>
+ This function basically selects the set of modes to use based on
+ those available and the various constraints. It also sets some
+ other related parameters. It is normally called near the end of
+ the &s.code;ChipPreInit()&e.code; function.
+
+ The parameters passed to the function are:
+
+ &s.code;availModes&e.code;
+ <quote><p>
+ List of modes available for the monitor.
+
+ </quote>
+ &s.code;modeNames&e.code;
+ <quote><p>
+ List of mode names that the screen is requesting.
+
+ </quote>
+ &s.code;clockRanges&e.code;
+ <quote><p>
+ A list of clock ranges allowed by the driver. Each
+ range includes whether interlaced or multiscan modes
+ are supported for that range. See below for more on
+ &s.code;clockRanges&e.code;.
+
+ </quote>
+ &s.code;linePitches&e.code;
+ <quote><p>
+ List of line pitches supported by the driver.
+ This is optional and should be &s.code;NULL&e.code; when
+ not used.
+
+ </quote>
+ &s.code;minPitch&e.code;
+ <quote><p>
+ Minimum line pitch supported by the driver. This must
+ be supplied when &s.code;linePitches&e.code; is
+ &s.code;NULL&e.code;, and is ignored otherwise.
+
+ </quote>
+ &s.code;maxPitch&e.code;
+ <quote><p>
+ Maximum line pitch supported by the driver. This is
+ required when &s.code;minPitch&e.code; is required.
+
+ </quote>
+ &s.code;pitchInc&e.code;
+ <quote><p>
+ Granularity of horizontal pitch values as supported by
+ the chipset. This is expressed in bits. This must be
+ supplied.
+
+ </quote>
+ &s.code;minHeight&e.code;
+ <quote><p>
+ minimum virtual height allowed. If zero, no limit is
+ imposed.
+
+ </quote>
+ &s.code;maxHeight&e.code;
+ <quote><p>
+ maximum virtual height allowed. If zero, no limit is
+ imposed.
+
+ </quote>
+ &s.code;virtualX&e.code;
+ <quote><p>
+ If greater than zero, this is the virtual width value
+ that will be used. Otherwise, the virtual width is
+ chosen to be the smallest that can accommodate the modes
+ selected.
+
+ </quote>
+ &s.code;virtualY&e.code;
+ <quote><p>
+ If greater than zero, this is the virtual height value
+ that will be used. Otherwise, the virtual height is
+ chosen to be the smallest that can accommodate the modes
+ selected.
+
+ </quote>
+ &s.code;apertureSize&e.code;
+ <quote><p>
+ The size (in bytes) of the aperture used to access video
+ memory.
+
+ </quote>
+ &s.code;strategy&e.code;
+ <quote><p>
+ The strategy to use when choosing from multiple modes
+ with the same name. The options are:
+
+ &s.code;LOOKUP_DEFAULT&e.code;
+ <quote>???</quote>
+ &s.code;LOOKUP_BEST_REFRESH&e.code;
+ <quote>mode with best refresh rate</quote>
+ &s.code;LOOKUP_CLOSEST_CLOCK&e.code;
+ <quote>mode with closest matching clock</quote>
+ &s.code;LOOKUP_LIST_ORDER&e.code;
+ <quote>first usable mode in list</quote>
+
+ The following options can also be combined (OR'ed) with
+ one of the above:
+
+ &s.code;LOOKUP_CLKDIV2&e.code;
+ <quote>Allow halved clocks</quote>
+ &s.code;LOOKUP_OPTIONAL_TOLERANCES&e.code;
+ <quote>Allow missing horizontal sync and/or vertical refresh
+ ranges in the xorg.conf Monitor section</quote>
+
+ &s.code;LOOKUP_OPTIONAL_TOLERANCES&e.code; should only be
+ specified when the driver can ensure all modes it generates
+ can sync on, or at least not damage, the monitor or digital
+ flat panel. Horizontal sync and/or vertical refresh ranges
+ specified by the user will still be honoured (and acted upon).
+
+ </quote>
+
+ This function requires that the following fields of the
+ &s.code;ScrnInfoRec&e.code; are initialised prior to calling it:
+
+ &s.code;clock[]&e.code;
+ <quote>List of discrete clocks (when non-programmable)</quote>
+ &s.code;numClocks&e.code;
+ <quote>Number of discrete clocks (when non-programmable)</quote>
+ &s.code;progClock&e.code;
+ <quote>Whether the clock is programmable or not</quote>
+ &s.code;monitor&e.code;
+ <quote>Pointer to the applicable xorg.conf monitor section</quote>
+ &s.code;fdFormat&e.code;
+ <quote>Format of the screen buffer</quote>
+ &s.code;videoRam&e.code;
+ <quote>total video memory size (in bytes)</quote>
+ &s.code;maxHValue&e.code;
+ <quote>Maximum horizontal timing value allowed</quote>
+ &s.code;maxVValue&e.code;
+ <quote>Maximum vertical timing value allowed</quote>
+ &s.code;xInc&e.code;
+ <quote>Horizontal timing increment in pixels (defaults to 8)</quote>
+
+ This function fills in the following &s.code;ScrnInfoRec&e.code;
+ fields:
+
+ &s.code;modePool&e.code;
+ <quote><p>
+ A subset of the modes available to the monitor which
+ are compatible with the driver.
+
+ </quote>
+ &s.code;modes&e.code;
+ <quote><p>
+ One mode entry for each of the requested modes, with
+ the status field of each filled in to indicate if
+ the mode has been accepted or not. This list of
+ modes is a circular list.
+
+ </quote>
+ &s.code;virtualX&e.code;
+ <quote><p>
+ The resulting virtual width.
+
+ </quote>
+ &s.code;virtualY&e.code;
+ <quote><p>
+ The resulting virtual height.
+
+ </quote>
+ &s.code;displayWidth&e.code;
+ <quote><p>
+ The resulting line pitch.
+
+ </quote>
+ &s.code;virtualFrom&e.code;
+ <quote><p>
+ Where the virtual size was determined from.
+
+ </quote>
+
+ The first stage of this function checks that the
+ &s.code;virtualX&e.code; and &s.code;virtualY&e.code; values
+ supplied (if greater than zero) are consistent with the line pitch
+ and &s.code;maxHeight&e.code; limitations. If not, an error
+ message is printed, and the return value is &s.code;-1&e.code;.
+
+ The second stage sets up the mode pool, eliminating immediately
+ any modes that exceed the driver's line pitch limits, and also
+ the virtual width and height limits (if greater than zero). For
+ each mode removed an informational message is printed at verbosity
+ level &s.code;2&e.code;. If the mode pool ends up being empty,
+ a warning message is printed, and the return value is
+ &s.code;0&e.code;.
+
+ The final stage is to lookup each mode name, and fill in the remaining
+ parameters. If an error condition is encountered, a message is
+ printed, and the return value is &s.code;-1&e.code;. Otherwise,
+ the return value is the number of valid modes found
+ (&s.code;0&e.code; if none are found).
+
+ Even if the supplied mode names include duplicates, no two names will
+ ever match the same mode. Furthermore, if the supplied mode names do not
+ yield a valid mode (including the case where no names are passed at all),
+ the function will continue looking through the mode pool until it finds
+ a mode that survives all checks, or until the mode pool is exhausted.
+
+ A message is only printed by this function when a fundamental
+ problem is found. It is intended that this function may be called
+ more than once if there is more than one set of constraints that
+ the driver can work within.
+
+ If this function returns &s.code;-1&e.code;, the
+ &s.code;ChipPreInit()&e.code; function should return
+ &s.code;FALSE&e.code;.
+
+ &s.code;clockRanges&e.code; is a linked list of clock ranges
+ allowed by the driver. If a mode doesn't fit in any of the defined
+ &s.code;clockRanges&e.code;, it is rejected. The first
+ &s.code;clockRange&e.code; that matches all requirements is used.
+ This structure needs to be initialized to NULL when allocated.
+
+ &s.code;clockRanges&e.code; contains the following fields:
+
+ &s.code;minClock&nl;
+ maxClock&e.code;
+ <quote><p>
+ The lower and upper mode clock bounds for which the rest
+ of the &s.code;clockRange&e.code; parameters apply.
+ Since these are the mode clocks, they are not scaled
+ with the &s.code;ClockMulFactor&e.code; and
+ &s.code;ClockDivFactor&e.code;. It is up to the driver
+ to adjust these values if they depend on the clock
+ scaling factors.
+
+ </quote>
+ &s.code;clockIndex&e.code;
+ <quote><p>
+ (not used yet) &s.code;-1&e.code; for programmable clocks
+
+ </quote>
+ &s.code;interlaceAllowed&e.code;
+ <quote><p>
+ &s.code;TRUE&e.code; if interlacing is allowed for this
+ range
+
+ </quote>
+ &s.code;doubleScanAllowed&e.code;
+ <quote><p>
+ &s.code;TRUE&e.code; if doublescan or multiscan is allowed
+ for this range
+
+ </quote>
+ &s.code;ClockMulFactor&nl;
+ ClockDivFactor&e.code;
+ <quote><p>
+ Scaling factors that are applied to the mode clocks ONLY
+ before selecting a clock index (when there is no
+ programmable clock) or a &s.code;SynthClock&e.code;
+ value. This is useful for drivers that support pixel
+ multiplexing or that need to scale the clocks because
+ of hardware restrictions (like sending 24bpp data to an
+ 8 bit RAMDAC using a tripled clock).
+
+ Note that these parameters describe what must be done
+ to the mode clock to achieve the data transport clock
+ between graphics controller and RAMDAC. For example
+ for &s.code;2:1&e.code; pixel multiplexing, two pixels
+ are sent to the RAMDAC on each clock. This allows the
+ RAMDAC clock to be half of the actual pixel clock.
+ Hence, &s.code;ClockMulFactor=1&e.code; and
+ &s.code;ClockDivFactor=2&e.code;. This means that the
+ clock used for clock selection (ie, determining the
+ correct clock index from the list of discrete clocks)
+ or for the &s.code;SynthClock&e.code; field in case of
+ a programmable clock is: (&s.code;mode->Clock *
+ ClockMulFactor) / ClockDivFactor&e.code;.
+
+ </quote>
+ &s.code;PrivFlags&e.code;
+ <quote><p>
+ This field is copied into the
+ &s.code;mode->PrivFlags&e.code; field when this
+ &s.code;clockRange&e.code; is selected by
+ &s.code;xf86ValidateModes()&e.code;. It allows the
+ driver to find out what clock range was selected, so it
+ knows it needs to set up pixel multiplexing or any other
+ range-dependent feature. This field is purely
+ driver-defined: it may contain flag bits, an index or
+ anything else (as long as it is an &s.code;INT&e.code;).
+ </quote>
+
+ Note that the &s.code;mode->SynthClock&e.code; field is always
+ filled in by &s.code;xf86ValidateModes()&e.code;: it will contain
+ the ``data transport clock'', which is the clock that will have
+ to be programmed in the chip when it has a programmable clock, or
+ the clock that will be picked from the clocks list when it is not
+ a programmable one. Thus:
+
+ &s.code;mode->SynthClock =
+ &f.indent;(mode->Clock * ClockMulFactor) / ClockDivFactor&e.code;
+
+ </quote>
+
+ &s.code;void xf86PruneDriverModes(ScrnInfoPtr scrp)&e.code;
+ <quote><p>
+ This function deletes modes in the modes field of the
+ &s.code;ScrnInfoRec&e.code; that have been marked as invalid.
+ This is normally run after having run
+ &s.code;xf86ValidateModes()&e.code; for the last time. For each
+ mode that is deleted, a warning message is printed out indicating
+ the reason for it being deleted.
+
+ </quote>
+
+ &s.code;void xf86SetCrtcForModes(ScrnInfoPtr scrp, int adjustFlags)&e.code;
+ <quote><p>
+ This function fills in the &s.code;Crtc*&e.code; fields for all
+ the modes in the &s.code;modes&e.code; field of the
+ &s.code;ScrnInfoRec&e.code;. The &s.code;adjustFlags&e.code;
+ parameter determines how the vertical CRTC values are scaled for
+ interlaced modes. They are halved if it is
+ &s.code;INTERLACE_HALVE_V&e.code;. The vertical CRTC values are
+ doubled for doublescan modes, and are further multiplied by the
+ &s.code;VScan&e.code; value.
+
+ This function is normally called after calling
+ &s.code;xf86PruneDriverModes()&e.code;.
+
+ </quote>
+
+ &s.code;void xf86PrintModes(ScrnInfoPtr scrp)&e.code;
+ <quote><p>
+ This function prints out the virtual size setting, and the line
+ pitch being used. It also prints out two lines for each mode being
+ used. The first line includes the mode's pixel clock, horizontal sync
+ rate, refresh rate, and whether it is interlaced, doublescanned and/or
+ multi-scanned. The second line is the mode's Modeline.
+
+ This function is normally called after calling
+ &s.code;xf86SetCrtcForModes()&e.code;.
+
+ </quote>
+ </quote>
+
+
+<sect1>Secondary Mode functions
+<p>
+
+The secondary mode helper functions are functions which are normally
+used by the primary mode helper functions, and which are not normally
+called directly by a driver. If a driver has unusual requirements
+and needs to do its own mode validation, it might be able to make
+use of some of these secondary mode helper functions.
+
+ <quote><p>
+ &s.code;int xf86GetNearestClock(ScrnInfoPtr scrp, int freq, Bool allowDiv2,
+ &f.indent;int *divider)&e.code;
+ <quote><p>
+ This function returns the index of the closest clock to the
+ frequency &s.code;freq&e.code; given (in kHz). It assumes that
+ the number of clocks is greater than zero. It requires that the
+ &s.code;numClocks&e.code; and &s.code;clock&e.code; fields of the
+ &s.code;ScrnInfoRec&e.code; are initialised. The
+ &s.code;allowDiv2&e.code; field determines if the clocks can be
+ halved. The &s.code;*divider&e.code; return value indicates
+ whether clock division is used when determining the clock returned.
+
+ This function is only for non-programmable clocks.
+
+ </quote>
+
+ &s.code;const char *xf86ModeStatusToString(ModeStatus status)&e.code;
+ <quote><p>
+ This function converts the &s.code;status&e.code; value to a
+ descriptive printable string.
+
+ </quote>
+
+ &s.code;ModeStatus xf86LookupMode(ScrnInfoPtr scrp, DisplayModePtr modep,
+ &f.indent;ClockRangePtr clockRanges, LookupModeFlags strategy)&e.code;
+ <quote><p>
+ This function takes a pointer to a mode with the name filled in,
+ and looks for a mode in the &s.code;modePool&e.code; list which
+ matches. The parameters of the matching mode are filled in to
+ &s.code;*modep&e.code;. The &s.code;clockRanges&e.code; and
+ &s.code;strategy&e.code; parameters are as for the
+ &s.code;xf86ValidateModes()&e.code; function above.
+
+ This function requires the &s.code;modePool&e.code;,
+ &s.code;clock[]&e.code;, &s.code;numClocks&e.code; and
+ &s.code;progClock&e.code; fields of the &s.code;ScrnInfoRec&e.code;
+ to be initialised before being called.
+
+ The return value is &s.code;MODE_OK&e.code; if a mode was found.
+ Otherwise it indicates why a matching mode could not be found.
+
+ </quote>
+
+ &s.code;ModeStatus xf86InitialCheckModeForDriver(ScrnInfoPtr scrp,
+ &f.indent;DisplayModePtr mode, ClockRangePtr clockRanges,
+ &f.indent;LookupModeFlags strategy, int maxPitch,
+ &f.indent;int virtualX, int virtualY)&e.code;
+ <quote><p>
+ This function checks the passed mode against some basic driver
+ constraints. Apart from the ones passed explicitly, the
+ &s.code;maxHValue&e.code; and &s.code;maxVValue&e.code; fields of
+ the &s.code;ScrnInfoRec&e.code; are also used. If the
+ &s.code;ValidMode&e.code; field of the &s.code;ScrnInfoRec&e.code;
+ is set, that function is also called to check the mode. Next, the
+ mode is checked against the monitor's constraints.
+
+ If the mode is consistent with all constraints, the return value
+ is &s.code;MODE_OK&e.code;. Otherwise the return value indicates
+ which constraint wasn't met.
+
+ </quote>
+
+ &s.code;void xf86DeleteMode(DisplayModePtr *modeList, DisplayModePtr mode)&e.code;
+ <quote><p>
+ This function deletes the &s.code;mode&e.code; given from the
+ &s.code;modeList&e.code;. It never prints any messages, so it is
+ up to the caller to print a message if required.
+
+ </quote>
+ </quote>
+
+<sect1>Functions for handling strings and tokens
+<p>
+
+ Tables associating strings and numerical tokens combined with the
+ following functions provide a compact way of handling strings from
+ the config file, and for converting tokens into printable strings.
+ The table data structure is:
+
+<quote><verb>
+typedef struct {
+ int token;
+ const char * name;
+} SymTabRec, *SymTabPtr;
+</verb></quote>
+
+ A table is an initialised array of &s.code;SymTabRec&e.code;. The
+ tokens must be non-negative integers. Multiple names may be mapped
+ to a single token. The table is terminated with an element with a
+ &s.code;token&e.code; value of &s.code;-1&e.code; and
+ &s.code;NULL&e.code; for the &s.code;name&e.code;.
+
+
+ <quote><p>
+ &s.code;const char *xf86TokenToString(SymTabPtr table, int token)&e.code;
+ <quote><p>
+ This function returns the first string in &s.code;table&e.code;
+ that matches &s.code;token&e.code;. If no match is found,
+ &s.code;NULL&e.code; is returned (NOTE, older versions of this
+ function would return the string "unknown" when no match is found).
+
+ </quote>
+
+ &s.code;int xf86StringToToken(SymTabPtr table, const char *string)&e.code;
+ <quote><p>
+ This function returns the first token in &s.code;table&e.code;
+ that matches &s.code;string&e.code;. The
+ &s.code;xf86NameCmp()&e.code; function is used to determine the
+ match. If no match is found, &s.code;-1&e.code; is returned.
+
+ </quote>
+ </quote>
+
+
+<sect1>Functions for finding which config file entries to use
+<p>
+
+ These functions can be used to select the appropriate config file
+ entries that match the detected hardware. They are described above
+ in the <ref id="probe" name="Probe"> and
+ <ref id="avail" name="Available Functions"> sections.
+
+
+<sect1>Probing discrete clocks on old hardware
+<p>
+
+ The &s.code;xf86GetClocks()&e.code; function may be used to assist
+ in finding the discrete pixel clock values on older hardware.
+
+
+ <quote><p>
+ &s.code;void xf86GetClocks(ScrnInfoPtr pScrn, int num,
+ &f.indent;Bool (*ClockFunc)(ScrnInfoPtr, int),
+ &f.indent;void (*ProtectRegs)(ScrnInfoPtr, Bool),
+ &f.indent;void (*BlankScreen)(ScrnInfoPtr, Bool),
+ &f.indent;int vertsyncreg, int maskval, int knownclkindex,
+ &f.indent;int knownclkvalue)&e.code;
+ <quote><p>
+ This function uses a comparative sampling method to measure the
+ discrete pixel clock values. The number of discrete clocks to
+ measure is given by &s.code;num&e.code;. &s.code;clockFunc&e.code;
+ is a function that selects the &s.code;n&e.code;'th clock. It
+ should also save or restore any state affected by programming the
+ clocks when the index passed is &s.code;CLK_REG_SAVE&e.code; or
+ &s.code;CLK_REG_RESTORE&e.code;. &s.code;ProtectRegs&e.code; is
+ a function that does whatever is required to protect the hardware
+ state while selecting a new clock. &s.code;BlankScreen&e.code;
+ is a function that blanks the screen. &s.code;vertsyncreg&e.code;
+ and &s.code;maskval&e.code; are the register and bitmask to
+ check for the presence of vertical sync pulses.
+ &s.code;knownclkindex&e.code; and &s.code;knownclkvalue&e.code;
+ are the index and value of a known clock. These are the known
+ references on which the comparative measurements are based. The
+ number of clocks probed is set in &s.code;pScrn->numClocks&e.code;,
+ and the probed clocks are set in the &s.code;pScrn->clock[]&e.code;
+ array. All of the clock values are in units of kHz.
+
+ </quote>
+
+ &s.code;void xf86ShowClocks(ScrnInfoPtr scrp, MessageType from)&e.code;
+ <quote><p>
+ Print out the pixel clocks &s.code;scrp->clock[]&e.code;.
+ &s.code;from&e.code; indicates whether the clocks were probed
+ or from the config file.
+
+ </quote>
+ </quote>
+
+<sect1>Other helper functions
+<p>
+ <quote><p>
+ &s.code;Bool xf86IsUnblank(int mode)&e.code;
+ <quote><p>
+ Returns &s.code;TRUE&e.code; when the screen saver mode specified
+ by &s.code;mode&e.code; requires the screen be unblanked,
+ and &s.code;FALSE&e.code; otherwise. The screen saver modes that
+ require blanking are &s.code;SCREEN_SAVER_ON&e.code; and
+ &s.code;SCREEN_SAVER_CYCLE&e.code;, and the screen saver modes that
+ require unblanking are &s.code;SCREEN_SAVER_OFF&e.code; and
+ &s.code;SCREEN_SAVER_FORCER&e.code;. Drivers may call this helper
+ from their &s.code;SaveScreen()&e.code; function to interpret the
+ screen saver modes.
+
+ </quote>
+ </quote>
+
+<sect>The vgahw module
+<p>
+
+The vgahw modules provides an interface for saving, restoring and
+programming the standard VGA registers, and for handling VGA colourmaps.
+
+<sect1>Data Structures
+<p>
+
+ The public data structures used by the vgahw module are
+ &s.code;vgaRegRec&e.code; and &s.code;vgaHWRec&e.code;. They are
+ defined in &s.code;vgaHW.h.&e.code;
+
+
+<sect1>General vgahw Functions
+<p>
+
+ <quote><p>
+ &s.code;Bool vgaHWGetHWRec(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ This function allocates a &s.code;vgaHWRec&e.code; structure, and
+ hooks it into the &s.code;ScrnInfoRec&e.code;'s
+ &s.code;privates&e.code;. Like all information hooked into the
+ &s.code;privates&e.code;, it is persistent, and only needs to be
+ allocated once per screen. This function should normally be called
+ from the driver's &s.code;ChipPreInit()&e.code; function. The
+ &s.code;vgaHWRec&e.code; is zero-allocated, and the following
+ fields are explicitly initialised:
+
+ &s.code;ModeReg.DAC[]&e.code;
+ <quote>initialised with a default colourmap</quote>
+ &s.code;ModeReg.Attribute[0x11]&e.code;
+ <quote>initialised with the default overscan index</quote>
+ &s.code;ShowOverscan&e.code;
+ <quote>initialised according to the "ShowOverscan" option</quote>
+ &s.code;paletteEnabled&e.code;
+ <quote>initialised to FALSE</quote>
+ &s.code;cmapSaved&e.code;
+ <quote>initialised to FALSE</quote>
+ &s.code;pScrn&e.code;
+ <quote>initialised to pScrn</quote>
+
+ In addition to the above, &s.code;vgaHWSetStdFuncs()&e.code; is
+ called to initialise the register access function fields with the
+ standard VGA set of functions.
+
+ Once allocated, a pointer to the &s.code;vgaHWRec&e.code; can be
+ obtained from the &s.code;ScrnInfoPtr&e.code; with the
+ &s.code;VGAHWPTR(pScrn)&e.code; macro.
+
+ </quote>
+
+ &s.code;void vgaHWFreeHWRec(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ This function frees a &s.code;vgaHWRec&e.code; structure. It
+ should be called from a driver's &s.code;ChipFreeScreen()&e.code;
+ function.
+
+ </quote>
+
+ &s.code;Bool vgaHWSetRegCounts(ScrnInfoPtr pScrn, int numCRTC,
+ &f.indent;int numSequencer, int numGraphics, int numAttribute)&e.code;
+ <quote><p>
+ This function allows the number of CRTC, Sequencer, Graphics and
+ Attribute registers to be changed. This makes it possible for
+ extended registers to be saved and restored with
+ &s.code;vgaHWSave()&e.code; and &s.code;vgaHWRestore()&e.code;.
+ This function should be called after a &s.code;vgaHWRec&e.code;
+ has been allocated with &s.code;vgaHWGetHWRec()&e.code;. The
+ default values are defined in &s.code;vgaHW.h&e.code; as follows:
+
+ <quote><verb>
+#define VGA_NUM_CRTC 25
+#define VGA_NUM_SEQ 5
+#define VGA_NUM_GFX 9
+#define VGA_NUM_ATTR 21
+ </verb></quote>
+
+ </quote>
+
+ &s.code;Bool vgaHWCopyReg(vgaRegPtr dst, vgaRegPtr src)&e.code;
+ <quote><p>
+ This function copies the contents of the VGA saved registers in
+ &s.code;src&e.code; to &s.code;dst&e.code;. Note that it isn't
+ possible to simply do this with &s.code;memcpy()&e.code; (or
+ similar). This function returns &s.code;TRUE&e.code; unless there
+ is a problem allocating space for the &s.code;CRTC&e.code and
+ related fields in &s.code;dst&e.code;.
+
+ </quote>
+
+ &s.code;void vgaHWSetStdFuncs(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ This function initialises the register access function fields of
+ &s.code;hwp&e.code; with the standard VGA set of functions. This
+ is called by &s.code;vgaHWGetHWRec()&e.code;, so there is usually
+ no need to call this explicitly. The register access functions
+ are described below. If the registers are shadowed in some other
+ port I/O space (for example a PCI I/O region), these functions
+ can be used to access the shadowed registers if
+ &s.code;hwp->PIOOffset&e.code; is initialised with
+ &s.code;offset&e.code;, calculated in such a way that when the
+ standard VGA I/O port value is added to it the correct offset into
+ the PIO area results. This value is initialised to zero in
+ &s.code;vgaHWGetHWRec()&e.code;. (Note: the PIOOffset functionality
+ is present in XFree86 4.1.0 and later.)
+
+ </quote>
+
+ &s.code;void vgaHWSetMmioFuncs(vgaHWPtr hwp, CARD8 *base, int offset)&e.code;
+ <quote><p>
+ This function initialised the register access function fields of
+ hwp with a generic MMIO set of functions.
+ &s.code;hwp->MMIOBase&e.code; is initialised with
+ &s.code;base&e.code;, which must be the virtual address that the
+ start of MMIO area is mapped to. &s.code;hwp->MMIOOffset&e.code;
+ is initialised with &s.code;offset&e.code;, which must be calculated
+ in such a way that when the standard VGA I/O port value is added
+ to it the correct offset into the MMIO area results. That means
+ that these functions are only suitable when the VGA I/O ports are
+ made available in a direct mapping to the MMIO space. If that is
+ not the case, the driver will need to provide its own register
+ access functions. The register access functions are described
+ below.
+
+ </quote>
+
+ &s.code;Bool vgaHWMapMem(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ This function maps the VGA memory window. It requires that the
+ &s.code;vgaHWRec&e.code; be allocated. If a driver requires
+ non-default &s.code;MapPhys&e.code; or &s.code;MapSize&e.code;
+ settings (the physical location and size of the VGA memory window)
+ then those fields of the &s.code;vgaHWRec&e.code; must be initialised
+ before calling this function. Otherwise, this function initialiases
+ the default values of &s.code;0xA0000&e.code; for
+ &s.code;MapPhys&e.code; and &s.code;(64 * 1024)&e.code; for
+ &s.code;MapSize&e.code;. This function must be called before
+ attempting to save or restore the VGA state. If the driver doesn't
+ call it explicitly, the &s.code;vgaHWSave()&e.code; and
+ &s.code;vgaHWRestore()&e.code; functions may call it if they need
+ to access the VGA memory (in which case they will also call
+ &s.code;vgaHWUnmapMem()&e.code; to unmap the VGA memory before
+ exiting).
+
+ </quote>
+
+ &s.code;void vgaHWUnmapMem(ScrnInfoPtr pScrn)&e.code;
+ <quote><p>
+ This function unmaps the VGA memory window. It must only be called
+ after the memory has been mapped. The &s.code;Base&e.code; field
+ of the &s.code;vgaHWRec&e.code; field is set to &s.code;NULL&e.code;
+ to indicate that the memory is no longer mapped.
+
+ </quote>
+
+ &s.code;void vgaHWGetIOBase(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ This function initialises the &s.code;IOBase&e.code; field of the
+ &s.code;vgaHWRec&e.code;. This function must be called before
+ using any other functions that access the video hardware.
+
+ A macro &s.code;VGAHW_GET_IOBASE()&e.code; is also available in
+ &s.code;vgaHW.h&e.code; that returns the I/O base, and this may
+ be used when the vgahw module is not loaded (for example, in the
+ &s.code;ChipProbe()&e.code; function).
+
+ </quote>
+
+ &s.code;void vgaHWUnlock(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ This function unlocks the VGA &s.code;CRTC[0-7]&e.code; registers,
+ and must be called before attempting to write to those registers.
+
+ </quote>
+
+ &s.code;void vgaHWLock(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ This function locks the VGA &s.code;CRTC[0-7]&e.code; registers.
+
+ </quote>
+
+ &s.code;void vgaHWEnable(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ This function enables the VGA subsystem. (Note, this function is
+ present in XFree86 4.1.0 and later.).
+
+ </quote>
+
+ &s.code;void vgaHWDisable(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ This function disables the VGA subsystem. (Note, this function is
+ present in XFree86 4.1.0 and later.).
+
+ </quote>
+
+ &s.code;void vgaHWSave(ScrnInfoPtr pScrn, vgaRegPtr save, int flags)&e.code;
+ <quote><p>
+ This function saves the VGA state. The state is written to the
+ &s.code;vgaRegRec&e.code; pointed to by &s.code;save&e.code;.
+ &s.code;flags&e.code; is set to one or more of the following flags
+ ORed together:
+
+ &s.code;VGA_SR_MODE&e.code;
+ <quote>the mode setting registers are saved</quote>
+ &s.code;VGA_SR_FONTS&e.code;
+ <quote>the text mode font/text data is saved</quote>
+ &s.code;VGA_SR_CMAP&e.code;
+ <quote>the colourmap (LUT) is saved</quote>
+ &s.code;VGA_SR_ALL&e.code;
+ <quote>all of the above are saved</quote>
+
+ The &s.code;vgaHWRec&e.code; and its &s.code;IOBase&e.code; fields
+ must be initialised before this function is called. If
+ &s.code;VGA_SR_FONTS&e.code; is set in &s.code;flags&e.code;, the
+ VGA memory window must be mapped. If it isn't then
+ &s.code;vgaHWMapMem()&e.code; will be called to map it, and
+ &s.code;vgaHWUnmapMem()&e.code; will be called to unmap it
+ afterwards. &s.code;vgaHWSave()&e.code; uses the three functions
+ below in the order &s.code;vgaHWSaveColormap()&e.code;,
+ &s.code;vgaHWSaveMode()&e.code;, &s.code;vgaHWSaveFonts()&e.code; to
+ carry out the different save phases. It is undecided at this
+ stage whether they will remain part of the vgahw module's public
+ interface or not.
+
+ </quote>
+
+ &s.code;void vgaHWSaveMode(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code;
+ <quote><p>
+ This function saves the VGA mode registers. They are saved to
+ the &s.code;vgaRegRec&e.code; pointed to by &s.code;save&e.code;.
+ The registers saved are:
+
+ <quote>
+ &s.code;MiscOut&nl;
+ CRTC[0-0x18]&nl;
+ Attribute[0-0x14]&nl;
+ Graphics[0-8]&nl;
+ Sequencer[0-4]&e.code;
+ </quote>
+
+ The number of registers actually saved may be modified by a prior call
+ to &s.code;vgaHWSetRegCounts()&e.code;.
+
+ </quote>
+
+ &s.code;void vgaHWSaveFonts(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code;
+ <quote><p>
+ This function saves the text mode font and text data held in the
+ video memory. If called while in a graphics mode, no save is
+ done. The VGA memory window must be mapped with
+ &s.code;vgaHWMapMem()&e.code; before to calling this function.
+
+ On some platforms, one or more of the font/text plane saves may be
+ no-ops. This is the case when the platform's VC driver already
+ takes care of this.
+
+ </quote>
+
+ &s.code;void vgaHWSaveColormap(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code;
+ <quote><p>
+ This function saves the VGA colourmap (LUT). Before saving it, it
+ attempts to verify that the colourmap is readable. In rare cases
+ where it isn't readable, a default colourmap is saved instead.
+
+ </quote>
+
+ &s.code;void vgaHWRestore(ScrnInfoPtr pScrn, vgaRegPtr restore, int flags)&e.code;
+ <quote><p>
+ This function programs the VGA state. The state programmed is
+ that contained in the &s.code;vgaRegRec&e.code; pointed to by
+ &s.code;restore&e.code;. &s.code;flags&e.code; is the same
+ as described above for the &s.code;vgaHWSave()&e.code; function.
+
+ The &s.code;vgaHWRec&e.code; and its &s.code;IOBase&e.code; fields
+ must be initialised before this function is called. If
+ &s.code;VGA_SR_FONTS&e.code; is set in &s.code;flags&e.code;, the
+ VGA memory window must be mapped. If it isn't then
+ &s.code;vgaHWMapMem()&e.code; will be called to map it, and
+ &s.code;vgaHWUnmapMem()&e.code; will be called to unmap it
+ afterwards. &s.code;vgaHWRestore()&e.code; uses the three functions
+ below in the order &s.code;vgaHWRestoreFonts()&e.code;,
+ &s.code;vgaHWRestoreMode()&e.code;,
+ &s.code;vgaHWRestoreColormap()&e.code; to carry out the different
+ restore phases. It is undecided at this stage whether they will
+ remain part of the vgahw module's public interface or not.
+
+ </quote>
+
+ &s.code;void vgaHWRestoreMode(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code;
+ <quote><p>
+ This function restores the VGA mode registers. They are restored
+ from the data in the &s.code;vgaRegRec&e.code; pointed to by
+ &s.code;restore&e.code;. The registers restored are:
+
+ <quote>
+ &s.code;MiscOut&nl;
+ CRTC[0-0x18]&nl;
+ Attribute[0-0x14]&nl;
+ Graphics[0-8]&nl;
+ Sequencer[0-4]&e.code;
+ </quote>
+
+ The number of registers actually restored may be modified by a prior call
+ to &s.code;vgaHWSetRegCounts()&e.code;.
+
+ </quote>
+
+ &s.code;void vgaHWRestoreFonts(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code;
+ <quote><p>
+ This function restores the text mode font and text data to the
+ video memory. The VGA memory window must be mapped with
+ &s.code;vgaHWMapMem()&e.code; before to calling this function.
+
+ On some platforms, one or more of the font/text plane restores
+ may be no-ops. This is the case when the platform's VC driver
+ already takes care of this.
+
+ </quote>
+
+ &s.code;void vgaHWRestoreColormap(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code;
+ <quote><p>
+ This function restores the VGA colourmap (LUT).
+
+ </quote>
+
+ &s.code;void vgaHWInit(ScrnInfoPtr pScrn, DisplayModePtr mode)&e.code;
+ <quote><p>
+ This function fills in the &s.code;vgaHWRec&e.code;'s
+ &s.code;ModeReg&e.code; field with the values appropriate for
+ programming the given video mode. It requires that the
+ &s.code;ScrnInfoRec&e.code;'s &s.code;depth&e.code; field is
+ initialised, which determines how the registers are programmed.
+
+ </quote>
+
+ &s.code;void vgaHWSeqReset(vgaHWPtr hwp, Bool start)&e.code;
+ <quote><p>
+ Do a VGA sequencer reset. If start is &s.code;TRUE&e.code;, the
+ reset is started. If start is &s.code;FALSE&e.code;, the reset
+ is ended.
+
+ </quote>
+
+ &s.code;void vgaHWProtect(ScrnInfoPtr pScrn, Bool on)&e.code;
+ <quote><p>
+ This function protects VGA registers and memory from corruption
+ during loads. It is typically called with on set to
+ &s.code;TRUE&e.code; before programming, and with on set to
+ &s.code;FALSE&e.code; after programming.
+
+ </quote>
+
+ &s.code;Bool vgaHWSaveScreen(ScreenPtr pScreen, int mode)&e.code;
+ <quote><p>
+ This function blanks and unblanks the screen. It is blanked when
+ &s.code;mode&e.code; is &s.code;SCREEN_SAVER_ON&e.code; or
+ &s.code;SCREEN_SAVER_CYCLE&e.code;, and unblanked when
+ &s.code;mode&e.code; is &s.code;SCREEN_SAVER_OFF&e.code; or
+ &s.code;SCREEN_SAVER_FORCER&e.code;.
+
+ </quote>
+
+ &s.code;void vgaHWBlankScreen(ScrnInfoPtr pScrn, Bool on)&e.code;
+ <quote><p>
+ This function blanks and unblanks the screen. It is blanked when
+ &s.code;on&e.code; is &s.code;FALSE&e.code;, and unblanked when
+ &s.code;on&e.code; is &s.code;TRUE&e.code;. This function is
+ provided for use in cases where the &s.code;ScrnInfoRec&e.code;
+ can't be derived from the &s.code;ScreenRec&e.code; (while probing
+ for clocks, for example).
+
+ </quote>
+ </quote>
+
+<sect1>VGA Colormap Functions
+<p>
+
+ The vgahw module uses the standard colormap support (see the
+ <ref id="cmap" name="Colormap Handling"> section. This is initialised
+ with the following function:
+
+ <quote>
+ &s.code;Bool vgaHWHandleColormaps(ScreenPtr pScreen)&e.code;
+ </quote>
+
+
+<sect1>VGA Register Access Functions
+<p>
+
+ The vgahw module abstracts access to the standard VGA registers by
+ using a set of functions held in the &s.code;vgaHWRec&e.code;. When
+ the &s.code;vgaHWRec&e.code; is created these function pointers are
+ initialised with the set of standard VGA I/O register access functions.
+ In addition to these, the vgahw module includes a basic set of MMIO
+ register access functions, and the &s.code;vgaHWRec&e.code; function
+ pointers can be initialised to these by calling the
+ &s.code;vgaHWSetMmioFuncs()&e.code; function described above. Some
+ drivers/platforms may require a different set of functions for VGA
+ access. The access functions are described here.
+
+
+ <quote><p>
+ &s.code;void writeCrtc(vgaHWPtr hwp, CARD8 index, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to CRTC register &s.code;index&e.code;.
+
+ </quote>
+
+ &s.code;CARD8 readCrtc(vgaHWPtr hwp, CARD8 index)&e.code;
+ <quote><p>
+ Return the value read from CRTC register &s.code;index&e.code;.
+
+ </quote>
+
+ &s.code;void writeGr(vgaHWPtr hwp, CARD8 index, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to Graphics Controller register
+ &s.code;index&e.code;.
+
+ </quote>
+
+ &s.code;CARD8 readGR(vgaHWPtr hwp, CARD8 index)&e.code;
+ <quote><p>
+ Return the value read from Graphics Controller register
+ &s.code;index&e.code;.
+
+ </quote>
+
+ &s.code;void writeSeq(vgaHWPtr hwp, CARD8 index, CARD8, value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to Sequencer register
+ &s.code;index&e.code;.
+
+ </quote>
+
+ &s.code;CARD8 readSeq(vgaHWPtr hwp, CARD8 index)&e.code;
+ <quote><p>
+ Return the value read from Sequencer register &s.code;index&e.code;.
+
+ </quote>
+
+ &s.code;void writeAttr(vgaHWPtr hwp, CARD8 index, CARD8, value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to Attribute Controller register
+ &s.code;index&e.code;. When writing out the index value this
+ function should set bit 5 (&s.code;0x20&e.code;) according to the
+ setting of &s.code;hwp->paletteEnabled&e.code; in order to
+ preserve the palette access state. It should be cleared when
+ &s.code;hwp->paletteEnabled&e.code; is &s.code;TRUE&e.code;
+ and set when it is &s.code;FALSE&e.code;.
+
+ </quote>
+
+ &s.code;CARD8 readAttr(vgaHWPtr hwp, CARD8 index)&e.code;
+ <quote><p>
+ Return the value read from Attribute Controller register
+ &s.code;index&e.code;. When writing out the index value this
+ function should set bit 5 (&s.code;0x20&e.code;) according to the
+ setting of &s.code;hwp->paletteEnabled&e.code; in order to
+ preserve the palette access state. It should be cleared when
+ &s.code;hwp->paletteEnabled&e.code; is &s.code;TRUE&e.code;
+ and set when it is &s.code;FALSE&e.code;.
+
+ </quote>
+
+ &s.code;void writeMiscOut(vgaHWPtr hwp, CARD8 value)&e.code;
+ <quote><p>
+ Write `&s.code;value&e.code;' to the Miscellaneous Output register.
+
+ </quote>
+
+ &s.code;CARD8 readMiscOut(vgwHWPtr hwp)&e.code;
+ <quote><p>
+ Return the value read from the Miscellaneous Output register.
+
+ </quote>
+
+ &s.code;void enablePalette(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ Clear the palette address source bit in the Attribute Controller
+ index register and set &s.code;hwp->paletteEnabled&e.code; to
+ &s.code;TRUE&e.code;.
+
+ </quote>
+
+ &s.code;void disablePalette(vgaHWPtr hwp)&e.code;
+ <quote><p>
+ Set the palette address source bit in the Attribute Controller
+ index register and set &s.code;hwp->paletteEnabled&e.code; to
+ &s.code;FALSE&e.code;.
+
+ </quote>
+
+ &s.code;void writeDacMask(vgaHWPtr hwp, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to the DAC Mask register.
+
+ </quote>
+
+ &s.code;CARD8 readDacMask(vgaHWptr hwp)&e.code;
+ <quote><p>
+ Return the value read from the DAC Mask register.
+
+ </quote>
+
+ &s.code;void writeDacReadAddress(vgaHWPtr hwp, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to the DAC Read Address register.
+
+ </quote>
+
+ &s.code;void writeDacWriteAddress(vgaHWPtr hwp, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to the DAC Write Address register.
+
+ </quote>
+
+ &s.code;void writeDacData(vgaHWPtr hwp, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to the DAC Data register.
+
+ </quote>
+
+ &s.code;CARD8 readDacData(vgaHWptr hwp)&e.code;
+ <quote><p>
+ Return the value read from the DAC Data register.
+
+ </quote>
+
+ &s.code;CARD8 readEnable(vgaHWptr hwp)&e.code;
+ <quote><p>
+ Return the value read from the VGA Enable register. (Note: This
+ function is present in XFree86 4.1.0 and later.)
+
+ </quote>
+
+ &s.code;void writeEnable(vgaHWPtr hwp, CARD8 value)&e.code;
+ <quote><p>
+ Write &s.code;value&e.code; to the VGA Enable register. (Note: This
+ function is present in XFree86 4.1.0 and later.)
+
+ </quote>
+ </quote>
+
+<sect>Some notes about writing a driver<label id="sample">
+<p>
+
+<em>NOTE: some parts of this are not up to date</em>
+
+The following is an outline for writing a basic unaccelerated driver
+for a PCI video card with a linear mapped framebuffer, and which has a
+VGA core. It is includes some general information that is relevant to
+most drivers (even those which don't fit that basic description).
+
+The information here is based on the initial conversion of the Matrox
+Millennium driver to the ``new design''. For a fleshing out and sample
+implementation of some of the bits outlined here, refer to that driver.
+Note that this is an example only. The approach used here will not be
+appropriate for all drivers.
+
+Each driver must reserve a unique driver name, and a string that is used
+to prefix all of its externally visible symbols. This is to avoid name
+space clashes when loading multiple drivers. The examples here are for
+the ``ZZZ'' driver, which uses the ``ZZZ'' or ``zzz'' prefix for its externally
+visible symbols.
+
+
+<sect1>Include files
+<p>
+
+ All drivers normally include the following headers:
+ <quote>
+ &s.code;"xf86.h"&nl;
+ "xf86_OSproc.h"&nl;
+ "xf86_ansic.h"&nl;
+ "xf86Resources.h"&e.code;
+ </quote>
+ Wherever inb/outb (and related things) are used the following should be
+ included:
+ <quote>
+ &s.code;"compiler.h"&e.code;
+ </quote>
+ Note: in drivers, this must be included after &s.code;"xf86_ansic.h"&e.code;.
+
+ Drivers that need to access PCI vendor/device definitions need this:
+ <quote>
+ &s.code;"xf86PciInfo.h"&e.code;
+ </quote>
+
+ Drivers that need to access the PCI config space need this:
+ <quote>
+ &s.code;"xf86Pci.h"&e.code;
+ </quote>
+
+ Drivers using the mi banking wrapper need:
+
+ <quote>
+ &s.code;"mibank.h"&e.code;
+ </quote>
+
+ Drivers that initialise a SW cursor need this:
+ <quote>
+ &s.code;"mipointer.h"&e.code;
+ </quote>
+
+ All drivers implementing backing store need this:
+ <quote>
+ &s.code;"mibstore.h"&e.code;
+ </quote>
+
+ All drivers using the mi colourmap code need this:
+ <quote>
+ &s.code;"micmap.h"&e.code;
+ </quote>
+
+ If a driver uses the vgahw module, it needs this:
+ <quote>
+ &s.code;"vgaHW.h"&e.code;
+ </quote>
+
+ Drivers supporting VGA or Hercules monochrome screens need:
+ <quote>
+ &s.code;"xf1bpp.h"&e.code;
+ </quote>
+
+ Drivers supporting VGA or EGC 16-colour screens need:
+ <quote>
+ &s.code;"xf4bpp.h"&e.code;
+ </quote>
+
+ Drivers using cfb need:
+ <quote>
+ &s.code;#define PSZ 8&nl;
+ #include "cfb.h"&nl;
+ #undef PSZ&e.code;
+ </quote>
+
+ Drivers supporting bpp 16, 24 or 32 with cfb need one or more of:
+ <quote>
+ &s.code;"cfb16.h"&nl;
+ "cfb24.h"&nl;
+ "cfb32.h"&e.code;
+ </quote>
+
+ The driver's own header file:
+ <quote>
+ &s.code;"zzz.h"&e.code;
+ </quote>
+
+ Drivers must NOT include the following:
+
+ <quote>
+ &s.code;"xf86Priv.h"&nl;
+ "xf86Privstr.h"&nl;
+ "xf86_libc.h"&nl;
+ "xf86_OSlib.h"&nl;
+ "Xos.h"&e.code;&nl;
+ any OS header
+ </quote>
+
+
+<sect1>Data structures and initialisation
+<p>
+
+<itemize>
+ <item>The following macros should be defined:
+ <code>
+#define VERSION <version-as-an-int>
+#define ZZZ_NAME "ZZZ" /* the name used to prefix messages */
+#define ZZZ_DRIVER_NAME "zzz" /* the driver name as used in config file */
+#define ZZZ_MAJOR_VERSION <int>
+#define ZZZ_MINOR_VERSION <int>
+#define ZZZ_PATCHLEVEL <int>
+ </code>
+<p>
+ NOTE: &s.code;ZZZ_DRIVER_NAME&e.code; should match the name of the
+ driver module without things like the "lib" prefix, the "_drv" suffix
+ or filename extensions.
+<p>
+
+ <item>A DriverRec must be defined, which includes the functions required
+ at the pre-probe phase. The name of this DriverRec must be an
+ upper-case version of ZZZ_DRIVER_NAME (for the purposes of static
+ linking).
+<p>
+ <code>
+DriverRec ZZZ = {
+ VERSION,
+ ZZZ_DRIVER_NAME,
+ ZZZIdentify,
+ ZZZProbe,
+ ZZZAvailableOptions,
+ NULL,
+ 0
+};
+ </code>
+
+ <item>Define list of supported chips and their matching ID:
+<p>
+ <code>
+static SymTabRec ZZZChipsets[] = {
+ { PCI_CHIP_ZZZ1234, "zzz1234a" },
+ { PCI_CHIP_ZZZ5678, "zzz5678a" },
+ { -1, NULL }
+};
+ </code>
+<p>
+ The token field may be any integer value that the driver may use to
+ uniquely identify the supported chipsets. For drivers that support
+ only PCI devices using the PCI device IDs might be a natural choice,
+ but this isn't mandatory. For drivers that support both PCI and other
+ devices (like ISA), some other ID should probably used. When other
+ IDs are used as the tokens it is recommended that the names be
+ defined as an &s.code;enum&e.code; type.
+<p>
+ <item>If the driver uses the &s.code;xf86MatchPciInstances(&e.code;)
+ helper (recommended for drivers that support PCI cards) a list that
+ maps PCI IDs to chip IDs and fixed resources must be defined:
+<p>
+ <code>
+static PciChipsets ZZZPciChipsets[] = {
+ { PCI_CHIP_ZZZ1234, PCI_CHIP_ZZZ1234, RES_SHARED_VGA },
+ { PCI_CHIP_ZZZ5678, PCI_CHIP_ZZZ5678, RES_SHARED_VGA },
+ { -1, -1, RES_UNDEFINED }
+}
+ </code>
+<p>
+ <item>Define the &s.code;XF86ModuleVersionInfo&e.code; struct for the
+ driver. This is required for the dynamically loaded version:
+<p>
+ <code>
+static XF86ModuleVersionInfo zzzVersRec =
+{
+ "zzz",
+ MODULEVENDORSTRING,
+ MODINFOSTRING1,
+ MODINFOSTRING2,
+ XF86_VERSION_CURRENT,
+ ZZZ_MAJOR_VERSION, ZZZ_MINOR_VERSION, ZZZ_PATCHLEVEL,
+ ABI_CLASS_VIDEODRV,
+ ABI_VIDEODRV_VERSION,
+ MOD_CLASS_VIDEODRV,
+ {0,0,0,0}
+};
+ </code>
+<p>
+ <item>Define a data structure to hold the driver's screen-specific data.
+ This must be used instead of global variables. This would be defined
+ in the &s.code;"zzz.h"&e.code; file, something like:
+<p>
+ <code>
+typedef struct {
+ type1 field1;
+ type2 field2;
+ int fooHack;
+ Bool pciRetry;
+ Bool noAccel;
+ Bool hwCursor;
+ CloseScreenProcPtr CloseScreen;
+ OptionInfoPtr Options;
+ ...
+} ZZZRec, *ZZZPtr;
+ </code>
+<p>
+ <item>Define the list of config file Options that the driver accepts. For
+ consistency between drivers those in the list of ``standard'' options
+ should be used where appropriate before inventing new options.
+<p>
+ <code>
+typedef enum {
+ OPTION_FOO_HACK,
+ OPTION_PCI_RETRY,
+ OPTION_HW_CURSOR,
+ OPTION_NOACCEL
+} ZZZOpts;
+
+static const OptionInfoRec ZZZOptions[] = {
+ { OPTION_FOO_HACK, "FooHack", OPTV_INTEGER, {0}, FALSE },
+ { OPTION_PCI_RETRY, "PciRetry", OPTV_BOOLEAN, {0}, FALSE },
+ { OPTION_HW_CURSOR, "HWcursor", OPTV_BOOLEAN, {0}, FALSE },
+ { OPTION_NOACCEL, "NoAccel", OPTV_BOOLEAN, {0}, FALSE },
+ { -1, NULL, OPTV_NONE, {0}, FALSE }
+};
+ </code>
+<p>
+</itemize>
+
+<sect1>Functions
+<p>
+
+
+<sect2>SetupProc
+<p>
+
+ For dynamically loaded modules, a &s.code;ModuleData&e.code;
+ variable is required. It is should be the name of the driver
+ prepended to "ModuleData". A &s.code;Setup()&e.code; function is
+ also required, which calls &s.code;xf86AddDriver()&e.code; to add
+ the driver to the main list of drivers.
+
+ <code>
+static MODULESETUPPROTO(zzzSetup);
+
+XF86ModuleData zzzModuleData = { &zzzVersRec, zzzSetup, NULL };
+
+static pointer
+zzzSetup(pointer module, pointer opts, int *errmaj, int *errmin)
+{
+ static Bool setupDone = FALSE;
+
+ /* This module should be loaded only once, but check to be sure. */
+
+ if (!setupDone) {
+ /*
+ * Modules that this driver always requires may be loaded
+ * here by calling LoadSubModule().
+ */
+
+ setupDone = TRUE;
+ xf86AddDriver(&MGA, module, 0);
+
+ /*
+ * The return value must be non-NULL on success even though
+ * there is no TearDownProc.
+ */
+ return (pointer)1;
+ } else {
+ if (errmaj) *errmaj = LDR_ONCEONLY;
+ return NULL;
+ }
+}
+ </code>
+
+<sect2>GetRec, FreeRec
+<p>
+
+ A function is usually required to allocate the driver's
+ screen-specific data structure and hook it into the
+ &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; field.
+ The &s.code;ScrnInfoRec&e.code;'s &s.code;driverPrivate&e.code; is
+ initialised to &s.code;NULL&e.code;, so it is easy to check if the
+ initialisation has already been done. After allocating it, initialise
+ the fields. By using &s.code;xnfcalloc()&e.code; to do the allocation
+ it is zeroed, and if the allocation fails the server exits.
+<p>
+ NOTE:
+ When allocating structures from inside the driver which are defined
+ on the common level it is important to initialize the structure to
+ zero.
+ Only this guarantees that the server remains source compatible to
+ future changes in common level structures.
+
+ <code>
+static Bool
+ZZZGetRec(ScrnInfoPtr pScrn)
+{
+ if (pScrn->driverPrivate != NULL)
+ return TRUE;
+ pScrn->driverPrivate = xnfcalloc(sizeof(ZZZRec), 1);
+ /* Initialise as required */
+ ...
+ return TRUE;
+}
+ </code>
+
+ Define a macro in &s.code;"zzz.h"&e.code; which gets a pointer to
+ the &s.code;ZZZRec&e.code; when given &s.code;pScrn&e.code;:
+
+ <code>
+#define ZZZPTR(p) ((ZZZPtr)((p)->driverPrivate))
+ </code>
+
+ Define a function to free the above, setting it to &s.code;NULL&e.code;
+ once it has been freed:
+
+ <code>
+static void
+ZZZFreeRec(ScrnInfoPtr pScrn)
+{
+ if (pScrn->driverPrivate == NULL)
+ return;
+ xfree(pScrn->driverPrivate);
+ pScrn->driverPrivate = NULL;
+}
+ </code>
+
+<sect2>Identify
+<p>
+
+ Define the &s.code;Identify()&e.code; function. It is run before
+ the Probe, and typically prints out an identifying message, which
+ might include the chipsets it supports. This function is mandatory:
+
+ <code>
+static void
+ZZZIdentify(int flags)
+{
+ xf86PrintChipsets(ZZZ_NAME, "driver for ZZZ Tech chipsets",
+ ZZZChipsets);
+}
+ </code>
+
+<sect2>Probe
+<p>
+
+ Define the &s.code;Probe()&e.code; function. The purpose of this
+ is to find all instances of the hardware that the driver supports,
+ and for the ones not already claimed by another driver, claim the
+ slot, and allocate a &s.code;ScrnInfoRec&e.code;. This should be
+ a minimal probe, and it should under no circumstances leave the
+ state of the hardware changed. Because a device is found, don't
+ assume that it will be used. Don't do any initialisations other
+ than the required &s.code;ScrnInfoRec&e.code; initialisations.
+ Don't allocate any new data structures.
+
+ This function is mandatory.
+
+ NOTE: The &s.code;xf86DrvMsg()&e.code; functions cannot be used from
+ the Probe.
+
+ <code>
+static Bool
+ZZZProbe(DriverPtr drv, int flags)
+{
+ Bool foundScreen = FALSE;
+ int numDevSections, numUsed;
+ GDevPtr *devSections;
+ int *usedChips;
+ int i;
+
+ /*
+ * Find the config file Device sections that match this
+ * driver, and return if there are none.
+ */
+ if ((numDevSections = xf86MatchDevice(ZZZ_DRIVER_NAME,
+ &devSections)) <= 0) {
+ return FALSE;
+ }
+
+ /*
+ * Since this is a PCI card, "probing" just amounts to checking
+ * the PCI data that the server has already collected. If there
+ * is none, return.
+ *
+ * Although the config file is allowed to override things, it
+ * is reasonable to not allow it to override the detection
+ * of no PCI video cards.
+ *
+ * The provided xf86MatchPciInstances() helper takes care of
+ * the details.
+ */
+ /* test if PCI bus present */
+ if (xf86GetPciVideoInfo()) {
+
+ numUsed = xf86MatchPciInstances(ZZZ_NAME, PCI_VENDOR_ZZZ,
+ ZZZChipsets, ZZZPciChipsets, devSections,
+ numDevSections, drv, &usedChips);
+
+ for (i = 0; i < numUsed; i++) {
+ ScrnInfoPtr pScrn = NULL;
+ if ((pScrn = xf86ConfigPciEntity(pScrn, flags, usedChips[i],
+ ZZZPciChipsets, NULL, NULL,
+ NULL, NULL, NULL))) {
+ /* Allocate a ScrnInfoRec */
+ pScrn->driverVersion = VERSION;
+ pScrn->driverName = ZZZ_DRIVER_NAME;
+ pScrn->name = ZZZ_NAME;
+ pScrn->Probe = ZZZProbe;
+ pScrn->PreInit = ZZZPreInit;
+ pScrn->ScreenInit = ZZZScreenInit;
+ pScrn->SwitchMode = ZZZSwitchMode;
+ pScrn->AdjustFrame = ZZZAdjustFrame;
+ pScrn->EnterVT = ZZZEnterVT;
+ pScrn->LeaveVT = ZZZLeaveVT;
+ pScrn->FreeScreen = ZZZFreeScreen;
+ pScrn->ValidMode = ZZZValidMode;
+ foundScreen = TRUE;
+ /* add screen to entity */
+ }
+ }
+ xfree(usedChips);
+ }
+
+#ifdef HAS_ISA_DEVS
+ /*
+ * If the driver supports ISA hardware, the following block
+ * can be included too.
+ */
+ numUsed = xf86MatchIsaInstances(ZZZ_NAME, ZZZChipsets,
+ ZZZIsaChipsets, drv, ZZZFindIsaDevice,
+ devSections, numDevSections, &usedChips);
+ for (i = 0; i < numUsed; i++) {
+ ScrnInfoPtr pScrn = NULL;
+ if ((pScrn = xf86ConfigIsaEntity(pScrn, flags, usedChips[i],
+ ZZZIsaChipsets, NULL, NULL, NULL,
+ NULL, NULL))) {
+ pScrn->driverVersion = VERSION;
+ pScrn->driverName = ZZZ_DRIVER_NAME;
+ pScrn->name = ZZZ_NAME;
+ pScrn->Probe = ZZZProbe;
+ pScrn->PreInit = ZZZPreInit;
+ pScrn->ScreenInit = ZZZScreenInit;
+ pScrn->SwitchMode = ZZZSwitchMode;
+ pScrn->AdjustFrame = ZZZAdjustFrame;
+ pScrn->EnterVT = ZZZEnterVT;
+ pScrn->LeaveVT = ZZZLeaveVT;
+ pScrn->FreeScreen = ZZZFreeScreen;
+ pScrn->ValidMode = ZZZValidMode;
+ foundScreen = TRUE;
+ }
+ }
+ xfree(usedChips);
+#endif /* HAS_ISA_DEVS */
+
+ xfree(devSections);
+ return foundScreen;
+ </code>
+
+<sect2>AvailableOptions
+<p>
+
+ Define the &s.code;AvailableOptions()&e.code; function. The purpose
+ of this is to return the available driver options back to the
+ -configure option, so that an xorg.conf file can be built and the
+ user can see which options are available for them to use.
+
+<sect2>PreInit
+<p>
+
+ Define the &s.code;PreInit()&e.code; function. The purpose of
+ this is to find all the information required to determine if the
+ configuration is usable, and to initialise those parts of the
+ &s.code;ScrnInfoRec&e.code; that can be set once at the beginning
+ of the first server generation. The information should be found in
+ the least intrusive way possible.
+
+ This function is mandatory.
+
+ NOTES:
+ <enum>
+ <item>The &s.code;PreInit()&e.code; function is only called once
+ during the life of the X server (at the start of the first
+ generation).
+
+ <item>Data allocated here must be of the type that persists for
+ the life of the X server. This means that data that hooks into
+ the &s.code;ScrnInfoRec&e.code;'s &s.code;privates&e.code;
+ field should be allocated here, but data that hooks into the
+ &s.code;ScreenRec&e.code;'s &s.code;devPrivates&e.code; field
+ should not be allocated here. The &s.code;driverPrivate&e.code;
+ field should also be allocated here.
+
+ <item>Although the &s.code;ScrnInfoRec&e.code; has been allocated
+ before this function is called, the &s.code;ScreenRec&e.code;
+ has not been allocated. That means that things requiring it
+ cannot be used in this function.
+
+ <item>Very little of the &s.code;ScrnInfoRec&e.code; has been
+ initialised when this function is called. It is important to
+ get the order of doing things right in this function.
+
+ </enum>
+
+ <code>
+static Bool
+ZZZPreInit(ScrnInfoPtr pScrn, int flags)
+{
+ /* Fill in the monitor field */
+ pScrn->monitor = pScrn->confScreen->monitor;
+
+ /*
+ * If using the vgahw module, it will typically be loaded
+ * here by calling xf86LoadSubModule(pScrn, "vgahw");
+ */
+
+ /*
+ * Set the depth/bpp. Use the globally preferred depth/bpp. If the
+ * driver has special default depth/bpp requirements, the defaults should
+ * be specified here explicitly.
+ * We support both 24bpp and 32bpp framebuffer layouts.
+ * This sets pScrn->display also.
+ */
+ if (!xf86SetDepthBpp(pScrn, 0, 0, 0,
+ Support24bppFb | Support32bppFb)) {
+ return FALSE;
+ } else {
+ if (depth/bpp isn't one we support) {
+ print error message;
+ return FALSE;
+ }
+ }
+ /* Print out the depth/bpp that was set */
+ xf86PrintDepthBpp(pScrn);
+
+ /* Set bits per RGB for 8bpp */
+ if (pScrn->depth <= 8) {
+ /* Take into account a dac_6_bit option here */
+ pScrn->rgbBits = 6 or 8;
+ }
+
+ /*
+ * xf86SetWeight() and xf86SetDefaultVisual() must be called
+ * after pScrn->display is initialised.
+ */
+
+ /* Set weight/mask/offset for depth > 8 */
+ if (pScrn->depth > 8) {
+ if (!xf86SetWeight(pScrn, defaultWeight, defaultMask)) {
+ return FALSE;
+ } else {
+ if (weight isn't one we support) {
+ print error message;
+ return FALSE;
+ }
+ }
+ }
+
+ /* Set the default visual. */
+ if (!xf86SetDefaultVisual(pScrn, -1)) {
+ return FALSE;
+ } else {
+ if (visual isn't one we support) {
+ print error message;
+ return FALSE;
+ }
+ }
+
+ /* If the driver supports gamma correction, set the gamma. */
+ if (!xf86SetGamma(pScrn, default_gamma)) {
+ return FALSE;
+ }
+
+ /* This driver uses a programmable clock */
+ pScrn->progClock = TRUE;
+
+ /* Allocate the ZZZRec driverPrivate */
+ if (!ZZZGetRec(pScrn)) {
+ return FALSE;
+ }
+
+ pZzz = ZZZPTR(pScrn);
+
+ /* Collect all of the option flags (fill in pScrn->options) */
+ xf86CollectOptions(pScrn, NULL);
+
+ /*
+ * Process the options based on the information in ZZZOptions.
+ * The results are written to pZzz->Options. If all of the options
+ * processing is done within this function a local variable "options"
+ * can be used instead of pZzz->Options.
+ */
+ if (!(pZzz->Options = xalloc(sizeof(ZZZOptions))))
+ return FALSE;
+ (void)memcpy(pZzz->Options, ZZZOptions, sizeof(ZZZOptions));
+ xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, pZzz->Options);
+
+ /*
+ * Set various fields of ScrnInfoRec and/or ZZZRec based on
+ * the options found.
+ */
+ from = X_DEFAULT;
+ pZzz->hwCursor = FALSE;
+ if (xf86IsOptionSet(pZzz->Options, OPTION_HW_CURSOR)) {
+ from = X_CONFIG;
+ pZzz->hwCursor = TRUE;
+ }
+ xf86DrvMsg(pScrn->scrnIndex, from, "Using %s cursor\n",
+ pZzz->hwCursor ? "HW" : "SW");
+ if (xf86IsOptionSet(pZzz->Options, OPTION_NOACCEL)) {
+ pZzz->noAccel = TRUE;
+ xf86DrvMsg(pScrn->scrnIndex, X_CONFIG,
+ "Acceleration disabled\n");
+ } else {
+ pZzz->noAccel = FALSE;
+ }
+ if (xf86IsOptionSet(pZzz->Options, OPTION_PCI_RETRY)) {
+ pZzz->UsePCIRetry = TRUE;
+ xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "PCI retry enabled\n");
+ }
+ pZzz->fooHack = 0;
+ if (xf86GetOptValInteger(pZzz->Options, OPTION_FOO_HACK,
+ &pZzz->fooHack)) {
+ xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Foo Hack set to %d\n",
+ pZzz->fooHack);
+ }
+
+ /*
+ * Find the PCI slot(s) that this screen claimed in the probe.
+ * In this case, exactly one is expected, so complain otherwise.
+ * Note in this case we're not interested in the card types so
+ * that parameter is set to NULL.
+ */
+ if ((i = xf86GetPciInfoForScreen(pScrn->scrnIndex, &pciList, NULL))
+ != 1) {
+ print error message;
+ ZZZFreeRec(pScrn);
+ if (i > 0)
+ xfree(pciList);
+ return FALSE;
+ }
+ /* Note that pciList should be freed below when no longer needed */
+
+ /*
+ * Determine the chipset, allowing config file chipset and
+ * chipid values to override the probed information. The config
+ * chipset value has precedence over its chipid value if both
+ * are present.
+ *
+ * It isn't necessary to fill in pScrn->chipset if the driver
+ * keeps track of the chipset in its ZZZRec.
+ */
+
+ ...
+
+ /*
+ * Determine video memory, fb base address, I/O addresses, etc,
+ * allowing the config file to override probed values.
+ *
+ * Set the appropriate pScrn fields (videoRam is probably the
+ * most important one that other code might require), and
+ * print out the settings.
+ */
+
+ ...
+
+ /* Initialise a clockRanges list. */
+
+ ...
+
+ /* Set any other chipset specific things in the ZZZRec */
+
+ ...
+
+ /* Select valid modes from those available */
+
+ i = xf86ValidateModes(pScrn, pScrn->monitor->Modes,
+ pScrn->display->modes, clockRanges,
+ NULL, minPitch, maxPitch, rounding,
+ minHeight, maxHeight,
+ pScrn->display->virtualX,
+ pScrn->display->virtualY,
+ pScrn->videoRam * 1024,
+ LOOKUP_BEST_REFRESH);
+ if (i == -1) {
+ ZZZFreeRec(pScrn);
+ return FALSE;
+ }
+
+ /* Prune the modes marked as invalid */
+
+ xf86PruneDriverModes(pScrn);
+
+ /* If no valid modes, return */
+
+ if (i == 0 || pScrn->modes == NULL) {
+ print error message;
+ ZZZFreeRec(pScrn);
+ return FALSE;
+ }
+
+ /*
+ * Initialise the CRTC fields for the modes. This driver expects
+ * vertical values to be halved for interlaced modes.
+ */
+ xf86SetCrtcForModes(pScrn, INTERLACE_HALVE_V);
+
+ /* Set the current mode to the first in the list. */
+ pScrn->currentMode = pScrn->modes;
+
+ /* Print the list of modes being used. */
+ xf86PrintModes(pScrn);
+
+ /* Set the DPI */
+ xf86SetDpi(pScrn, 0, 0);
+
+ /* Load bpp-specific modules */
+ switch (pScrn->bitsPerPixel) {
+ case 1:
+ mod = "xf1bpp";
+ break;
+ case 4:
+ mod = "xf4bpp";
+ break;
+ case 8:
+ mod = "cfb";
+ break;
+ case 16:
+ mod = "cfb16";
+ break;
+ case 24:
+ mod = "cfb24";
+ break;
+ case 32:
+ mod = "cfb32";
+ break;
+ }
+ if (mod && !xf86LoadSubModule(pScrn, mod))
+ ZZZFreeRec(pScrn);
+ return FALSE;
+
+ /* Load XAA if needed */
+ if (!pZzz->noAccel || pZzz->hwCursor)
+ if (!xf86LoadSubModule(pScrn, "xaa")) {
+ ZZZFreeRec(pScrn);
+ return FALSE;
+ }
+
+ /* Done */
+ return TRUE;
+}
+ </code>
+
+<sect2>MapMem, UnmapMem
+<p>
+
+ Define functions to map and unmap the video memory and any other
+ memory apertures required. These functions are not mandatory, but
+ it is often useful to have such functions.
+
+ <code>
+static Bool
+ZZZMapMem(ScrnInfoPtr pScrn)
+{
+ /* Call xf86MapPciMem() to map each PCI memory area */
+ ...
+ return TRUE or FALSE;
+}
+
+static Bool
+ZZZUnmapMem(ScrnInfoPtr pScrn)
+{
+ /* Call xf86UnMapVidMem() to unmap each memory area */
+ ...
+ return TRUE or FALSE;
+}
+ </code>
+
+<sect2>Save, Restore
+<p>
+
+ Define functions to save and restore the original video state. These
+ functions are not mandatory, but are often useful.
+
+ <code>
+static void
+ZZZSave(ScrnInfoPtr pScrn)
+{
+ /*
+ * Save state into per-screen data structures.
+ * If using the vgahw module, vgaHWSave will typically be
+ * called here.
+ */
+ ...
+}
+
+static void
+ZZZRestore(ScrnInfoPtr pScrn)
+{
+ /*
+ * Restore state from per-screen data structures.
+ * If using the vgahw module, vgaHWRestore will typically be
+ * called here.
+ */
+ ...
+}
+ </code>
+
+<sect2>ModeInit
+<p>
+
+ Define a function to initialise a new video mode. This function isn't
+ mandatory, but is often useful.
+
+ <code>
+static Bool
+ZZZModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
+{
+ /*
+ * Program a video mode. If using the vgahw module,
+ * vgaHWInit and vgaRestore will typically be called here.
+ * Once up to the point where there can't be a failure
+ * set pScrn->vtSema to TRUE.
+ */
+ ...
+}
+ </code>
+
+<sect2>ScreenInit
+<p>
+
+ Define the &s.code;ScreenInit()&e.code; function. This is called
+ at the start of each server generation, and should fill in as much
+ of the &s.code;ScreenRec&e.code; as possible as well as any other
+ data that is initialised once per generation. It should initialise
+ the framebuffer layers it is using, and initialise the initial video
+ mode.
+
+ This function is mandatory.
+
+ NOTE: The &s.code;ScreenRec&e.code; (&s.code;pScreen&e.code;) is
+ passed to this driver, but it and the
+ &s.code;ScrnInfoRecs&e.code; are not yet hooked into each
+ other. This means that in this function, and functions it
+ calls, one cannot be found from the other.
+
+ <code>
+static Bool
+ZZZScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+{
+ /* Get the ScrnInfoRec */
+ pScrn = xf86Screens[pScreen->myNum];
+
+ /*
+ * If using the vgahw module, its data structures and related
+ * things are typically initialised/mapped here.
+ */
+
+ /* Save the current video state */
+ ZZZSave(pScrn);
+
+ /* Initialise the first mode */
+ ZZZModeInit(pScrn, pScrn->currentMode);
+
+ /* Set the viewport if supported */
+
+ ZZZAdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
+
+ /*
+ * Setup the screen's visuals, and initialise the framebuffer
+ * code.
+ */
+
+ /* Reset the visual list */
+ miClearVisualTypes();
+
+ /*
+ * Setup the visuals supported. This driver only supports
+ * TrueColor for bpp > 8, so the default set of visuals isn't
+ * acceptable. To deal with this, call miSetVisualTypes with
+ * the appropriate visual mask.
+ */
+
+ if (pScrn->bitsPerPixel > 8) {
+ if (!miSetVisualTypes(pScrn->depth, TrueColorMask,
+ pScrn->rgbBits, pScrn->defaultVisual))
+ return FALSE;
+ } else {
+ if (!miSetVisualTypes(pScrn->depth,
+ miGetDefaultVisualMask(pScrn->depth),
+ pScrn->rgbBits, pScrn->defaultVisual))
+ return FALSE;
+ }
+
+ /*
+ * Initialise the framebuffer.
+ */
+
+ switch (pScrn->bitsPerPixel) {
+ case 1:
+ ret = xf1bppScreenInit(pScreen, FbBase,
+ pScrn->virtualX, pScrn->virtualY,
+ pScrn->xDpi, pScrn->yDpi,
+ pScrn->displayWidth);
+ break;
+ case 4:
+ ret = xf4bppScreenInit(pScreen, FbBase,
+ pScrn->virtualX, pScrn->virtualY,
+ pScrn->xDpi, pScrn->yDpi,
+ pScrn->displayWidth);
+ break;
+ case 8:
+ ret = cfbScreenInit(pScreen, FbBase,
+ pScrn->virtualX, pScrn->virtualY,
+ pScrn->xDpi, pScrn->yDpi,
+ pScrn->displayWidth);
+ break;
+ case 16:
+ ret = cfb16ScreenInit(pScreen, FbBase,
+ pScrn->virtualX, pScrn->virtualY,
+ pScrn->xDpi, pScrn->yDpi,
+ pScrn->displayWidth);
+ break;
+ case 24:
+ ret = cfb24ScreenInit(pScreen, FbBase,
+ pScrn->virtualX, pScrn->virtualY,
+ pScrn->xDpi, pScrn->yDpi,
+ pScrn->displayWidth);
+ break;
+ case 32:
+ ret = cfb32ScreenInit(pScreen, FbBase,
+ pScrn->virtualX, pScrn->virtualY,
+ pScrn->xDpi, pScrn->yDpi,
+ pScrn->displayWidth);
+ break;
+ default:
+ print a message about an internal error;
+ ret = FALSE;
+ break;
+ }
+
+ if (!ret)
+ return FALSE;
+
+ /* Override the default mask/offset settings */
+ if (pScrn->bitsPerPixel > 8) {
+ for (i = 0, visual = pScreen->visuals;
+ i < pScreen->numVisuals; i++, visual++) {
+ if ((visual->class | DynamicClass) == DirectColor) {
+ visual->offsetRed = pScrn->offset.red;
+ visual->offsetGreen = pScrn->offset.green;
+ visual->offsetBlue = pScrn->offset.blue;
+ visual->redMask = pScrn->mask.red;
+ visual->greenMask = pScrn->mask.green;
+ visual->blueMask = pScrn->mask.blue;
+ }
+ }
+ }
+
+ /*
+ * If banking is needed, initialise an miBankInfoRec (defined in
+ * "mibank.h"), and call miInitializeBanking().
+ */
+ if (!miInitializeBanking(pScreen, pScrn->virtualX, pScrn->virtualY,
+ pScrn->displayWidth, pBankInfo))
+ return FALSE;
+
+ /*
+ * If backing store is to be supported (as is usually the case),
+ * initialise it.
+ */
+ miInitializeBackingStore(pScreen);
+
+ /*
+ * Set initial black & white colourmap indices.
+ */
+ xf86SetBlackWhitePixels(pScreen);
+
+ /*
+ * Install colourmap functions. If using the vgahw module,
+ * vgaHandleColormaps would usually be called here.
+ */
+
+ ...
+
+ /*
+ * Initialise cursor functions. This example is for the mi
+ * software cursor.
+ */
+ miDCInitialize(pScreen, xf86GetPointerScreenFuncs());
+
+ /* Initialise the default colourmap */
+ switch (pScrn->depth) {
+ case 1:
+ if (!xf1bppCreateDefColormap(pScreen))
+ return FALSE;
+ break;
+ case 4:
+ if (!xf4bppCreateDefColormap(pScreen))
+ return FALSE;
+ break;
+ default:
+ if (!cfbCreateDefColormap(pScreen))
+ return FALSE;
+ break;
+ }
+
+ /*
+ * Wrap the CloseScreen vector and set SaveScreen.
+ */
+ ZZZPTR(pScrn)->CloseScreen = pScreen->CloseScreen;
+ pScreen->CloseScreen = ZZZCloseScreen;
+ pScreen->SaveScreen = ZZZSaveScreen;
+
+ /* Report any unused options (only for the first generation) */
+ if (serverGeneration == 1) {
+ xf86ShowUnusedOptions(pScrn->scrnIndex, pScrn->options);
+ }
+
+ /* Done */
+ return TRUE;
+}
+ </code>
+
+
+<sect2>SwitchMode
+<p>
+
+ Define the &s.code;SwitchMode()&e.code; function if mode switching
+ is supported by the driver.
+
+ <code>
+static Bool
+ZZZSwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
+{
+ return ZZZModeInit(xf86Screens[scrnIndex], mode);
+}
+ </code>
+
+
+<sect2>AdjustFrame
+<p>
+
+ Define the &s.code;AdjustFrame()&e.code; function if the driver
+ supports this.
+
+ <code>
+static void
+ZZZAdjustFrame(int scrnIndex, int x, int y, int flags)
+{
+ /* Adjust the viewport */
+}
+ </code>
+
+
+<sect2>EnterVT, LeaveVT
+<p>
+
+ Define the &s.code;EnterVT()&e.code; and &s.code;LeaveVT()&e.code;
+ functions.
+
+ These functions are mandatory.
+
+ <code>
+static Bool
+ZZZEnterVT(int scrnIndex, int flags)
+{
+ ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
+ return ZZZModeInit(pScrn, pScrn->currentMode);
+}
+
+static void
+ZZZLeaveVT(int scrnIndex, int flags)
+{
+ ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
+ ZZZRestore(pScrn);
+}
+ </code>
+
+<sect2>CloseScreen
+<p>
+
+ Define the &s.code;CloseScreen()&e.code; function:
+
+ This function is mandatory. Note that it unwraps the previously
+ wrapped &s.code;pScreen->CloseScreen&e.code;, and finishes by
+ calling it.
+
+ <code>
+static Bool
+ZZZCloseScreen(int scrnIndex, ScreenPtr pScreen)
+{
+ ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
+ if (pScrn->vtSema) {
+ ZZZRestore(pScrn);
+ ZZZUnmapMem(pScrn);
+ }
+ pScrn->vtSema = FALSE;
+ pScreen->CloseScreen = ZZZPTR(pScrn)->CloseScreen;
+ return (*pScreen->CloseScreen)(scrnIndex, pScreen);
+}
+ </code>
+
+<sect2>SaveScreen
+<p>
+
+ Define the &s.code;SaveScreen()&e.code; function (the screen
+ blanking function). When using the vgahw module, this will typically
+ be:
+
+ <code>
+static Bool
+ZZZSaveScreen(ScreenPtr pScreen, int mode)
+{
+ return vgaHWSaveScreen(pScreen, mode);
+}
+ </code>
+
+ This function is mandatory. Before modifying any hardware register
+ directly this function needs to make sure that the Xserver is active
+ by checking if &s.code;pScrn&e.code; is non-NULL and for
+ &s.code;pScrn->vtSema == TRUE&e.code;.
+
+<sect2>FreeScreen
+<p>
+
+ Define the &s.code;FreeScreen()&e.code; function. This function
+ is optional. It should be defined if the &s.code;ScrnInfoRec&e.code;
+ &s.code;driverPrivate&e.code; field is used so that it can be freed
+ when a screen is deleted by the common layer for reasons possibly
+ beyond the driver's control. This function is not used in during
+ normal (error free) operation. The per-generation data is freed by
+ the &s.code;CloseScreen()&e.code; function.
+
+ <code>
+static void
+ZZZFreeScreen(int scrnIndex, int flags)
+{
+ /*
+ * If the vgahw module is used vgaHWFreeHWRec() would be called
+ * here.
+ */
+ ZZZFreeRec(xf86Screens[scrnIndex]);
+}
+ </code>
+
+
+</article>
|