xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Linux-2.6.12-rc2

Browse Source 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
This commit is contained in:
Linus Torvalds
2005-04-16 15:20:36 -07:00
commit 1da177e4c3
17291 changed files with 6718755 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

399
Documentation/video4linux/API.html Normal file
View File

@@ -0,0 +1,399 @@
<HTML><HEAD>
<TITLE>Video4Linux Kernel API Reference v0.1:19990430</TITLE>
</HEAD>
<! Revision History: >
<! 4/30/1999 - Fred Gleason (fredg@wava.com)>
<! Documented extensions for the Radio Data System (RDS) extensions >
<BODY bgcolor="#ffffff">
<H3>Devices</H3>
Video4Linux provides the following sets of device files. These live on the
character device formerly known as "/dev/bttv". /dev/bttv should be a
symlink to /dev/video0 for most people.
<P>
<TABLE>
<TR><TH>Device Name</TH><TH>Minor Range</TH><TH>Function</TH>
<TR><TD>/dev/video</TD><TD>0-63</TD><TD>Video Capture Interface</TD>
<TR><TD>/dev/radio</TD><TD>64-127</TD><TD>AM/FM Radio Devices</TD>
<TR><TD>/dev/vtx</TD><TD>192-223</TD><TD>Teletext Interface Chips</TD>
<TR><TD>/dev/vbi</TD><TD>224-239</TD><TD>Raw VBI Data (Intercast/teletext)</TD>
</TABLE>
<P>
Video4Linux programs open and scan the devices to find what they are looking
for. Capability queries define what each interface supports. The
described API is only defined for video capture cards. The relevant subset
applies to radio cards. Teletext interfaces talk the existing VTX API.
<P>
<H3>Capability Query Ioctl</H3>
The <B>VIDIOCGCAP</B> ioctl call is used to obtain the capability
information for a video device. The <b>struct video_capability</b> object
passed to the ioctl is completed and returned. It contains the following
information
<P>
<TABLE>
<TR><TD><b>name[32]</b><TD>Canonical name for this interface</TD>
<TR><TD><b>type</b><TD>Type of interface</TD>
<TR><TD><b>channels</b><TD>Number of radio/tv channels if appropriate</TD>
<TR><TD><b>audios</b><TD>Number of audio devices if appropriate</TD>
<TR><TD><b>maxwidth</b><TD>Maximum capture width in pixels</TD>
<TR><TD><b>maxheight</b><TD>Maximum capture height in pixels</TD>
<TR><TD><b>minwidth</b><TD>Minimum capture width in pixels</TD>
<TR><TD><b>minheight</b><TD>Minimum capture height in pixels</TD>
</TABLE>
<P>
The type field lists the capability flags for the device. These are
as follows
<P>
<TABLE>
<TR><TH>Name</TH><TH>Description</TH>
<TR><TD><b>VID_TYPE_CAPTURE</b><TD>Can capture to memory</TD>
<TR><TD><b>VID_TYPE_TUNER</b><TD>Has a tuner of some form</TD>
<TR><TD><b>VID_TYPE_TELETEXT</b><TD>Has teletext capability</TD>
<TR><TD><b>VID_TYPE_OVERLAY</b><TD>Can overlay its image onto the frame buffer</TD>
<TR><TD><b>VID_TYPE_CHROMAKEY</b><TD>Overlay is Chromakeyed</TD>
<TR><TD><b>VID_TYPE_CLIPPING</b><TD>Overlay clipping is supported</TD>
<TR><TD><b>VID_TYPE_FRAMERAM</b><TD>Overlay overwrites frame buffer memory</TD>
<TR><TD><b>VID_TYPE_SCALES</b><TD>The hardware supports image scaling</TD>
<TR><TD><b>VID_TYPE_MONOCHROME</b><TD>Image capture is grey scale only</TD>
<TR><TD><b>VID_TYPE_SUBCAPTURE</b><TD>Capture can be of only part of the image</TD>
</TABLE>
<P>
The minimum and maximum sizes listed for a capture device do not imply all
that all height/width ratios or sizes within the range are possible. A
request to set a size will be honoured by the largest available capture
size whose capture is no large than the requested rectangle in either
direction. For example the quickcam has 3 fixed settings.
<P>
<H3>Frame Buffer</H3>
Capture cards that drop data directly onto the frame buffer must be told the
base address of the frame buffer, its size and organisation. This is a
privileged ioctl and one that eventually X itself should set.
<P>
The <b>VIDIOCSFBUF</b> ioctl sets the frame buffer parameters for a capture
card. If the card does not do direct writes to the frame buffer then this
ioctl will be unsupported. The <b>VIDIOCGFBUF</b> ioctl returns the
currently used parameters. The structure used in both cases is a
<b>struct video_buffer</b>.
<P>
<TABLE>
<TR><TD><b>void *base</b></TD><TD>Base physical address of the buffer</TD>
<TR><TD><b>int height</b></TD><TD>Height of the frame buffer</TD>
<TR><TD><b>int width</b></TD><TD>Width of the frame buffer</TD>
<TR><TD><b>int depth</b></TD><TD>Depth of the frame buffer</TD>
<TR><TD><b>int bytesperline</b></TD><TD>Number of bytes of memory between the start of two adjacent lines</TD>
</TABLE>
<P>
Note that these values reflect the physical layout of the frame buffer.
The visible area may be smaller. In fact under XFree86 this is commonly the
case. XFree86 DGA can provide the parameters required to set up this ioctl.
Setting the base address to NULL indicates there is no physical frame buffer
access.
<P>
<H3>Capture Windows</H3>
The capture area is described by a <b>struct video_window</b>. This defines
a capture area and the clipping information if relevant. The
<b>VIDIOCGWIN</b> ioctl recovers the current settings and the
<b>VIDIOCSWIN</b> sets new values. A successful call to <b>VIDIOCSWIN</b>
indicates that a suitable set of parameters have been chosen. They do not
indicate that exactly what was requested was granted. The program should
call <b>VIDIOCGWIN</b> to check if the nearest match was suitable. The
<b>struct video_window</b> contains the following fields.
<P>
<TABLE>
<TR><TD><b>x</b><TD>The X co-ordinate specified in X windows format.</TD>
<TR><TD><b>y</b><TD>The Y co-ordinate specified in X windows format.</TD>
<TR><TD><b>width</b><TD>The width of the image capture.</TD>
<TR><TD><b>height</b><TD>The height of the image capture.</TD>
<TR><TD><b>chromakey</b><TD>A host order RGB32 value for the chroma key.</TD>
<TR><TD><b>flags</b><TD>Additional capture flags.</TD>
<TR><TD><b>clips</b><TD>A list of clipping rectangles. <em>(Set only)</em></TD>
<TR><TD><b>clipcount</b><TD>The number of clipping rectangles. <em>(Set only)</em></TD>
</TABLE>
<P>
Clipping rectangles are passed as an array. Each clip consists of the following
fields available to the user.
<P>
<TABLE>
<TR><TD><b>x</b></TD><TD>X co-ordinate of rectangle to skip</TD>
<TR><TD><b>y</b></TD><TD>Y co-ordinate of rectangle to skip</TD>
<TR><TD><b>width</b></TD><TD>Width of rectangle to skip</TD>
<TR><TD><b>height</b></TD><TD>Height of rectangle to skip</TD>
</TABLE>
<P>
Merely setting the window does not enable capturing. Overlay capturing
(i.e. PCI-PCI transfer to the frame buffer of the video card)
is activated by passing the <b>VIDIOCCAPTURE</b> ioctl a value of 1, and
disabled by passing it a value of 0.
<P>
Some capture devices can capture a subfield of the image they actually see.
This is indicated when VIDEO_TYPE_SUBCAPTURE is defined.
The video_capture describes the time and special subfields to capture.
The video_capture structure contains the following fields.
<P>
<TABLE>
<TR><TD><b>x</b></TD><TD>X co-ordinate of source rectangle to grab</TD>
<TR><TD><b>y</b></TD><TD>Y co-ordinate of source rectangle to grab</TD>
<TR><TD><b>width</b></TD><TD>Width of source rectangle to grab</TD>
<TR><TD><b>height</b></TD><TD>Height of source rectangle to grab</TD>
<TR><TD><b>decimation</b></TD><TD>Decimation to apply</TD>
<TR><TD><b>flags</b></TD><TD>Flag settings for grabbing</TD>
</TABLE>
The available flags are
<P>
<TABLE>
<TR><TH>Name</TH><TH>Description</TH>
<TR><TD><b>VIDEO_CAPTURE_ODD</b><TD>Capture only odd frames</TD>
<TR><TD><b>VIDEO_CAPTURE_EVEN</b><TD>Capture only even frames</TD>
</TABLE>
<P>
<H3>Video Sources</H3>
Each video4linux video or audio device captures from one or more
source <b>channels</b>. Each channel can be queries with the
<b>VDIOCGCHAN</b> ioctl call. Before invoking this function the caller
must set the channel field to the channel that is being queried. On return
the <b>struct video_channel</b> is filled in with information about the
nature of the channel itself.
<P>
The <b>VIDIOCSCHAN</b> ioctl takes an integer argument and switches the
capture to this input. It is not defined whether parameters such as colour
settings or tuning are maintained across a channel switch. The caller should
maintain settings as desired for each channel. (This is reasonable as
different video inputs may have different properties).
<P>
The <b>struct video_channel</b> consists of the following
<P>
<TABLE>
<TR><TD><b>channel</b></TD><TD>The channel number</TD>
<TR><TD><b>name</b></TD><TD>The input name - preferably reflecting the label
on the card input itself</TD>
<TR><TD><b>tuners</b></TD><TD>Number of tuners for this input</TD>
<TR><TD><b>flags</b></TD><TD>Properties the tuner has</TD>
<TR><TD><b>type</b></TD><TD>Input type (if known)</TD>
<TR><TD><b>norm</b><TD>The norm for this channel</TD>
</TABLE>
<P>
The flags defined are
<P>
<TABLE>
<TR><TD><b>VIDEO_VC_TUNER</b><TD>Channel has tuners.</TD>
<TR><TD><b>VIDEO_VC_AUDIO</b><TD>Channel has audio.</TD>
<TR><TD><b>VIDEO_VC_NORM</b><TD>Channel has norm setting.</TD>
</TABLE>
<P>
The types defined are
<P>
<TABLE>
<TR><TD><b>VIDEO_TYPE_TV</b><TD>The input is a TV input.</TD>
<TR><TD><b>VIDEO_TYPE_CAMERA</b><TD>The input is a camera.</TD>
</TABLE>
<P>
<H3>Image Properties</H3>
The image properties of the picture can be queried with the <b>VIDIOCGPICT</b>
ioctl which fills in a <b>struct video_picture</b>. The <b>VIDIOCSPICT</b>
ioctl allows values to be changed. All values except for the palette type
are scaled between 0-65535.
<P>
The <b>struct video_picture</b> consists of the following fields
<P>
<TABLE>
<TR><TD><b>brightness</b><TD>Picture brightness</TD>
<TR><TD><b>hue</b><TD>Picture hue (colour only)</TD>
<TR><TD><b>colour</b><TD>Picture colour (colour only)</TD>
<TR><TD><b>contrast</b><TD>Picture contrast</TD>
<TR><TD><b>whiteness</b><TD>The whiteness (greyscale only)</TD>
<TR><TD><b>depth</b><TD>The capture depth (may need to match the frame buffer depth)</TD>
<TR><TD><b>palette</b><TD>Reports the palette that should be used for this image</TD>
</TABLE>
<P>
The following palettes are defined
<P>
<TABLE>
<TR><TD><b>VIDEO_PALETTE_GREY</b><TD>Linear intensity grey scale (255 is brightest).</TD>
<TR><TD><b>VIDEO_PALETTE_HI240</b><TD>The BT848 8bit colour cube.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB565</b><TD>RGB565 packed into 16 bit words.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB555</b><TD>RGV555 packed into 16 bit words, top bit undefined.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB24</b><TD>RGB888 packed into 24bit words.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB32</b><TD>RGB888 packed into the low 3 bytes of 32bit words. The top 8bits are undefined.</TD>
<TR><TD><b>VIDEO_PALETTE_YUV422</b><TD>Video style YUV422 - 8bits packed 4bits Y 2bits U 2bits V</TD>
<TR><TD><b>VIDEO_PALETTE_YUYV</b><TD>Describe me</TD>
<TR><TD><b>VIDEO_PALETTE_UYVY</b><TD>Describe me</TD>
<TR><TD><b>VIDEO_PALETTE_YUV420</b><TD>YUV420 capture</TD>
<TR><TD><b>VIDEO_PALETTE_YUV411</b><TD>YUV411 capture</TD>
<TR><TD><b>VIDEO_PALETTE_RAW</b><TD>RAW capture (BT848)</TD>
<TR><TD><b>VIDEO_PALETTE_YUV422P</b><TD>YUV 4:2:2 Planar</TD>
<TR><TD><b>VIDEO_PALETTE_YUV411P</b><TD>YUV 4:1:1 Planar</TD>
</TABLE>
<P>
<H3>Tuning</H3>
Each video input channel can have one or more tuners associated with it. Many
devices will not have tuners. TV cards and radio cards will have one or more
tuners attached.
<P>
Tuners are described by a <b>struct video_tuner</b> which can be obtained by
the <b>VIDIOCGTUNER</b> ioctl. Fill in the tuner number in the structure
then pass the structure to the ioctl to have the data filled in. The
tuner can be switched using <b>VIDIOCSTUNER</b> which takes an integer argument
giving the tuner to use. A struct tuner has the following fields
<P>
<TABLE>
<TR><TD><b>tuner</b><TD>Number of the tuner</TD>
<TR><TD><b>name</b><TD>Canonical name for this tuner (eg FM/AM/TV)</TD>
<TR><TD><b>rangelow</b><TD>Lowest tunable frequency</TD>
<TR><TD><b>rangehigh</b><TD>Highest tunable frequency</TD>
<TR><TD><b>flags</b><TD>Flags describing the tuner</TD>
<TR><TD><b>mode</b><TD>The video signal mode if relevant</TD>
<TR><TD><b>signal</b><TD>Signal strength if known - between 0-65535</TD>
</TABLE>
<P>
The following flags exist
<P>
<TABLE>
<TR><TD><b>VIDEO_TUNER_PAL</b><TD>PAL tuning is supported</TD>
<TR><TD><b>VIDEO_TUNER_NTSC</b><TD>NTSC tuning is supported</TD>
<TR><TD><b>VIDEO_TUNER_SECAM</b><TD>SECAM tuning is supported</TD>
<TR><TD><b>VIDEO_TUNER_LOW</b><TD>Frequency is in a lower range</TD>
<TR><TD><b>VIDEO_TUNER_NORM</b><TD>The norm for this tuner is settable</TD>
<TR><TD><b>VIDEO_TUNER_STEREO_ON</b><TD>The tuner is seeing stereo audio</TD>
<TR><TD><b>VIDEO_TUNER_RDS_ON</b><TD>The tuner is seeing a RDS datastream</TD>
<TR><TD><b>VIDEO_TUNER_MBS_ON</b><TD>The tuner is seeing a MBS datastream</TD>
</TABLE>
<P>
The following modes are defined
<P>
<TABLE>
<TR><TD><b>VIDEO_MODE_PAL</b><TD>The tuner is in PAL mode</TD>
<TR><TD><b>VIDEO_MODE_NTSC</b><TD>The tuner is in NTSC mode</TD>
<TR><TD><b>VIDEO_MODE_SECAM</b><TD>The tuner is in SECAM mode</TD>
<TR><TD><b>VIDEO_MODE_AUTO</b><TD>The tuner auto switches, or mode does not apply</TD>
</TABLE>
<P>
Tuning frequencies are an unsigned 32bit value in 1/16th MHz or if the
<b>VIDEO_TUNER_LOW</b> flag is set they are in 1/16th KHz. The current
frequency is obtained as an unsigned long via the <b>VIDIOCGFREQ</b> ioctl and
set by the <b>VIDIOCSFREQ</b> ioctl.
<P>
<H3>Audio</H3>
TV and Radio devices have one or more audio inputs that may be selected.
The audio properties are queried by passing a <b>struct video_audio</b> to <b>VIDIOCGAUDIO</b> ioctl. The
<b>VIDIOCSAUDIO</b> ioctl sets audio properties.
<P>
The structure contains the following fields
<P>
<TABLE>
<TR><TD><b>audio</b><TD>The channel number</TD>
<TR><TD><b>volume</b><TD>The volume level</TD>
<TR><TD><b>bass</b><TD>The bass level</TD>
<TR><TD><b>treble</b><TD>The treble level</TD>
<TR><TD><b>flags</b><TD>Flags describing the audio channel</TD>
<TR><TD><b>name</b><TD>Canonical name for the audio input</TD>
<TR><TD><b>mode</b><TD>The mode the audio input is in</TD>
<TR><TD><b>balance</b><TD>The left/right balance</TD>
<TR><TD><b>step</b><TD>Actual step used by the hardware</TD>
</TABLE>
<P>
The following flags are defined
<P>
<TABLE>
<TR><TD><b>VIDEO_AUDIO_MUTE</b><TD>The audio is muted</TD>
<TR><TD><b>VIDEO_AUDIO_MUTABLE</b><TD>Audio muting is supported</TD>
<TR><TD><b>VIDEO_AUDIO_VOLUME</b><TD>The volume is controllable</TD>
<TR><TD><b>VIDEO_AUDIO_BASS</b><TD>The bass is controllable</TD>
<TR><TD><b>VIDEO_AUDIO_TREBLE</b><TD>The treble is controllable</TD>
<TR><TD><b>VIDEO_AUDIO_BALANCE</b><TD>The balance is controllable</TD>
</TABLE>
<P>
The following decoding modes are defined
<P>
<TABLE>
<TR><TD><b>VIDEO_SOUND_MONO</b><TD>Mono signal</TD>
<TR><TD><b>VIDEO_SOUND_STEREO</b><TD>Stereo signal (NICAM for TV)</TD>
<TR><TD><b>VIDEO_SOUND_LANG1</b><TD>European TV alternate language 1</TD>
<TR><TD><b>VIDEO_SOUND_LANG2</b><TD>European TV alternate language 2</TD>
</TABLE>
<P>
<H3>Reading Images</H3>
Each call to the <b>read</b> syscall returns the next available image
from the device. It is up to the caller to set format and size (using
the VIDIOCSPICT and VIDIOCSWIN ioctls) and then to pass a suitable
size buffer and length to the function. Not all devices will support
read operations.
<P>
A second way to handle image capture is via the mmap interface if supported.
To use the mmap interface a user first sets the desired image size and depth
properties. Next the VIDIOCGMBUF ioctl is issued. This reports the size
of buffer to mmap and the offset within the buffer for each frame. The
number of frames supported is device dependent and may only be one.
<P>
The video_mbuf structure contains the following fields
<P>
<TABLE>
<TR><TD><b>size</b><TD>The number of bytes to map</TD>
<TR><TD><b>frames</b><TD>The number of frames</TD>
<TR><TD><b>offsets</b><TD>The offset of each frame</TD>
</TABLE>
<P>
Once the mmap has been made the VIDIOCMCAPTURE ioctl starts the
capture to a frame using the format and image size specified in the
video_mmap (which should match or be below the initial query size).
When the VIDIOCMCAPTURE ioctl returns the frame is <em>not</em>
captured yet, the driver just instructed the hardware to start the
capture. The application has to use the VIDIOCSYNC ioctl to wait
until the capture of a frame is finished. VIDIOCSYNC takes the frame
number you want to wait for as argument.
<p>
It is allowed to call VIDIOCMCAPTURE multiple times (with different
frame numbers in video_mmap->frame of course) and thus have multiple
outstanding capture requests. A simple way do to double-buffering
using this feature looks like this:
<pre>
/* setup everything */
VIDIOCMCAPTURE(0)
while (whatever) {
VIDIOCMCAPTURE(1)
VIDIOCSYNC(0)
/* process frame 0 while the hardware captures frame 1 */
VIDIOCMCAPTURE(0)
VIDIOCSYNC(1)
/* process frame 1 while the hardware captures frame 0 */
}
</pre>
Note that you are <em>not</em> limited to only two frames. The API
allows up to 32 frames, the VIDIOCGMBUF ioctl returns the number of
frames the driver granted. Thus it is possible to build deeper queues
to avoid loosing frames on load peaks.
<p>
While capturing to memory the driver will make a "best effort" attempt
to capture to screen as well if requested. This normally means all
frames that "miss" memory mapped capture will go to the display.
<P>
A final ioctl exists to allow a device to obtain related devices if a
driver has multiple components (for example video0 may not be associated
with vbi0 which would cause an intercast display program to make a bad
mistake). The VIDIOCGUNIT ioctl reports the unit numbers of the associated
devices if any exist. The video_unit structure has the following fields.
<P>
<TABLE>
<TR><TD><b>video</b><TD>Video capture device</TD>
<TR><TD><b>vbi</b><TD>VBI capture device</TD>
<TR><TD><b>radio</b><TD>Radio device</TD>
<TR><TD><b>audio</b><TD>Audio mixer</TD>
<TR><TD><b>teletext</b><TD>Teletext device</TD>
</TABLE>
<P>
<H3>RDS Datastreams</H3>
For radio devices that support it, it is possible to receive Radio Data
System (RDS) data by means of a read() on the device. The data is packed in
groups of three, as follows:
<TABLE>
<TR><TD>First Octet</TD><TD>Least Significant Byte of RDS Block</TD></TR>
<TR><TD>Second Octet</TD><TD>Most Significant Byte of RDS Block
<TR><TD>Third Octet</TD><TD>Bit 7:</TD><TD>Error bit. Indicates that
an uncorrectable error occurred during reception of this block.</TD></TR>
<TR><TD>&nbsp;</TD><TD>Bit 6:</TD><TD>Corrected bit. Indicates that
an error was corrected for this data block.</TD></TR>
<TR><TD>&nbsp;</TD><TD>Bits 5-3:</TD><TD>Received Offset. Indicates the
offset received by the sync system.</TD></TR>
<TR><TD>&nbsp;</TD><TD>Bits 2-0:</TD><TD>Offset Name. Indicates the
offset applied to this data.</TD></TR>
</TABLE>
</BODY>
</HTML>

