Please refer to xorg.conf(5) for general configuration details. This section only covers configuration
details specific to this driver.
The Intel 8xx and 9xx families of integrated graphics chipsets have a unified memory architecture meaning
that system memory is used as video RAM. For the i810 and i815 family of chipsets, operating system
support for allocating system memory is required in order to use this driver. For the 830M and later,
this is required in order for the driver to use more video RAM than has been pre-allocated at boot time
by the BIOS. This is usually achieved with an "agpgart" or "agp" kernel driver. Linux, FreeBSD,
OpenBSD, NetBSD, and Solaris have such kernel drivers available.
By default, the i810/i815 will use 8 MB of system memory for graphics if AGP allocable memory is < 128
MB, 16 MB if < 192 MB or 24 MB if higher. Use the VideoRam option to change the default value.
For the 830M and later, the driver will automatically size its memory allocation according to the
features it will support. Therefore, the VideoRam option, which in the past had been necessary to allow
more than some small amount of memory to be allocated, is now ignored.
The following driver Options are supported
Option"ColorKey""integer"
This sets the default pixel value for the YUV video overlay key.
Default: undefined.
Option"DRI""string"
Disable or enable DRI support. A driver name to use can be provided instead of simple boolean
value, which will be passed to the GL implementation for it to load the appropriate backend.
Alternatively the maximum level of DRI to enable (e.g. "1", "2" or "3") can be specified.
Default: All levels of DRI are enabled for configurations where it is supported.
The following driver Options are supported for the i810 and i815 chipsets:
Option"CacheLines""integer"
This allows the user to change the amount of graphics memory used for 2D acceleration and video
when XAA acceleration is enabled. Decreasing this amount leaves more for 3D textures. Increasing
it can improve 2D performance at the expense of 3D performance.
Default: depends on the resolution, depth, and available video memory. The driver attempts to
allocate space for at 3 screenfuls of pixmaps plus an HD-sized XV video. The default used for a
specific configuration can be found by examining the Xorg log file.
Option"DDC""boolean"
Disable or enable DDC support.
Default: enabled.
Option"Dac6Bit""boolean"
Enable or disable 6-bits per RGB for 8-bit modes.
Default: 8-bits per RGB for 8-bit modes.
Option"XvMCSurfaces""integer"
This option enables XvMC. The integer parameter specifies the number of surfaces to use. Valid
values are 6 and 7.
Default: XvMC is disabled.
VideoRaminteger
This option specifies the amount of system memory to use for graphics, in KB.
The default is 8192 if AGP allocable memory is < 128 MB, 16384 if < 192 MB, 24576 if higher. DRI
require at least a value of 16384. Higher values may give better 3D performance, at expense of
available system memory.
Option"Accel""boolean"
Enable or disable acceleration.
Default: acceleration is enabled.
The following driver Options are supported for the 830M and later chipsets:
Option"Accel""boolean"
Enable or disable acceleration.
Default: acceleration is enabled.
Option"Present""boolean"
Enable use of hardware counters and flow control for the Present extension.
Default: Enabled
Option"AccelMethod""string"
Select acceleration method. There are a couple of backends available for accelerating the DDX.
"UXA" (Unified Acceleration Architecture) is the mature backend that was introduced to support the
GEM driver model. It is in the process of being superseded by "SNA" (Sandybridge's New
Acceleration). Until that process is complete, the ability to choose which backend to use remains
for backwards compatibility. In addition, there are a pair of sub-options to limit the
acceleration for debugging use. Specify "off" or "none" to disable all acceleration, or "blt" to
disable render acceleration and only use the BLT engine.
Default: use SNA (render acceleration)
Option"TearFree""boolean"
Disable or enable TearFree updates. This option forces X to perform all rendering to a backbuffer
prior to updating the actual display. It requires an extra memory allocation the same size as a
framebuffer, the occasional extra copy, and requires Damage tracking. Thus enabling TearFree
requires more memory and is slower (reduced throughput) and introduces a small amount of output
latency, but it should not impact input latency. However, the update to the screen is then
performed synchronously with the vertical refresh of the display so that the entire update is
completed before the display starts its refresh. That is only one frame is ever visible,
preventing an unsightly tear between two visible and differing frames. Note that this replicates
what the compositing manager should be doing, however TearFree will redirect the compositor
updates (and those of fullscreen games) directly on to the scanout thus incurring no additional
overhead in the composited case. Also note that not all compositing managers prevent tearing, and
if the outputs are rotated, there will still be tearing without TearFree enabled.
Default: TearFree is disabled.
Option"ReprobeOutputs""boolean"
Disable or enable rediscovery of connected displays during server startup. As the kernel driver
loads it scans for connected displays and configures a console spanning those outputs. When the X
server starts, we then take the list of connected displays and framebuffer layout and use that for
the initial configuration. Sometimes, not all displays are correctly detected by the kernel and so
it is useful in a few circumstances for X to force the kernel to reprobe all displays when it
starts. To make the X server recheck the status of connected displays, set the "ReprobeOutputs"
option to true. Please do file a bug for any circumstances which require this workaround.
Default: reprobing is disabled for a faster startup.
Option"VideoKey""integer"
This is the same as the "ColorKey" option described above. It is provided for compatibility with
most other drivers.
Option"XvPreferOverlay""boolean"
Make hardware overlay be the first XV adaptor. The overlay behaves incorrectly in the presence of
compositing, but some prefer it due to it syncing to vblank in the absence of compositing. While
most XV-using applications have options to select which XV adaptor to use, this option can be used
to place the overlay first for applications which don't have options for selecting adaptors.
Default: Textured video adaptor is preferred.
Option"Backlight""string"
Override the probed backlight control interface. Sometimes the automatically selected backlight
interface may not correspond to the correct, or simply most useful, interface available on the
system. This allows you to override that choice by specifying the entry under /sys/class/backlight
to use.
Default: Automatic selection.
Option"CustomEDID""string"
Override the probed EDID on particular outputs. Sometimes the manufacturer supplied EDID is
corrupt or lacking a few usable modes and supplying a corrected EDID may be easier than specifying
every modeline. This option allows to pass the path to load an EDID from per output. The format is
a comma separated string of output:path pairs, e.g. DP1:/path/to/dp1.edid,DP2:/path/to/dp2.edid
Default: No override, use manufacturer supplied EDIDs.
Option"FallbackDebug""boolean"
Enable printing of debugging information on acceleration fallbacks to the server log.
Default: Disabled
Option"DebugFlushBatches""boolean"
Flush the batch buffer after every single operation.
Default: Disabled
Option"DebugFlushCaches""boolean"
Include an MI_FLUSH at the end of every batch buffer to force data to be flushed out of cache and
into memory before the completion of the batch.
Default: Disabled
Option"DebugWait""boolean"
Wait for the completion of every batch buffer before continuing, i.e. perform synchronous
rendering.
Default: Disabled
Option"HWRotation""boolean"
Override the use of native hardware rotation and force the use of software, but GPU accelerated
where possible, rotation. On some platforms the hardware can scanout directly into a rotated
output bypassing the intermediate rendering and extra allocations required for software
implemented rotation (i.e. native rotation uses less resources, is quicker and uses less power).
This allows you to disable the native rotation in case of errors.
Default: Enabled (use hardware rotation)
Option"VSync""boolean"
This option controls the use of commands to synchronise rendering with the vertical refresh of the
display. Some rendering commands have the option to be performed in a "tear-free" fashion by
stalling the GPU to wait for the display to be outside of the region to be updated. This slows
down all rendering, and historically has been the source of many GPU hangs.
Default: enabled.
Option"PageFlip""boolean"
This option controls the use of commands to flip the scanout address on a VBlank. This is used by
glXSwapBuffers to efficiently perform the back-to-front exchange at the end of a frame without
incurring the penalty of a copy, or stalling the render pipeline (the flip is performed
asynchronrously to the render command stream by the display engine). However, it has historically
been the source of many GPU hangs.
Default: enabled.
Option"SwapbuffersWait""boolean"
This option controls the behavior of glXSwapBuffers and glXCopySubBufferMESA calls by GL
applications. If enabled, the calls will avoid tearing by making sure the display scanline is
outside of the area to be copied before the copy occurs. If disabled, no scanline synchronization
is performed, meaning tearing will likely occur.
Default: enabled.
Option"TripleBuffer""boolean"
This option enables the use of a third buffer for page-flipping. The third buffer allows
applications to run at vrefresh rates even if they occasionally fail to swapbuffers on time. The
effect of such missed swaps is the output jitters between 60fps and 30fps, and in the worst case
appears frame-locked to 30fps. The disadvantage of triple buffering is that there is an extra
frame of latency, due to the pre-rendered frame sitting in the swap queue, between input and any
display update.
Default: enabled.
Option"Tiling""boolean"
This option controls whether memory buffers for Pixmaps are allocated in tiled mode. In most
cases (especially for complex rendering), tiling dramatically improves performance.
Default: enabled.
Option"LinearFramebuffer""boolean"
This option controls whether the memory for the scanout (also known as the front or frame buffer)
is allocated in linear memory. A tiled framebuffer is required for power conservation features,
but for certain system configurations you may wish to override this and force a linear layout.
Default: disabled
Option"RelaxedFencing""boolean"
This option controls whether we attempt to allocate the minimal amount of memory required for the
buffers. The reduction in working set has a substantial improvement on system performance.
However, this has been demonstrate to be buggy on older hardware (845-865 and 915-945, but ok on
PineView and later) so on those chipsets defaults to off.
Default: Enabled for G33 (includes PineView), and later, class machines.
Option"XvMC""boolean"
Enable XvMC driver. Current support MPEG2 MC on 915/945 and G33 series. User should provide
absolute path to libIntelXvMC.so in XvMCConfig file.
Default: Disabled.
Option"Throttle""boolean"
This option controls whether the driver periodically waits for pending drawing operations to
complete. Throttling ensures that the GPU does not lag too far behind the CPU and thus noticeable
delays in user responsible at the cost of throughput performance.
Default: enabled.
Option"HotPlug""boolean"
This option controls whether the driver automatically notifies applications when monitors are
connected or disconnected.
Default: enabled.
Option"Virtualheads""integer"
This option controls specifies the number of fake outputs to create in addition to the normal
outputs detected on your hardware. These outputs cannot be assigned to the regular displays
attached to the GPU, but do otherwise act as any other xrandr output and share a portion of the
regular framebuffer. One use case for these extra heads is for extending your desktop onto a
discrete GPU using the Bumblebee project. However, the recommendation here is to use PRIME instead
to create a single Xserver that can addresses and coordinate between multiple GPUs.
Default: 0
Option"ZaphodHeads""string"
Specify the randr output(s) to use with zaphod mode for a particular driver instance. If you set
this option you must use it with all instances of the driver. By default, each head is assigned
only one CRTC (which limits using multiple outputs with that head to cloned mode). CRTC can be
manually assigned to individual heads by preceding the output names with a comma delimited list of
pipe numbers followed by a colon. Note that different pipes may be limited in their functionality
and some outputs may only work with different pipes.
For example:
Option"ZaphodHeads""LVDS1,VGA1"
will assign xrandr outputs LVDS1 and VGA1 to this instance of the driver.
Option"ZaphodHeads""0,2:HDMI1,DP2"
will assign xrandr outputs HDMI1 and DP2 and CRTCs 0 and 2 to this instance of the driver.
Install Now
PNG Icons
