[xserver-commit] xfree86/docs ChangeLog.old,NONE,1.1 DDC.HOWTO,NONE,1.1 DebuggingHints,NONE,1.1 Domain.note,NONE,1.1 Options,NONE,1.1 RAC.Notes,NONE,1.1 Registry,NONE,1.1 XF86Conf.cpp,NONE,1.1 XFree86.man,NONE,1.1
Daniel Stone
xserver-commit@pdx.freedesktop.org
- Previous message: [xserver-commit] xfree86/xaa/msb_fixed Makefile.am,NONE,1.1
- Next message: [xserver-commit] xfree86/ddc ddcProperty.c,1.10,1.11 edid.c,1.4,1.5 edid.h,1.7,1.8 interpret_edid.c,1.8,1.9 interpret_vdif.c,1.6,1.7 print_edid.c,1.16,1.17 print_vdif.c,1.5,1.6 vdif.h,1.5,1.6 xf86DDC.c,1.27,1.28 xf86DDC.h,1.11,1.12
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Committed by: daniel
Update of /cvs/xserver/xfree86/docs
In directory pdx:/home/daniel/src/xserver/hw/xfree86/docs
Added Files:
ChangeLog.old DDC.HOWTO DebuggingHints Domain.note Options
RAC.Notes Registry XF86Conf.cpp XFree86.man
Log Message:
Checkin #3: Makefile.am's, files that've been moved and/or added.
--- NEW FILE: ChangeLog.old ---
XFree86 4.3.99.903 (xx January 2004)
783. Xterm followup fix for Bugzilla #981 (Thomas Dickey).
782. Fix EXT version of vertex arrays (DRI Project).
781. Fix long-standing off-by-one bug in calculating dimensions of single
(private) back cliprect when the window is partially offscreen in
libdri.a (Keith Whitwell)
780. Don't do the MGAISBUSY() loop in MGAStormSync() for Mystique cards
because this reportedly results in an infinite loop (Bugzila #85,
David Dawes, reported by Phil ??? and Stéphane VOLTZ).
779. Make sure the r128 driver enables the hsync and vsync signals after
programming a video mode (Bugzilla #935, Kevin Martin).
778. Fix Multitexture problems with vertex arrays and indirect rendering
(Bugzilla #1092, DRI Project).
777. Fix SecondaryColor & FogColor when indirect rendering (Bugzilla #1091,
DRI Project).
776. Fix build failures on Mac OS X 10.1.x (Torrey T. Lyons).
775. Fix a timing problem in the nsc driver that prevents the display from
working in some cases (Bugzilla #840, Hansruedi Glauser, Alan Hourihane).
774. Via driver workaround to handle setting WC for the video memory when
[...18575 lines suppressed...]
8. Fix incorrect usage of $(DESTDIR) in some lnxLib.rules.
7. Code to detect 928-P (Harald Koenig).
6. Fix cbrt() in mi/ so that it can handle negative arguments.
5. Fix for line clipping problem in cfb.banked (Glenn Lai).
XFree86 3.0a (28 April 1994)
4. Add XFree86 server names to the list in xinit.
3. Set XawI18nDefines correctly for SVR4.0.
2. Update ncr.cf to pick up AllocateLocalDefines when building servers.
1. Fold in client/lib OS support not picked up by the XC.
XFree86 3.0 (26 April 1994)
$XFree86: xc/programs/Xserver/hw/xfree86/CHANGELOG,v 3.3125 2004/02/01 02:19:58 dickey Exp $
--- NEW FILE: DDC.HOWTO ---
DDC.HOWTO
This file describes how to add DDC support to a chipset driver.
1) DDC INITIALIZATION
When implementing DDC in the driver one has the choice between
DDC1 and DDC2.
DDC1 data is contiuously transmitted by a DDC1 capable display
device. The data is send serially over a data line; the Vsync
signal serves as clock. Only one EDID 1.x data block can be
transmitted using DDC1. Since transmission of an EDID1 block
using a regular Vsync frequency would take up several seconds
the driver can increase the Vsync frequency to up to 25 kHz as
soon as it detects DDC1 activety on the data line.
DDC2 data is transmitted using the I2C protocol. This requires
an additional clock line. DDC2 is capable of transmitting EDID1
and EDID2 block as well as a VDIF block on display devices that
support these.
Display devices switch into the DDC2 mode as soon as they detect
activety on the DDC clock line. Once the are in DDC2 mode they
stop transmitting DDC1 signals until the next power cycle.
Some graphics chipset configurations which are not capable of
DDC2 might still be able to read DDC1 data. Where available
DDC2 it is preferrable.
All relevant prototypes and defines are in xf86DDC.h.
DDC2 additionally requires I2C support. The I2C prototypes
are in xf86i2c.h.
DDC1 Support:
The driver has to provide a read function which waits for the
end of the next Vsync signal and reads in and returns the status
of the DDC line:
unsigned int XXX_ddc1Read(ScrnInfoPtr pScrn)
Additionally a function is required to inclrease the Vsync
frequency to max. 25 kHz.
void XXX_ddc1SetSpeed(ScrnInfoPtr pScrn, xf86ddcSpeed speed)
If the speed argument is DDC_FAST the function should increase
the Vsync frequency on DDC_SLOW it should restore the original
value. For convenience a generic ddc1SetSpeed() function is provided
in the vga module for VGA-like chipsets.
void vgaHWddc1SetSpeed(ScrnInfoPtr pScrn, sf86ddcSpeed speed).
To read out the DDC1 data the driver should call
xf86MonPtr xf86DoEDID_DDC1(int scrnIndex,
void (*DDC1SetSpeed)(ScrnInfoPtr, xf86ddcSpeed),
unsigned int (*DDC1Read)(ScrnInfoPtr))
in PreInit(). DDC1SetSpeed is a pointer to the SetSpeed()
function, DDC1Read has to point to the DDC1 read function.
The function will return a pointer to the xf86Monitor structure
which contains all information retreived by DDC.
NULL will be returned on failure.
DDC2 Support
To read out DDC2 information I2C has to be initialized first.
(See documentation for the i2c module).
The function
xf86MonPtr xf86DoEDID_DDC2(int scrnIndex, I2CBusPtr pBus)
is provided to read out and process DDC2 data. A pointer
to the I2CBusRec of the appropriate I2C Bus has to be passed
as the second argument.
The function will return a pointer to the xf86Monitor structure
which contains all information retreived by DDC.
NULL will be returned on failure.
Printing monitor parameters
To print out the information contained in the xf86Monitor
structure the function
xf86MonPtr xf86PrintEDID(xf86MonPtr monitor)
is provided.
Further processing of the xf86Monitor structure is not yet
implemented. Howerver it is planned to use the information
about video modes, gamma values etc.
Therefore it is strongly recommended to read out DDC data
before any video mode processing is done.
$XFree86: xc/programs/Xserver/hw/xfree86/ddc/DDC.HOWTO,v 1.3 1999/09/25 14:37:16 dawes Exp $
--- NEW FILE: DebuggingHints ---
Xserver Debugging
=================
This file is intended to collect helpful hints on Xserver debugging.
I merely outline my experiences here. Somebody else might have better
methods on doing it. This person is therefore invited to share this
experience with the rest of the world by adding it here.
Paul Flinders has made some patches to gdb to add support for loadable
modules. This version of gdb is currently available as binary for
Linux/x86 on Paul's web site:
www.dawa.demon.co.uk/xfree-gdb
This web-site also contains the patches to gdb 4.18 so you may port it
to other platforms.
It loads the module symbols and supports all gdb features like
breakpointing, disassembling and single stepping. It also shows the
exact location of a signal 11. Paul has fixed the code so that all of
this is working even if using modules compiled without -g. You can
find his latest version on his web site.
If no module aware gdb is available the following hints might help:
1. Use remote login. This can be done thru a network connection or
simply by connecting a serial console. This enables you to watch
the Xservers output while running set breakpoints with gdb etc.
Don't even try to run the Xserver from a system console. Whenever
something happens gdb waits for input. However the Xserver has
locked the system console including the keyboard, therefore you'll
never be able to send any input to gdb. Even if your process
doesn't crash or you haven't set any breakpoints a vt switch can be
hazardous: When doing vt switching a signal is sent; unless you did
gdb> handle SIGUSR1 nostop
gdb waits for you to continue the program which cannot happen as
you don't have access to gdb's console.
2. You can compile any source file with debugging symbols to obtain
more information about where an error occurred. Simply go to the
directory which holds the corresponding object file and do:
# rm <file>.o
# xc/config/util/makeg.sh <file>.o
After relinking the server or module gdb is able to obtain the
necessary debugging information and will show the exact line in the
source where the error ccurred. See also:
xc/config/util/makeg.man.
3. In some cases it might be useful to have the assembler output of a
compiled source file. This can be obtained by doing:
# make <file>.s
or
# xc/config/util/makeg.sh <file>.s
Make will use exactly the same rules it uses for building *.o files.
4. In some cases it might be useful to set breakpoints in modules. If
no module aware gdb is available you should add a call to one of
the three dummy breakpoint functions
xf86Break1(), xf86Break2() and xf86Break3()
to the source file and recompile the module. You now just have to
set a breakpoint onto the appropriate dummy functions. These
functions are located in the core part of the server and therefore
will be available any time.
5. Without module support gdb is not able to print the function where
an error occurred in a module.
If you get a line like:
(gdb) bt
#0 0x823b4f5 in ?? ()
....
You may obtain the function the address belongs to by calling
LoaderPrintSymbol():
(gdb) call LoaderPrintSymbol(0x823b4f5)
The symbol returned might not always be the name of the function
which contains the address. In case of static functions the symbol
is not known to the loader. However LoaderPrintSymbol() will print
the nearest known function and the offset from its start. You may
easily find the exact location of the address if you do:
# objdump --disassemble <file>.o
<file>.o is the name of the object file containing the symbol printed.
6. Locating static symbols in modules is simpler if the module is a
single object file instead of a library. Such a object file can
easily be build from a library: # mkdir tmp # cd tmp; ar x
module-path/<libname>.a # ld -r *.o -o module-path/<name>.o
When calling LoaderPrintSymbol() the closes public symbol will be
printed together with the offset from the symbol's address. If a
static symbol comes before the first public symbol in a module The
following trick may help:
create a file 1-<name>.c in tmp/
containing:
void Dummy-<name>() {}
Compile it:
# gcc -c 1-<name>.c
and do the link step above.
This way Dummy-<name>() will be the first public function in the
module. All addresses in static function can now be printed
relatively to this address if no other public function comes before
this static one.
7. In some situations it is quite helpful to add debugging symbols to
the binary. This can be done per object file. Simply remove the
object file and do
# makeg
When looking for a bug in a module these debugging infos can be
very helpful: Calling LoaderPrintSymbol() as described above will
return a function and an offset giving the exact location of the
address with respect to this function entry point. When
disassembling an object file with debugging symbols: # objdump -d
-l <file>.o one will receive a disassembled output containing line
number information. Thus one can locate the exact line of code
where the error occurred.
8. To quickly trace the value of a variable declared in a module three
dummy variables have been added to the core part:
CARD32 xf86DummyVar1;
CARD32 xf86DummyVar2;
CARD32 xf86DummyVar3;
The variable can be assigned to one of them. One can then use gdb
to return the value of this variable:
gdb> p /x xf86DummyVar1
9. Sometimes it might be useful to check how the preprocessor replaced
symbols. One can obtain a preprocessed version of the source file
by doing:
make <filename>.i
This will generate a preprocessed source in <filename>.i.
10. xfree() can catch if one tries to free a memory range twice. You
will get the message:
Xalloc error: range already freed in Xrealloc() :-(
To find the location from which xfree() was called one can
breakpoint on XfreeTrap(). The backtrace should show the origin of the
call this call.
11. To access mapped physical memory the following functions might be
useful.
These may be used to access physical memory that was mapped using
the flags VIDMEM_FRAMEBUFFER or VIDMEM_MMIO32:
CARD8 xf86PeekFb8(CARD8 *p);
CARD16 xf86PeekFb16(CARD16 *p);
CARD32 xf86PeekFb32(CARD32 *p);
void xf86PokeFb8(CARD8 *p, CARD8 v);
void xf86PokeFb16(CARD16 *p, CARD16 v);
void xf86PokeFb32(CARD16 *p, CARD32 v);
Physical memory which was mapped by setting VIDMEM_MMIO should be
accessed using the following. Here the base address to which the
memory is mapped and the offset are required separately.
CARD8 xf86PeekMmio8(pointer Base, unsigned long Offset);
CARD16 xf86PeekMmio16(pointer Base, unsigned long Offset);
CARD32 xf86PeekMmio32(pointer Base, unsigned long Offset);
void xf86PokeMmio8(pointer Base, unsigned long Offset, CARD8 v);
void xf86PokeMmio16(pointer Base, unsigned long Offset, CARD16 v);
void xf86PokeMmio32(pointer Base, unsigned long Offset, CARD32 v);
--- NEW FILE: Domain.note ---
The purpose of the changes described here is to implement a more general
framework for multi-head on systems with more than one host-to-PCI bridge.
The changes also implement a basic port of XFree86 to SPARC Solaris.
These changes are derived from David S. Miller's submission #4653 to the
patch list. David Andrew of Sun Microsystems was also kind enough to
arrange for a hardware loan for development of these changes.
These changes are known to work on several SPARC SunOS and UltraSPARC
Linux configurations. Linux kernel work is in progress to port these
changes to Linux/PowerPC.
Several loose ends still need to be addressed before these changes can be
considered stable. The bulk of this note is devoted to enumerating what
remains to be done, along with other notes, broken down into various broad
categories.
SPARC SunOS (aka Solaris)
-------------------------
- An overview of this XFree86 port is available in README.Solaris.
- The keyboard map code in hw/xfree86/os-support/sunos/sun_kbdEv.c needs
to be extended to handle more than only the sun5 keyboard I targeted it
for. Even for the sun5, the map is incomplete as several keys are not
mapped. What is there is just barely usable.
- On exit, the server will zero out /dev/fb, but that might not be the
right thing to do for all primary adapters. This does however
appear to emulate the behaviour of Sun's commercial servers. It also
eliminates the need for output drivers to save and restore video memory
contents. (They still need to save/restore the mode timing however.)
This also chimes into a long-standing XFree86 policy to not save/restore
video memory contents if the mode on entry is found to be non-VGA, a
policy several existing drivers comply with.
- The SBUS drivers (sunbw2, suncg14, suncg3, suncg6, sunffb, sunleo and
suntcx), the common layer's SBUS code and the fbdev driver have all
only been compile tested. There are likely to be Linux'isms within
them that remain to be dealt with.
- It still needs to be verified whether or not this work adversely
affected support for ix86 Solaris.
UltraSPARC Linux
----------------
- Although this code can be compiled using any Linux/SPARC64 kernel, it
can only run successfully using 2.4.12 or later.
- I haven't had time to sufficiently dig into XKB to properly configure it
for sun5 keyboards. Given XFree86 on Linux/SPARC has been around for a
while, it's likely someone has already done this, and I'd appreciate
receiving a copy of a working XF86Config input section.
PowerPC Linux
-------------
- As mentioned above, kernel work is in progress to port this PCI scheme
to Linux/PowerPC.
- Aside from kernel work, the inX() and outX() definitions in compiler.h
will need to be changed to do something akin to their SPARC definitions,
i.e. consider their port argument to be a virtual address.
Other Linux ports to multi-domain architectures
-----------------------------------------------
- Comments in os-support/bus/linuxPci.c document the kernel interface
required to port these changes. In short, Linux ports, such as Alpha
and mips, should follow SPARC and PowerPC's lead in providing support to
mmap() PCI devices through their /proc/bus/pci pseudo-files and to treat
such requests for host bridges as requests to mmap() space provided by
these bridges.
Other OS's
----------
- In the right hands, either linuxPci.c or sparcPci.c can be used as a
guide for what would need to be done to port this scheme to other OS's.
Perhaps the largest difference between the two (in terms of interface to
the common layer) is that the SunOS port includes internally generated
domain numbers in PCITAG's, whereas the Linux port doesn't need to. The
remainder of the PCI code (which is OS-independent) can handle either
scheme.
- Required entry points are xf86GetPciDomain(), xf86MapDomainMemory(),
xf86MapDomainIO() and xf86ReadDomainMemory(). Replacements for
xf86BusAccWindowsFromOS(), xf86PciBusAccWindowsFromOS() and
xf86AccResFromOS() might also be required.
- Development of these changes has detected the fact that the XFree86 port
to the PowerMax OS is broken, and has been for some time, i.e. since
shortly after its introduction, back in the 3.9* days.
SPARC PCI (OS-independent)
--------------------------
- The "Simba" PCI-to-PCI bridge used in SPARC's does not implement VGA
routing, as defined in the PCI specs. Fortunately, OpenPROM seems to
always route VGA resources to the bus with PCI connectors, but this also
causes the common layer to not mark any PCI adapter as primary.
Multiple PCI domains (architecture- and OS-independent)
-------------------------------------------------------
- This implementation assumes every host-to-PCI bridge provides access to
a separate PCI domain. Each such domain provides three different
"address" spaces: PCI configuration, I/O and memory. The
implementation can also deal with situations where more than one PCI
domain share (different subsets of) the same PCI configuration space. I
have unconfirmed information that suggests it might be necessary to also
allow the sharing of PCI memory spaces.
- This implementation also assumes the CPU's physical address space
includes the entirety of each domain's I/O and memory spaces. I know
this'll need to be changed to deal with the so-called UniNorth bridge,
found on PowerPC's, which allows access to only a subset of the memory
space behind it.
- Ideally, the common layer should mark as primary up to one PCI adapter
per domain. This has yet to be done.
- Something needs to be done about PCI master aborts on primary buses.
For details on this, see my long-winded diatribe in sparcPci.c, and
related comments in linuxPci.c. Suffice it to say here that I see the
eventual implementation of host bridge drivers within XFree86 as
unavoidable at this point.
- DGA is broken on multi-domain platforms. The information passed to the
client to locate the framebuffer still needs to be revised. The best way
to deal with this is to change all drivers' OpenFramebuffer() function to
call a common layer routine to set the device name and displacements to be
returned to the DGA client.
Output drivers
--------------
Most drivers currently used on ix86 need(ed) source code changes.
- Calls to xf86ReadBIOS() and xf86MapVidMem() were replaced with calls to
xf86ReadDomainMemory() and xf86MapDomainMemory() respectively. Except
for the "ati" and "atimisc" modules, this has already been done.
- All ix86-style I/O port numbers need to be declared as an IOADDRESS, a
type defined in xf86Pci.h as "unsigned long". Such port numbers also
need to be offset by a displacement which is also defined as an
IOADDRESS. Before a driver's PreInit() is called, the common layer
makes this displacement available in ScrnInfoRec.domainIOBase. For
single-domain architectures, such as ix86, domainIOBase will always be
zero. Current use of vgaHWRec.PIOOffset has also been adjusted
accordingly. Some drivers have been changed to keep a copy of this
displacement in their private structure. Internally, an IOADDRESS is
actually a pointer that has been recasted to an unsigned long, but the
common layer "hides" this fact from the driver ABI, which means that I/O
port numbers, as seen by drivers, remain as integers rather than
addresses. Aside from the ati and atimisc modules, s3, sis and tseng
are the only modules left whose I/O still needs to be converted (I've
temporarily run out of steam).
- Note that these conversions are not necessarily sufficient to produce
drivers that will work on any given multi-domain architecture. A driver
that, for example, had endianness problems, still does. But, at least,
these conversions, along with the supporting common layer changes, make
PCI drivers more widely amenable to porting.
- rdinx(), wrinx(), modinx(), testrg(), testinx() and testinx2() are not
given enough information to allow for the relocation of their I/O. They
are consequently being deleted. The apm and ark drivers, the only
remaining callers of the first three, have been changed to use local
definitions instead. The last three (test*()) were already unused.
- As a temporary measure, these changes completely disable ISA-style
probing on SPARC's and PowerPC's. This means that driver calls to
xf86MatchIsaInstances(), while still valid, will always return detection
failure on SPARC's and PowerPC's. This will be dealt with when a more
general master abort handling scheme is implemented.
- I need to make a decision about the master abort issues mentionned above
before I can convert the "ati" and "atimisc" modules. Consequently,
these modules still need to be compiled with -DAVOID_CPIO on
multi-domain architectures, and support for Mach64 variants as
non-primary heads is not yet available.
$XFree86: xc/programs/Xserver/hw/xfree86/Domain.note,v 1.2 2002/01/25 21:55:49 tsi Exp $
--- NEW FILE: Options ---
!!
!! Copyright (c) 2001 by The XFree86 Project, Inc.
!!
!! Permission is hereby granted, free of charge, to any person obtaining a
!! copy of this software and associated documentation files (the "Software"),
!! to deal in the Software without restriction, including without limitation
!! the rights to use, copy, modify, merge, publish, distribute, sublicense,
!! and/or sell copies of the Software, and to permit persons to whom the
!! Software is furnished to do so, subject to the following conditions:
!!
!! The above copyright notice and this permission notice shall be included in
!! all copies or substantial portions of the Software.
!!
!! THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
!! IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
!! FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
!! THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
!! WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
!! OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
!! SOFTWARE.
!!
!! Except as contained in this notice, the name of the XFree86 Project shall
!! not be used in advertising or otherwise to promote the sale, use or other
!! dealings in this Software without prior written authorization from the
!! XFree86 Project.
!!
!! $XFree86: xc/programs/Xserver/hw/xfree86/Options,v 1.10 2003/02/15 06:46:30 paulo Exp $
!! XAA options
xaa.XaaNoCPUToScreenColorExpandFill:\
Disables accelerated rectangular expansion blits from source patterns \
stored in system memory (using a memory-mapped aperture).
xaa.XaaNoColor8x8PatternFillRect:\
Disables accelerated fills of a rectangular region with a full-color pattern.
xaa.XaaNoColor8x8PatternFillTrap:\
Disables accelerated fills of a trapezoidal region with a full-color pattern.
xaa.XaaNoDashedBresenhamLine:\
Disables accelerated dashed Bresenham line draws.
xaa.XaaNoDashedTwoPointLine:\
Disables accelerated dashed line draws between two arbitrary points.
xaa.XaaNoImageWriteRect:\
Disables acclerated transfers of full-color rectangular patterns from \
system memory to video memory (using a memory-mapped aperture).
xaa.XaaNoMono8x8PatternFillRect:\
Disables accelerated fills of a rectangular region with a monochrome pattern.
xaa.XaaNoMono8x8PatternFillTrap:\
Disables accelerated fills of a trapezoidal region with a monochrome pattern.
xaa.XaaNoOffscreenPixmaps:\
Disables accelerated draws into pixmaps stored in offscreen video memory.
xaa.XaaNoPixmapCache:\
Disables caching of patterns in offscreen video memory.
xaa.XaaNoScanlineCPUToScreenColorExpandFill:\
Disables accelerated rectangular expansion blits from source patterns \
stored in system memory (one scan line at a time).
xaa.XaaNoScanlineImageWriteRect:\
Disables accelerated transfers of full-color rectangular patterns from \
system memory to video memory (one scan line at a time).
xaa.XaaNoScreenToScreenColorExpandFill:\
Disables accelerated rectangular expansion blits from source patterns \
stored in off-screen video memory.
xaa.XaaNoScreenToScreenCopy:\
Disables accelerated copies of rectangular regions from one part of video \
memory to another part of video memory.
xaa.XaaNoSolidBresenhamLine:\
Disables accelerated solid Bresenham line draws.
xaa.XaaNoSolidFillRect:\
Disables accelerated solid-color fills of rectangles.
xaa.XaaNoSolidFillTrap:\
Disables accelerated solid-color fills of Bresenham trapezoids.
xaa.XaaNoSolidHorVertLine:\
Disables accelerated solid horizontal and vertical line draws.
xaa.XaaNoSolidTwoPointLine:\
Disables accelerated solid line draws between two arbitrary points.
!! DDC Options
ddc.NoDDC:\
Disables DDC (Display Data Channel) so that the Xserver doesn't try to talk to\
the Monitor. \
Default: off, implies DDC is used.
ddc.NoDDC1:\
Disables use of DDC version 1 (DDC using vertical refresh). \
Default: off, implies DDC1 is used.
ddc.NoDDC2:\
Disables use of DDC version 2 (DDC using I2C - usually over vga connector). \
Default: off, implies DDC2 is used.
!! FBDev options
fbdev.fbdev:\
The framebuffer device to use. \
Default: /dev/fb0.
fbdev.ShadowFB:\
Enable or disable use of the shadow framebuffer layer. \
Default: on.
fbdev.Rotate:\
Enable rotation of the display. The supported values are "CW" (clockwise, \
90 degrees), "UD" (upside down, 180 degrees) and "CCW" (counter clockwise, \
270 degrees). Implies use of the shadow framebuffer layer. \
Default: off.
!! MGA options
mga.ColorKey:\
Set the colormap index used for the transparency key for the depth 8 plane \
when operating in 8+24 overlay mode. The value must be in the range 2-255. \
Default: 255.
!mga.HWcursor:\
!Enable or disable the HW cursor. Default: on.
mga.MGASDRAM:\
Specify whether G100, G200 or G400 cards have SDRAM. The driver attempts to \
auto-detect this based on the card's PCI subsystem ID. This option may be \
used to override that auto-detection. The mga driver is not able to \
auto-detect the presence of of SDRAM on secondary heads in multihead \
configurations so this option will often need to be specified in multihead \
configurations. Default: auto-detected.
mga.NoAccel:\
Disable or enable 2D hardware acceleration. Default: acceleration is enabled.
mga.OverclockMem:\
Set clocks to values used by some commercial X-Servers (G100, G200 and \
G400 only). Default: off.
mga.Overlay:\
Enable 8+24 overlay mode. Only appropriate for depth 24. (Note: the G100 is \
unaccelerated in the 8+24 overlay mode due to a missing hardware feature). \
Default: off.
mga.PciRetry:\
Enable or disable PCI retries. Default: off.
mga.Rotate:\
Rotate the display clockwise or counterclockwise. This mode is unaccelerated. \
Default: no rotation.
mga.ShadowFB:\
Enable or disable use of the shadow framebuffer layer. Default: off. \
mga.SyncOnGreen:\
Enable or disable combining the sync signals with the green signal. \
Default: off.
mga.UseFBDev:\
Enable or disable use of on OS-specific fb interface (and is not supported \
on all OSs). See fbdevhw(4) for further information. Default: off.
mga.VideoKey:\
This sets the default pixel value for the YUV video overlay key. \
Default: undefined.
mga.TexturedVideo:\
This has XvImage support use the texture engine rather than the video \
overlay. This option is only supported by the G200 and G400, and only in \
16 and 32 bits per pixel. Default: off.
mga.NoHal:\
Matrox provides a "Hardware Abstraction Layer", \
a separate binary which enables extra hardware features from G400 onwards. \
Default: HAL is used.
!mga.DigitalScreen:\
! Option Ignored. Drivers auto-detect Digital output if they support it at all.
!Default: Auto-detected.
! mga.TV:\
! Option Ignored. Drivers auto-detect TV if they support TV out at all.
!Default: Auto-detected.
mga.TVStandard:\
(HAL only) Picture standard for TV out. Use "PAL" for 50Hz PAL. \
Default: 60Hz NTSC.
mga.CableType:\
(HAL only) Set the cable type for TV out. Options are "SCART_RGB", \
"SCART_COMPOSITE", or "SCART_TYPE2". Any other string enables the default. \
Default: YC_COMPOSITE.
mga.SwappedHead:\
(HAL only) For Dual Head cards, reverse relationship between CRTC picture \
generators and video output sockets. \
Especially useful with TV or digital outputs. \
Default: CRTC1 generates output for socket 1 and CRTC2 generates output for socket 2.
mga.Crtc2Half:\
In dual head mode, allow CRTC2 to use half of the video memory. \
Default: CRTC2 uses min{8MB, half video RAM}, but see also Crtc2Ram.
mga.Crtc2Ram:\
In dual head mode, CRTC2 will use this many KB of video memory. \
Overrrides Crtc2Half. \
Default: CRTC2 uses min{8MB, half video RAM}, but see also Crtc2Half.
mga.ShowCache:\
An option for hackers. The pixmap cache lives in off-screen video memory. \
This option extends the virtual desktop to show this part of video memory. \
Default: Off.
mga.AGPMode:\
AGP bus speed multiplier, used by DRI. \
Default: x1 (slowest but most stable).
!! R128 options
!r128.SWcursor: \
!Selects software cursor. \
!Default: off.
r128.NoAccel:\
Enables or disables all hardware acceleration. \
Default: on.
r128.Dac6Bit:\
Enables or disables the use of 6 bits per color component when in 8 bpp \
mode (emulates VGA mode). \
Default: off.
r128.VideoKey:\
This overrides the default pixel value for the YUV video overlay key. \
Default: undefined.
r128.Display:\
Select display mode for devices which support flat panels. Supported\
modes are "FP", "CRT", "Mirror", "BIOS". \
Default: "FP".
r128.ProgramFPRegs:\
Enable or disable programming of the flat panel registers.\
Beware that this may damage your panel, so use at your own risk. \
Default: device dependant.
r128.PanelWidth:\
Override flat panel width in pixels. \
Default: determined using BIOS.
r128.PanelHeight:\
Override flat panel height in pixels. \
Default: determined using BIOS.
r128.UseFBDev:\
Enable or disable use of on OS-specific fb interface (and is not supported \
on all OSs). See fbdevhw(4) for further information. Default: off.
r128.DMAForXv:\
Try or don't try to use DMA for Xv image transfers. This will reduce CPU \
usage when playing big videos like DVDs, but may cause instabilities. \
Default: off.
!! Radeon options
radeon.SWcursor:\
Selects software cursor. Default: off.
radeon.NoAccel:\
Disables all hardware acceleration. Default: off.
radeon.Dac6Bit:\
Enables or disables the use of 6 bits per color component when in 8 bpp \
mode (emulates VGA mode). Default: off.
radeon.VideoKey:\
This overrides the default pixel value for the YUV video overlay key. \
Default: undefined.
radeon.UseFBDev:\
Enable or disable use of an OS-specific framebuffer device interface \
(which is not supported on all OSs). Default: off.
radeon.AGPMode:\
Set AGP data transfer rate. (used only when DRI is enabled) \
Valid choices: 1 (default), 2 and 4
radeon.AGPFastWrite:\
Enable AGP fast write. (used only when DRI is enabled) \
Default: off.
radeon.ForcePCIMode:\
Force to use PCI GART for DRI acceleration. (used only when DRI is enabled) \
Default: off.
radeon.DDCMode:\
Force to use the modes queried from the connected monitor. Default: off.
radeon.CloneDisplay:\
This option is only used for dual-head cards with only single screen section \
specified in the configuration file. Valid choices: \
0 - disable (one CRTC used for both heads) \
1 - auto-detect (default) \
2 - force on \
3 - auto-detect + 2nd head overlay \
4 - force on + 2nd head overlay \
radeon.CloneMode:\
Set the first mode for the secondary head. It can be different from the modes \
used for the primary head. If you don't have this line while clone is on, the \
modes specified for the primary head will be used for the secondary head.
radeon.CloneHSync:\
Set the horizontal sync range for the secondary monitor. It is not required if \
a DDC capable monitor is connected. Default: undefined.
radeon.CloneVRefresh:\
Set the vertical refresh range for the secondary monitor. It is not required \
if a DDC capable monitor is connected. Default: undefined.
radeon.PanelOff:\
Disable panel output. Only used when clone is enabled. Default: off.
radeon.EnablePageFlip:\
Enable page flipping for 3D acceleration. This will increase performance but \
not work correctly in some rare cases. Default: off.
!! NeoMagic options
neo.StrangeLockups:\
Before XFree86 version 4.2.0 many NeoMagic systems experienced \
strange lockups unless they used the options \
"XaaNoScanlineImageWriteRect" and "XaaNoScanlineCPUToScreenColorExpandFill". \
Setting this to "No" is faster but will lock some machines. \
Default: Yes.
!! Vesa options
vesa.ShadowFB:\
Enable or disable use of the shadow framebuffer layer. See shadowfb(4)\
for further information. Default: on.
!! SiS Options
sis.NoAccel:\
Disable or enable acceleration. \
Default: acceleration is enabled.
!sis.HWcursor:\
!Enable or disable the HW cursor. \
!Default: on.
!sis.SWcursor:\
!The opposite of HWCursor. \
!Default: on.
sis.NoXVideo:\
Disable XV (XVideo) extension support. \
Default: off.
sis.SetMClk:\
Set the memory clock in MHz. \
Default: autodetect.
sis.PciRetry:\
Enable or disable PCI retries. \
Default: on.
sis.TurboQueue:\
Enable or disable TurboQueue mode. \
Default: off for SIS530, on for the others.
sis.FastVram:\
Enable or disable FastVram mode. \
Default: on.
sis.Rotate:\
Rotate the display clockwise (CW) or counterclockwise (CCW). \
This mode is unaccelerated, and uses the Shadow Frame Buffer layer \
Default: no rotation.
sis.ForceCRT2Type:\
Force display type to one of: TV, LCD or VGA. \
Default: autodetect.
sis.ShadowFB:\
Enable or disable use of the shadow framebuffer layer. See shadowfb(4) for \
further information. Default: off.
!! Generic driver options, apply to many drivers
*.SWcursor:\
See also HWcursor.\
Default: Usually Off.
*.HWcursor:\
Use the hardware cursor. See also SWcursor. \
Default: usually HWcursor, but some drivers may default to software.
--- NEW FILE: RAC.Notes ---
I. Abstract
===========
Graphics devices are accessed thru 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. Up to version 3.3 of
XFree86 only a single graphics device could be driven. Therfore there
was no need to address the issue of sharing such memory or I/O ranges
among several devices. Starting with version 4.0 XFree86 is capable of
driving more than one graphics interface in a multi-head environment.
Therefore a mechanism needed to be designed which was capable of
controlling the sharing the access to memory and I/O ranges. In this
document we describe to use of the RAC (Resource Access Control)
system in the XFree86 server which provides the service of controlling
access to interface resources.
II. Introduction
================
Terms and definitions:
II.1. Bus
---------
'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, MC and VL buses are currently treated like
ISA buses). 'Bus' may always 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 RACY as they
require specific drivers.
II.2. Entity
------------
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.
II.3. Resource
--------------
'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. Resource 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 condition:
address & mask == base
with base & mask == base. Resources addressed in such a way are
considered sparse resources.
II.4. Server States
------------------
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 any entity resource is under resource access control.
During OPERATING state only those entities are controlled which
actually have shared resources that conflict with others. The
determination which entity is to be placed under RAC during OPERATING
state takes place after ScreenInit() during the first server
generation. This doesn't apply if only one screen is active: in this
case no RAC is needed and the screen is simply left enabled while the
server is active.
III. Theory of operation
========================
III.1. General
--------------
The common level 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.
The user should provide a device section in XF86Config for each
graphics device installed in his system. Each such entity which is
never to be used as X display device might be marked as inactive by
adding the keyword "Inactive" to the device section.
When the Probe() 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 Probe() 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 EntityInit(),
EntityLeave() and EntityEnter() function.
EntityInit() 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 EntityInit(), EntityEnter() and EntityLeave() 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 EntityInit() or EntityEnter() 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 'ResInit' so that they can be
removed from the resource list after processing all EntityInit()
functions. EntityEnter() 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
EntityInit() 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. EntityLeave() 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 PreInit() phase each driver should check if any sharable resources
it has registered during Probe() has been denied and take appropriate
action which could simply be to fail. If it needs to access resources
it has disabled during EntitySetup() it can do so provided it has
registered these and will disable them before returning from
PreInit(). 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
ScreenInit(), this is not desirable.
Following PreInit() 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 ScreenInit()
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 ScreenInit() 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:
a. 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 (IO or MEM).
b. A resource marked 'disabled' during OPERATING state will be ignored
entirely.
c. 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.
d. 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.
The driver has the choice among different ways to control access to
certain resources:
a. It can relay 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.
b. 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 PreInit() stage.
Since the replacement functions are registered in PreInit() 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.
c. 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.
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 EnableAccess() function is called before
control is passed on. EnableAccess() 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, EnableAccess() determines
which resource types (MEM,IO) 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.
III.3. Resource Types
---------------------
Resource have certain properties. When registering resources each
range is accompanied by a flag consisting of the or'ed flags of the
different properties the resource has. Each resource range may be
classified according to
- its physical properties ie. if it addresses
memory (ResMem) or
I/O space (ResIo),
- if it addresses a
block (ResBlock) or
sparse (ResSparse)
range,
- its access properties.
There are two known access properties:
- ResExclusive
for resources which may not be shared with any other device and
- ResShared
for resources which can be disabled and therefore can be shared.
If it is desirable to test a resource against any type a generic
access type 'ResAny' 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 (ResUnused) or during OPERATING state
(ResUnusedOpr). A resource only visible during the init functions (ie.
EntityInit(), EntityEnter() and EntityLeave() should be registered
with the flag 'ResInit'. A resource that might conflict with
background resource ranges may be flagged with 'ResBios'. 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 common/sf86Resources.h.
IV. Available Functions
=======================
The functions provided for resource management will be listed in order
of use in the driver.
IV.1. Probe phase
-----------------
In this stage 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
XF86Config file to the devices:
int xf86MatchPciInstances(const char *driverName, int vendorID,
SymTabPtr chipsets, PciChipsets *PCIchipsets,
GDevPtr *devList, int numDevs, DriverPtr drvp,
int **foundEntities);
int xf86MatchIsaInstances(const char *driverName, SymTabPtr chipsets,
IsaChipsets *ISAchipsets, DriverPtr drvp,
FindIsaDevProc FindIsaDevice, GDevPtr *devList,
int numDevs, int **foundEntities);
Both functions return the number of matched entities and their indices
in foundEntities list.
They make use of several sub functions which are also available on the
driver level:
Bool xf86ComparePciBusString(const char *busID, int bus,
int device, int func);
and
Bool xf86ParseIsaBusString(const char *busID);
are called to interpret the busID in the device section. The functions:
int xf86ClaimPciSlot(int bus, int device, int func, DriverPtr drvp,
int chipset, GDevPtr dev, Bool active);
int xf86ClaimIsaSlot(DriverPtr drvp, int chipset, GDevPtr dev, Bool
active);
are used to allocate the entities and initialize their data
structures. Both functions return the index of the newly allocated
entity record or (-1) should the function fail. Before probing an ISA
card
Bool xf86IsPrimaryIsa();
gets called to determine if the primary card was not detected on the
PCI bus.
Two helper functions are provided to aid configuring entities:
Bool xf86ConfigActivePciEntity(ScrnInfoPtr pScrn, int entityIndex,
PciChipsets *p_chip, resList res,
EntityProc init, EntityProc enter,
EntityProc leave, pointer private);
Bool xf86ConfigActiveIsaEntity(ScrnInfoPtr pScrn, int entityIndex,
IsaChipsets *i_chip, resList res,
EntityProc init, EntityProc enter,
EntityProc leave, pointer private);
They are used to register the init/enter/leave functions described
above as well as the non-relocatable resources. Generally 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. The init/enter/leave functions have to be of type
typedef void (*EntityProc)(int entityIndex,pointer private);
They are passed the entity index and a pointer to a private scratch
area. This are can be set up during Probe() and its address can be
passed to xf86ConfigActiveIsaEntity() xf86ConfigActivePciEntity() as
the last argument.
These helper functions use:
void xf86ClaimFixedResources(resList list, int entityIndex);
To register 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 Probe() phase.
Bool xf86SetEntityFuncs(int entityIndex, EntityProc init,
EntityProc enter, EntityProc leave, pointer);
This function registers the init/enter/leave() functions along with
the pointer to their private area to the entity.
void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex);
adds the entity to the screen.
These functions are also available on the driver level. A detailed
Probe() function is listed below. For most drivers this can be used
with little change.
Please note that VGA resources have to be claimed in Probe()
phase. Otherwise they are not routed to the bus.
IV.2. PreInit() phase
---------------------
During this phase the remaining resource should be registered.
PreInit() should call
EntityInfoPtr xf86GetEntityInfo(int entityIndex);
To obtain a pointer to an EntityInfoRec for each entity it is able to
drive and check if any resource are listed in 'resources'. These have
been rejected in the post-Probe() phase. The driver should decide if
it can continue without using these or if it should fail. The pointer
to the EntityInfoRec should be freed if not needed any more.
Several functions are provided to simplify resource registration:
Bool xf86IsEntityPrimary(int entityIndex);
is used to determine if the entity is the display device that is used
during boot-up and text mode.
Bool xf86IsScreenPrimary(int scrnIndex);
finds out if the primary entity is registered for the screen with
specified index.
pciVideoPtr xf86GetPciInfoForEntity(int entityIndex);
returns a pointer to the pciVideoRec of the specified entity. If the
entity is not a PCI device NULL is returned.
The primary function for registration of resources is
resPtr xf86RegisterResources(int entityIndex, resList list, int access);
it tries to register the resources in 'list'. If list is NULL 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 (ResShared) 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 0 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 move
the resource to different locations. In case of PCI bus entities this
is done by passing the list of failed resources to
resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes);
this function returns a list of reallocated resource. This list needs
to be passed to xf86RegisterResources() again to be registered with
the broker.
Two functions are provided to obtain a resource range of a given type:
resRange xf86GetBlock(long type, memType size,
memType window_start, memType window_end,
memType align_mask, resPtr avoid);
resRange xf86GetSparse(long type, unsigned long fixed_bits,
unsigned long decode_mask, unsigned long address_mask,
resPtr avoid);
The first one tries to find a block range of size 'size' and type
'type' in a window bound by window_start and window_end with the
alignment specified in alignment mask. Optionally a list of resource
ranges which should be avoided inside this window can be passed. On
failure it will return a zero range of type 'ResEnd'.
The latter function does the same for sparse resources. A spares range
is determined by to parameters: the mask and the base value. An
address satisfying
mask & address == base
belongs to the specific spares range. 'mask' and 'base' themselves
have to satisfy:
mask & base == base.
Here three values have to be specified: the address mask which marks
all bits of the mask part of the address, the decode_mask which masks
out the bits which are hard coded 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 'ResEnd'. Optionally it might be
passed a list of resource ranges to avoid.
Certain 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:
Bool xf86FixPciResource(int entityIndex, unsigned int prt, CARD32 alignment,
long type);
is used for that. The parameter prt contains the number of the PCI
base register that needs to be modified. A value of 6 refers to the
BIOS base register. The size is specified in the alignment
register. Since PCI resources need to span an integral range of the
size 2^n 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 'ResShared'. The resource
broker needs to know that to find a matching resource range. This
function should be called before calling xf86RegisterResources().
Bool xf86CheckPciMemBase(pciVideoPtr pPci, unsigned long base);
checks that the memory base value specified in base matches one of the
PCI base address register values for the given PCI device.
The driver may replace the generic access control functions for an
entity by it's own ones.
void xf86SetAccessFuncs(EntityInfoPtr pEnt, xf86SetAccessFuncPtr funcs,
xf86SetAccessFuncPtr oldFuncs);
with:
typedef struct {
xf86AccessPtr mem;
xf86AccessPtr io;
xf86AccessPtr io_mem;
} xf86SetAccessFuncRec, *xf86SetAccessFuncPtr;
is used for that. 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
NULL value is passed as third argument it is interpreted as an address
where to store the old access records. If the third argument is NULL
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 his 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.
To find out if specific resource range is conflicting with another
resource
memType xf86ChkConflict(resRange *rgp, int entityIndex);
may be called. If a non-zero value is returned a conflict is found.
resPtr xf86SetOperatingState(resList list, int entityIndex, int mask);
is used to set the state of a resource during OPERATING state. 'list'
holds a list to which 'mask' is to be applied. The parameter 'mask'
may have the value 'ResUnusedOpr' and 'ResDisableOpr'. The first one
should be used if a resource isn't used during OPERATING state however
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 A and ending at B and suppose C us a value
satisfying A < C < B one may not specify the resource range (A,B) by
splitting it into two ranges (A,C) and (C,B).
Two functions are provided for special cases:
void xf86RemoveEntityFromScreen(ScrnInfoPtr pScrn, int entityIndex);
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.
void xf86DeallocateResourcesForEntity(int entityIndex, long type);
deallocates all resources of a given type registered for a certain
entity from the resource broker list.
IV.3. ScreenInit() phase
------------------------
Setting up the rac flags is all that remains to do in ScreenInit()
phase (Note that these flags might also be set up in PreInit() phase).
The ScrnInfoRec has separate flags for memory and PIO access:
racIoFlags and racMemFlags. They specifies which graphics operations
might require the use of resources which might be disabled for some
reason. Note that even exclusive resources might be disabled if they
are disabled along with shared resources. For example if a driver has
registered the VGA PIO resources and lets the common level disable
these by disabling PIO access in PCI config space (the standard way),
exclusive PCI PIO ranges will also be disabled. Therefore the driver
has to flag any operations requiring PCI PIO resources in racIoFlags.
The avaliable flags are defined in rac/xf86RAC.h. Available are:
RAC_FB for framebuffer operations (including hw acceleration)
RAC_CURSOR for Cursor operations
(??? I'm not sure if we need this for SW cursor it depends
on which level the sw cursor is drawn)
RAC_COLORMAP for colormap operations
RAC_VIEWPORT for the call to RACAdjustFrame()
The flags are or'ed.
V. Appendix
===========
A. Sample Probe() Function
--------------------------
static Bool
XXXProbe(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(CHIPS_DRIVER_NAME,
&devSections)) <= 0) {
return FALSE;
}
/* PCI BUS */
/* test if PCI bus present */
if (xf86GetPciVideoInfo() ) {
/* match PCI instances with ones supported by the driver */
numUsed = xf86MatchPciInstances(XXX_NAME, PCI_VENDOR_XXX,
XXXChipsets, XXXPCIchipsets,
devSections,numDevSections, drv,
&usedChips);
if (numUsed > 0) {
for (i = 0; i < numUsed; i++) {
/* Allocate a ScrnInfoRec */
ScrnInfoPtr pScrn = xf86AllocateScreen(drv,0);
pScrn->driverVersion = VERSION;
pScrn->driverName = XXX_DRIVER_NAME;
pScrn->name = XXX_NAME;
pScrn->Probe = XXXProbe;
pScrn->PreInit = XXXPreInit;
pScrn->ScreenInit = XXXScreenInit;
pScrn->SwitchMode = XXXSwitchMode;
pScrn->AdjustFrame = XXXAdjustFrame;
pScrn->EnterVT = XXXEnterVT;
pScrn->LeaveVT = XXXLeaveVT;
pScrn->FreeScreen = XXXFreeScreen;
pScrn->ValidMode = XXXValidMode;
foundScreen = TRUE;
/* add screen to entity */
xf86ConfigActivePciEntity(pScrn,usedChips[i],XXXPCIchipsets,
NULL,NULL,NULL,NULL,NULL);
}
}
}
/* Isa Bus */
numUsed = xf86MatchIsaInstances(XXX_NAME,XXXChipsets,XXXISAchipsets,
drv,chipsFindIsaDevice,devSections,
numDevSections,&usedChips);
if(numUsed >= 0)
for (i = 0; i < numUsed; i++) {
ScrnInfoPtr pScrn = xf86AllocateScreen(drv,0);
pScrn->driverVersion = VERSION;
pScrn->driverName = XXX_DRIVER_NAME;
pScrn->name = XXX_NAME;
pScrn->Probe = XXXProbe;
pScrn->PreInit = XXXPreInit;
pScrn->ScreenInit = XXXScreenInit;
pScrn->SwitchMode = XXXSwitchMode;
pScrn->AdjustFrame = XXXAdjustFrame;
pScrn->EnterVT = XXXEnterVT;
pScrn->LeaveVT = XXXLeaveVT;
pScrn->FreeScreen = XXXFreeScreen;
pScrn->ValidMode = XXXValidMode;
foundScreen = TRUE;
xf86ConfigActiveIsaEntity(pScrn,usedChips[i],XXXISAchipsets,
NULL,NULL,NULL,NULL,NULL);
}
xfree(devSections);
return foundScreen;
}
B. Porting Issues
-----------------
Here are some hints on porting code developed for RAC 1 to RAC 2.
1. a. Initialization of RAC is now entirely done on the common level.
Therefore the call to xf86RACInit() can be removed.
b. Also there is no need for the racSymbols list.
c. LoadSubModule(..,rac) should be removed.
d. racSymbols should be removed from LoaderRequestSymList(racSymbols,..)
2. a. if the driver uses the predefined resource lists xf86Resources.h
needs to be included.
b. RES_VGA should be changed to RES_EXCLUSIVE_VGA
3. The device list now belongs to the EntityInfoRec.
Change pScrn->device to xxx->pEnt->device.
4. Rewrite the Probe() function. The example given above should work
as a guideline.
5. Register all necessary resources in PreInit() by calling
xf86RegisterResources().
6. If applicable set the operating state of the registered resources
by calling xf86SetOperatingState(). This should be done during
PreInit(). If necessary it might still be done in ScreenInit()
7. Set up the racIoFlags and racMemFlags.
LocalWords: ISA
--- NEW FILE: Registry ---
This is the XFree86 driver/module registry. To avoid name space clashes and
to maintain some consistency between drivers the important name spaces are
maintained here.
1. Module Names.
Each module is required to have a unique name. Registered names are:
GLcore
acecad
afb
apm
ark
ati
atimisc
bitmap
bt8xx
calcomp
cfb
cfb16
cfb24
cfb32
chips
cirrus
citron
cyrix
dbe
ddc
digitaledge
dmc
dri
drm
dynapro
elo2300
elographics
extmod
fb
fbdev
fbdevhw
fi12x6
freetype
glide
glint
glx
hyperpen
i128
i2c
i740
i810
imstt
int10
joystick
keyboard
layer
magellan
magictouch
mfb
mga
microtouch
mouse
msp34xx
mutouch
neomagic
newport
nv
pcidata
penmount
pex5
r128
radeon
rac
ramdac
record
rendition
s3
s3virge
savage
scanpci
shadow
shadowfb
siliconmotion
sis
spaceorb
speedo
summa
sunbw2
suncg14
suncg3
suncg6
sunffb
sunleo
suntcx
tdfx
tga
trident
tseng
type1
v4l
vbe
vesa
vga
vgahw
vmware
void
wacom
xaa
xf1bpp
xf24_32bpp
xf4bpp
xf8_16bpp
xf8_32bpp
xf8_32wid
xie
xtrap
xtt
2. External Module Object Symbols.
Each module is required to use a unique prefix or prefixes for all of
its externally visible symbols. They should be unique without regard to
case. Registered prefixes are:
ati
bt8xx
cfb
chips
fi12x6
glide
glint
mfb
mga
msp34xx
neo
permedia
tseng
vga
vgahw
vmware
xaa
xf1bpp
xf4bpp
3. Chipset Names.
Each video driver is required to use a unique set of chipset names. Case,
white space and underscore characters are ignored when comparing chipset
names. All names listed here are in lower case with all white space and
underscores removed. Registered chipset names are:
ati
ativga
ct64200
ct64300
ct65520
ct65525
ct65530
ct65535
ct65540
ct65545
ct65546
ct65548
ct65550
ct65554
ct65555
ct68554
ct69000
et4000
et4000w32
et4000w32i
et4000w32p
et6000
et6100
generic
ibmvga
ibm8514
mach32
mach64
mach8
mga2064w
mga1064sg
mga2164w
mga2164wagp
neo2070
neo2090
neo2093
neo2097
neo2160
neo2200
tipm2
vgawonder
voodoo
4. Option Names.
Option names and their usage should be consistent between drivers.
Case, white space and underscore characters are ignored when comparing
option names. The prefix "no" may be added or removed from boolean
option names. All names listed here are in their preferred user-visible
form. Some registered option names are:
Types are: B = boolean, O = set/unset (no value), I = integer, S = string,
A = optional string, F = floating point number Q = frequency
Scopes are: F = global flags, V = video driver, C = common (per screen),
I = input drivers, X = XAA, Xv = Xv extension, M = misc.
Names currently in use:
Name Type Scope Description
----------------------------------------------------------------------------
AllowMouseOpenFail B F ignore mouse dev open failure
AllowNonLocalModInDev B F allow non-local mod of input devs
AllowNonLocalXvidtune B F allow non-local VidMode connections
BlankTime I F Screen saver timeout (min)
DisableModInDev B F disallow changing input devs
DisableVidModeExtension B F disable VidMode extension
DontVTSwitch B F disable Ctrl-Alt-Fn
DontZap B F disable Ctrl-Alt-BS sequence
DontZoom B F disable Ctrl-Alt-+/-
NoTrapSignals B F don't trap signals
OffTime I F Time before DPMS off mode active (min)
PciProbe1 O F use PCI probe algorithm 1
PciProbe2 O F use PCI probe algorithm 2
PciForceConfig1 O F force PCI config type 1
PciForceConfig2 O F force PCI config type 2
Pixmap I F depth 24 pixmap size (24 or 32)
StandbyTime I F Time before DPMS standby active (min)
SuspendTime I F Time before DPMS suspend mode active (min)
BackingStore B C Enable backing store
DDC B C Enable/disable DDC
DDC1 B C Enable/disable DDC1
DDC2 B C Enable/disable DDC2
DPMS O C Enable DPMS
MTRR B C Enable/disable setting MTRRs
BaudRate I I Serial port baud rate
ButtonNumber I I Button number (for touch screen?)
ButtonThreshold I I ??
ClearDTR O I Clear serial port DTR
ClearRTS O I Clear serial port RTS
DataBits I I Serial port data bits
DemandLoad O I ??
Device S I Device file name
DeviceName S I Input device name
FlowControl S I Serial flow control ("xon", "none")
HistorySize I I ??
MaxX I I Maximum X coordinate
MaxY I I Maximum Y coordinate
MinX I I Minimum X coordinate
MinY I I Minimum Y coordinate
Parity S I Serial port parity ("odd", "even", "none")
ReportDelay I I ??
ReportingMode S I may be "raw" or "scaled"
ScreenNumber I I Screen number (for touch screen)
SendCoreEvents B I Send core events
SendDragEvents B I Send drag events
StopBits I I Serial port stop bits
SwapXY B I Swap the X and Y axes
UntouchDelay I I ??
Vmin I I Tty VMIN
Vtime I I Tty VTIME
18BitBus B V ??
8Plus16 B V Enable depth 8 + depth 16 with overlay
8Plus24 B V Enable depth 8 + depth 24 with overlay
BlockWrite B V Enable/disable block write
ColorKey I V Set the color key for overlay modes
CompositeSync B V Composite sync
CRTDisplay B V Force display on CRT, not LCD
CRTScreen B V Display on CRT, not LCD (Obsolete)
EarlyRasPrecharge O V Early RAS pre-charge
FastDRAM O V Fast DRAM
FifoAggressive O V Aggressive FIFO setting
FifoConservative O V Conservative FIFO setting
FifoModerate O V Moderate FIFO setting
FireGL3000 B V Card is Diamond FireGL3000
FixPanelSize B V ??
FPClock8 Q V Flat panel clock for 8bpp fb (MHz)
FPClock16 Q V Flat panel clock for 16bpp fb (MHz)
FPClock24 Q V Flat panel clock for 24bpp fb (MHz)
FPClock32 Q V Flat panel clock for 32bpp fb (MHz)
FPMVRAM O V Fast page mode VRAM
FramebufferWC B V Enable/disable WC for the framebuffer
GlideDevice I V Selects which Voodoo board to use
HiBitHigh O V High clock bit default to set
HiBitLow O V High clock bit default to cleared
HWClocks B V Enable/disable HW clocks
HWCursor B V Enable/disable HW cursor
LateRasPrecharge O V Late RAS pre-charge
Legend O V Card is Legend ET4000
LCDCenter B V Enable/disable centering for LCD displays
Linear B V Enable/disable linear framebuffer
MCLK Q V Specify the current MCLK value (MHz)
MedDRAM B V Medium speed DRAM
MemCfg1 I V ??
MemCfg2 I V ??
MGASDRAM B V Mga card has SDRAM
MMIO B V Enable/disable memory mapped I/O
MMIOCache B V Enable/Disable MMIO cache
MuxThreshold I V Multiplexing threshold (kHz)
NoAccel B V Disable/enable acceleration
NoClockChip B V ??
NoStretch B V Disable/enable stretching for LCD displays
OnAtExit B V Leave video signal on when exiting server
OverclockMem B V Enable memory overclocking
Overlay A V Enable multi-depth/overlay. An optional
string "M,N" may be specified, where
M, N are the depths.
PanelDisplay B V Force display on LCD
PciBurst B V Enable/disable PCI burst mode
PciRetry B V Enable/disable PCI retries
ProbeClocks B V Force probe for non-programmable clocks
ReferenceClock Q V Clock generator reference frequency
RGBbits I V Number of significant bits per rgb
Rotate S V Rotate the virtual display (CW or CCW)
SetLCDClk Q V Set LCD clock (MHz)
SetMclk Q V Set Memory Clock (MHz)
ShadowFB B V Enable shadow framebuffer layer
ShowCache B V Enable viewing of offscreen memory
ShowOverscan O V Set the overscan area to a visible colour
SlowDRAM O V Slow DRAM
SlowEDODRAM O V Slow EDO DRAM
STN B V STN screen type (??)
SWCursor B V Enable/disable SW cursor
SuspendHack B V ??
SyncOnGreen B V Enable/disable sync on green
TurboQueue B V Enable/disable turbo queue
UseFBDev B V Use the fbdev driver interface
UseModeLine B V Use Modeline (??)
W32Interleave B V ??
Buffers I Xv Number of buffers
Device S Xv Device file name
Expose B Xv Disable occlusion clipping (see DESIGN)
FramesPerSec I Xv Max. refresh frequency
XAA options. All are of type "O" and scope "X", and are self-explanatory
XaaNoColor8x8PatternFillRect
XaaNoColor8x8PatternFillTrap
XaaNoCPUToScreenColorExpandFill
XaaNoDashedBresenhamLine
XaaNoDashedTwoPointLine
XaaNoScreenToScreenCopy
XaaNoImageReadRect
XaaNoImageWriteRect
XaaNoMono8x8PatternFillRect
XaaNoMono8x8PatternFillTrap
XaaNoOffscreenPixmaps
XaaNoPixmapCache
XaaNoScanlineCPUToScreenColorExpandFill
XaaNoScanlineImageWriteRect
XaaNoScreenToScreenColorExpandFill
XaaNoSolidBresenhamLine
XaaNoSolidFillRect
XaaNoSolidFillTrap
XaaNoSolidHorVertLine
XaaNoSolidTwoPointLine
Names used in previous versions:
16Clocks
8Clocks
ClkDiv2
EDO VRAM
ExternDisp
ExtFramBuf
FastVRAM
FavorBitBlt
InternDisp
NoBitBlt
NoFontCache
NoImageBlt
NoMemAccess
NoPciDisconnect
NoPixmapCache
NoProgramClocks
NoSplitXfer
OverrideBIOS
OverrideValidateMode
ProgLcdModeRegs
ProgLcdModeStretch
SlowDRAMrefresh
SlowVRAM
SwapHiBit
5. Ramdac Names.
Ramdac names should be consistent between drivers. Case, white space
and underscore characters are ignored when comparing ramdac names. All
names listed here are in lower case with all white space and underscores
removed.
6. Clock Chip Names.
Clock chip names should be consistent between drivers. Case, white
space and underscore characters are ignored when comparing clock chip
names. All names listed here are in lower case with all white space
and underscores removed.
$XFree86: xc/programs/Xserver/hw/xfree86/Registry,v 1.19 2003/02/20 04:05:12 dawes Exp $
--- NEW FILE: XF86Conf.cpp ---
XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/XF86Conf.cpp,v 3.46 2003/05/27 16:11:04 tsi Exp $
XCOMM
XCOMM Copyright (c) 1994-1998 by The XFree86 Project, Inc.
XCOMM
XCOMM Permission is hereby granted, free of charge, to any person obtaining a
XCOMM copy of this software and associated documentation files (the "Software"),
XCOMM to deal in the Software without restriction, including without limitation
XCOMM the rights to use, copy, modify, merge, publish, distribute, sublicense,
XCOMM and/or sell copies of the Software, and to permit persons to whom the
XCOMM Software is furnished to do so, subject to the following conditions:
XCOMM
XCOMM The above copyright notice and this permission notice shall be included in
XCOMM all copies or substantial portions of the Software.
XCOMM
XCOMM THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
XCOMM IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
XCOMM FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
XCOMM THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
XCOMM WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
XCOMM OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
XCOMM SOFTWARE.
XCOMM
XCOMM Except as contained in this notice, the name of the XFree86 Project shall
XCOMM not be used in advertising or otherwise to promote the sale, use or other
XCOMM dealings in this Software without prior written authorization from the
XCOMM XFree86 Project.
XCOMM
XCOMM $XConsortium: XF86Conf.cpp /main/22 1996/10/23 11:43:51 kaleb $
XCOMM **********************************************************************
XCOMM This is a sample configuration file only, intended to illustrate
XCOMM what a config file might look like. Refer to the XF86Config(4/5)
XCOMM man page for details about the format of this file. This man page
XCOMM is installed as MANPAGE
XCOMM **********************************************************************
XCOMM The ordering of sections is not important in version 4.0 and later.
XCOMM **********************************************************************
XCOMM Files section. This allows default font and rgb paths to be set
XCOMM **********************************************************************
Section "Files"
XCOMM The location of the RGB database. Note, this is the name of the
XCOMM file minus the extension (like ".txt" or ".db"). There is normally
XCOMM no need to change the default.
RgbPath RGBPATH
XCOMM Multiple FontPath entries are allowed (which are concatenated together),
XCOMM as well as specifying multiple comma-separated entries in one FontPath
XCOMM command (or a combination of both methods)
FontPath LOCALFONTPATH
FontPath MISCFONTPATH
FontPath DPI75USFONTPATH
FontPath DPI100USFONTPATH
FontPath T1FONTPATH
FontPath CIDFONTPATH
FontPath SPFONTPATH
FontPath DPI75FONTPATH
FontPath DPI100FONTPATH
XCOMM ModulePath can be used to set a search path for the X server modules.
XCOMM The default path is shown here.
XCOMM ModulePath MODULEPATH
EndSection
XCOMM **********************************************************************
XCOMM Module section -- this is an optional section which is used to specify
XCOMM which run-time loadable modules to load when the X server starts up.
XCOMM **********************************************************************
Section "Module"
XCOMM This loads the DBE extension module.
Load "dbe"
XCOMM This loads the miscellaneous extensions module, and disables
XCOMM initialisation of the XFree86-DGA extension within that module.
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection
XCOMM This loads the Type1 and FreeType font modules
Load "type1"
Load "freetype"
EndSection
XCOMM **********************************************************************
XCOMM Server flags section. This contains various server-wide Options.
XCOMM **********************************************************************
Section "ServerFlags"
XCOMM Uncomment this to cause a core dump at the spot where a signal is
XCOMM received. This may leave the console in an unusable state, but may
XCOMM provide a better stack trace in the core dump to aid in debugging
XCOMM Option "NoTrapSignals"
XCOMM Uncomment this to disable the <Crtl><Alt><Fn> VT switch sequence
XCOMM (where n is 1 through 12). This allows clients to receive these key
XCOMM events.
XCOMM Option "DontVTSwitch"
XCOMM Uncomment this to disable the <Crtl><Alt><BS> server abort sequence
XCOMM This allows clients to receive this key event.
XCOMM Option "DontZap"
XCOMM Uncomment this to disable the <Crtl><Alt><KP_+>/<KP_-> mode switching
XCOMM sequences. This allows clients to receive these key events.
XCOMM Option "DontZoom"
XCOMM Uncomment this to disable tuning with the xvidtune client. With
XCOMM it the client can still run and fetch card and monitor attributes,
XCOMM but it will not be allowed to change them. If it tries it will
XCOMM receive a protocol error.
XCOMM Option "DisableVidModeExtension"
XCOMM Uncomment this to enable the use of a non-local xvidtune client.
XCOMM Option "AllowNonLocalXvidtune"
XCOMM Uncomment this to disable dynamically modifying the input device
XCOMM (mouse and keyboard) settings.
XCOMM Option "DisableModInDev"
XCOMM Uncomment this to enable the use of a non-local client to
XCOMM change the keyboard or mouse settings (currently only xset).
XCOMM Option "AllowNonLocalModInDev"
XCOMM Set the basic blanking screen saver timeout.
Option "blank time" "10" # 10 minutes
XCOMM Set the DPMS timeouts. These are set here because they are global
XCOMM rather than screen-specific. These settings alone don't enable DPMS.
XCOMM It is enabled per-screen (or per-monitor), and even then only when
XCOMM the driver supports it.
Option "standby time" "20"
Option "suspend time" "30"
Option "off time" "60"
XCOMM On some platform the server needs to estimate the sizes of PCI
XCOMM memory and pio ranges. This is done by assuming that PCI ranges
XCOMM don't overlap. Some broken BIOSes tend to set ranges of inactive
XCOMM devices wrong. Here one can adjust how aggressive the assumptions
XCOMM should be. Default is 0.
XCOMM Option "EstimateSizesAggresively" "0"
EndSection
XCOMM **********************************************************************
XCOMM Input devices
XCOMM **********************************************************************
XCOMM **********************************************************************
XCOMM Core keyboard's InputDevice section
XCOMM **********************************************************************
Section "InputDevice"
Identifier "Keyboard1"
Driver "keyboard"
XCOMM For most OSs the protocol can be omitted (it defaults to "Standard").
XCOMM When using XQUEUE (only for SVR3 and SVR4, but not Solaris), comment
XCOMM out the above line, and uncomment the following line.
XCOMM Option "Protocol" "Xqueue"
XCOMM Set the keyboard auto repeat parameters. Not all platforms implement
XCOMM this.
Option "AutoRepeat" "500 5"
XCOMM Specifiy which keyboard LEDs can be user-controlled (eg, with xset(1)).
XCOMM Option "Xleds" "1 2 3"
XCOMM To disable the XKEYBOARD extension, uncomment XkbDisable.
XCOMM Option "XkbDisable"
XCOMM To customise the XKB settings to suit your keyboard, modify the
XCOMM lines below (which are the defaults). For example, for a European
XCOMM keyboard, you will probably want to use one of:
XCOMM
XCOMM Option "XkbModel" "pc102"
XCOMM Option "XkbModel" "pc105"
XCOMM
XCOMM If you have a Microsoft Natural keyboard, you can use:
XCOMM
XCOMM Option "XkbModel" "microsoft"
XCOMM
XCOMM If you have a US "windows" keyboard you will want:
XCOMM
XCOMM Option "XkbModel" "pc104"
XCOMM
XCOMM Then to change the language, change the Layout setting.
XCOMM For example, a german layout can be obtained with:
XCOMM
XCOMM Option "XkbLayout" "de"
XCOMM
XCOMM or:
XCOMM
XCOMM Option "XkbLayout" "de"
XCOMM Option "XkbVariant" "nodeadkeys"
XCOMM
XCOMM If you'd like to switch the positions of your capslock and
XCOMM control keys, use:
XCOMM
XCOMM Option "XkbOptions" "ctrl:swapcaps"
XCOMM These are the default XKB settings for XFree86
XCOMM
XCOMM Option "XkbRules" "xfree86"
XCOMM Option "XkbModel" "pc101"
XCOMM Option "XkbLayout" "us"
XCOMM Option "XkbVariant" ""
XCOMM Option "XkbOptions" ""
EndSection
XCOMM **********************************************************************
XCOMM Core Pointer's InputDevice section
XCOMM **********************************************************************
Section "InputDevice"
XCOMM Identifier and driver
Identifier "Mouse1"
Driver "mouse"
XCOMM The mouse protocol and device. The device is normally set to /dev/mouse,
XCOMM which is usually a symbolic link to the real device.
Option "Protocol" "Microsoft"
Option "Device" "/dev/mouse"
XCOMM On platforms where PnP mouse detection is supported the following
XCOMM protocol setting can be used when using a newer PnP mouse:
XCOMM Option "Protocol" "Auto"
XCOMM When using mouse connected to a PS/2 port (aka "MousePort"), set the
XCOMM the protocol as follows. On some platforms some other settings may
XCOMM be available.
XCOMM Option "Protocol" "PS/2"
XCOMM When using XQUEUE (only for SVR3 and SVR4, but not Solaris), use
XCOMM the following instead of any of the lines above. The Device line
XCOMM is not required in this case.
XCOMM Option "Protocol" "Xqueue"
XCOMM Baudrate and SampleRate are only for some older Logitech mice. In
XCOMM almost every case these lines should be omitted.
XCOMM Option "BaudRate" "9600"
XCOMM Option "SampleRate" "150"
XCOMM Emulate3Buttons is an option for 2-button mice
XCOMM Emulate3Timeout is the timeout in milliseconds (default is 50ms)
XCOMM Option "Emulate3Buttons"
XCOMM Option "Emulate3Timeout" "50"
XCOMM ChordMiddle is an option for some 3-button Logitech mice, or any
XCOMM 3-button mouse where the middle button generates left+right button
XCOMM events.
XCOMM Option "ChordMiddle"
EndSection
Section "InputDevice"
Identifier "Mouse2"
Driver "mouse"
Option "Protocol" "MouseMan"
Option "Device" "/dev/mouse2"
EndSection
XCOMM Some examples of extended input devices
XCOMM Section "InputDevice"
XCOMM Identifier "spaceball"
XCOMM Driver "magellan"
XCOMM Option "Device" "/dev/cua0"
XCOMM EndSection
XCOMM
XCOMM Section "InputDevice"
XCOMM Identifier "spaceball2"
XCOMM Driver "spaceorb"
XCOMM Option "Device" "/dev/cua0"
XCOMM EndSection
XCOMM
XCOMM Section "InputDevice"
XCOMM Identifier "touchscreen0"
XCOMM Driver "microtouch"
XCOMM Option "Device" "/dev/ttyS0"
XCOMM Option "MinX" "1412"
XCOMM Option "MaxX" "15184"
XCOMM Option "MinY" "15372"
XCOMM Option "MaxY" "1230"
XCOMM Option "ScreenNumber" "0"
XCOMM Option "ReportingMode" "Scaled"
XCOMM Option "ButtonNumber" "1"
XCOMM Option "SendCoreEvents"
XCOMM EndSection
XCOMM
XCOMM Section "InputDevice"
XCOMM Identifier "touchscreen1"
XCOMM Driver "elo2300"
XCOMM Option "Device" "/dev/ttyS0"
XCOMM Option "MinX" "231"
XCOMM Option "MaxX" "3868"
XCOMM Option "MinY" "3858"
XCOMM Option "MaxY" "272"
XCOMM Option "ScreenNumber" "0"
XCOMM Option "ReportingMode" "Scaled"
XCOMM Option "ButtonThreshold" "17"
XCOMM Option "ButtonNumber" "1"
XCOMM Option "SendCoreEvents"
XCOMM EndSection
XCOMM **********************************************************************
XCOMM Monitor section
XCOMM **********************************************************************
XCOMM Any number of monitor sections may be present
Section "Monitor"
XCOMM The identifier line must be present.
Identifier "Generic Monitor"
XCOMM HorizSync is in kHz unless units are specified.
XCOMM HorizSync may be a comma separated list of discrete values, or a
XCOMM comma separated list of ranges of values.
XCOMM NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S
XCOMM USER MANUAL FOR THE CORRECT NUMBERS.
XCOMM HorizSync 31.5 # typical for a single frequency fixed-sync monitor
XCOMM HorizSync 30-64 # multisync
XCOMM HorizSync 31.5, 35.2 # multiple fixed sync frequencies
XCOMM HorizSync 15-25, 30-50 # multiple ranges of sync frequencies
XCOMM VertRefresh is in Hz unless units are specified.
XCOMM VertRefresh may be a comma separated list of discrete values, or a
XCOMM comma separated list of ranges of values.
XCOMM NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S
XCOMM USER MANUAL FOR THE CORRECT NUMBERS.
XCOMM VertRefresh 60 # typical for a single frequency fixed-sync monitor
XCOMM VertRefresh 50-100 # multisync
XCOMM VertRefresh 60, 65 # multiple fixed sync frequencies
XCOMM VertRefresh 40-50, 80-100 # multiple ranges of sync frequencies
XCOMM Modes can be specified in two formats. A compact one-line format, or
XCOMM a multi-line format.
XCOMM A generic VGA 640x480 mode (hsync = 31.5kHz, refresh = 60Hz)
XCOMM These two are equivalent
XCOMM ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525
Mode "640x480"
DotClock 25.175
HTimings 640 664 760 800
VTimings 480 491 493 525
EndMode
XCOMM These two are equivalent
XCOMM ModeLine "1024x768i" 45 1024 1048 1208 1264 768 776 784 817 Interlace
XCOMM Mode "1024x768i"
XCOMM DotClock 45
XCOMM HTimings 1024 1048 1208 1264
XCOMM VTimings 768 776 784 817
XCOMM Flags "Interlace"
XCOMM EndMode
XCOMM If a monitor has DPMS support, that can be indicated here. This will
XCOMM enable DPMS when the monitor is used with drivers that support it.
XCOMM Option "dpms"
XCOMM If a monitor requires that the sync signals be superimposed on the
XCOMM green signal, the following option will enable this when used with
XCOMM drivers that support it. Only a relatively small range of hardware
XCOMM (and drivers) actually support this.
XCOMM Option "sync on green"
EndSection
XCOMM **********************************************************************
XCOMM Graphics device section
XCOMM **********************************************************************
XCOMM Any number of graphics device sections may be present
Section "Device"
XCOMM The Identifier must be present.
Identifier "Generic VGA"
XCOMM The Driver line must be present. When using run-time loadable driver
XCOMM modules, this line instructs the server to load the specified driver
XCOMM module. Even when not using loadable driver modules, this line
XCOMM indicates which driver should interpret the information in this section.
Driver "vga"
XCOMM The chipset line is optional in most cases. It can be used to override
XCOMM the driver's chipset detection, and should not normally be specified.
XCOMM Chipset "generic"
XCOMM Various other lines can be specified to override the driver's automatic
XCOMM detection code. In most cases they are not needed.
XCOMM VideoRam 256
XCOMM Clocks 25.2 28.3
XCOMM The BusID line is used to specify which of possibly multiple devices
XCOMM this section is intended for. When this line isn't present, a device
XCOMM section can only match up with the primary video device. For PCI
XCOMM devices a line like the following could be used. This line should not
XCOMM normally be included unless there is more than one video device
XCOMM intalled.
XCOMM BusID "PCI:0:10:0"
XCOMM Various option lines can be added here as required. Some options
XCOMM are more appropriate in Screen sections, Display subsections or even
XCOMM Monitor sections.
XCOMM Option "hw cursor" "off"
EndSection
Section "Device"
Identifier "any supported Trident chip"
Driver "trident"
EndSection
Section "Device"
Identifier "MGA Millennium I"
Driver "mga"
Option "hw cursor" "off"
BusID "PCI:0:10:0"
EndSection
Section "Device"
Identifier "MGA G200 AGP"
Driver "mga"
BusID "PCI:1:0:0"
Option "pci retry"
EndSection
XCOMM **********************************************************************
XCOMM Screen sections.
XCOMM **********************************************************************
XCOMM Any number of screen sections may be present. Each describes
XCOMM the configuration of a single screen. A single specific screen section
XCOMM may be specified from the X server command line with the "-screen"
XCOMM option.
Section "Screen"
XCOMM The Identifier, Device and Monitor lines must be present
Identifier "Screen 1"
Device "Generic VGA"
Monitor "Generic Monitor"
XCOMM The favoured Depth and/or Bpp may be specified here
DefaultDepth 8
SubSection "Display"
Depth 8
Modes "640x480"
ViewPort 0 0
Virtual 800 600
EndSubsection
SubSection "Display"
Depth 4
Modes "640x480"
EndSubSection
SubSection "Display"
Depth 1
Modes "640x480"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen MGA1"
Device "MGA Millennium I"
Monitor "Generic Monitor"
Option "no accel"
DefaultDepth 16
XCOMM DefaultDepth 24
SubSection "Display"
Depth 8
Modes "1280x1024"
Option "rgb bits" "8"
Visual "StaticColor"
EndSubSection
SubSection "Display"
Depth 16
Modes "1280x1024"
EndSubSection
SubSection "Display"
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen MGA2"
Device "MGA G200 AGP"
Monitor "Generic Monitor"
DefaultDepth 8
SubSection "Display"
Depth 8
Modes "1280x1024"
Option "rgb bits" "8"
Visual "StaticColor"
EndSubSection
EndSection
XCOMM **********************************************************************
XCOMM ServerLayout sections.
XCOMM **********************************************************************
XCOMM Any number of ServerLayout sections may be present. Each describes
XCOMM the way multiple screens are organised. A specific ServerLayout
XCOMM section may be specified from the X server command line with the
XCOMM "-layout" option. In the absence of this, the first section is used.
XCOMM When now ServerLayout section is present, the first Screen section
XCOMM is used alone.
Section "ServerLayout"
XCOMM The Identifier line must be present
Identifier "Main Layout"
XCOMM Each Screen line specifies a Screen section name, and optionally
XCOMM the relative position of other screens. The four names after
XCOMM primary screen name are the screens to the top, bottom, left and right
XCOMM of the primary screen. In this example, screen 2 is located to the
XCOMM right of screen 1.
Screen "Screen MGA 1" "" "" "" "Screen MGA 2"
Screen "Screen MGA 2" "" "" "Screen MGA 1" ""
XCOMM Each InputDevice line specifies an InputDevice section name and
XCOMM optionally some options to specify the way the device is to be
XCOMM used. Those options include "CorePointer", "CoreKeyboard" and
XCOMM "SendCoreEvents". In this example, "Mouse1" is the core pointer,
XCOMM and "Mouse2" is an extended input device that also generates core
XCOMM pointer events (i.e., both mice will move the standard pointer).
InputDevice "Mouse1" "CorePointer"
InputDevice "Mouse2" "SendCoreEvents"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
Section "ServerLayout"
Identifier "another layout"
Screen "Screen 1"
Screen "Screen MGA 1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
Section "ServerLayout"
Identifier "simple layout"
Screen "Screen 1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
--- NEW FILE: XFree86.man ---
.\" $XFree86: xc/programs/Xserver/hw/xfree86/XFree86.man,v 3.65 2003/11/12 19:06:46 dawes Exp $
.TH XFree86 1 __vendorversion__
.SH NAME
XFree86 - X11R6 X server
.SH SYNOPSIS
.B XFree86
.RI [\fB:\fP display ]
.RI [ option
.IR ... ]
.SH DESCRIPTION
.B XFree86
is a full featured X server that was originally designed for UNIX and
UNIX-like operating systems running on Intel x86 hardware. It now runs
on a wider range of hardware and OS platforms.
.PP
This work was originally derived from
.I "X386\ 1.2"
by Thomas Roell which was contributed to X11R5 by Snitily Graphics
Consulting Service. The
.B XFree86
server architecture was redesigned for the 4.0 release, and it includes
among many other things a loadable module system derived from code
donated by Metro Link, Inc. The current XFree86 release is compatible
with X11R6.6.
.SH PLATFORMS
.PP
.B XFree86
operates under a wide range of operating systems and hardware platforms.
The Intel x86 (IA32) architecture is the most widely supported hardware
platform. Other hardware platforms include Compaq Alpha, Intel IA64,
SPARC and PowerPC. The most widely supported operating systems are the
free/OpenSource UNIX-like systems such as Linux, FreeBSD, NetBSD and
OpenBSD. Commercial UNIX operating systems such as Solaris (x86) and
UnixWare are also supported. Other supported operating systems include
LynxOS, and GNU Hurd. Darwin and Mac OS X are supported with the
XDarwin(1) X server. Win32/Cygwin is supported with the XWin X server.
.PP
.SH "NETWORK CONNECTIONS"
.B XFree86
supports connections made using the following reliable
byte-streams:
.TP 4
.I "Local"
On most platforms, the "Local" connection type is a UNIX-domain socket.
On some System V platforms, the "local" connection types also include
STREAMS pipes, named pipes, and some other mechanisms.
.TP 4
.I TCP\/IP
.B XFree86
listens on port
.RI 6000+ n ,
where
.I n
is the display number. This connection type can be disabled with the
.B \-nolisten
option (see the Xserver(1) man page for details).
.SH "ENVIRONMENT VARIABLES"
For operating systems that support local connections other than Unix
Domain sockets (SVR3 and SVR4), there is a compiled-in list specifying
the order in which local connections should be attempted. This list
can be overridden by the
.I XLOCAL
environment variable described below. If the display name indicates a
best-choice connection should be made (e.g.
.BR :0.0 ),
each connection mechanism is tried until a connection succeeds or no
more mechanisms are available. Note: for these OSs, the Unix Domain
socket connection is treated differently from the other local connection
types. To use it the connection must be made to
.BR unix:0.0 .
.PP
The
.I XLOCAL
environment variable should contain a list of one more
more of the following:
.PP
.RS 8
.nf
NAMED
PTS
SCO
ISC
.fi
.RE
.PP
which represent SVR4 Named Streams pipe, Old-style USL Streams pipe,
SCO XSight Streams pipe, and ISC Streams pipe, respectively. You can
select a single mechanism (e.g.
.IR XLOCAL=NAMED ),
or an ordered list (e.g. \fIXLOCAL="NAMED:PTS:SCO"\fP).
his variable overrides the compiled-in defaults. For SVR4 it is
recommended that
.I NAMED
be the first preference connection. The default setting is
.IR PTS:NAMED:ISC:SCO .
.PP
To globally override the compiled-in defaults, you should define (and
export if using
.B sh
or
.BR ksh )
.I XLOCAL
globally. If you use startx(1) or xinit(1), the definition should be
at the top of your
.I .xinitrc
file. If you use xdm(1), the definitions should be early on in the
.I __projectroot__/lib/X11/xdm/Xsession
script.
.SH OPTIONS
.B XFree86
supports several mechanisms for supplying/obtaining configuration and
run-time parameters: command line options, environment variables, the
XF86Config(__filemansuffix__) configuration file, auto-detection, and
fallback defaults. When the same information is supplied in more than
one way, the highest precedence mechanism is used. The list of mechanisms
is ordered from highest precedence to lowest. Note that not all parameters
can be supplied via all methods. The available command line options
and environment variables (and some defaults) are described here and in
the Xserver(1) manual page. Most configuration file parameters, with
their defaults, are described in the XF86Config(__filemansuffix__) manual
page. Driver and module specific configuration parameters are described
in the relevant driver or module manual page.
.PP
Starting with version 4.4,
.B XFree86
has support for generating a usable configuration at run-time when no
XF86Config(__filemansuffix__) configuration file is provided. The
initial version of this automatic configuration support is targeted at
the most popular hardware and software platforms supported by XFree86.
Some details about how this works can be found in the
.B CONFIGURATION
section below and in the getconfig(1) manual page.
.PP
In addition to the normal server options described in the Xserver(1)
manual page,
.B XFree86
accepts the following command line switches:
.TP 8
.BI vt XX
.I XX
specifies the Virtual Terminal device number which
.B XFree86
will use. Without this option,
.B XFree86
will pick the first available Virtual Terminal that it can locate. This
option applies only to platforms such as Linux, BSD, SVR3 and SVR4, that
have virtual terminal support.
.TP
.B \-allowMouseOpenFail
Allow the server to start up even if the mouse device can't be opened
or initialised. This is equivalent to the
.B AllowMouseOpenFail
XF86Config(__filemansuffix__) file option.
.TP 8
.B \-allowNonLocalModInDev
Allow changes to keyboard and mouse settings from non-local clients.
By default, connections from non-local clients are not allowed to do
this. This is equivalent to the
.B AllowNonLocalModInDev
XF86Config(__filemansuffix__) file option.
.TP 8
.B \-allowNonLocalXvidtune
Make the VidMode extension available to remote clients. This allows
the xvidtune client to connect from another host. This is equivalent
to the
.B AllowNonLocalXvidtune
XF86Config(__filemansuffix__) file option. By default non-local
connections are not allowed.
.TP 8
.BI \-bgamma " value"
Set the blue gamma correction.
.I value
must be between 0.1 and 10.
The default is 1.0. Not all drivers support this. See also the
.BR \-gamma ,
.BR \-rgamma ,
and
.B \-ggamma
options.
.TP 8
.BI \-bpp " n"
No longer supported. Use
.B \-depth
to set the color depth, and use
.B \-fbbpp
if you really need to force a non-default framebuffer (hardware) pixel
format.
.TP
.B \-configure
When this option is specified, the
.B XFree86
server loads all video driver modules, probes for available hardware,
and writes out an initial XF86Config(__filemansuffix__) file based on
what was detected. This option currently has some problems on some
platforms, but in most cases it is a good way to bootstrap the
configuration process. This option is only available when the server
is run as root (i.e, with real-uid 0).
.TP 8
.BI "\-crt /dev/tty" XX
SCO only. This is the same as the
.B vt
option, and is provided for compatibility with the native SCO X server.
.TP 8
.BI \-depth " n"
Sets the default color depth. Legal values are 1, 4, 8, 15, 16, and
24. Not all drivers support all values.
.TP 8
.B \-disableModInDev
Disable dynamic modification of input device settings. This is equivalent
to the
.B DisableModInDev
XF86Config(__filemansuffix__) file option.
.TP 8
.B \-disableVidMode
Disable the the parts of the VidMode extension (used by the xvidtune
client) that can be used to change the video modes. This is equivalent
to the
.B DisableVidModeExtension
XF86Config(__filemansuffix__) file option.
.TP 8
.B \-fbbpp \fIn\fP
Sets the number of framebuffer bits per pixel. You should only set this
if you're sure it's necessary; normally the server can deduce the correct
value from
.B \-depth
above. Useful if you want to run a depth 24 configuration with a 24
bpp framebuffer rather than the (possibly default) 32 bpp framebuffer
(or vice versa). Legal values are 1, 8, 16, 24, 32. Not all drivers
support all values.
.TP 8
.B \-flipPixels
Swap the default values for the black and white pixels.
.TP 8
.BI \-gamma " value"
Set the gamma correction.
.I value
must be between 0.1 and 10. The default is 1.0. This value is applied
equally to the R, G and B values. Those values can be set independently
with the
.BR \-rgamma ,
.BR \-bgamma ,
and
.B \-ggamma
options. Not all drivers support this.
.TP 8
.BI \-ggamma " value"
Set the green gamma correction.
.I value
must be between 0.1 and 10. The default is 1.0. Not all drivers support
this. See also the
.BR \-gamma ,
.BR \-rgamma ,
and
.B \-bgamma
options.
.TP 8
.B \-ignoreABI
The
.B XFree86
server checks the ABI revision levels of each module that it loads. It
will normally refuse to load modules with ABI revisions that are newer
than the server's. This is because such modules might use interfaces
that the server does not have. When this option is specified, mismatches
like this are downgraded from fatal errors to warnings. This option
should be used with care.
.TP 8
.B \-keeptty
Prevent the server from detaching its initial controlling terminal.
This option is only useful when debugging the server. Not all platforms
support (or can use) this option.
.TP 8
.BI \-keyboard " keyboard-name"
Use the XF86Config(__filemansuffix__) file
.B InputDevice
section called
.I keyboard-name
as the core keyboard. This option is ignored when the
.B Layout
section specifies a core keyboard. In the absence of both a Layout
section and this option, the first relevant
.B InputDevice
section is used for the core keyboard.
.TP 8
.BI \-layout " layout-name"
Use the XF86Config(__filemansuffix__) file
.B Layout
section called
.IR layout-name .
By default the first
.B Layout
section is used.
.TP 8
.BI \-logfile " filename"
Use the file called
.I filename
as the
.B XFree86
server log file. The default log file is
.BI __logdir__/XFree86. n .log
on most platforms, where
.I n
is the display number of the
.B XFree86
server. The default may be in a different directory on some platforms.
This option is only available when the server is run as root (i.e, with
real-uid 0).
.TP 8
.BR \-logverbose " [\fIn\fP]"
Sets the verbosity level for information printed to the
.B XFree86
server log file. If the
.I n
value isn't supplied, each occurrence of this option increments the log
file verbosity level. When the
.I n
value is supplied, the log file verbosity level is set to that value.
The default log file verbosity level is 3.
.TP 8
.BI \-modulepath " searchpath"
Set the module search path to
.IR searchpath .
.I searchpath
is a comma separated list of directories to search for
.B XFree86
server modules. This option is only available when the server is run
as root (i.e, with real-uid 0).
.TP 8
.B \-nosilk
Disable Silken Mouse support.
.TP 8
.B \-pixmap24
Set the internal pixmap format for depth 24 pixmaps to 24 bits per pixel.
The default is usually 32 bits per pixel. There is normally little
reason to use this option. Some client applications don't like this
pixmap format, even though it is a perfectly legal format. This is
equivalent to the
.B Pixmap
XF86Config(__filemansuffix__) file option.
.TP 8
.B \-pixmap32
Set the internal pixmap format for depth 24 pixmaps to 32 bits per pixel.
This is usually the default. This is equivalent to the
.B Pixmap
XF86Config(__filemansuffix__) file option.
.TP 8
.BI \-pointer " pointer-name"
Use the XF86Config(__filemansuffix__) file
.B InputDevice
section called
.I pointer-name
as the core pointer. This option is ignored when the
.B Layout
section specifies a core pointer. In the absence of both a Layout
section and this option, the first relevant
.B InputDevice
section is used for the core pointer.
.TP 8
.B \-probeonly
Causes the server to exit after the device probing stage. The
XF86Config(__filemansuffix__) file is still used when this option is
given, so information that can be auto-detected should be commented out.
.TP 8
.B \-quiet
Suppress most informational messages at startup. The verbosity level
is set to zero.
.TP 8
.BI \-rgamma " value"
Set the red gamma correction.
.I value
must be between 0.1 and 10. The default is 1.0. Not all drivers support
this. See also the
.BR \-gamma ,
.BR \-bgamma ,
and
.B \-ggamma
options.
.TP 8
.B \-scanpci
When this option is specified, the
.B XFree86
server scans the PCI bus, and prints out some information about each
device that was detected. See also scanpci(1) and pcitweak(1).
.TP 8
.BI \-screen " screen-name"
Use the XF86Config(__filemansuffix__) file
.B Screen
section called
.IR screen-name .
By default the screens referenced by the default
.B Layout
section are used, or the first
.B Screen
section when there are no
.B Layout
sections.
.TP 8
.B \-showconfig
This is the same as the
.B \-version
option, and is included for compatibility reasons. It may be removed
in a future release, so the
.B \-version
option should be used instead.
.TP 8
.BI \-weight " nnn"
Set RGB weighting at 16 bpp. The default is 565. This applies only to
those drivers which support 16 bpp.
.TP 8
.BR \-verbose " [\fIn\fP]"
Sets the verbosity level for information printed on stderr. If the
.I n
value isn't supplied, each occurrence of this option increments the
verbosity level. When the
.I n
value is supplied, the verbosity level is set to that value. The default
verbosity level is 0.
.TP 8
.B \-version
Print out the server version, patchlevel, release date, the operating
system/platform it was built on, and whether it includes module loader
support.
.TP 8
.BI \-xf86config " file"
Read the server configuration from
.IR file .
This option will work for any file when the server is run as root (i.e,
with real-uid 0), or for files relative to a directory in the config
search path for all other users.
.SH "KEYBOARD"
.PP
The
.B XFree86
server is normally configured to recognize various special combinations
of key presses that instruct the server to perform some action, rather
than just sending the key press event to a client application. The
default XKEYBOARD keymap defines the key combinations listed below.
The server also has these key combinations builtin to its event handler
for cases where the XKEYBOARD extension is not being used. When using
the XKEYBOARD extension, which key combinations perform which actions
is completely configurable.
.PP
For more information about when the builtin event handler
is used to recognize the special key combinations, see
the documentation on the
.B HandleSpecialKeys
option in the XF86Config(__filemansuffix__) man page.
.PP
The special combinations of key presses recognized directly
by
.B XFree86
are:
.TP 8
.B Ctrl+Alt+Backspace
Immediately kills the server -- no questions asked. This can be disabled
with the
.B DontZap
XF86Config(__filemansuffix__) file option.
.TP 8
.B Ctrl+Alt+Keypad-Plus
Change video mode to next one specified in the configuration file.
This can be disabled with the
.B DontZoom
XF86Config(__filemansuffix__) file option.
.TP 8
.B Ctrl+Alt+Keypad-Minus
Change video mode to previous one specified in the configuration file.
This can be disabled with the
.B DontZoom
XF86Config(__filemansuffix__) file option.
.TP 8
.B Ctrl+Alt+Keypad-Multiply
Not treated specially by default. If the
.B AllowClosedownGrabs
XF86Config(__filemansuffix__) file option is specified, this key sequence
kills clients with an active keyboard or mouse grab as well as killing any
application that may have locked the server, normally using the
XGrabServer(__libmansuffix__) Xlib function.
.TP 8
.B Ctrl+Alt+Keypad-Divide
Not treated specially by default. If the
.B AllowDeactivateGrabs
XF86Config(__filemansuffix__) file option is specified, this key sequence
deactivates any active keyboard and mouse grabs.
.TP 8
.B Ctrl+Alt+F1...F12
For BSD and Linux systems with virtual terminal support, these keystroke
combinations are used to switch to virtual terminals 1 through 12,
respectively. This can be disabled with the
.B DontVTSwitch
XF86Config(__filemansuffix__) file option.
.SH CONFIGURATION
.B XFree86
typically uses a configuration file called
.B XF86Config
for its initial setup.
Refer to the XF86Config(__filemansuffix__) manual page for information
about the format of this file.
.PP
Starting with version 4.4,
.B XFree86
has a mechanism for automatically generating a built-in configuration
at run-time when no
.B XF86Config
file is present. The current version of this automatic configuration
mechanism works in three ways.
.PP
The first is via enhancements that have made many components of the
.B XF86Config
file optional. This means that information that can be probed or
reasonably deduced doesn't need to be specified explicitly, greatly
reducing the amount of built-in configuration information that needs to
be generated at run-time.
.PP
The second is to use an external utility called getconfig(1), when
available, to use meta-configuration information to generate a suitable
configuration for the primary video device. The meta-configuration
information can be updated to allow an existing installation to get the
best out of new hardware or to work around bugs that are found
post-release.
.PP
The third is to have "safe" fallbacks for most configuration information.
This maximises the likelihood that the
.B XFree86
server will start up in some usable configuration even when information
about the specific hardware is not available.
.PP
The automatic configuration support for XFree86 is work in progress.
It is currently aimed at the most popular hardware and software platforms
supported by XFree86. Enhancements are planned for future releases.
.SH FILES
The
.B XFree86
server config file can be found in a range of locations. These are
documented fully in the XF86Config(__filemansuffix__) manual page. The
most commonly used locations are shown here.
.TP 30
.B /etc/X11/XF86Config
Server configuration file.
.TP 30
.B /etc/X11/XF86Config-4
Server configuration file.
.TP 30
.B /etc/XF86Config
Server configuration file.
.TP 30
.B __projectroot__/etc/XF86Config
Server configuration file.
.TP 30
.B __projectroot__/lib/X11/XF86Config
Server configuration file.
.TP 30
.BI __logdir__/XFree86. n .log
Server log file for display
.IR n .
.TP 30
.B __projectroot__/bin/\(**
Client binaries.
.TP 30
.B __projectroot__/include/\(**
Header files.
.TP 30
.B __projectroot__/lib/\(**
Libraries.
.TP 30
.B __projectroot__/lib/X11/fonts/\(**
Fonts.
.TP 30
.B __projectroot__/lib/X11/rgb.txt
Color names to RGB mapping.
.TP 30
.B __projectroot__/lib/X11/XErrorDB
Client error message database.
.TP 30
.B __projectroot__/lib/X11/app-defaults/\(**
Client resource specifications.
.TP 30
.B __projectroot__/man/man?/\(**
Manual pages.
.TP 30
.BI /etc/X n .hosts
Initial access control list for display
.IR n .
.SH "SEE ALSO"
X(__miscmansuffix__), Xserver(1), xdm(1), xinit(1),
XF86Config(__filemansuffix__), xf86config(1), xf86cfg(1), xvidtune(1),
apm(__drivermansuffix__),
ati(__drivermansuffix__),
chips(__drivermansuffix__),
cirrus(__drivermansuffix__),
cyrix(__drivermansuffix__),
fbdev(__drivermansuffix__),
glide(__drivermansuffix__),
glint(__drivermansuffix__),
i128(__drivermansuffix__),
i740(__drivermansuffix__),
i810(__drivermansuffix__),
imstt(__drivermansuffix__),
mga(__drivermansuffix__),
neomagic(__drivermansuffix__),
nsc(__drivermansuffix__),
nv(__drivermansuffix__),
r128(__drivermansuffix__),
rendition(__drivermansuffix__),
s3virge(__drivermansuffix__),
siliconmotion(__drivermansuffix__),
sis(__drivermansuffix__),
sunbw2(__drivermansuffix__),
suncg14(__drivermansuffix__),
suncg3(__drivermansuffix__),
suncg6(__drivermansuffix__),
sunffb(__drivermansuffix__),
sunleo(__drivermansuffix__),
suntcx(__drivermansuffix__),
tdfx(__drivermansuffix__),
tga(__drivermansuffix__),
trident(__drivermansuffix__),
tseng(__drivermansuffix__),
v4l(__drivermansuffix__),
vesa(__drivermansuffix__),
vga(__drivermansuffix__),
vmware(__drivermansuffix__),
.br
README
.IR <http://www.xfree86.org/current/README.html> ,
.br
RELNOTES
.IR <http://www.xfree86.org/current/RELNOTES.html> ,
.br
README.mouse
.IR <http://www.xfree86.org/current/mouse.html> ,
.br
README.DRI
.IR <http://www.xfree86.org/current/DRI.html> ,
.br
Status
.IR <http://www.xfree86.org/current/Status.html> ,
.br
Install
.IR <http://www.xfree86.org/current/Install.html> .
.SH AUTHORS
XFree86 has many contributors world wide. The names of most of them
can be found in the documentation, CHANGELOG files in the source tree,
and in the actual source code.
.PP
XFree86 was originally based on \fIX386 1.2\fP by Thomas Roell, which
was contributed to the then X Consortium's X11R5 distribution by SGCS.
.PP
The project that became XFree86 was originally founded in 1992 by
David Dawes, Glenn Lai, Jim Tsillas and David Wexelblat.
.PP
XFree86 was later integrated in the then X Consortium's X11R6 release
by a group of dedicated XFree86 developers, including the following:
.PP
.RS 4
.nf
Stuart Anderson \fIanderson@metrolink.com\fP
Doug Anson \fIdanson@lgc.com\fP
Gertjan Akkerman \fIakkerman@dutiba.twi.tudelft.nl\fP
Mike Bernson \fImike@mbsun.mlb.org\fP
Robin Cutshaw \fIrobin@XFree86.org\fP
David Dawes \fIdawes@XFree86.org\fP
Marc Evans \fImarc@XFree86.org\fP
Pascal Haible \fIhaible@izfm.uni-stuttgart.de\fP
Matthieu Herrb \fIMatthieu.Herrb@laas.fr\fP
Dirk Hohndel \fIhohndel@XFree86.org\fP
David Holland \fIdavidh@use.com\fP
Alan Hourihane \fIalanh@fairlite.demon.co.uk\fP
Jeffrey Hsu \fIhsu@soda.berkeley.edu\fP
Glenn Lai \fIglenn@cs.utexas.edu\fP
Ted Lemon \fImellon@ncd.com\fP
Rich Murphey \fIrich@XFree86.org\fP
Hans Nasten \fInasten@everyware.se\fP
Mark Snitily \fImark@sgcs.com\fP
Randy Terbush \fIrandyt@cse.unl.edu\fP
Jon Tombs \fItombs@XFree86.org\fP
Kees Verstoep \fIversto@cs.vu.nl\fP
Paul Vixie \fIpaul@vix.com\fP
Mark Weaver \fIMark_Weaver@brown.edu\fP
David Wexelblat \fIdwex@XFree86.org\fP
Philip Wheatley \fIPhilip.Wheatley@ColumbiaSC.NCR.COM\fP
Thomas Wolfram \fIwolf@prz.tu-berlin.de\fP
Orest Zborowski \fIorestz@eskimo.com\fP
.fi
.RE
.PP
The current XFree86 core team consists of:
.PP
.RS 4
.nf
David Dawes \fIdawes@xfree86.org\fP
Egbert Eich \fIeich@xfree86.org\fP
Marc Evans \fImarc@xfree86.org\fP
Matthieu Herrb \fIherrb@xfree86.org\fP
Alan Hourihane \fIalanh@xfree86.org\fP
Marc La France \fItsi@xfree86.org\fP
Kevin Martin \fImartin@xfree86.org\fP
Rich Murphey \fIrich@xfree86.org\fP
Mark Vojkovich \fImarkv@xfree86.org\fP
David Wexelblat \fIdwex@xfree86.org\fP
.fi
.RE
.PP
XFree86 source is available from the FTP server
\fI<ftp://ftp.XFree86.org/pub/XFree86/>\fP, and from the XFree86 CVS
server \fI<http://www.xfree86.org/cvs/>\fP. Documentation and other
information can be found from the XFree86 web site
\fI<http://www.xfree86.org/>\fP.
.SH LEGAL
.PP
.B XFree86
is copyright software, provided under licenses that permit modification
and redistribution in source and binary form without fee. Portions of
.B XFree86
are copyright by The XFree86 Project, Inc. and numerous authors and
contributors from around the world. Licensing information can be found
at
.IR <http://www.xfree86.org/current/LICENSE.html> .
Refer to the source code for specific copyright notices.
.PP
.B XFree86(TM)
is a trademark of The XFree86 Project, Inc.
- Previous message: [xserver-commit] xfree86/xaa/msb_fixed Makefile.am,NONE,1.1
- Next message: [xserver-commit] xfree86/ddc ddcProperty.c,1.10,1.11 edid.c,1.4,1.5 edid.h,1.7,1.8 interpret_edid.c,1.8,1.9 interpret_vdif.c,1.6,1.7 print_edid.c,1.16,1.17 print_vdif.c,1.5,1.6 vdif.h,1.5,1.6 xf86DDC.c,1.27,1.28 xf86DDC.h,1.11,1.12
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]