121
Documentation/video4linux/CARDLIST.bttv Normal file
View File

@@ -0,0 +1,121 @@
card=0 - *** UNKNOWN/GENERIC ***
card=1 - MIRO PCTV
card=2 - Hauppauge (bt848)
card=3 - STB, Gateway P/N 6000699 (bt848)
card=4 - Intel Create and Share PCI/ Smart Video Recorder III
card=5 - Diamond DTV2000
card=6 - AVerMedia TVPhone
card=7 - MATRIX-Vision MV-Delta
card=8 - Lifeview FlyVideo II (Bt848) LR26 / MAXI TV Video PCI2 LR26
card=9 - IMS/IXmicro TurboTV
card=10 - Hauppauge (bt878)
card=11 - MIRO PCTV pro
card=12 - ADS Technologies Channel Surfer TV (bt848)
card=13 - AVerMedia TVCapture 98
card=14 - Aimslab Video Highway Xtreme (VHX)
card=15 - Zoltrix TV-Max
card=16 - Prolink Pixelview PlayTV (bt878)
card=17 - Leadtek WinView 601
card=18 - AVEC Intercapture
card=19 - Lifeview FlyVideo II EZ /FlyKit LR38 Bt848 (capture only)
card=20 - CEI Raffles Card
card=21 - Lifeview FlyVideo 98/ Lucky Star Image World ConferenceTV LR50
card=22 - Askey CPH050/ Phoebe Tv Master + FM
card=23 - Modular Technology MM201/MM202/MM205/MM210/MM215 PCTV, bt878
card=24 - Askey CPH05X/06X (bt878) [many vendors]
card=25 - Terratec TerraTV+ Version 1.0 (Bt848)/ Terra TValue Version 1.0/ Vobis TV-Boostar
card=26 - Hauppauge WinCam newer (bt878)
card=27 - Lifeview FlyVideo 98/ MAXI TV Video PCI2 LR50
card=28 - Terratec TerraTV+ Version 1.1 (bt878)
card=29 - Imagenation PXC200
card=30 - Lifeview FlyVideo 98 LR50
card=31 - Formac iProTV, Formac ProTV I (bt848)
card=32 - Intel Create and Share PCI/ Smart Video Recorder III
card=33 - Terratec TerraTValue Version Bt878
card=34 - Leadtek WinFast 2000/ WinFast 2000 XP
card=35 - Lifeview FlyVideo 98 LR50 / Chronos Video Shuttle II
card=36 - Lifeview FlyVideo 98FM LR50 / Typhoon TView TV/FM Tuner
card=37 - Prolink PixelView PlayTV pro
card=38 - Askey CPH06X TView99
card=39 - Pinnacle PCTV Studio/Rave
card=40 - STB TV PCI FM, Gateway P/N 6000704 (bt878), 3Dfx VoodooTV 100
card=41 - AVerMedia TVPhone 98
card=42 - ProVideo PV951
card=43 - Little OnAir TV
card=44 - Sigma TVII-FM
card=45 - MATRIX-Vision MV-Delta 2
card=46 - Zoltrix Genie TV/FM
card=47 - Terratec TV/Radio+
card=48 - Askey CPH03x/ Dynalink Magic TView
card=49 - IODATA GV-BCTV3/PCI
card=50 - Prolink PV-BT878P+4E / PixelView PlayTV PAK / Lenco MXTV-9578 CP
card=51 - Eagle Wireless Capricorn2 (bt878A)
card=52 - Pinnacle PCTV Studio Pro
card=53 - Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS
card=54 - Lifeview FlyVideo 2000 /FlyVideo A2/ Lifetec LT 9415 TV [LR90]
card=55 - Askey CPH031/ BESTBUY Easy TV
card=56 - Lifeview FlyVideo 98FM LR50
card=57 - GrandTec 'Grand Video Capture' (Bt848)
card=58 - Askey CPH060/ Phoebe TV Master Only (No FM)
card=59 - Askey CPH03x TV Capturer
card=60 - Modular Technology MM100PCTV
card=61 - AG Electronics GMV1
card=62 - Askey CPH061/ BESTBUY Easy TV (bt878)
card=63 - ATI TV-Wonder
card=64 - ATI TV-Wonder VE
card=65 - Lifeview FlyVideo 2000S LR90
card=66 - Terratec TValueRadio
card=67 - IODATA GV-BCTV4/PCI
card=68 - 3Dfx VoodooTV FM (Euro), VoodooTV 200 (USA)
card=69 - Active Imaging AIMMS
card=70 - Prolink Pixelview PV-BT878P+ (Rev.4C,8E)
card=71 - Lifeview FlyVideo 98EZ (capture only) LR51
card=72 - Prolink Pixelview PV-BT878P+9B (PlayTV Pro rev.9B FM+NICAM)
card=73 - Sensoray 311
card=74 - RemoteVision MX (RV605)
card=75 - Powercolor MTV878/ MTV878R/ MTV878F
card=76 - Canopus WinDVR PCI (COMPAQ Presario 3524JP, 5112JP)
card=77 - GrandTec Multi Capture Card (Bt878)
card=78 - Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF
card=79 - DSP Design TCVIDEO
card=80 - Hauppauge WinTV PVR
card=81 - IODATA GV-BCTV5/PCI
card=82 - Osprey 100/150 (878)
card=83 - Osprey 100/150 (848)
card=84 - Osprey 101 (848)
card=85 - Osprey 101/151
card=86 - Osprey 101/151 w/ svid
card=87 - Osprey 200/201/250/251
card=88 - Osprey 200/250
card=89 - Osprey 210/220
card=90 - Osprey 500
card=91 - Osprey 540
card=92 - Osprey 2000
card=93 - IDS Eagle
card=94 - Pinnacle PCTV Sat
card=95 - Formac ProTV II (bt878)
card=96 - MachTV
card=97 - Euresys Picolo
card=98 - ProVideo PV150
card=99 - AD-TVK503
card=100 - Hercules Smart TV Stereo
card=101 - Pace TV & Radio Card
card=102 - IVC-200
card=103 - Grand X-Guard / Trust 814PCI
card=104 - Nebula Electronics DigiTV
card=105 - ProVideo PV143
card=106 - PHYTEC VD-009-X1 MiniDIN (bt878)
card=107 - PHYTEC VD-009-X1 Combi (bt878)
card=108 - PHYTEC VD-009 MiniDIN (bt878)
card=109 - PHYTEC VD-009 Combi (bt878)
card=110 - IVC-100
card=111 - IVC-120G
card=112 - pcHDTV HD-2000 TV
card=113 - Twinhan DST + clones
card=114 - Winfast VC100
card=115 - Teppro TEV-560/InterVision IV-560
card=116 - SIMUS GVC1100
card=117 - NGS NGSTV+
card=118 - LMLBT4
card=119 - Tekram M205 PRO
card=120 - Conceptronic CONTVFMi

35
Documentation/video4linux/CARDLIST.saa7134 Normal file
View File

@@ -0,0 +1,35 @@
0 -> UNKNOWN/GENERIC
1 -> Proteus Pro [philips reference design] [1131:2001,1131:2001]
2 -> LifeView FlyVIDEO3000 [5168:0138,4e42:0138]
3 -> LifeView FlyVIDEO2000 [5168:0138]
4 -> EMPRESS [1131:6752]
5 -> SKNet Monster TV [1131:4e85]
6 -> Tevion MD 9717
7 -> KNC One TV-Station RDS / Typhoon TV Tuner RDS [1131:fe01,1894:fe01]
8 -> Terratec Cinergy 400 TV [153B:1142]
9 -> Medion 5044
10 -> Kworld/KuroutoShikou SAA7130-TVPCI
11 -> Terratec Cinergy 600 TV [153B:1143]
12 -> Medion 7134 [16be:0003]
13 -> Typhoon TV+Radio 90031
14 -> ELSA EX-VISION 300TV [1048:226b]
15 -> ELSA EX-VISION 500TV [1048:226b]
16 -> ASUS TV-FM 7134 [1043:4842,1043:4830,1043:4840]
17 -> AOPEN VA1000 POWER [1131:7133]
18 -> BMK MPEX No Tuner
19 -> Compro VideoMate TV [185b:c100]
20 -> Matrox CronosPlus [102B:48d0]
21 -> 10MOONS PCI TV CAPTURE CARD [1131:2001]
22 -> Medion 2819/ AverMedia M156 [1461:a70b,1461:2115]
23 -> BMK MPEX Tuner
24 -> KNC One TV-Station DVR [1894:a006]
25 -> ASUS TV-FM 7133 [1043:4843]
26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b]
27 -> Manli MuchTV M-TV002
28 -> Manli MuchTV M-TV001
29 -> Nagase Sangyo TransGear 3000TV [1461:050c]
30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4]
31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5]
32 -> AVACS SmartTV
33 -> AVerMedia DVD EZMaker [1461:10ff]
34 -> LifeView FlyTV Platinum33 mini [5168:0212]

46
Documentation/video4linux/CARDLIST.tuner Normal file
View File

@@ -0,0 +1,46 @@
tuner=0 - Temic PAL (4002 FH5)
tuner=1 - Philips PAL_I (FI1246 and compatibles)
tuner=2 - Philips NTSC (FI1236,FM1236 and compatibles)
tuner=3 - Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF)
tuner=4 - NoTuner
tuner=5 - Philips PAL_BG (FI1216 and compatibles)
tuner=6 - Temic NTSC (4032 FY5)
tuner=7 - Temic PAL_I (4062 FY5)
tuner=8 - Temic NTSC (4036 FY5)
tuner=9 - Alps HSBH1
tuner=10 - Alps TSBE1
tuner=11 - Alps TSBB5
tuner=12 - Alps TSBE5
tuner=13 - Alps TSBC5
tuner=14 - Temic PAL_BG (4006FH5)
tuner=15 - Alps TSCH6
tuner=16 - Temic PAL_DK (4016 FY5)
tuner=17 - Philips NTSC_M (MK2)
tuner=18 - Temic PAL_I (4066 FY5)
tuner=19 - Temic PAL* auto (4006 FN5)
tuner=20 - Temic PAL_BG (4009 FR5) or PAL_I (4069 FR5)
tuner=21 - Temic NTSC (4039 FR5)
tuner=22 - Temic PAL/SECAM multi (4046 FM5)
tuner=23 - Philips PAL_DK (FI1256 and compatibles)
tuner=24 - Philips PAL/SECAM multi (FQ1216ME)
tuner=25 - LG PAL_I+FM (TAPC-I001D)
tuner=26 - LG PAL_I (TAPC-I701D)
tuner=27 - LG NTSC+FM (TPI8NSR01F)
tuner=28 - LG PAL_BG+FM (TPI8PSB01D)
tuner=29 - LG PAL_BG (TPI8PSB11D)
tuner=30 - Temic PAL* auto + FM (4009 FN5)
tuner=31 - SHARP NTSC_JP (2U5JF5540)
tuner=32 - Samsung PAL TCPM9091PD27
tuner=33 - MT20xx universal
tuner=34 - Temic PAL_BG (4106 FH5)
tuner=35 - Temic PAL_DK/SECAM_L (4012 FY5)
tuner=36 - Temic NTSC (4136 FY5)
tuner=37 - LG PAL (newer TAPC series)
tuner=38 - Philips PAL/SECAM multi (FM1216ME MK3)
tuner=39 - LG NTSC (newer TAPC series)
tuner=40 - HITACHI V7-J180AT
tuner=41 - Philips PAL_MK (FI1216 MK)
tuner=42 - Philips 1236D ATSC/NTSC daul in
tuner=43 - Philips NTSC MK3 (FM1236MK3 or FM1236/F)
tuner=44 - Philips 4 in 1 (ATI TV Wonder Pro/Conexant)
tuner=45 - Microtune 4049 FM5

412
Documentation/video4linux/CQcam.txt Normal file
View File

