NAME
s3 - S3 video driver
SYNOPSIS
Section "Device"
Identifier "devname"
Driver "s3"
...
[Option "optionname" ["optionvalue"]]
EndSection
SUPPORTED HARDWARE
The s3 driver supports PCI video cards based on the following S3 chips:
Trio32 86C732
Trio64 86C764
Trio64V+ 86C765
Aurora64V+ 86CM65
Trio64UV+ 86C767
Trio64V2/DX 86C775
Trio64V2/GX 86C785
Vision964 86C964
Vision968 86C968
Also driver supports the following RAMDACs:
IBM 524, IBM 524A, IBM 526, IBM 526DB
TI ViewPoint 3025
DESCRIPTION
s3 is an Xorg driver for S3 based video cards. The driver provides full
accelerated support for the following colour depths: 8, 15, 16 and 24.
The overlay video (Xv) is supported in depths 16 and 24 for the
Trio64V+, Trio64UV+, Trio64V2/DX and Trio64V2/GX chips.
CONFIGURATION DETAILS
Please refer to xorg.conf(5) for general configuration details. This
section only covers configuration details specific to this driver. All
options names are case and white space insensitive when parsed by the
server, for example, "trio 32/64" and "Trio32/64" are equivalent.
Chip overriding
The driver auto-detects the chipset and RAMDAC, but the following
Chipset names may optionally be specified in the configuration file
"Device" section, and will override the auto-detection:
"964-0", "964-1" 86C964 (rev.0 and rev.1)
"968" 86C968
"Trio32/64" 86C732/86C764
"Aurora64V+" 86CM65
"Trio64UV+" 86C767
"Trio64V2/DX/GX" 86C775/86C785
The 86C765 (Trio64V+) is Chipset "Trio32/64" with ChipRev greater or
equal 0x40.
An overriding of RAMDAC auto-detection currently is not implemented.
Colour depth
For every supported colour depth the X server automatically selects an
appropriate number of bits per pixel (bpp) for framebuffer. The depth 8
is represented by 8 bpp framebuffer (1 byte/pixel), the depths 15 and
16 (respectively 5.5.5 and 5.6.5 pixel formats) are represented by the
16 bpp framebuffer (2 bytes/pixel). Whenever the depth 24 is
configured, the X server by default uses the 32 bpp framebuffer (4
bytes/pixel), and the hardware is adjusted accordingly to the X.8.8.8
pixel format, where X is the ignored upper byte.
As the second option for the depth 24, the X server can be configured
to use 24 bpp framebuffer with the 8.8.8 pixel format (3 bytes/pixel),
which is supported by Trio64V+, Trio64UV+, Trio64V2/DX and Trio64V2/GX.
If the video board has limited video RAM the 24 bpp framebuffer has an
advantage over 32 bpp framebuffer as it requires less memory to store
screen, and, therefore, more space will be available for a video frame
(see "Overlay video" section). The 24 bpp framebuffer can be selected
by X server's option -fbbpp 24 or by specifying DefaultFbBpp option in
xorg.conf(5):
Section "Screen"
DefaultFbBpp 24
DefaultDepth 24
...
EndSection
However, the 24 bpp framebuffer mode has the hardware limitations: (i)
the 2D acceleration doesn't work with this mode (use the "shadowFB"
option to speed up drawing routines in this case); (ii) 24 bpp
framebuffer cannot be used with either interlaced or doublescan
graphics modes.
Overlay video
If your video board has limited RAM it would be useful to estimate how
large video frame might be placed in offscreen video memory. Suppose
that the video board has 2 MB of RAM, and X server is configured to
display 800x600 with the depth 24. By default the 32 bpp framebuffer
will be chosen for this depth, so 800 x 600 x 4 = 1875 kB will be
reserved for screen, and 2 MB - 1875 kB = 173 kB will remain for the
offscreen area. This is sufficient space, for example, for the VCD NTSC
352x240 frame. If you need to upscale video with a bigger frame, but it
doesn't fit the offscreen area, the only way to do this is to lower
either the resolution or framebuffer's depth or both before the
viewing, otherwise, you will get the allocation error and will not see
the video. For example, with 24 bpp framebuffer and the same resolution
800x600 the offscreen area will be about 640 kB - it's enough for the
640x480 frame. 800x600 with the 16 bpp framebuffer gives about 1110 kB
of offscreen area - this allows to upscale up to 768x576 movies. Note,
that all movie resolutions in examples above are provided as a
reference; the movies can have the different aspect ratios and non-
standard dimensions. A total pixel amount is the main consideration not
the certain width and height.
Due to hardware limitation the overlay video will not work with the
interlaced/doublescan modes. Downscaling is not implemented in
hardware.
Configuration options
The following display Options are supported:
Option "HWCursor" "boolean"
Enable or disable the hardware cursor. Currently, hardware
cursor is not implemented, so the option will be ignored.
Default: off (software cursor).
Option "NoAccel" "boolean"
Disable acceleration. Very useful for determining if the driver
has problems with drawing and acceleration routines. This is the
first option to try if your server runs but you see graphic
corruption on the screen. Using it decreases performance, as it
uses software emulation for drawing operations the video driver
can accelerate with hardware. Default: off (acceleration is
enabled).
Option "ShadowFB" "boolean"
Use shadow framebuffer. Disables hardware acceleration. Use this
option when the hardware acceleration is not available or
undesirable. Default: off.
Option "XVideo" "boolean"
Enable or disable Xv support. Default: on.
The following video memory Options are supported:
Option "slow_dram_refresh" "boolean"
Enable three refresh cycles per scanline. Default: off (one
refresh cycle).
Option "slow_edodram" "boolean"
Switch to 2-cycle EDO mode. Try this if you encounter pixel
corruption. Using this option will cause a decrease in
performance. Default: off (BIOS defaults).
Option "slow_dram" "boolean"
For Trio and Aurora64V+ chips: increase -RAS Precharge Timing to
3.5 MCLK. Try this option if you encounter pixel errors.
Default: off (BIOS defaults).
Option "slow_vram" "boolean"
For Vision964, Vision968 chips: increase -RAS Low Timing to 4.5
MCLK. Default: off (BIOS defaults).
SEE ALSO
Xorg(1), xorg.conf(5), Xserver(1), X(7)
AUTHORS
Thomas Roell, Mark Vojkovich, Kevin E. Martin, Amancio Hasty, Jon N.
Tombs and others were the original authors of driver for XFree86 3.x.
Ani Joshi reworked driver for XFree86 4.x. The further modifications
were made by the following contributors: Adam Jackson, Alan
Coopersmith, Dave Airlie, Andrew Radrianasulu, Paulo Cesar Pereira de
Andrade, Eric Anholt, Sren Sandmann Pedersen, Alex Deucher, Evgeny M.
Zubok, Daniel Stone and others.
The manual was written by Evgeny M. Zubok <evgeny.zubok@tochka.ru>