@@ -0,0 +1,412 @@
c-qcam - Connectix Color QuickCam video4linux kernel driver
Copyright (C) 1999 Dave Forrest <drf5n@virginia.edu>
released under GNU GPL.
1999-12-08 Dave Forrest, written with kernel version 2.2.12 in mind
Table of Contents
1.0 Introduction
2.0 Compilation, Installation, and Configuration
3.0 Troubleshooting
4.0 Future Work / current work arounds
9.0 Sample Program, v4lgrab
10.0 Other Information
1.0 Introduction
The file ../drivers/char/c-qcam.c is a device driver for the
Logitech (nee Connectix) parallel port interface color CCD camera.
This is a fairly inexpensive device for capturing images. Logitech
does not currently provide information for developers, but many people
have engineered several solutions for non-Microsoft use of the Color
Quickcam.
1.1 Motivation
I spent a number of hours trying to get my camera to work, and I
hope this document saves you some time. My camera will not work with
the 2.2.13 kernel as distributed, but with a few patches to the
module, I was able to grab some frames. See 4.0, Future Work.
2.0 Compilation, Installation, and Configuration
The c-qcam depends on parallel port support, video4linux, and the
Color Quickcam. It is also nice to have the parallel port readback
support enabled. I enabled these as modules during the kernel
configuration. The appropriate flags are:
CONFIG_PRINTER M for lp.o, parport.o parport_pc.o modules
CONFIG_PNP_PARPORT M for autoprobe.o IEEE1284 readback module
CONFIG_PRINTER_READBACK M for parport_probe.o IEEE1284 readback module
CONFIG_VIDEO_DEV M for videodev.o video4linux module
CONFIG_VIDEO_CQCAM M for c-qcam.o Color Quickcam module
With these flags, the kernel should compile and install the modules.
To record and monitor the compilation, I use:
(make zlilo ; \
make modules; \
make modules_install ;
depmod -a ) &>log &
less log # then a capital 'F' to watch the progress
But that is my personal preference.
2.2 Configuration
The configuration requires module configuration and device
configuration. I like kmod or kerneld process with the
/etc/modprobe.conf file so the modules can automatically load/unload as
they are used. The video devices could already exist, be generated
using MAKEDEV, or need to be created. The following sections detail
these procedures.
2.1 Module Configuration
Using modules requires a bit of work to install and pass the
parameters. Understand that entries in /etc/modprobe.conf of:
alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=none
alias char-major-81 videodev
alias char-major-81-0 c-qcam
will cause the kmod/modprobe to do certain things. If you are
using kmod, then a request for a 'char-major-81-0' will cause
the 'c-qcam' module to load. If you have other video sources with
modules, you might want to assign the different minor numbers to
different modules.
2.2 Device Configuration
At this point, we need to ensure that the device files exist.
Video4linux used the /dev/video* files, and we want to attach the
Quickcam to one of these.
ls -lad /dev/video* # should produce a list of the video devices
If the video devices do not exist, you can create them with:
su
cd /dev
for ii in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do
mknod video$ii c 81 $ii # char-major-81-[0-16]
chown root.root video$ii # owned by root
chmod 600 video$ii # read/writable by root only
done
Lots of people connect video0 to video and bttv, but you might want
your c-qcam to mean something more:
ln -s video0 c-qcam # make /dev/c-qcam a working file
ln -s c-qcam video # make /dev/c-qcam your default video source
But these are conveniences. The important part is to make the proper
special character files with the right major and minor numbers. All
of the special device files are listed in ../devices.txt. If you
would like the c-qcam readable by non-root users, you will need to
change the permissions.
3.0 Troubleshooting
If the sample program below, v4lgrab, gives you output then
everything is working.
v4lgrab | wc # should give you a count of characters
Otherwise, you have some problem.
The c-qcam is IEEE1284 compatible, so if you are using the proc file
system (CONFIG_PROC_FS), the parallel printer support
(CONFIG_PRINTER), the IEEE 1284 system,(CONFIG_PRINTER_READBACK), you
should be able to read some identification from your quickcam with
modprobe -v parport
modprobe -v parport_probe
cat /proc/parport/PORTNUMBER/autoprobe
Returns:
CLASS:MEDIA;
MODEL:Color QuickCam 2.0;
MANUFACTURER:Connectix;
A good response to this indicates that your color quickcam is alive
and well. A common problem is that the current driver does not
reliably detect a c-qcam, even though one is attached. In this case,
modprobe -v c-qcam
or
insmod -v c-qcam
Returns a message saying "Device or resource busy" Development is
currently underway, but a workaround is to patch the module to skip
the detection code and attach to a defined port. Check the
video4linux mailing list and archive for more current information.
3.1 Checklist:
Can you get an image?
v4lgrab >qcam.ppm ; wc qcam.ppm ; xv qcam.ppm
Is a working c-qcam connected to the port?
grep ^ /proc/parport/?/autoprobe
Do the /dev/video* files exist?
ls -lad /dev/video
Is the c-qcam module loaded?
modprobe -v c-qcam ; lsmod
Does the camera work with alternate programs? cqcam, etc?
4.0 Future Work / current workarounds
It is hoped that this section will soon become obsolete, but if it
isn't, you might try patching the c-qcam module to add a parport=xxx
option as in the bw-qcam module so you can specify the parallel port:
insmod -v c-qcam parport=0
And bypass the detection code, see ../../drivers/char/c-qcam.c and
look for the 'qc_detect' code and call.
Note that there is work in progress to change the video4linux API,
this work is documented at the video4linux2 site listed below.
9.0 --- A sample program using v4lgrabber,
This program is a simple image grabber that will copy a frame from the
first video device, /dev/video0 to standard output in portable pixmap
format (.ppm) Using this like: 'v4lgrab | convert - c-qcam.jpg'
produced this picture of me at
http://mug.sys.virginia.edu/~drf5n/extras/c-qcam.jpg
-------------------- 8< ---------------- 8< -----------------------------
/* Simple Video4Linux image grabber. */
/*
* Video4Linux Driver Test/Example Framegrabbing Program
*
* Compile with:
* gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab
* Use as:
* v4lgrab >image.ppm
*
* Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org>
* Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
* with minor modifications (Dave Forrest, drf5n@virginia.edu).
*
*/
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <stdlib.h>
#include <linux/types.h>
#include <linux/videodev.h>
#define FILE "/dev/video0"
/* Stole this from tvset.c */
#define READ_VIDEO_PIXEL(buf, format, depth, r, g, b) \
{ \
switch (format) \
{ \
case VIDEO_PALETTE_GREY: \
switch (depth) \
{ \
case 4: \
case 6: \
case 8: \
(r) = (g) = (b) = (*buf++ << 8);\
break; \
\
case 16: \
(r) = (g) = (b) = \
*((unsigned short *) buf); \
buf += 2; \
break; \
} \
break; \
\
\
case VIDEO_PALETTE_RGB565: \
{ \
unsigned short tmp = *(unsigned short *)buf; \
(r) = tmp&0xF800; \
(g) = (tmp<<5)&0xFC00; \
(b) = (tmp<<11)&0xF800; \
buf += 2; \
} \
break; \
\
case VIDEO_PALETTE_RGB555: \
(r) = (buf[0]&0xF8)<<8; \
(g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8; \
(b) = ((buf[1] << 2 ) & 0xF8)<<8; \
buf += 2; \
break; \
\
case VIDEO_PALETTE_RGB24: \
(r) = buf[0] << 8; (g) = buf[1] << 8; \
(b) = buf[2] << 8; \
buf += 3; \
break; \
\
default: \
fprintf(stderr, \
"Format %d not yet supported\n", \
format); \
} \
}
int get_brightness_adj(unsigned char *image, long size, int *brightness) {
long i, tot = 0;
for (i=0;i<size*3;i++)
tot += image[i];
*brightness = (128 - tot/(size*3))/3;
return !((tot/(size*3)) >= 126 && (tot/(size*3)) <= 130);
}
int main(int argc, char ** argv)
{
int fd = open(FILE, O_RDONLY), f;
struct video_capability cap;
struct video_window win;
struct video_picture vpic;
unsigned char *buffer, *src;
int bpp = 24, r, g, b;
unsigned int i, src_depth;
if (fd < 0) {
perror(FILE);
exit(1);
}
if (ioctl(fd, VIDIOCGCAP, &cap) < 0) {
perror("VIDIOGCAP");
fprintf(stderr, "(" FILE " not a video4linux device?)\n");
close(fd);
exit(1);
}
if (ioctl(fd, VIDIOCGWIN, &win) < 0) {
perror("VIDIOCGWIN");
close(fd);
exit(1);
}
if (ioctl(fd, VIDIOCGPICT, &vpic) < 0) {
perror("VIDIOCGPICT");
close(fd);
exit(1);
}
if (cap.type & VID_TYPE_MONOCHROME) {
vpic.depth=8;
vpic.palette=VIDEO_PALETTE_GREY; /* 8bit grey */
if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
vpic.depth=6;
if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
vpic.depth=4;
if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
fprintf(stderr, "Unable to find a supported capture format.\n");
close(fd);
exit(1);
}
}
}
} else {
vpic.depth=24;
vpic.palette=VIDEO_PALETTE_RGB24;
if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
vpic.palette=VIDEO_PALETTE_RGB565;
vpic.depth=16;
if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) {
vpic.palette=VIDEO_PALETTE_RGB555;
vpic.depth=15;
if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) {
fprintf(stderr, "Unable to find a supported capture format.\n");
return -1;
}
}
}
}
buffer = malloc(win.width * win.height * bpp);
if (!buffer) {
fprintf(stderr, "Out of memory.\n");
exit(1);
}
do {
int newbright;
read(fd, buffer, win.width * win.height * bpp);
f = get_brightness_adj(buffer, win.width * win.height, &newbright);
if (f) {
vpic.brightness += (newbright << 8);
if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) {
perror("VIDIOSPICT");
break;
}
}
} while (f);
fprintf(stdout, "P6\n%d %d 255\n", win.width, win.height);
src = buffer;
for (i = 0; i < win.width * win.height; i++) {
READ_VIDEO_PIXEL(src, vpic.palette, src_depth, r, g, b);
fputc(r>>8, stdout);
fputc(g>>8, stdout);
fputc(b>>8, stdout);
}
close(fd);
return 0;
}
-------------------- 8< ---------------- 8< -----------------------------
10.0 --- Other Information
Use the ../../Maintainers file, particularly the VIDEO FOR LINUX and PARALLEL
PORT SUPPORT sections
The video4linux page:
http://roadrunner.swansea.linux.org.uk/v4l.shtml
The video4linux2 page:
http://millennium.diads.com/bdirks/v4l2.htm
Some web pages about the quickcams:
http://www.dkfz-heidelberg.de/Macromol/wedemann/mini-HOWTO-cqcam.html
http://www.crynwr.com/qcpc/ QuickCam Third-Party Drivers
http://www.crynwr.com/qcpc/re.html Some Reverse Engineering
http://cse.unl.edu/~cluening/gqcam/ v4l client
http://phobos.illtel.denver.co.us/pub/qcread/ doesn't use v4l
ftp://ftp.cs.unm.edu/pub/chris/quickcam/ Has lots of drivers
http://www.cs.duke.edu/~reynolds/quickcam/ Has lots of information

191
Documentation/video4linux/README.cpia Normal file
View File

@@ -0,0 +1,191 @@
This is a driver for the CPiA PPC2 driven parallel connected
Camera. For example the Creative WebcamII is CPiA driven.
) [1]Peter Pregler, Linz 2000, published under the [2]GNU GPL
---------------------------------------------------------------------------
USAGE:
General:
========
1) Make sure you have created the video devices (/dev/video*):
- if you have a recent MAKEDEV do a 'cd /dev;./MAKEDEV video'
- otherwise do a:
cd /dev
mknod video0 c 81 0
ln -s video0 video
2) Compile the kernel (see below for the list of options to use),
configure your parport and reboot.
3) If all worked well you should get messages similar
to the following (your versions may be different) on the console:
V4L-Driver for Vision CPiA based cameras v0.7.4
parport0: read2 timeout.
parport0: Multimedia device, VLSI Vision Ltd PPC2
Parallel port driver for Vision CPiA based camera
CPIA Version: 1.20 (2.0)
CPIA PnP-ID: 0553:0002:0100
VP-Version: 1.0 0100
1 camera(s) found
As modules:
===========
Make sure you have selected the following kernel options (you can
select all stuff as modules):
The cpia-stuff is in the section 'Character devices -> Video For Linux'.
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
For autoloading of all those modules you need to tell module-init-tools
some stuff. Add the following line to your module-init-tools config-file
(e.g. /etc/modprobe.conf or wherever your distribution does store that
stuff):
options parport_pc io=0x378 irq=7 dma=3
alias char-major-81 cpia_pp
The first line tells the dma/irq channels to use. Those _must_ match
the settings of your BIOS. Do NOT simply use the values above. See
Documentation/parport.txt for more information about this. The second
line associates the video-device file with the driver. Of cause you
can also load the modules once upon boot (usually done in /etc/modules).
Linked into the kernel:
=======================
Make sure you have selected the following kernel options. Note that
you cannot compile the parport-stuff as modules and the cpia-driver
statically (the other way round is okay though).
The cpia-stuff is in the section 'Character devices -> Video For Linux'.
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_CPIA=y
CONFIG_VIDEO_CPIA_PP=y
To use DMA/irq you will need to tell the kernel upon boot time the
hardware configuration of the parport. You can give the boot-parameter
at the LILO-prompt or specify it in lilo.conf. I use the following
append-line in lilo.conf:
append="parport=0x378,7,3"
See Documentation/parport.txt for more information about the
configuration of the parport and the values given above. Do not simply
use the values given above.
---------------------------------------------------------------------------
FEATURES:
- mmap/read v4l-interface (but no overlay)
- image formats: CIF/QCIF, SIF/QSIF, various others used by isabel;
note: all sizes except CIF/QCIF are implemented by clipping, i.e.
pixels are not uploaded from the camera
- palettes: VIDEO_PALETTE_GRAY, VIDEO_PALETTE_RGB565, VIDEO_PALETTE_RGB555,
VIDEO_PALETTE_RGB24, VIDEO_PALETTE_RGB32, VIDEO_PALETTE_YUYV,
VIDEO_PALETTE_UYVY, VIDEO_PALETTE_YUV422
- state information (color balance, exposure, ...) is preserved between
device opens
- complete control over camera via proc-interface (_all_ camera settings are
supported), there is also a python-gtk application available for this [3]
- works under SMP (but the driver is completely serialized and synchronous)
so you get no benefit from SMP, but at least it does not crash your box
- might work for non-Intel architecture, let us know about this
---------------------------------------------------------------------------
TESTED APPLICATIONS:
- a simple test application based on Xt is available at [3]
- another test-application based on gqcam-0.4 (uses GTK)
- gqcam-0.6 should work
- xawtv-3.x (also the webcam software)
- xawtv-2.46
- w3cam (cgi-interface and vidcat, e.g. you may try out 'vidcat |xv
-maxpect -root -quit +noresetroot -rmode 5 -')
- vic, the MBONE video conferencing tool (version 2.8ucl4-1)
- isabel 3R4beta (barely working, but AFAICT all the problems are on
their side)
- camserv-0.40
See [3] for pointers to v4l-applications.
---------------------------------------------------------------------------
KNOWN PROBLEMS:
- some applications do not handle the image format correctly, you will
see strange horizontal stripes instead of a nice picture -> make sure
your application does use a supported image size or queries the driver
for the actually used size (reason behind this: the camera cannot
provide any image format, so if size NxM is requested the driver will
use a format to the closest fitting N1xM1, the application should now
query for this granted size, most applications do not).
- all the todo ;)
- if there is not enough light and the picture is too dark try to
adjust the SetSensorFPS setting, automatic frame rate adjustment
has its price
- do not try out isabel 3R4beta (built 135), you will be disappointed
---------------------------------------------------------------------------
TODO:
- multiple camera support (struct camera or something) - This should work,
but hasn't been tested yet.
- architecture independence?
- SMP-safe asynchronous mmap interface
- nibble mode for old parport interfaces
- streaming capture, this should give a performance gain
---------------------------------------------------------------------------
IMPLEMENTATION NOTES:
The camera can act in two modes, streaming or grabbing. Right now a
polling grab-scheme is used. Maybe interrupt driven streaming will be
used for a asynchronous mmap interface in the next major release of the
driver. This might give a better frame rate.
---------------------------------------------------------------------------
THANKS (in no particular order):
- Scott J. Bertin <sbertin@mindspring.com> for cleanups, the proc-filesystem
and much more
- Henry Bruce <whb@vvl.co.uk> for providing developers information about
the CPiA chip, I wish all companies would treat Linux as seriously
- Karoly Erdei <Karoly.Erdei@risc.uni-linz.ac.at> and RISC-Linz for being
my boss ;) resp. my employer and for providing me the hardware and
allow me to devote some working time to this project
- Manuel J. Petit de Gabriel <mpetit@dit.upm.es> for providing help
with Isabel (http://isabel.dit.upm.es/)
- Bas Huisman <bhuism@cs.utwente.nl> for writing the initial parport code
- Jarl Totland <Jarl.Totland@bdc.no> for setting up the mailing list
and maintaining the web-server[3]
- Chris Whiteford <Chris@informinteractive.com> for fixes related to the
1.02 firmware
- special kudos to all the tester whose machines crashed and/or
will crash. :)
---------------------------------------------------------------------------
REFERENCES
1. http://www.risc.uni-linz.ac.at/people/ppregler
mailto:Peter_Pregler@email.com
2. see the file COPYING in the top directory of the kernel tree
3. http://webcam.sourceforge.net/

69
Documentation/video4linux/README.cx88 Normal file
View File

@@ -0,0 +1,69 @@
cx8800 release notes
====================
This is a v4l2 device driver for the cx2388x chip.
current status
==============
video
- Basically works.
- Some minor image quality glitches.
- For now only capture, overlay support isn't completed yet.
audio
- The chip specs for the on-chip TV sound decoder are next
to useless :-/
- Neverless the builtin TV sound decoder starts working now,
at least for PAL-BG. Other TV norms need other code ...
FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
USING.
- Most tuner chips do provide mono sound, which may or may not
be useable depending on the board design. With the Hauppauge
cards it works, so there is mono sound available as fallback.
- audio data dma (i.e. recording without loopback cable to the
sound card) should be possible, but there is no code yet ...
vbi
- some code present. Doesn't crash any more, but also doesn't
work yet ...
how to add support for new cards
================================
The driver needs some config info for the TV cards. This stuff is in
cx88-cards.c. If the driver doesn't work well you likely need a new
entry for your card in that file. Check the kernel log (using dmesg)
to see whenever the driver knows your card or not. There is a line
like this one:
cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \
34xxx models [card=1,autodetected]
If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to
the driver. What to do then?
(1) Try upgrading to the latest snapshot, maybe it has been added
meanwhile.
(2) You can try to create a new entry yourself, have a look at
cx88-cards.c. If that worked, mail me your changes as unified
diff ("diff -u").
(3) Or you can mail me the config information. I need at least the
following informations to add the card:
* the PCI Subsystem ID ("0070:3400" from the line above,
"lspci -v" output is fine too).
* the tuner type used by the card. You can try to find one by
trial-and-error using the tuner=<n> insmod option. If you
know which one the card has you can also have a look at the
list in CARDLIST.tuner
Have fun,
Gerd
--
Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]

72
Documentation/video4linux/README.ir Normal file
View File

@@ -0,0 +1,72 @@
infrared remote control support in video4linux drivers
======================================================
basics
------
Current versions use the linux input layer to support infrared
remote controls. I suggest to download my input layer tools
from http://bytesex.org/snapshot/input-<date>.tar.gz
Modules you have to load:
saa7134 statically built in, i.e. just the driver :)
bttv ir-kbd-gpio or ir-kbd-i2c depending on your
card.
ir-kbd-gpio and ir-kbd-i2c don't support all cards lirc supports
(yet), mainly for the reason that the code of lirc_i2c and lirc_gpio
was very confusing and I decided to basically start over from scratch.
Feel free to contact me in case of trouble. Note that the ir-kbd-*
modules work on 2.6.x kernels only through ...
how it works
------------
The modules register the remote as keyboard within the linux input
layer, i.e. you'll see the keys of the remote as normal key strokes
(if CONFIG_INPUT_KEYBOARD is enabled).
Using the event devices (CONFIG_INPUT_EVDEV) it is possible for
applications to access the remote via /dev/input/event<n> devices.
You might have to create the special files using "/sbin/MAKEDEV
input". The input layer tools mentioned above use the event device.
The input layer tools are nice for trouble shooting, i.e. to check
whenever the input device is really present, which of the devices it
is, check whenever pressing keys on the remote actually generates
events and the like. You can also use the kbd utility to change the
keymaps (2.6.x kernels only through).
using with lircd
================
The cvs version of the lircd daemon supports reading events from the
linux input layer (via event device). The input layer tools tarball
comes with a lircd config file.
using without lircd
===================
XFree86 likely can be configured to recognise the remote keys. Once I
simply tried to configure one of the multimedia keyboards as input
device, which had the effect that XFree86 recognised some of the keys
of my remote control and passed volume up/down key presses as
XF86AudioRaiseVolume and XF86AudioLowerVolume key events to the X11
clients.
It likely is possible to make that fly with a nice xkb config file,
I know next to nothing about that through.
Have fun,
Gerd
--
Gerd Knorr <kraxel@bytesex.org>

73
Documentation/video4linux/README.saa7134 Normal file
View File

@@ -0,0 +1,73 @@
What is it?
===========
This is a v4l2/oss device driver for saa7130/33/34/35 based capture / TV
boards. See http://www.semiconductors.philips.com/pip/saa7134hl for a
description.
Status
======
Almost everything is working. video, sound, tuner, radio, mpeg ts, ...
As with bttv, card-specific tweaks are needed. Check CARDLIST for a
list of known TV cards and saa7134-cards.c for the drivers card
configuration info.
Build
=====
Pick up videodev + v4l2 patches from http://bytesex.org/patches/.
Configure, build, install + boot the new kernel. You'll need at least
these config options:
CONFIG_I2C=m
CONFIG_VIDEO_DEV=m
Type "make" to build the driver now. "make install" installs the
driver. "modprobe saa7134" should load it. Depending on the card you
might have to pass card=<nr> as insmod option, check CARDLIST for
valid choices.
Changes / Fixes
===============
Please mail me unified diffs ("diff -u") with your changes, and don't
forget to tell me what it changes / which problem it fixes / whatever
it is good for ...
Known Problems
==============
* The tuner for the flyvideos isn't detected automatically and the
default might not work for you depending on which version you have.
There is a tuner= insmod option to override the driver's default.
Card Variations:
================
Cards can use either of these two crystals (xtal):
- 32.11 MHz -> .audio_clock=0x187de7
- 24.576MHz -> .audio_clock=0x200000
(xtal * .audio_clock = 51539600)
Credits
=======
andrew.stevens@philips.com + werner.leeb@philips.com for providing
saa7134 hardware specs and sample board.
Have fun,
Gerd
--
Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]

557
Documentation/video4linux/Zoran Normal file
View File

@@ -0,0 +1,557 @@
Frequently Asked Questions:
===========================
subject: unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)
website: http://mjpeg.sourceforge.net/driver-zoran/
1. What cards are supported
1.1 What the TV decoder can do an what not
1.2 What the TV encoder can do an what not
2. How do I get this damn thing to work
3. What mainboard should I use (or why doesn't my card work)
4. Programming interface
5. Applications
6. Concerning buffer sizes, quality, output size etc.
7. It hangs/crashes/fails/whatevers! Help!
8. Maintainers/Contacting
9. License
===========================
1. What cards are supported
Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
DC10/DC10+/DC30/DC30+ and related boards (available under various names).
Iomega Buz:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7111 TV decoder
* Philips saa7185 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7111, saa7185, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 7
Linux Media Labs LML33:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Brooktree bt819 TV decoder
* Brooktree bt856 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, bt819, bt856, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 5
Linux Media Labs LML33R10:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7114 TV decoder
* Analog Devices adv7170 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7114, adv7170, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 6
Pinnacle/Miro DC10(new):
* Zoran zr36057 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7110, adv7175, zr36060, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 1
Pinnacle/Miro DC10+:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, sa7110, adv7175, zr36060, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 2
Pinnacle/Miro DC10(old): *
* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
* Micronas vpx3220a TV decoder
* mse3000 TV encoder or Analog Devices adv7176 TV encoder *
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 0
Pinnacle/Miro DC30: *
* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 3
Pinnacle/Miro DC30+: *
* Zoran zr36067 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 4
Note: No module for the mse3000 is available yet
Note: No module for the vpx3224 is available yet
Note: use encoder=X or decoder=X for non-default i2c chips (see i2c-id.h)
===========================
1.1 What the TV decoder can do an what not
The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
information is not enough. There are several formats of the TV standards.
And not every TV decoder is able to handle every format. Also the every
combination is supported by the driver. There are currently 11 different
tv broadcast formats all aver the world.
The CCIR defines parameters needed for broadcasting the signal.
The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
The CCIR says not much about about the colorsystem used !!!
And talking about a colorsystem says not to much about how it is broadcast.
The CCIR standards A,E,F are not used any more.
When you speak about NTSC, you usually mean the standard: CCIR - M using
the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
and a few others.
When you talk about PAL, you usually mean: CCIR - B/G using the PAL
colorsystem which is used in many Countries.
When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
which is used in France, and a few others.
There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.
The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
Ireland, Nigeria, South Africa.
The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
and is used in Argentinia, Uruguay, an a few others
We do not talk about how the audio is broadcast !
A rather good sites about the TV standards are:
http://www.sony.jp/ServiceArea/Voltage_map/
http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
and http://www.cabl.com/restaurant/channel.html
Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
be the same as NTSC 4.43.
NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
to split coma and luma instead of a Delay line.
But I did not defiantly find out what NTSC Comb is.
Philips saa7111 TV decoder
was introduced in 1997, is used in the BUZ and
can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM
Philips saa7110a TV decoder
was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
can handle: PAL B/G, NTSC M and SECAM
Philips saa7114 TV decoder
was introduced in 2000, is used in the LML33R10 and
can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
Brooktree bt819 TV decoder
was introduced in 1996, and is used in the LML33 and
can handle: PAL B/D/G/H/I, NTSC M
Micronas vpx3220a TV decoder
was introduced in 1996, is used in the DC30 and DC30+ and
can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb
===========================
1.2 What the TV encoder can do an what not
The TV encoder are doing the "same" as the decoder, but in the oder direction.
You feed them digital data and the generate a Composite or SVHS signal.
For information about the colorsystems and TV norm take a look in the
TV decoder section.
Philips saa7185 TV Encoder
was introduced in 1996, is used in the BUZ
can generate: PAL B/G, NTSC M
Brooktree bt856 TV Encoder
was introduced in 1994, is used in the LML33
can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
Analog Devices adv7170 TV Encoder
was introduced in 2000, is used in the LML300R10
can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60
Analog Devices adv7175 TV Encoder
was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
can generate: PAL B/D/G/H/I/N, PAL M, NTSC M
ITT mse3000 TV encoder
was introduced in 1991, is used in the DC10 old
can generate: PAL , NTSC , SECAM
The adv717x, should be able to produce PAL N. But you find nothing PAL N
specific in the the registers. Seem that you have to reuse a other standard
to generate PAL N, maybe it would work if you use the PAL M settings.
==========================
2. How do I get this damn thing to work
Load zr36067.o. If it can't autodetect your card, use the card=X insmod
option with X being the card number as given in the previous section.
To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
To automate this, add the following to your /etc/modprobe.conf:
options zr36067 card=X1[,X2[,X3[,X4[..]]]]
alias char-major-81-0 zr36067
One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
just automates loading. If you start using xawtv, the device won't load on
some systems, since you're trying to load modules as a user, which is not
allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
one of your startup scripts (normally rc.local) if you don't use X. Both
make sure that the modules are loaded on startup, under the root account.
===========================
3. What mainboard should I use (or why doesn't my card work)
<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.
Experience tells us that people with a Buz, on average, have more problems
than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
based on a different chipset. Here's some notes from Andrew Stevens:
--
Here's my experience of using LML33 and Buz on various motherboards:
VIA MVP3
Forget it. Pointless. Doesn't work.
Intel 430FX (Pentium 200)
LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
Intel 440BX (early stepping)
LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
Intel 440BX (late stepping)
Buz tolerable, LML3 almost perfect (occasional single frame drops)
SiS735
LML33 perfect, Buz tolerable.
VIA KT133(*)
LML33 starting to get annoying, Buz poor enough that I have up.
Both 440BX boards were dual CPU versions.
--
Bernhard Praschinger later added:
--
AMD 751
Buz perfect-tolerable
AMD 760
Buz perfect-tolerable
--
In general, people on the user mailinglist won't give you much of a chance
if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
rather want to spend some more money on better boards. In general, VIA
mainboard's IDE/PCI performance will also suck badly compared to others.
You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
Basically, you can assume that if the Buz works, the LML33 will work too. If
the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
different mainboard chipsets from all of the supported cards.
If you experience timeouts during capture, buy a better mainboard or lower
the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
output size etc.'). If it hangs, there's little we can do as of now. Check
your IRQs and make sure the card has its own interrupts.
===========================
4. Programming interface
This driver conforms to video4linux and video4linux2, both can be used to
use the driver. Since video4linux didn't provide adequate calls to fully
use the cards' features, we've introduced several programming extensions,
which are currently officially accepted in the 2.4.x branch of the kernel.
These extensions are known as the v4l/mjpeg extensions. See zoran.h for
details (structs/ioctls).
Information - video4linux:
http://roadrunner.swansea.linux.org.uk/v4lapi.shtml
Documentation/video4linux/API.html
/usr/include/linux/videodev.h
Information - video4linux/mjpeg extensions:
./zoran.h
(also see below)
Information - video4linux2:
http://www.thedirks.org/v4l2/
/usr/include/linux/videodev2.h
http://www.bytesex.org/v4l/
More information on the video4linux/mjpeg extensions, by Serguei
Miridonovi and Rainer Johanni:
--
The ioctls for that interface are as follows:
BUZIOC_G_PARAMS
BUZIOC_S_PARAMS
Get and set the parameters of the buz. The user should always do a
BUZIOC_G_PARAMS (with a struct buz_params) to obtain the default
settings, change what he likes and then make a BUZIOC_S_PARAMS call.
BUZIOC_REQBUFS
Before being able to capture/playback, the user has to request
the buffers he is wanting to use. Fill the structure
zoran_requestbuffers with the size (recommended: 256*1024) and
the number (recommended 32 up to 256). There are no such restrictions
as for the Video for Linux buffers, you should LEAVE SUFFICIENT
MEMORY for your system however, else strange things will happen ....
On return, the zoran_requestbuffers structure contains number and
size of the actually allocated buffers.
You should use these numbers for doing a mmap of the buffers
into the user space.
The BUZIOC_REQBUFS ioctl also makes it happen, that the next mmap
maps the MJPEG buffer instead of the V4L buffers.
BUZIOC_QBUF_CAPT
BUZIOC_QBUF_PLAY
Queue a buffer for capture or playback. The first call also starts
streaming capture. When streaming capture is going on, you may
only queue further buffers or issue syncs until streaming
capture is switched off again with a argument of -1 to
a BUZIOC_QBUF_CAPT/BUZIOC_QBUF_PLAY ioctl.
BUZIOC_SYNC
Issue this ioctl when all buffers are queued. This ioctl will
block until the first buffer becomes free for saving its
data to disk (after BUZIOC_QBUF_CAPT) or for reuse (after BUZIOC_QBUF_PLAY).
BUZIOC_G_STATUS
Get the status of the input lines (video source connected/norm).
For programming example, please, look at lavrec.c and lavplay.c code in
lavtools-1.2p2 package (URL: http://www.cicese.mx/~mirsev/DC10plus/)
and the 'examples' directory in the original Buz driver distribution.
Additional notes for software developers:
The driver returns maxwidth and maxheight parameters according to
the current TV standard (norm). Therefore, the software which
communicates with the driver and "asks" for these parameters should
first set the correct norm. Well, it seems logically correct: TV
standard is "more constant" for current country than geometry
settings of a variety of TV capture cards which may work in ITU or
square pixel format. Remember that users now can lock the norm to
avoid any ambiguity.
--
Please note that lavplay/lavrec are also included in the MJPEG-tools
(http://mjpeg.sf.net/).
===========================
5. Applications
Applications known to work with this driver:
TV viewing:
* xawtv
* kwintv
* probably any TV application that supports video4linux or video4linux2.
MJPEG capture/playback:
* mjpegtools/lavtools (or Linux Video Studio)
* gstreamer
* mplayer
General raw capture:
* xawtv
* gstreamer
* probably any application that supports video4linux or video4linux2
Video editing:
* Cinelerra
* MainActor
* mjpegtools (or Linux Video Studio)
===========================
6. Concerning buffer sizes, quality, output size etc.
The zr36060 can do 1:2 JPEG compression. This is really the theoretical
maximum that the chipset can reach. The driver can, however, limit compression
to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
can't handle 1:2 compression without stopping capture after only a few minutes.
With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
1:4 max. compression mode.
100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
(quantization) tables, and you'll get to something like 512kB per frame for
1:2 compression. For 1:4 compression, you'd have frames of half this size.
Some additional explanation by Martin Samuelsson, which also explains the
importance of buffer sizes:
--
> Hmm, I do not think it is really that way. With the current (downloaded
> at 18:00 Monday) driver I get that output sizes for 10 sec:
> -q 50 -b 128 : 24.283.332 Bytes
> -q 50 -b 256 : 48.442.368
> -q 25 -b 128 : 24.655.992
> -q 25 -b 256 : 25.859.820
I woke up, and can't go to sleep again. I'll kill some time explaining why
this doesn't look strange to me.
Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
actually use that number or not, but that's not too important right now.
704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
output becomes 512 bits per block. Actually 510, but 512 is simpler to use
for calculations.
Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
here, so we don't need to do any fancy corrections for bits-per-pixel or such
things. 101376 bytes per field.
d1 video contains two fields per frame. Those sum up to 202752 bytes per
frame, and one of those frames goes into each buffer.
But wait a second! -b128 gives 128kB buffers! It's not possible to cram
202752 bytes of JPEG data into 128kB!
This is what the driver notice and automatically compensate for in your
examples. Let's do some math using this information:
128kB is 131072 bytes. In this buffer, we want to store two fields, which
leaves 65536 bytes for each field. Using 3168 blocks per field, we get
20.68686868... available bytes per block; 165 bits. We can't allow the
request for 256 bits per block when there's only 165 bits available! The -q50
option is silently overridden, and the -b128 option takes precedence, leaving
us with the equivalence of -q32.
This gives us a data rate of 165 bits per block, which, times 3168, sums up
to 65340 bytes per field, out of the allowed 65536. The current driver has
another level of rate limiting; it won't accept -q values that fill more than
6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
a safe bet. Personally, I think I would have lowered requested-bits-per-block
by one, or something like that.) We can't use 165 bits per block, but have to
lower it again, to 6/8 of the available buffer space: We end up with 124 bits
per block, the equivalence of -q24. With 128kB buffers, you can't use greater
than -q24 at -d1. (And PAL, and 704 pixels width...)
The third example is limited to -q24 through the same process. The second
example, using very similar calculations, is limited to -q48. The only
example that actually grab at the specified -q value is the last one, which
is clearly visible, looking at the file size.
--
Conclusion: the quality of the resulting movie depends on buffer size, quality,
whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
module to do 1:4 instead of 1:2 compression, etc.
If you experience timeouts, lowering the quality/buffersize or using
'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
proven by the Buz.
===========================
7. It hangs/crashes/fails/whatevers! Help!
Make sure that the card has its own interrupts (see /proc/interrupts), check
the output of dmesg at high verbosity (load zr36067.o with debug=2,
load all other modules with debug=1). Check that your mainboard is favorable
(see question 2) and if not, test the card in another computer. Also see the
notes given in question 3 and try lowering quality/buffersize/capturesize
if recording fails after a period of time.
If all this doesn't help, give a clear description of the problem including
detailed hardware information (memory+brand, mainboard+chipset+brand, which
MJPEG card, processor, other PCI cards that might be of interest), give the
system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
the kernel version, driver version, glibc version, gcc version and any other
information that might possibly be of interest. Also provide the dmesg output
at high verbosity. See 'Contacting' on how to contact the developers.
===========================
8. Maintainers/Contacting
The driver is currently maintained by Laurent Pinchart and Ronald Bultje
(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug
reports or questions, please contact the mailinglist instead of the developers
individually. For user questions (i.e. bug reports or how-to questions), send
an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to
help programming), send an email to <mjpeg-developer@lists.sf.net>. See
http://www.sf.net/projects/mjpeg/ for subscription information.
For bug reports, be sure to include all the information as described in
the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure
you're using the latest version (http://mjpeg.sf.net/driver-zoran/).
Previous maintainers/developers of this driver include Serguei Miridonov
<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks
<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>.
===========================
9. License
This driver is distributed under the terms of the General Public License.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
See http://www.gnu.org/ for more information.

25
Documentation/video4linux/bttv/CONTRIBUTORS Normal file
View File

@@ -0,0 +1,25 @@
Contributors to bttv:
Michael Chu <mmchu@pobox.com>
AverMedia fix and more flexible card recognition
Alan Cox <alan@redhat.com>
Video4Linux interface and 2.1.x kernel adaptation
Chris Kleitsch
Hardware I2C
Gerd Knorr <kraxel@cs.tu-berlin.de>
Radio card (ITT sound processor)
bigfoot <bigfoot@net-way.net>
Ragnar Hojland Espinosa <ragnar@macula.net>
ConferenceTV card
+ many more (please mail me if you are missing in this list and would
like to be mentioned)

964
Documentation/video4linux/bttv/Cards Normal file
View File

@@ -0,0 +1,964 @@
Gunther Mayer's bttv card gallery (graphical version of this text file :-)
is available at: http://www.bttv-gallery.de/
Supported cards:
Bt848/Bt848a/Bt849/Bt878/Bt879 cards
------------------------------------
All cards with Bt848/Bt848a/Bt849/Bt878/Bt879 and normal
Composite/S-VHS inputs are supported. Teletext and Intercast support
(PAL only) for ALL cards via VBI sample decoding in software.
Some cards with additional multiplexing of inputs or other additional
fancy chips are only partially supported (unless specifications by the
card manufacturer are given). When a card is listed here it isn't
necessarily fully supported.
All other cards only differ by additional components as tuners, sound
decoders, EEPROMs, teletext decoders ...
Unsupported Cards:
------------------
Cards with Zoran (ZR) or Philips (SAA) or ISA are not supported by
this driver.
MATRIX Vision
-------------
MV-Delta
- Bt848A
- 4 Composite inputs, 1 S-VHS input (shared with 4th composite)
- EEPROM
http://www.matrix-vision.de/
This card has no tuner but supports all 4 composite (1 shared with an
S-VHS input) of the Bt848A.
Very nice card if you only have satellite TV but several tuners connected
to the card via composite.
Many thanks to Matrix-Vision for giving us 2 cards for free which made
Bt848a/Bt849 single crytal operation support possible!!!
Miro/Pinnacle PCTV
------------------
- Bt848
some (all??) come with 2 crystals for PAL/SECAM and NTSC
- PAL, SECAM or NTSC TV tuner (Philips or TEMIC)
- MSP34xx sound decoder on add on board
decoder is supported but AFAIK does not yet work
(other sound MUX setting in GPIO port needed??? somebody who fixed this???)
- 1 tuner, 1 composite and 1 S-VHS input
- tuner type is autodetected
http://www.miro.de/
http://www.miro.com/
Many thanks for the free card which made first NTSC support possible back
in 1997!
Hauppauge Win/TV pci
--------------------
There are many different versions of the Hauppauge cards with different
tuners (TV+Radio ...), teletext decoders.
Note that even cards with same model numbers have (depending on the revision)
different chips on it.
- Bt848 (and others but always in 2 crystal operation???)
newer cards have a Bt878
- PAL, SECAM, NTSC or tuner with or without Radio support
e.g.:
PAL:
TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
NTSC:
TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5518: no datasheet available on Philips site
- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip
with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM)
SAA5246 (I2C 0x22) is supported
- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y
with configuration information
I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf)
- 1 tuner, 1 composite and (depending on model) 1 S-VHS input
- 14052B: mux for selection of sound source
- sound decoder: TDA9800, MSP34xx (stereo cards)
Askey CPH-Series
----------------
Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink)
Card series:
CPH01x: BT848 capture only
CPH03x: BT848
CPH05x: BT878 with FM
CPH06x: BT878 (w/o FM)
CPH07x: BT878 capture only
TV standards:
CPH0x0: NTSC-M/M
CPH0x1: PAL-B/G
CPH0x2: PAL-I/I
CPH0x3: PAL-D/K
CPH0x4: SECAM-L/L
CPH0x5: SECAM-B/G
CPH0x6: SECAM-D/K
CPH0x7: PAL-N/N
CPH0x8: PAL-B/H
CPH0x9: PAL-M/M
CPH03x was often sold as "TV capturer".
Identifying:
1) 878 cards can be identified by PCI Subsystem-ID:
144f:3000 = CPH06x
144F:3002 = CPH05x w/ FM
144F:3005 = CPH06x_LC (w/o remote control)
1) The cards have a sticker with "CPH"-model on the back.
2) These cards have a number printed on the PCB just above the tuner metal box:
"80-CP2000300-x" = CPH03X
"80-CP2000500-x" = CPH05X
"80-CP2000600-x" = CPH06X / CPH06x_LC
Askey sells these cards as "Magic TView series", Brand "MagicXpress".
Other OEM often call these "Tview", "TView99" or else.
Lifeview Flyvideo Series:
-------------------------
The naming of these series differs in time and space.
Identifying:
1) Some models can be identified by PCI subsystem ID:
1852:1852 = Flyvideo 98 FM
1851:1850 = Flyvideo 98
1851:1851 = Flyvideo 98 EZ (capture only)
2) There is a print on the PCB:
LR25 = Flyvideo (Zoran ZR36120, SAA7110A)
LR26 Rev.N = Flyvideo II (Bt848)
Rev.O = Flyvideo II (Bt878)
LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110)
LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only)
LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID)
Rev.W = Flyvideo 98 (no eeprom)
LR51 Rev.E = Flyvideo 98 EZ (capture only)
LR90 = Flyvideo 2000 (Bt878)
Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard)
LR91 = Stereo daughter card for LR90
LR97 = Flyvideo DVBS
LR99 Rev.E = Low profile card for OEM integration (only internal audio!) bt878
LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134)
LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394)
LR138 Rev.C= Flyvideo 2000 (SAA7130)
or Flyvideo 3000 (SAA7134) w/Stereo TV
These exist in variations w/FM and w/Remote sometimes denoted
by suffixes "FM" and "R".
3) You have a laptop (miniPCI card):
Product = FlyTV Platinum Mini
Model/Chip = LR212/saa7135
Lifeview.com.tw states (Feb. 2002):
"The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98."
Their Bt8x8 cards are listed as discontinued.
Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?).
The new Flyvideo 2000/3000 are SAA7130/SAA7134 based.
"Flyvideo II" had been the name for the 848 cards, nowadays (in Germany)
this name is re-used for LR50 Rev.W.
The Lifeview website mentioned Flyvideo III at some time, but such a card
has not yet been seen (perhaps it was the german name for LR90 [stereo]).
These cards are sold by many OEMs too.
FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Germany}
Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134
Typhoon TV card series:
-----------------------
These can be CPH, Flyvideo, Pixelview or KNC1 series.
Typhoon is the brand of Anubis.
Model 50680 got re-used, some model no. had different contents over time.
Models:
50680 "TV Tuner PCI Pal BG"(old,red package)=can be CPH03x(bt848) or CPH06x(bt878)
50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B)
50681 "TV Tuner PCI Pal I" (variant of 50680)
50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q)
Note: The package has a picture of CPH05x (which would be a real TView)
50683 "TV Tuner PCI SECAM" (variant of 50680)
50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D)
50686 "TV Tuner" = KNC1 TV Station
50687 "TV Tuner stereo" = KNC1 TV Station pro
50688 "TV Tuner RDS" (black package) = KNC1 TV Station RDS
50689 TV SAT DVB-S CARD CI PCI (SAA7146AH, SU1278?) = "KNC1 TV Station DVB-S"
50692 "TV/FM Tuner" (small PCB)
50694 TV TUNER CARD RDS (PHILIPS CHIPSET SAA7134HL)
50696 TV TUNER STEREO (PHILIPS CHIPSET SAA7134HL, MK3ME Tuner)
50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps)
50866 TVIEW SAT RECEIVER+ADR
50868 "TV/FM Tuner Pal I" (variant of 50682)
50999 "TV/FM Tuner Secam" (variant of 50682)
Guillemot
---------
Maxi-TV PCI (ZR36120)
Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM)
Maxi TV Video 3 = CPH064 (PAL BG + SECAM)
Mentor
------
Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote)
Prolink
-------
TV cards:
PixelView Play TV pro - (Model: PV-BT878P+ REV 8E)
PixelView Play TV pro - (Model: PV-BT878P+ REV 9D)
PixelView Play TV pro - (Model: PV-BT878P+ REV 4C / 8D / 10A )
PixelView Play TV - (Model: PV-BT848P+)
878TV - (Model: PV-BT878TV)
Multimedia TV packages (card + software pack):
PixelView Play TV Theater - (Model: PV-M4200) = PixelView Play TV pro + Software
PixelView Play TV PAK - (Model: PV-BT878P+ REV 4E)
PixelView Play TV/VCR - (Model: PV-M3200 REV 4C / 8D / 10A )
PixelView Studio PAK - (Model: M2200 REV 4C / 8D / 10A )
PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E)
PixelView DigitalVCR PAK - (Model: PV-M2400 REV 4C / 8D / 10A )
PixelView PlayTV PAK II (TV/FM card + usb camera) PV-M3800
PixelView PlayTV XP PV-M4700,PV-M4700(w/FM)
PixelView PlayTV DVR PV-M4600 package contents:PixelView PlayTV pro, windvr & videoMail s/w
Further Cards:
PV-BT878P+rev.9B (Play TV Pro, opt. w/FM w/NICAM)
PV-BT878P+rev.2F
PV-BT878P Rev.1D (bt878, capture only)
XCapture PV-CX881P (cx23881)
PlayTV HD PV-CX881PL+, PV-CX881PL+(w/FM) (cx23881)
DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030
DTV2000 DVB-S = Twinhan VP-1020
Video Conferencing:
PixelView Meeting PAK - (Model: PV-BT878P)
PixelView Meeting PAK Lite - (Model: PV-BT878P)
PixelView Meeting PAK plus - (Model: PV-BT878P+rev 4C/8D/10A)
PixelView Capture - (Model: PV-BT848P)
PixelView PlayTV USB pro
Model No. PV-NT1004+, PV-NT1004+ (w/FM) = NT1004 USB decoder chip + SAA7113 video decoder chip
Dynalink
--------
These are CPH series.
Phoebemicro
-----------
TV Master = CPH030 or CPH060
TV Master FM = CPH050
Genius/Kye
----------
Video Wonder/Genius Internet Video Kit = LR37 Rev.C
Video Wonder Pro II (848 or 878) = LR26
Tekram
------
VideoCap C205 (Bt848)
VideoCap C210 (zr36120 +Philips)
CaptureTV M200 (ISA)
CaptureTV M205 (Bt848)
Lucky Star
----------
Image World Conference TV = LR50 Rev. Q
Leadtek
-------
WinView 601 (Bt848)
WinView 610 (Zoran)
WinFast2000
WinFast2000 XP
KNC One
-------
TV-Station
TV-Station SE (+Software Bundle)
TV-Station pro (+TV stereo)
TV-Station FM (+Radio)
TV-Station RDS (+RDS)
TV Station SAT (analog satellite)
TV-Station DVB-S
newer Cards have saa7134, but model name stayed the same?
Provideo
--------
PV951 or PV-951 (also are sold as:
Boeder TV-FM Video Capture Card
Titanmedia Supervision TV-2400
Provideo PV951 TF
3DeMon PV951
MediaForte TV-Vision PV951
Yoko PV951
Vivanco Tuner Card PCI Art.-Nr.: 68404
) now named PV-951T
Surveillance Series
PV-141
PV-143
PV-147
PV-148 (capture only)
PV-150
PV-151
TV-FM Tuner Series
PV-951TDV (tv tuner + 1394)
PV-951T/TF
PV-951PT/TF
PV-956T/TF Low Profile
PV-911
Highscreen
----------
TV Karte = LR50 Rev.S
TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb"
Zoltrix
-------
Face to Face Capture (Bt848 capture only) (PCB "VP-2848")
Face To Face TV MAX (Bt848) (PCB "VP-8482 Rev1.3")
Genie TV (Bt878) (PCB "VP-8790 Rev 2.1")
Genie Wonder Pro
AVerMedia
---------
AVer FunTV Lite (ISA, AV3001 chipset) "M101.C"
AVerTV
AVerTV Stereo
AVerTV Studio (w/FM)
AVerMedia TV98 with Remote
AVerMedia TV/FM98 Stereo
AVerMedia TVCAM98
TVCapture (Bt848)
TVPhone (Bt848)
TVCapture98 (="AVerMedia TV98" in USA) (Bt878)
TVPhone98 (Bt878, w/FM)
PCB PCI-ID Model-Name Eeprom Tuner Sound Country
--------------------------------------------------------------------
M101.C ISA !
M108-B Bt848 -- FR1236 US (2),(3)
M1A8-A Bt848 AVer TV-Phone FM1216 --
M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D (1) w/FM w/Remote
M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote
M168II-B 1461:0003 Medion MD9592 48:16 FM1216 TDA9873H D w/FM
(1) Daughterboard MB68-A with TDA9820T and TDA9840T
(2) Sony NE41S soldered (stereo sound?)
(3) Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz
US site has different drivers for (as of 09/2002):
EZ Capture/InterCam PCI (BT-848 chip)
EZ Capture/InterCam PCI (BT-878 chip)
TV-Phone (BT-848 chip)
TV98 (BT-848 chip)
TV98 With Remote (BT-848 chip)
TV98 (BT-878 chip)
TV98 With Remote (BT-878)
TV/FM98 (BT-878 chip)
AVerTV
AverTV Stereo
AVerTV Studio
DE hat diverse Treiber fuer diese Modelle (Stand 09/2002):
TVPhone (848) mit Philips tuner FR12X6 (w/ FM radio)
TVPhone (848) mit Philips tuner FM12X6 (w/ FM radio)
TVCapture (848) w/Philips tuner FI12X6
TVCapture (848) non-Philips tuner
TVCapture98 (Bt878)
TVPhone98 (Bt878)
AVerTV und TVCapture98 w/VCR (Bt 878)
AVerTVStudio und TVPhone98 w/VCR (Bt878)
AVerTV GO Serie (Kein SVideo Input)
AVerTV98 (BT-878 chip)
AVerTV98 mit Fernbedienung (BT-878 chip)
AVerTV/FM98 (BT-878 chip)
VDOmate (www.averm.com.cn) = M168U ?
Aimslab
-------
Video Highway or "Video Highway TR200" (ISA)
Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757)
IXMicro (former: IMS=Integrated Micro Solutions)
-------
IXTV BT848 (=TurboTV)
IXTV BT878
IMS TurboTV (Bt848)
Lifetec/Medion/Tevion/Aldi
--------------------------
LT9306/MD9306 = CPH061
LT9415/MD9415 = LR90 Rev.F or Rev.G
MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H)
MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner)
MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner)
Modular Technologies (www.modulartech.com) UK
---------------------------------------------
MM100 PCTV (Bt848)
MM201 PCTV (Bt878, Bt832) w/ Quartzsight camera
MM202 PCTV (Bt878, Bt832, tda9874)
MM205 PCTV (Bt878)
MM210 PCTV (Bt878) (Galaxy TV, Galaxymedia ?)
Terratec
--------
Terra TV+ Version 1.0 (Bt848), "ceb105.PCB" printed on the PCB, TDA9821
Terra TV+ Version 1.1 (Bt878), "LR74 Rev.E" printed on the PCB, TDA9821
Terra TValueRadio, "LR102 Rev.C" printed on the PCB
Terra TV/Radio+ Version 1.0, "80-CP2830100-0" TTTV3 printed on the PCB,
"CPH010-E83" on the back, SAA6588T, TDA9873H
Terra TValue Version BT878, "80-CP2830110-0 TTTV4" printed on the PCB,
"CPH011-D83" on back
Terra TValue Version 1.0 "ceb105.PCB" (really identical to Terra TV+ Version 1.0)
Terra TValue New Revision "LR102 Rec.C"
Terra Active Radio Upgrade (tea5757h, saa6588t)
LR74 is a newer PCB revision of ceb105 (both incl. connector for Active Radio Upgrade)
Cinergy 400 (saa7134), "E877 11(S)", "PM820092D" printed on PCB
Cinergy 600 (saa7134)
Technisat
---------
Discos ADR PC-Karte ISA (no TV!)
Discos ADR PC-Karte PCI (probably no TV?)
Techni-PC-Sat (Sat. analog)
Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A)
Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio)
Mediafocus II (saa7146, Sat. analog)
SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A)
SkyStar 1 DVB (AV7110) = Technotrend Premium
SkyStar 2 DVB (B2C2) (=Sky2PC)
Siemens
-------
Multimedia eXtension Board (MXB) (SAA7146, SAA7111)
Stradis
-------
SDM275,SDM250,SDM026,SDM025 (SAA7146, IBMMPEG2): MPEG2 decoder only
Powercolor
----------
MTV878
Package comes with different contents:
a) pcb "MTV878" (CARD=75)
b) Pixelview Rev. 4_
MTV878R w/Remote Control
MTV878F w/Remote Control w/FM radio
Pinnacle
--------
Mirovideo PCTV (Bt848)
Mirovideo PCTV SE (Bt848)
Mirovideo PCTV Pro (Bt848 + Daughterboard for TV Stereo and FM)
Studio PCTV Rave (Bt848 Version = Mirovideo PCTV)
Studio PCTV Rave (Bt878 package w/o infrared)
Studio PCTV (Bt878)
Studio PCTV Pro (Bt878 stereo w/ FM)
Pinnacle PCTV (Bt878, MT2032)
Pinnacle PCTV Pro (Bt878, MT2032)
Pinncale PCTV Sat (bt878a, HM1821/1221) ["Conexant CX24110 with CX24108 tuner, aka HM1221/HM1811"]
Pinnacle PCTV Sat XE
M(J)PEG capture and playback:
DC1+ (ISA)
DC10 (zr36057, zr36060, saa7110, adv7176)
DC10+ (zr36067, zr36060, saa7110, adv7176)
DC20 (ql16x24b,zr36050, zr36016, saa7110, saa7187 ...)
DC30 (zr36057, zr36050, zr36016, vpx3220, adv7176, ad1843, tea6415, miro FST97A1)
DC30+ (zr36067, zr36050, zr36016, vpx3220, adv7176)
DC50 (zr36067, zr36050, zr36016, saa7112, adv7176 (2 pcs.?), ad1843, miro FST97A1, Lattice ???)
Lenco
-----
MXR-9565 (=Technisat Mediafocus?)
MXR-9571 (Bt848) (=CPH031?)
MXR-9575
MXR-9577 (Bt878) (=Prolink 878TV Rev.3x)
MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E)
Iomega
------
Buz (zr36067, zr36060, saa7111, saa7185)
LML
---
LML33 (zr36067, zr36060, bt819, bt856)
Grandtec
--------
Grand Video Capture (Bt848)
Multi Capture Card (Bt878)
Koutech
-------
KW-606 (Bt848)
KW-607 (Bt848 capture only)
KW-606RSF
KW-607A (capture only)
KW-608 (Zoran capture only)
IODATA (jp)
------
GV-BCTV/PCI
GV-BCTV2/PCI
GV-BCTV3/PCI
GV-BCTV4/PCI
GV-VCP/PCI (capture only)
GV-VCP2/PCI (capture only)
Canopus (jp)
-------
WinDVR = Kworld "KW-TVL878RF"
www.sigmacom.co.kr
------------------
Sigma Cyber TV II
www.sasem.co.kr
---------------
Litte OnAir TV
hama
----
TV/Radio-Tuner Card, PCI (Model 44677) = CPH051
Sigma Designs
-------------
Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder
Formac
------
iProTV (Card for iMac Mezzanine slot, Bt848+SCSI)
ProTV (Bt848)
ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono]
ATI
---
TV-Wonder
TV-Wonder VE
Diamond Multimedia
------------------
DTV2000 (Bt848, tda9875)
Aopen
-----
VA1000 Plus (w/ Stereo)
VA1000 Lite
VA1000 (=LR90)
Intel
-----
Smart Video Recorder (ISA full-length)
Smart Video Recorder pro (ISA half-length)
Smart Video Recorder III (Bt848)
STB
---
STB Gateway 6000704 (bt878)
STB Gateway 6000699 (bt848)
STB Gateway 6000402 (bt848)
STB TV130 PCI
Videologic
----------
Captivator Pro/TV (ISA?)
Captivator PCI/VC (Bt848 bundled with camera) (capture only)
Technotrend
------------
TT-SAT PCI (PCB "Sat-PCI Rev.:1.3.1"; zr36125, vpx3225d, stc0056a, Tuner:BSKE6-155A
TT-DVB-Sat
revisions 1.1, 1.3, 1.5, 1.6 and 2.1
This card is sold as OEM from:
Siemens DVB-s Card
Hauppauge WinTV DVB-S
Technisat SkyStar 1 DVB
Galaxis DVB Sat
Now this card is called TT-PCline Premium Family
TT-Budget (saa7146, bsru6-701a)
This card is sold as OEM from:
Hauppauge WinTV Nova
Satelco Standard PCI (DVB-S)
TT-DVB-C PCI
Teles
-----
DVB-s (Rev. 2.2, BSRV2-301A, data only?)
Remote Vision
-------------
MX RV605 (Bt848 capture only)
Boeder
------
PC ChatCam (Model 68252) (Bt848 capture only)
Tv/Fm Capture Card (Model 68404) = PV951
Media-Surfer (esc-kathrein.de)
-------------------------------
Sat-Surfer (ISA)
Sat-Surfer PCI = Techni-PC-Sat
Cable-Surfer 1
Cable-Surfer 2
Cable-Surfer PCI (zr36120)
Audio-Surfer (ISA Radio card)
Jetway (www.jetway.com.tw)
--------------------------
JW-TV 878M
JW-TV 878 = KWorld KW-TV878RF
Galaxis
-------
Galaxis DVB Card S CI
Galaxis DVB Card C CI
Galaxis DVB Card S
Galaxis DVB Card C
Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI
Hauppauge
---------
many many WinTV models ...
WinTV DVBs = Technotrend Premium 1.3
WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA"
WinTV NOVA-CI "SDVBACI"
WinTV Nova USB (=Technotrend USB 1.0)
WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2)
WinTV PVR
WinTV PVR 250
WinTV PVR 450
US models
990 WinTV-PVR-350 (249USD) (iTVC15 chipset + radio)
980 WinTV-PVR-250 (149USD) (iTVC15 chipset)
880 WinTV-PVR-PCI (199USD) (KFIR chipset + bt878)
881 WinTV-PVR-USB
190 WinTV-GO
191 WinTV-GO-FM
404 WinTV
401 WinTV-radio
495 WinTV-Theater
602 WinTV-USB
621 WinTV-USB-FM
600 USB-Live
698 WinTV-HD
697 WinTV-D
564 WinTV-Nexus-S
Deutsche Modelle
603 WinTV GO
719 WinTV Primio-FM
718 WinTV PCI-FM
497 WinTV Theater
569 WinTV USB
568 WinTV USB-FM
882 WinTV PVR
981 WinTV PVR 250
891 WinTV-PVR-USB
541 WinTV Nova
488 WinTV Nova-Ci
564 WinTV-Nexus-s
727 WinTV-DVB-c
545 Common Interface
898 WinTV-Nova-USB
UK models
607 WinTV Go
693,793 WinTV Primio FM
647,747 WinTV PCI FM
498 WinTV Theater
883 WinTV PVR
893 WinTV PVR USB (Duplicate entry)
566 WinTV USB (UK)
573 WinTV USB FM
429 Impact VCB (bt848)
600 USB Live (Video-In 1x Comp, 1xSVHS)
542 WinTV Nova
717 WinTV DVB-S
909 Nova-t PCI
893 Nova-t USB (Duplicate entry)
802 MyTV
804 MyView
809 MyVideo
872 MyTV2Go FM
546 WinTV Nova-S CI
543 WinTV Nova
907 Nova-S USB
908 Nova-T USB
717 WinTV Nexus-S
157 DEC3000-s Standalone + USB
Spain
685 WinTV-Go
690 WinTV-PrimioFM
416 WinTV-PCI Nicam Estereo
677 WinTV-PCI-FM
699 WinTV-Theater
683 WinTV-USB
678 WinTV-USB-FM
983 WinTV-PVR-250
883 WinTV-PVR-PCI
993 WinTV-PVR-350
893 WinTV-PVR-USB
728 WinTV-DVB-C PCI
832 MyTV2Go
869 MyTV2Go-FM
805 MyVideo (USB)
Matrix-Vision
-------------
MATRIX-Vision MV-Delta
MATRIX-Vision MV-Delta 2
MVsigma-SLC (Bt848)
Conceptronic (.net)
------------
TVCON FM, TV card w/ FM = CPH05x
TVCON = CPH06x
BestData
--------
HCC100 = VCC100rev1 + camera
VCC100 rev1 (bt848)
VCC100 rev2 (bt878)
Gallant (www.gallantcom.com) www.minton.com.tw
-----------------------------------------------
Intervision IV-510 (capture only bt8x8)
Intervision IV-550 (bt8x8)
Intervision IV-100 (zoran)
Intervision IV-1000 (bt8x8)
Asonic (www.asonic.com.cn) (website down)
-----------------------------------------
SkyEye tv 878
Hoontech
--------
878TV/FM
Teppro (www.itcteppro.com.tw)
-----------------------------
ITC PCITV (Card Ver 1.0) "Teppro TV1/TVFM1 Card"
ITC PCITV (Card Ver 2.0)
ITC PCITV (Card Ver 3.0) = "PV-BT878P+ (REV.9D)"
ITC PCITV (Card Ver 4.0)
TEPPRO IV-550 (For BT848 Main Chip)
ITC DSTTV (bt878, satellite)
ITC VideoMaker (saa7146, StreamMachine sm2110, tvtuner) "PV-SM2210P+ (REV:1C)"
Kworld (www.kworld.com.tw)
--------------------------
PC TV Station
KWORLD KW-TV878R TV (no radio)
KWORLD KW-TV878RF TV (w/ radio)
KWORLD KW-TVL878RF (low profile)
KWORLD KW-TV713XRF (saa7134)
MPEG TV Station (same cards as above plus WinDVR Software MPEG en/decoder)
KWORLD KW-TV878R -Pro TV (no Radio)
KWORLD KW-TV878RF-Pro TV (w/ Radio)
KWORLD KW-TV878R -Ultra TV (no Radio)
KWORLD KW-TV878RF-Ultra TV (w/ Radio)
JTT/ Justy Corp.http://www.justy.co.jp/ (www.jtt.com.jp website down)
---------------------------------------------------------------------
JTT-02 (JTT TV) "TV watchmate pro" (bt848)
ADS www.adstech.com
-------------------
Channel Surfer TV ( CHX-950 )
Channel Surfer TV+FM ( CHX-960FM )
AVEC www.prochips.com
---------------------
AVEC Intercapture (bt848, tea6320)
NoBrand
-------
TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_"
Mach www.machspeed.com
----
Mach TV 878
Eline www.eline-net.com/
-----
Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878)
Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x)
Spirit http://www.spiritmodems.com.au/
------
Spirit TV Tuner/Video Capture Card (bt848)
Boser www.boser.com.tw
-----
HS-878 Mini PCI Capture Add-on Card
HS-879 Mini PCI 3D Audio and Capture Add-on Card (w/ ES1938 Solo-1)
Satelco www.citycom-gmbh.de, www.satelco.de
-------
TV-FM =KNC1 saa7134
Standard PCI (DVB-S) = Technotrend Budget
Standard PCI (DVB-S) w/ CI
Satelco Highend PCI (DVB-S) = Technotrend Premium
Sensoray www.sensoray.com
--------
Sensoray 311 (PC/104 bus)
Sensoray 611 (PCI)
CEI (Chartered Electronics Industries Pte Ltd [CEI] [FCC ID HBY])
---
TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips
TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV
Primetime TV (ISA)
acquired by Singapore Technologies
now operating as Chartered Semiconductor Manufacturing
Manufacturer of video cards is listed as:
Cogent Electronics Industries [CEI]
AITech
------
Wavewatcher TV (ISA)
AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878)
WaveWatcher TVR-202 TV/FM Radio Card (ISA)
MAXRON
------
Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK
www.ids-imaging.de
------------------
Falcon Series (capture only)
In USA: http://www.theimagingsource.com/
DFG/LC1
www.sknet-web.co.jp
-------------------
SKnet Monster TV (saa7134)
A-Max www.amaxhk.com (Colormax, Amax, Napa)
-------------------
APAC Viewcomp 878
Cybertainment
-------------
CyberMail AV Video Email Kit w/ PCI Capture Card (capture only)
CyberMail Xtreme
These are Flyvideo
VCR (http://www.vcrinc.com/)
---
Video Catcher 16
Twinhan
-------
DST Card/DST-IP (bt878, twinhan asic) VP-1020
Sold as:
KWorld DVBS Satellite TV-Card
Powercolor DSTV Satellite Tuner Card
Prolink Pixelview DTV2000
Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ?
DST-CI Card (DVB Satellite) VP-1030
DCT Card (DVB cable)
MSI
---
MSI TV@nywhere Tuner Card (MS-8876) (CX23881/883) Not Bt878 compatible.
MS-8401 DVB-S
Focus www.focusinfo.com
-----
InVideo PCI (bt878)
Sdisilk www.sdisilk.com/
-------
SDI Silk 100
SDI Silk 200 SDI Input Card
www.euresys.com
PICOLO series
PMC/Pace
www.pacecom.co.uk website closed
Mercury www.kobian.com (UK and FR)
LR50
LR138RBG-Rx == LR138
TEC sound (package and manuals don't have any other manufacturer info) TecSound
Though educated googling found: www.techmakers.com
TV-Mate = Zoltrix VP-8482
Lorenzen www.lorenzen.de
--------
SL DVB-S PCI = Technotrend Budget PCI (su1278 or bsru version)
Origo (.uk) www.origo2000.com
PC TV Card = LR50
I/O Magic www.iomagic.com
---------
PC PVR - Desktop TV Personal Video Recorder DR-PCTV100 = Pinnacle ROB2D-51009464 4.0 + Cyberlink PowerVCR II
Arowana
-------
TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?)
iTVC15 boards:
-------------
kuroutoshikou.com ITVC15
yuan.com MPG160 PCI TV (Internal PCI MPEG2 encoder card plus TV-tuner)
Asus www.asuscom.com
Asus TV Tuner Card 880 NTSC (low profile, cx23880)
Asus TV (saa7134)
Hoontech
--------
http://www.hoontech.com/korean/download/down_driver_list03.html
HART Vision 848 (H-ART Vision 848)
HART Vision 878 (H-Art Vision 878)

37
Documentation/video4linux/bttv/ICs Normal file
View File

@@ -0,0 +1,37 @@
all boards:
Brooktree Bt848/848A/849/878/879: video capture chip
Miro PCTV:
Philips or Temic Tuner
Hauppauge Win/TV pci (version 405):
Microchip 24LC02B or
Philips 8582E2Y: 256 Byte EEPROM with configuration information
I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf)
Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23
TDA9800: sound decoder
Winbond W24257AS-35: 32Kx8 CMOS static RAM (Videotext buffer mem)
14052B: analog switch for selection of sound source
PAL:
TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
NTSC:
TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5518: no datasheet available on Philips site
STB TV pci:
???
if you want better support for STB cards send me info!
Look at the board! What chips are on it?

173
Documentation/video4linux/bttv/Insmod-options Normal file
View File

@@ -0,0 +1,173 @@
Note: "modinfo <module>" prints various informations about a kernel
module, among them a complete and up-to-date list of insmod options.
This list tends to be outdated because it is updated manually ...
==========================================================================
bttv.o
the bt848/878 (grabber chip) driver
insmod args:
card=n card type, see CARDLIST for a list.
tuner=n tuner type, see CARDLIST for a list.
radio=0/1 card supports radio
pll=0/1/2 pll settings
0: don't use PLL
1: 28 MHz crystal installed
2: 35 MHz crystal installed
triton1=0/1 for Triton1 (+others) compatibility
vsfx=0/1 yet another chipset bug compatibility bit
see README.quirks for details on these two.
bigendian=n Set the endianness of the gfx framebuffer.
Default is native endian.
fieldnr=0/1 Count fields. Some TV descrambling software
needs this, for others it only generates
50 useless IRQs/sec. default is 0 (off).
autoload=0/1 autoload helper modules (tuner, audio).
default is 1 (on).
bttv_verbose=0/1/2 verbose level (at insmod time, while
looking at the hardware). default is 1.
bttv_debug=0/1 debug messages (for capture).
default is 0 (off).
irq_debug=0/1 irq handler debug messages.
default is 0 (off).
gbuffers=2-32 number of capture buffers for mmap'ed capture.
default is 4.
gbufsize= size of capture buffers. default and
maximum value is 0x208000 (~2MB)
no_overlay=0 Enable overlay on broken hardware. There
are some chipsets (SIS for example) which
are known to have problems with the PCI DMA
push used by bttv. bttv will disable overlay
by default on this hardware to avoid crashes.
With this insmod option you can override this.
automute=0/1 Automatically mutes the sound if there is
no TV signal, on by default. You might try
to disable this if you have bad input signal
quality which leading to unwanted sound
dropouts.
chroma_agc=0/1 AGC of chroma signal, off by default.
adc_crush=0/1 Luminance ADC crush, on by default.
bttv_gpio=0/1
gpiomask=
audioall=
audiomux=
See Sound-FAQ for a detailed description.
remap, card, radio and pll accept up to four comma-separated arguments
(for multiple boards).
tuner.o
The tuner driver. You need this unless you want to use only
with a camera or external tuner ...
insmod args:
debug=1 print some debug info to the syslog
type=n type of the tuner chip. n as follows:
see CARDLIST for a complete list.
pal=[bdgil] select PAL variant (used for some tuners
only, important for the audio carrier).
tvmixer.o
registers a mixer device for the TV card's volume/bass/treble
controls (requires a i2c audio control chip like the msp3400).
insmod args:
debug=1 print some debug info to the syslog.
devnr=n allocate device #n (0 == /dev/mixer,
1 = /dev/mixer1, ...), default is to
use the first free one.
tvaudio.o
new, experimental module which is supported to provide a single
driver for all simple i2c audio control chips (tda/tea*).
insmod args:
tda8425 = 1 enable/disable the support for the
tda9840 = 1 various chips.
tda9850 = 1 The tea6300 can't be autodetected and is
tda9855 = 1 therefore off by default, if you have
tda9873 = 1 this one on your card (STB uses these)
tda9874a = 1 you have to enable it explicitly.
tea6300 = 0 The two tda985x chips use the same i2c
tea6420 = 1 address and can't be disturgished from
pic16c54 = 1 each other, you might have to disable
the wrong one.
debug = 1 print debug messages
insmod args for tda9874a:
tda9874a_SIF=1/2 select sound IF input pin (1 or 2)
(default is pin 1)
tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0)
Please read note 3 below!
tda9874a_STD=n select TV sound standard (0..8):
0 - A2, B/G
1 - A2, M (Korea)
2 - A2, D/K (1)
3 - A2, D/K (2)
4 - A2, D/K (3)
5 - NICAM, I
6 - NICAM, B/G
7 - NICAM, D/K (default)
8 - NICAM, L
Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips.
Note 2: tda9874h/a and tda9875 (which is supported separately by
tda9875.o) use the same i2c address so both modules should not be
used at the same time.
Note 3: Using tda9874a_AMSEL option depends on your TV card design!
AMSEL=0: auto-mute will switch between NICAM sound
and the sound on 1st carrier (i.e. FM mono or AM).
AMSEL=1: auto-mute will switch between NICAM sound
and the analog mono input (MONOIN pin).
If tda9874a decoder on your card has MONOIN pin not connected, then
use only tda9874_AMSEL=0 or don't specify this option at all.
For example:
card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0
card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only
msp3400.o
The driver for the msp34xx sound processor chips. If you have a
stereo card, you probably want to insmod this one.
insmod args:
debug=1/2 print some debug info to the syslog,
2 is more verbose.
simple=1 Use the "short programming" method. Newer
msp34xx versions support this. You need this
for dbx stereo. Default is on if supported by
the chip.
once=1 Don't check the TV-stations Audio mode
every few seconds, but only once after
channel switches.
amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This
should improve things for french people, the
carrier autoscan seems to work with FM only...
tea6300.o - OBSOLETE (use tvaudio instead)
The driver for the tea6300 fader chip. If you have a stereo
card and the msp3400.o doesn't work, you might want to try this
one. This chip is seen on most STB TV/FM cards (usually from
Gateway OEM sold surplus on auction sites).
insmod args:
debug=1 print some debug info to the syslog.
tda8425.o - OBSOLETE (use tvaudio instead)
The driver for the tda8425 fader chip. This driver used to be
part of bttv.c, so if your sound used to work but does not
anymore, try loading this module.
insmod args:
debug=1 print some debug info to the syslog.
tda985x.o - OBSOLETE (use tvaudio instead)
The driver for the tda9850/55 audio chips.
insmod args:
debug=1 print some debug info to the syslog.
chip=9850/9855 set the chip type.

28
Documentation/video4linux/bttv/MAKEDEV Normal file
View File

@@ -0,0 +1,28 @@
#!/bin/bash
function makedev () {
for dev in 0 1 2 3; do
echo "/dev/$1$dev: char 81 $[ $2 + $dev ]"
rm -f /dev/$1$dev
mknod /dev/$1$dev c 81 $[ $2 + $dev ]
chmod 666 /dev/$1$dev
done
# symlink for default device
rm -f /dev/$1
ln -s /dev/${1}0 /dev/$1
}
# see http://roadrunner.swansea.uk.linux.org/v4lapi.shtml
echo "*** new device names ***"
makedev video 0
makedev radio 64
makedev vtx 192
makedev vbi 224
#echo "*** old device names (for compatibility only) ***"
#makedev bttv 0
#makedev bttv-fm 64
#makedev bttv-vbi 224

11
Documentation/video4linux/bttv/Modprobe.conf Normal file
View File

@@ -0,0 +1,11 @@
# i2c
alias char-major-89 i2c-dev
options i2c-core i2c_debug=1
options i2c-algo-bit bit_test=1
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=2 radio=1
options tuner debug=1

14
Documentation/video4linux/bttv/Modules.conf Normal file
View File

@@ -0,0 +1,14 @@
# For modern kernels (2.6 or above), this belongs in /etc/modprobe.conf
# For for 2.4 kernels or earlier, this belongs in /etc/modules.conf.
# i2c
alias char-major-89 i2c-dev
options i2c-core i2c_debug=1
options i2c-algo-bit bit_test=1
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=2 radio=1
options tuner debug=1

62
Documentation/video4linux/bttv/PROBLEMS Normal file
View File

@@ -0,0 +1,62 @@
- Start capturing by pressing "c" or by selecting it via a menu!
- Start capturing by pressing "c" or by selecting it via a menu!!!
- The memory of some S3 cards is not recognized right:
First of all, if you are not using XFree-3.2 or newer, upgrade AT LEAST to
XFree-3.2A! This solved the problem for most people.
Start up X11 like this: "XF86_S3 -probeonly" and write down where the
linear frame buffer is.
If it is different to the address found by bttv install bttv like this:
"insmod bttv vidmem=0xfb0"
if the linear frame buffer is at 0xfb000000 (i.e. omit the last 5 zeros!)
Some S3 cards even take up 64MB of memory but only report 32MB to the BIOS.
If this 64MB area overlaps the IO memory of the Bt848 you also have to
remap this. E.g.: insmod bttv vidmem=0xfb0 remap=0xfa0
If the video memory is found at the right place and there are no address
conflicts but still no picture (or the computer even crashes),
try disabling features of your PCI chipset in the BIOS setup.
Frank Kapahnke <frank@kapahnke.prima.ruhr.de> also reported that problems
with his S3 868 went away when he upgraded to XFree 3.2.
- I still only get a black picture with my S3 card!
Even with XFree-3.2A some people have problems with their S3 cards
(mostly with Trio 64 but also with some others)
Get the free demo version of Accelerated X from www.xinside.com and try
bttv with it. bttv seems to work with most S3 cards with Accelerated X.
Since I do not know much (better make that almost nothing) about VGA card
programming I do not know the reason for this.
Looks like XFree does something different when setting up the video memory?
Maybe somebody can enlighten me?
Would be nice if somebody could get this to work with XFree since
Accelerated X costs more than some of the grabber cards ...
Better linear frame buffer support for S3 cards will probably be in
XFree 4.0.
- Grabbing is not switched off when changing consoles with XFree.
That's because XFree and some AcceleratedX versions do not send unmap
events.
- Some popup windows (e.g. of the window manager) are not refreshed.
Disable backing store by starting X with the option "-bs"
- When using 32 bpp in XFree or 24+8bpp mode in AccelX 3.1 the system
can sometimes lock up if you use more than 1 bt848 card at the same time.
You will always get pixel errors when e.g. using more than 1 card in full
screen mode. Maybe we need something faster than the PCI bus ...
- Some S3 cards and the Matrox Mystique will produce pixel errors with
full resolution in 32-bit mode.
- Some video cards have problems with Accelerated X 4.1

90
Documentation/video4linux/bttv/README Normal file
View File

@@ -0,0 +1,90 @@
Release notes for bttv
======================
You'll need at least these config options for bttv:
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_VIDEO_DEV=m
The latest bttv version is available from http://bytesex.org/bttv/
Make bttv work with your card
-----------------------------
Just try "modprobe bttv" and see if that works.
If it doesn't bttv likely could not autodetect your card and needs some
insmod options. The most important insmod option for bttv is "card=n"
to select the correct card type. If you get video but no sound you've
very likely specified the wrong (or no) card type. A list of supported
cards is in CARDLIST.bttv
If bttv takes very long to load (happens sometimes with the cheap
cards which have no tuner), try adding this to your modules.conf:
options i2c-algo-bit bit_test=1
For the WinTV/PVR you need one firmware file from the driver CD:
hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting
zip file, unzip can unpack it). Put it into the /etc/pvr directory or
use the firm_altera=<path> insmod option to point the driver to the
location of the file.
If your card isn't listed in CARDLIST.bttv or if you have trouble making
audio work, you should read the Sound-FAQ.
Autodetecting cards
-------------------
bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists
the Subsystem ID in the second line, looks like this:
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
Subsystem: Hauppauge computer works Inc. WinTV/GO
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at e2000000 (32-bit, prefetchable) [size=4K]
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
in bttv-cards.c (in case you are intrested or want to mail patches
with updates).
Still doesn't work?
-------------------
I do NOT have a lab with 30+ different grabber boards and a
PAL/NTSC/SECAM test signal generator at home, so I often can't
reproduce your problems. This makes debugging very difficult for me.
If you have some knowledge and spare time, please try to fix this
yourself (patches very welcome of course...) You know: The linux
slogan is "Do it yourself".
There is a mailing list: video4linux-list@redhat.com.
https://listman.redhat.com/mailman/listinfo/video4linux-list
If you have trouble with some specific TV card, try to ask there
instead of mailing me directly. The chance that someone with the
same card listens there is much higher...
For problems with sound: There are alot of different systems used
for TV sound all over the world. And there are also different chips
which decode the audio signal. Reports about sound problems ("stereo
does'nt work") are pretty useless unless you include some details
about your hardware and the TV sound scheme used in your country (or
at least the country you are living in).
Finally: If you mail some patches for bttv around the world (to
linux-kernel/Alan/Linus/...), please Cc: me.
Have fun with bttv,
Gerd
--
Gerd Knorr <kraxel@bytesex.org>

33
Documentation/video4linux/bttv/README.WINVIEW Normal file
View File

@@ -0,0 +1,33 @@
Support for the Leadtek WinView 601 TV/FM by Jon Tombs <jon@gte.esi.us.es>
This card is basically the same as all the rest (Bt484A, Philips tuner),
the main difference is that they have attached a programmable attenuator to 3
GPIO lines in order to give some volume control. They have also stuck an
infra-red remote control decoded on the board, I will add support for this
when I get time (it simple generates an interrupt for each key press, with
the key code is placed in the GPIO port).
I don't yet have any application to test the radio support. The tuner
frequency setting should work but it is possible that the audio multiplexer
is wrong. If it doesn't work, send me email.
- No Thanks to Leadtek they refused to answer any questions about their
hardware. The driver was written by visual inspection of the card. If you
use this driver, send an email insult to them, and tell them you won't
continue buying their hardware unless they support Linux.
- Little thanks to Princeton Technology Corp (http://www.princeton.com.tw)
who make the audio attenuator. Their publicly available data-sheet available
on their web site doesn't include the chip programming information! Hidden
on their server are the full data-sheets, but don't ask how I found it.
To use the driver I use the following options, the tuner and pll settings might
be different in your country
insmod videodev
insmod i2c scan=1 i2c_debug=0 verbose=0
insmod tuner type=1 debug=0
insmod bttv pll=1 radio=1 card=17

74
Documentation/video4linux/bttv/README.freeze Normal file
View File

@@ -0,0 +1,74 @@
If the box freezes hard with bttv ...
=====================================
It might be a bttv driver bug. It also might be bad hardware. It also
might be something else ...
Just mailing me "bttv freezes" isn't going to help much. This README
has a few hints how you can help to pin down the problem.
bttv bugs
---------
If some version works and another doesn't it is likely to be a driver
bug. It is very helpful if you can tell where exactly it broke
(i.e. the last working and the first broken version).
With a hard freeze you probably doesn't find anything in the logfiles.
The only way to capture any kernel messages is to hook up a serial
console and let some terminal application log the messages. /me uses
screen. See Documentation/serial-console.txt for details on setting
up a serial console.
Read Documentation/oops-tracing.txt to learn how to get any useful
information out of a register+stack dump printed by the kernel on
protection faults (so-called "kernel oops").
If you run into some kind of deadlock, you can try to dump a call trace
for each process using sysrq-t (see Documentation/sysrq.txt). ksymoops
will translate these dumps into kernel symbols too. This way it is
possible to figure where *exactly* some process in "D" state is stuck.
I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
for some people. Thus probably a small buglet left somewhere in bttv
0.7.x. I have no idea where exactly, it works stable for me and alot of
other people. But in case you have problems with the 0.7.x versions you
can give 0.8.x a try ...
hardware bugs
-------------
Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga).
Sometimes problems show up with bttv just because of the high load on
the PCI bus. The bt848/878 chips have a few workarounds for known
incompatibilities, see README.quirks.
Some folks report that increasing the pci latency helps too,
althrought I'm not sure whenever this really fixes the problems or
only makes it less likely to happen. Both bttv and btaudio have a
insmod option to set the PCI latency of the device.
Some mainboard have problems to deal correctly with multiple devices
doing DMA at the same time. bttv + ide seems to cause this sometimes,
if this is the case you likely see freezes only with video and hard disk
access at the same time. Updating the IDE driver to get the latest and
greatest workarounds for hardware bugs might fix these problems.
other
-----
If you use some binary-only yunk (like nvidia module) try to reproduce
the problem without.
IRQ sharing is known to cause problems in some cases. It works just
fine in theory and many configurations. Neverless it might be worth a
try to shuffle around the PCI cards to give bttv another IRQ or make
it share the IRQ with some other piece of hardware. IRQ sharing with
VGA cards seems to cause trouble sometimes. I've also seen funny
effects with bttv sharing the IRQ with the ACPI bridge (and
apci-enabled kernel).

83
Documentation/video4linux/bttv/README.quirks Normal file
View File

@@ -0,0 +1,83 @@
Below is what the bt878 data book says about the PCI bug compatibility
modes of the bt878 chip.
The triton1 insmod option sets the EN_TBFX bit in the control register.
The vsfx insmod option does the same for EN_VSFX bit. If you have
stability problems you can try if one of these options makes your box
work solid.
drivers/pci/quirks.c knows about these issues, this way these bits are
enabled automagically for known-buggy chipsets (look at the kernel
messages, bttv tells you).
HTH,
Gerd
---------------------------- cut here --------------------------
Normal PCI Mode
---------------
The PCI REQ signal is the logical-or of the incoming function requests.
The inter-nal GNT[0:1] signals are gated asynchronously with GNT and
demultiplexed by the audio request signal. Thus the arbiter defaults to
the video function at power-up and parks there during no requests for
bus access. This is desirable since the video will request the bus more
often. However, the audio will have highest bus access priority. Thus
the audio will have first access to the bus even when issuing a request
after the video request but before the PCI external arbiter has granted
access to the Bt879. Neither function can preempt the other once on the
bus. The duration to empty the entire video PCI FIFO onto the PCI bus is
very short compared to the bus access latency the audio PCI FIFO can
tolerate.
430FX Compatibility Mode
------------------------
When using the 430FX PCI, the following rules will ensure
compatibility:
(1) Deassert REQ at the same time as asserting FRAME.
(2) Do not reassert REQ to request another bus transaction until after
finish-ing the previous transaction.
Since the individual bus masters do not have direct control of REQ, a
simple logical-or of video and audio requests would violate the rules.
Thus, both the arbiter and the initiator contain 430FX compatibility
mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in
Device Control Register on page 104.
When EN_TBFX is enabled, the arbiter ensures that the two compatibility
rules are satisfied. Before GNT is asserted by the PCI arbiter, this
internal arbiter may still logical-or the two requests. However, once
the GNT is issued, this arbiter must lock in its decision and now route
only the granted request to the REQ pin. The arbiter decision lock
happens regardless of the state of FRAME because it does not know when
FRAME will be asserted (typically - each initiator will assert FRAME on
the cycle following GNT). When FRAME is asserted, it is the initiator s
responsibility to remove its request at the same time. It is the
arbiters responsibility to allow this request to flow through to REQ and
not allow the other request to hold REQ asserted. The decision lock may
be removed at the end of the transaction: for example, when the bus is
idle (FRAME and IRDY). The arbiter decision may then continue
asynchronously until GNT is again asserted.
Interfacing with Non-PCI 2.1 Compliant Core Logic
-------------------------------------------------
A small percentage of core logic devices may start a bus transaction
during the same cycle that GNT is de-asserted. This is non PCI 2.1
compliant. To ensure compatibility when using PCs with these PCI
controllers, the EN_VSFX bit must be enabled (refer to Device Control
Register on page 104). When in this mode, the arbiter does not pass GNT
to the internal functions unless REQ is asserted. This prevents a bus
transaction from starting the same cycle as GNT is de-asserted. This
also has the side effect of not being able to take advantage of bus
parking, thus lowering arbitration performance. The Bt879 drivers must
query for these non-compliant devices, and set the EN_VSFX bit only if
required.

148
Documentation/video4linux/bttv/Sound-FAQ Normal file
View File

@@ -0,0 +1,148 @@
bttv and sound mini howto
=========================
There are alot of different bt848/849/878/879 based boards available.
Making video work often is not a big deal, because this is handled
completely by the bt8xx chip, which is common on all boards. But
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
bttv-cards.c, which holds the informations required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one:
bttv0: model: BT848(Hauppauge old) [autodetected]
You should verify this is correct. If it isn't, you have to pass the
correct board type as insmod argument, "insmod bttv card=2" for
example. The file CARDLIST has a list of valid arguments for card.
If your card isn't listed there, you might check the source code for
new entries which are not listed yet. If there isn't one for your
card, you can check if one of the existing entries does work for you
(just trial and error...).
Some boards have an extra processor for sound to do stereo decoding
and other nice features. The msp34xx chips are used by Hauppauge for
example. If your board has one, you might have to load a helper
module like msp3400.o to make sound work. If there isn't one for the
chip used on your board: Bad luck. Start writing a new one. Well,
you might want to check the video4linux mailing list archive first...
Of course you need a correctly installed soundcard unless you have the
speakers connected directly to the grabber board. Hint: check the
mixer settings too. ALSA for example has everything muted by default.
How sound works in detail
=========================
Still doesn't work? Looks like some driver hacking is required.
Below is a do-it-yourself description for you.
The bt8xx chips have 32 general purpose pins, and registers to control
these pins. One register is the output enable register
(BT848_GPIO_OUT_EN), it says which pins are actively driven by the
bt848 chip. Another one is the data register (BT848_GPIO_DATA), where
you can get/set the status if these pins. They can be used for input
and output.
Most grabber board vendors use these pins to control an external chip
which does the sound routing. But every board is a little different.
These pins are also used by some companies to drive remote control
receiver chips. Some boards use the i2c bus instead of the gpio pins
to connect the mux chip.
As mentioned above, there is a array which holds the required
informations for each known board. You basically have to create a new
line for your board. The important fields are these two:
struct tvcard
{
[ ... ]
u32 gpiomask;
u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
};
gpiomask specifies which pins are used to control the audio mux chip.
The corresponding bits in the output enable register
(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the
bt848 chip.
The audiomux[] array holds the data values for the different inputs
(i.e. which pins must be high/low for tuner/mute/...). This will be
written to the data register (BT848_GPIO_DATA) to switch the audio
mux.
What you have to do is figure out the correct values for gpiomask and
the audiomux array. If you have Windows and the drivers four your
card installed, you might to check out if you can read these registers
values used by the windows driver. A tool to do this is available
from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it
does'nt work with bt878 boards according to some reports I received.
Another one with bt878 suport is available from
http://btwincap.sourceforge.net/Files/btspy2.00.zip
You might also dig around in the *.ini files of the Windows applications.
You can have a look at the board to see which of the gpio pins are
connected at all and then start trial-and-error ...
Starting with release 0.7.41 bttv has a number of insmod options to
make the gpio debugging easier:
bttv_gpio=0/1 enable/disable gpio debug messages
gpiomask=n set the gpiomask value
audiomux=i,j,... set the values of the audiomux array
audioall=a set the values of the audiomux array (one
value for all array elements, useful to check
out which effect the particular value has).
The messages printed with bttv_gpio=1 look like this:
bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
en = output _en_able register (BT848_GPIO_OUT_EN)
out = _out_put bits of the data register (BT848_GPIO_DATA),
i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
in = _in_put bits of the data register,
i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
Other elements of the tvcards array
===================================
If you are trying to make a new card work you might find it useful to
know what the other elements in the tvcards array are good for:
video_inputs - # of video inputs the card has
audio_inputs - historical cruft, not used any more.
tuner - which input is the tuner
svhs - which input is svhs (all others are labeled composite)
muxsel - video mux, input->registervalue mapping
pll - same as pll= insmod option
tuner_type - same as tuner= insmod option
*_modulename - hint whenever some card needs this or that audio
module loaded to work properly.
has_radio - whenever this TV card has a radio tuner.
no_msp34xx - "1" disables loading of msp3400.o module
no_tda9875 - "1" disables loading of tda9875.o module
needs_tvaudio - set to "1" to load tvaudio.o module
If some config item is specified both from the tvcards array and as
insmod option, the insmod option takes precedence.
Good luck,
Gerd
PS: If you have a new working entry, mail it to me.
--
Gerd Knorr <kraxel@bytesex.org>

3
Documentation/video4linux/bttv/Specs Normal file
View File

@@ -0,0 +1,3 @@
Philips http://www.Semiconductors.COM/pip/
Conexant http://www.conexant.com/techinfo/default.asp
Micronas http://www.micronas.de/pages/product_documentation/index.html

24
Documentation/video4linux/bttv/THANKS Normal file
View File

@@ -0,0 +1,24 @@
Many thanks to:
- Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848
and tuner programming and his control program xtvc.
- Martin Buck <martin-2.buck@student.uni-ulm.de> for his great Videotext
package.
- Gerd Knorr <kraxel@cs.tu-berlin.de> for the MSP3400 support and the modular
I2C, tuner, ... support.
- MATRIX Vision for giving us 2 cards for free, which made support of
single crystal operation possible.
- MIRO for providing a free PCTV card and detailed information about the
components on their cards. (E.g. how the tuner type is detected)
Without their card I could not have debugged the NTSC mode.
- Hauppauge for telling how the sound input is selected and what components
they do and will use on their radio cards.
Also many thanks for faxing me the FM1216 data sheet.

115
Documentation/video4linux/bttv/Tuners Normal file
View File

@@ -0,0 +1,115 @@
1) Tuner Programming
====================
There are some flavors of Tuner programming APIs.
These differ mainly by the bandswitch byte.
L= LG_API (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04)
P= PHILIPS_API (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04)
T= TEMIC_API (VHF_LO=0x02, VHF_HI=0x04, UHF=0x01)
A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11)
M= PHILIPS_MK3 (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19)
2) Tuner Manufacturers
======================
SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
[ABCJLMNQ]:
A= BG+DK
B= BG
C= I+DK
J= NTSC-Japan
L= Secam LL
M= BG+I+DK
N= NTSC
Q= BG+I+DK+LL
[89]: ?
[125]:
2: No FM
5: With FM
[DP]:
D= NTSC
P= PAL
[ACD]:
A= F-connector
C= Phono connector
D= Din Jack
[ABCD]:
3-wire/I2C tuning, 2-band/3-band
These Tuners are PHILIPS_API compatible.
Philips Tuner identification: (e.g. FM1216MF)
F[IRMQ]12[1345]6{MF|ME|MP}
F[IRMQ]:
FI12x6: Tuner Series
FR12x6: Tuner + Radio IF
FM12x6: Tuner + FM
FQ12x6: special
FMR12x6: special
TD15xx: Digital Tuner ATSC
12[1345]6:
1216: PAL BG
1236: NTSC
1246: PAL I
1256: Pal DK
{MF|ME|MP}
MF: BG LL w/ Secam (Multi France)
ME: BG DK I LL (Multi Europe)
MP: BG DK I (Multi PAL)
MR: BG DK M (?)
MG: BG DKI M (?)
MK2 series PHILIPS_API, most tuners are compatible to this one !
MK3 series introduced in 2002 w/ PHILIPS_MK3_API
Temic Tuner identification: (.e.g 4006FH5)
4[01][0136][269]F[HYNR]5
40x2: Tuner (5V/33V), TEMIC_API.
40x6: Tuner 5V
41xx: Tuner compact
40x9: Tuner+FM compact
[0136]
xx0x: PAL BG
xx1x: Pal DK, Secam LL
xx3x: NTSC
xx6x: PAL I
F[HYNR]5
FH5: Pal BG
FY5: others
FN5: multistandard
FR5: w/ FM radio
3X xxxx: order number with specific connector
Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API.
LG Innotek Tuner:
TPI8NSR11 : NTSC J/M (TPI8NSR01 w/FM) (P,210/497)
TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM) (P,170/450)
TAPC-I701 : PAL I (TAPC-I001 w/FM) (P,170/450)
TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM) (P,170/450)
TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450)
TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450)
TAPC-W701P: PAL I (TAPC-W001P w/FM) (L,170/450)
TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450)
TAPC-Q704P: PAL D/K+I (L,170/450)
TAPC-G702P: PAL D/K+B/G (L,170/450)
TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8)
TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69)
Suffix:
P= Standard phono female socket
D= IEC female socket
F= F-connector
Other Tuners:
TCL2002MB-1 : PAL BG + DK =TUNER_LG_PAL_NEW_TAPC
TCL2002MB-1F: PAL BG + DK w/FM =PHILIPS_PAL
TCL2002MI-2 : PAL I = ??
ALPS Tuners:
Most are LG_API compatible
TSCH6 has ALPS_API (TSCH5 ?)
TSBE1 has extra API 05,02,08 Control_byte=0xCB Source:(1)
Lit.
(1) conexant100029b-PCI-Decoder-ApplicationNote.pdf

130
Documentation/video4linux/meye.txt Normal file
View File

@@ -0,0 +1,130 @@
Vaio Picturebook Motion Eye Camera Driver Readme
------------------------------------------------
Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
Copyright (C) 2001-2002 Alc<6C>ve <www.alcove.com>
Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
This driver enable the use of video4linux compatible applications with the
Motion Eye camera. This driver requires the "Sony Vaio Programmable I/O
Control Device" driver (which can be found in the "Character drivers"
section of the kernel configuration utility) to be compiled and installed
(using its "camera=1" parameter).
It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
Grabbing is supported in packed YUV colorspace only.
MJPEG hardware grabbing is supported via a private API (see below).
Hardware supported:
-------------------
This driver supports the 'second' version of the MotionEye camera :)
The first version was connected directly on the video bus of the Neomagic
video card and is unsupported.
The second one, made by Kawasaki Steel is fully supported by this
driver (PCI vendor/device is 0x136b/0xff01)
The third one, present in recent (more or less last year) Picturebooks
(C1M* models), is not supported. The manufacturer has given the specs
to the developers under a NDA (which allows the develoment of a GPL
driver however), but things are not moving very fast (see
http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
There is a forth model connected on the USB bus in TR1* Vaio laptops.
This camera is not supported at all by the current driver, in fact
little information if any is available for this camera
(USB vendor/device is 0x054c/0x0107).
Driver options:
---------------
Several options can be passed to the meye driver using the standard
module argument syntax (<param>=<value> when passing the option to the
module or meye.<param>=<value> on the kernel boot line when meye is
statically linked into the kernel). Those options are:
forcev4l1: force use of V4L1 API instead of V4L2
gbuffers: number of capture buffers, default is 2 (32 max)
gbufsize: size of each capture buffer, default is 614400
video_nr: video device to register (0 = /dev/video0, etc)
Module use:
-----------
In order to automatically load the meye module on use, you can put those lines
in your /etc/modprobe.conf file:
alias char-major-81 videodev
alias char-major-81-0 meye
options meye gbuffers=32
Usage:
------
xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
for display and uncompressed video capture:
xawtv -c /dev/video0 -geometry 640x480
or
xawtv -c /dev/video0 -geometry 320x240
motioneye (<http://popies.net/meye/>)
for getting ppm or jpg snapshots, mjpeg video
Private API:
------------
The driver supports frame grabbing with the video4linux API
(either v4l1 or v4l2), so all video4linux tools (like xawtv)
should work with this driver.
Besides the video4linux interface, the driver has a private interface
for accessing the Motion Eye extended parameters (camera sharpness,
agc, video framerate), the shapshot and the MJPEG capture facilities.
This interface consists of several ioctls (prototypes and structures
can be found in include/linux/meye.h):
MEYEIOC_G_PARAMS
MEYEIOC_S_PARAMS
Get and set the extended parameters of the motion eye camera.
The user should always query the current parameters with
MEYEIOC_G_PARAMS, change what he likes and then issue the
MEYEIOC_S_PARAMS call (checking for -EINVAL). The extended
parameters are described by the meye_params structure.
MEYEIOC_QBUF_CAPT
Queue a buffer for capture (the buffers must have been
obtained with a VIDIOCGMBUF call and mmap'ed by the
application). The argument to MEYEIOC_QBUF_CAPT is the
buffer number to queue (or -1 to end capture). The first
call to MEYEIOC_QBUF_CAPT starts the streaming capture.
MEYEIOC_SYNC
Takes as an argument the buffer number you want to sync.
This ioctl blocks until the buffer is filled and ready
for the application to use. It returns the buffer size.
MEYEIOC_STILLCAPT
MEYEIOC_STILLJCAPT
Takes a snapshot in an uncompressed or compressed jpeg format.
This ioctl blocks until the snapshot is done and returns (for
jpeg snapshot) the size of the image. The image data is
available from the first mmap'ed buffer.
Look at the 'motioneye' application code for an actual example.
Bugs / Todo:
------------
- the driver could be much cleaned up by removing the v4l1 support.
However, this means all v4l1-only applications will stop working.
- 'motioneye' still uses the meye private v4l1 API extensions.

147
Documentation/video4linux/radiotrack.txt Normal file
View File

@@ -0,0 +1,147 @@
NOTES ON RADIOTRACK CARD CONTROL
by Stephen M. Benoit (benoits@servicepro.com) Dec 14, 1996
----------------------------------------------------------------------------
Document version 1.0
ACKNOWLEDGMENTS
----------------
This document was made based on 'C' code for Linux from Gideon le Grange
(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from
Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from
experiments that the author performed on his own setup, so your mileage may
vary... I make no guarantees, claims or warranties to the suitability or
validity of this information. No other documentation on the AIMS
Lab (http://www.aimslab.com/) RadioTrack card was made available to the
author. This document is offered in the hopes that it might help users who
want to use the RadioTrack card in an environment other than MS Windows.
WHY THIS DOCUMENT?
------------------
I have a RadioTrack card from back when I ran an MS-Windows platform. After
converting to Linux, I found Gideon le Grange's command-line software for
running the card, and found that it was good! Frans Brinkman made a
comfortable X-windows interface, and added a scanning feature. For hack
value, I wanted to see if the tuner could be tuned beyond the usual FM radio
broadcast band, so I could pick up the audio carriers from North American
broadcast TV channels, situated just below and above the 87.0-109.0 MHz range.
I did not get much success, but I learned about programming ioports under
Linux and gained some insights about the hardware design used for the card.
So, without further delay, here are the details.
PHYSICAL DESCRIPTION
--------------------
The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF)
input is simply an antenna lead, and the output is a power audio signal
available through a miniature phone plug. Its RF frequencies of operation are
more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast
band). Although the registers can be programmed to request frequencies beyond
these limits, experiments did not give promising results. The variable
frequency oscillator (VFO) that demodulates the intermediate frequency (IF)
signal probably has a small range of useful frequencies, and wraps around or
gets clipped beyond the limits mentioned above.
CONTROLLING THE CARD WITH IOPORT
--------------------------------
The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one
ioport seems to be involved. The ioport decoding circuitry must be pretty
simple, as individual ioport bits are directly matched to specific functions
(or blocks) of the radio card. This way, many functions can be changed in
parallel with one write to the ioport. The only feedback available through
the ioports appears to be the "Stereo Detect" bit.
The bits of the ioport are arranged as follows:
MSb LSb
+------+------+------+--------+--------+-------+---------+--------+
| VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune |
| (+) | (-) | | Detect | Audio | (bit) | (latch) | Update |
| | | | Enable | Enable | | | Enable |
+------+------+------+--------+--------+-------+---------+--------+
VolA . VolB [AB......]
-----------
0 0 : audio mute
0 1 : volume + (some delay required)
1 0 : volume - (some delay required)
1 1 : stay at present volume
Stereo Detect Enable [...S....]
--------------------
0 : No Detect
1 : Detect
Results available by reading ioport >60 msec after last port write.
0xff ==> no stereo detected, 0xfd ==> stereo detected.
Radio to Audio (path) Enable [....R...]
----------------------------
0 : Disable path (silence)
1 : Enable path (audio produced)
TuneA . TuneB [.....AB.]
-------------
0 0 : "zero" bit phase 1
0 1 : "zero" bit phase 2
1 0 : "one" bit phase 1
1 1 : "one" bit phase 2
24-bit code, where bits = (freq*40) + 10486188.
The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid.
The bits are shifted in LSb first.
Tune Update Enable [.......T]
------------------
0 : Tuner held constant
1 : Tuner updating in progress
PROGRAMMING EXAMPLES
--------------------
Default: BASE <-- 0xc8 (current volume, no stereo detect,
radio enable, tuner adjust disable)
Card Off: BASE <-- 0x00 (audio mute, no stereo detect,
radio disable, tuner adjust disable)
Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business)
BASE <-- 0xc8 (see "Default")
Volume Down: BASE <-- 0x48 (volume down, no stereo detect,
radio enable, tuner adjust disable)
* wait 10 msec *
BASE <-- 0xc8 (see "Default")
Volume Up: BASE <-- 0x88 (volume up, no stereo detect,
radio enable, tuner adjust disable)
* wait 10 msec *
BASE <-- 0xc8 (see "Default")
Check Stereo: BASE <-- 0xd8 (current volume, stereo detect,
radio enable, tuner adjust disable)
* wait 100 msec *
x <-- BASE (read ioport)
BASE <-- 0xc8 (see "Default")
x=0xff ==> "not stereo", x=0xfd ==> "stereo detected"
Set Frequency: code = (freq*40) + 10486188
foreach of the 24 bits in code,
(from Least to Most Significant):
to write a "zero" bit,
BASE <-- 0x01 (audio mute, no stereo detect, radio
disable, "zero" bit phase 1, tuner adjust)
BASE <-- 0x03 (audio mute, no stereo detect, radio
disable, "zero" bit phase 2, tuner adjust)
to write a "one" bit,
BASE <-- 0x05 (audio mute, no stereo detect, radio
disable, "one" bit phase 1, tuner adjust)
BASE <-- 0x07 (audio mute, no stereo detect, radio
disable, "one" bit phase 2, tuner adjust)
----------------------------------------------------------------------------

33
Documentation/video4linux/w9966.txt Normal file
View File

@@ -0,0 +1,33 @@
W9966 Camera driver, written by Jakob Kemi (jakob.kemi@telia.com)
After a lot of work in softice & wdasm, reading .pdf-files and tiresome
trial-and-error work I've finally got everything to work. I needed vision for a
robotics project so I borrowed this camera from a friend and started hacking.
Anyway I've converted my original code from the AVR 8bit RISC C/ASM code into
a working Linux driver.
To get it working simply configure your kernel to support
parport, ieee1284, video4linux and w9966
If w9966 is statically linked it will always perform aggressive probing for
the camera. If built as a module you'll have more configuration options.
Options:
modprobe w9966.o pardev=parport0(or whatever) parmode=0 (0=auto, 1=ecp, 2=epp)
voila!
you can also type 'modinfo -p w9966.o' for option usage
(or checkout w9966.c)
The only thing to keep in mind is that the image format is in Y-U-Y-V format
where every two pixels take 4 bytes. In SDL (www.libsdl.org) this format
is called VIDEO_PALETTE_YUV422 (16 bpp).
A minimal test application (with source) is available from:
http://hem.fyristorg.com/mogul/w9966.html
The slow framerate is due to missing DMA ECP read support in the
parport drivers. I might add working EPP support later.
Good luck!
/Jakob Kemi

159
Documentation/video4linux/zr36120.txt Normal file
View File

@@ -0,0 +1,159 @@
Driver for Trust Computer Products Framegrabber, version 0.6.1
------ --- ----- -------- -------- ------------ ------- - - -
- ZORAN ------------------------------------------------------
Author: Pauline Middelink <middelin@polyware.nl>
Date: 18 September 1999
Version: 0.6.1
- Description ------------------------------------------------
Video4Linux compatible driver for an unknown brand framegrabber
(Sold in the Netherlands by TRUST Computer Products) and various
other zoran zr36120 based framegrabbers.
The card contains a ZR36120 Multimedia PCI Interface and a Philips
SAA7110 Onechip Frontend videodecoder. There is also an DSP of
which I have forgotten the number, since i will never get that thing
to work without specs from the vendor itself.
The SAA711x are capable of processing 6 different video inputs,
CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or
SECAM and delivering a YUV datastream. On my card the input
'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2.
I have some reports of other cards working with the mentioned
chip sets. For a list of other working cards please have a look
at the cards named in the tvcards struct in the beginning of
zr36120.c
After some testing, I discovered that the carddesigner messed up
on the I2C interface. The Zoran chip includes 2 lines SDA and SCL
which (s)he connected reversely. So we have to clock on the SDA
and r/w data on the SCL pin. Life is fun... Each cardtype now has
a bit which signifies if you have a card with the same deficiency.
Oh, for the completeness of this story I must mention that my
card delivers the VSYNC pulse of the SAA chip to GIRQ1, not
GIRQ0 as some other cards have. This is also incorporated in
the driver be clearing/setting the 'useirq1' bit in the tvcard
description.
Another problems of continuous capturing data with a Zoran chip
is something nasty inside the chip. It effectively halves the
fps we ought to get... Here is the scenario: capturing frames
to memory is done in the so-called snapshot mode. In this mode
the Zoran stops after capturing a frame worth of data and wait
till the application set GRAB bit to indicate readiness for the
next frame. After detecting a set bit, the chip neatly waits
till the start of a frame, captures it and it goes back to off.
Smart ppl will notice the problem here. Its the waiting on the
_next_ frame each time we set the GRAB bit... Oh well, 12,5 fps
is still plenty fast for me.
-- update 28/7/1999 --
Don't believe a word I just said... Proof is the output
of `streamer -t 300 -r 25 -f avi15 -o /dev/null`
++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+-
syncer: done
writer: done
(note the /dev/null is prudent here, my system is not able to
grab /and/ write 25 fps to a file... gifts welcome :) )
The technical reasoning follows: The zoran completed the last
frame, the VSYNC goes low, and GRAB is cleared. The interrupt
routine starts to work since its VSYNC driven, and again
activates the GRAB bit. A few ms later the VSYNC (re-)rises and
the zoran starts to work on a new and freshly broadcasted frame....
For pointers I used the specs of both chips. Below are the URLs:
http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf
http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf
The documentation has very little on absolute numbers or timings
needed for the various modes/resolutions, but there are other
programs you can borrow those from.
------ Install --------------------------------------------
Read the file called TODO. Note its long list of limitations.
Build a kernel with VIDEO4LINUX enabled. Activate the
BT848 driver; we need this because we have need for the
other modules (i2c and videodev) it enables.
To install this software, extract it into a suitable directory.
Examine the makefile and change anything you don't like. Type "make".
After making the modules check if you have the much needed
/dev/video devices. If not, execute the following 4 lines:
mknod /dev/video c 81 0
mknod /dev/video1 c 81 1
mknod /dev/video2 c 81 2
mknod /dev/video3 c 81 3
mknod /dev/video4 c 81 4
After making/checking the devices do:
modprobe i2c
modprobe videodev
modprobe saa7110 (optional)
modprobe saa7111 (optional)
modprobe tuner (optional)
insmod zoran cardtype=<n>
<n> is the cardtype of the card you have. The cardnumber can
be found in the source of zr36120. Look for tvcards. If your
card is not there, please try if any other card gives some
response, and mail me if you got a working tvcard addition.
PS. <TVCard editors behold!)
Dont forget to set video_input to the number of inputs
you defined in the video_mux part of the tvcard definition.
Its a common error to add a channel but not incrementing
video_input and getting angry with me/v4l/linux/linus :(
You are now ready to test the framegrabber with your favorite
video4linux compatible tool
------ Application ----------------------------------------
This device works with all Video4Linux compatible applications,
given the limitations in the TODO file.
------ API ------------------------------------------------
This uses the V4L interface as of kernel release 2.1.116, and in
fact has not been tested on any lower version. There are a couple
of minor differences due to the fact that the amount of data returned
with each frame varies, and no doubt there are discrepancies due to my
misunderstanding of the API. I intend to convert this driver to the
new V4L2 API when it has stabilized more.
------ Current state --------------------------------------
The driver is capable of overlaying a video image in screen, and
even capable of grabbing frames. It uses the BIGPHYSAREA patch
to allocate lots of large memory blocks when tis patch is
found in the kernel, but it doesn't need it.
The consequence is that, when loading the driver as a module,
the module may tell you it's out of memory, but 'free' says
otherwise. The reason is simple; the modules wants its memory
contiguous, not fragmented, and after a long uptime there
probably isn't a fragment of memory large enough...
The driver uses a double buffering scheme, which should really
be an n-way buffer, depending on the size of allocated framebuffer
and the requested grab-size/format.
This current version also fixes a dead-lock situation during irq
time, which really, really froze my system... :)
Good luck.
Pauline