path: root/Documentation/video4linux
diff options
Diffstat (limited to 'Documentation/video4linux')
30 files changed, 4328 insertions, 0 deletions
diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html
new file mode 100644
index 000000000000..4b3d8f640a4a
--- /dev/null
+++ b/Documentation/video4linux/API.html
@@ -0,0 +1,399 @@
+<TITLE>Video4Linux Kernel API Reference v0.1:19990430</TITLE>
+<! Revision History: >
+<! 4/30/1999 - Fred Gleason (fredg@wava.com)>
+<! Documented extensions for the Radio Data System (RDS) extensions >
+<BODY bgcolor="#ffffff">
+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.
+<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>
+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.
+<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
+<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>
+The type field lists the capability flags for the device. These are
+as follows
+<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>
+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.
+<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.
+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>.
+<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>
+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
+<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.
+<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>
+Clipping rectangles are passed as an array. Each clip consists of the following
+fields available to the user.
+<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>
+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.
+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.
+<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>
+The available flags are
+<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>
+<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.
+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).
+The <b>struct video_channel</b> consists of the following
+<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>
+The flags defined are
+<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>
+The types defined are
+<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>
+<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.
+The <b>struct video_picture</b> consists of the following fields
+<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>
+The following palettes are defined
+<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>
+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.
+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
+<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>
+The following flags exist
+<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>
+The following modes are defined
+<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>
+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.
+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.
+The structure contains the following fields
+<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>
+The following flags are defined
+<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>
+The following decoding modes are defined
+<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>
+<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.
+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.
+The video_mbuf structure contains the following fields
+<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>
+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.
+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:
+/* setup everything */
+while (whatever) {
+ /* process frame 0 while the hardware captures frame 1 */
+ /* process frame 1 while the hardware captures frame 0 */
+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.
+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.
+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.
+<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>
+<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:
+<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>
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
new file mode 100644
index 000000000000..e46761c39e3f
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -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
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
new file mode 100644
index 000000000000..a6c82fa4de02
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -0,0 +1,35 @@
+ 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]
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
new file mode 100644
index 000000000000..f7bafe862ba0
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -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
diff --git a/Documentation/video4linux/CQcam.txt b/Documentation/video4linux/CQcam.txt
new file mode 100644
index 000000000000..e415e3604539
--- /dev/null
+++ b/Documentation/video4linux/CQcam.txt
@@ -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
+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
+should be able to read some identification from your quickcam with
+ modprobe -v parport
+ modprobe -v parport_probe
+ cat /proc/parport/PORTNUMBER/autoprobe
+ MODEL:Color QuickCam 2.0;
+ 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
+ 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) \
+ { \
+ 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; \
+ \
+ (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
diff --git a/Documentation/video4linux/README.cpia b/Documentation/video4linux/README.cpia
new file mode 100644
index 000000000000..c95e7bbc0fdf
--- /dev/null
+++ b/Documentation/video4linux/README.cpia
@@ -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
+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'.
+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
+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'.
+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.
+- 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
+- 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
+- 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.
+- 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
+- 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
+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. :)
+ 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/
diff --git a/Documentation/video4linux/README.cx88 b/Documentation/video4linux/README.cx88
new file mode 100644
index 000000000000..897ab834839a
--- /dev/null
+++ b/Documentation/video4linux/README.cx88
@@ -0,0 +1,69 @@
+cx8800 release notes
+This is a v4l2 device driver for the cx2388x chip.
+current status
+ - Basically works.
+ - Some minor image quality glitches.
+ - For now only capture, overlay support isn't completed yet.
+ - 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 ...
+ - 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 ...
+ - 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]
diff --git a/Documentation/video4linux/README.ir b/Documentation/video4linux/README.ir
new file mode 100644
index 000000000000..0da47a847056
--- /dev/null
+++ b/Documentation/video4linux/README.ir
@@ -0,0 +1,72 @@
+infrared remote control support in video4linux drivers
+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
+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>
diff --git a/Documentation/video4linux/README.saa7134 b/Documentation/video4linux/README.saa7134
new file mode 100644
index 000000000000..1a446c65365e
--- /dev/null
+++ b/Documentation/video4linux/README.saa7134
@@ -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
+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.
+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:
+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)
+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]
diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran
new file mode 100644
index 000000000000..01425c21986b
--- /dev/null
+++ b/Documentation/video4linux/Zoran
@@ -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:
+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:
+ 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)
+ 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:
+Information - video4linux/mjpeg extensions:
+(also see below)
+Information - video4linux2:
+More information on the video4linux/mjpeg extensions, by Serguei
+Miridonovi and Rainer Johanni:
+The ioctls for that interface are as follows:
+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.
+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.
+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
+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).
+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
+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
+ 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.
diff --git a/Documentation/video4linux/bttv/CONTRIBUTORS b/Documentation/video4linux/bttv/CONTRIBUTORS
new file mode 100644
index 000000000000..aef49db8847d
--- /dev/null
+++ b/Documentation/video4linux/bttv/CONTRIBUTORS
@@ -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)
diff --git a/Documentation/video4linux/bttv/Cards b/Documentation/video4linux/bttv/Cards
new file mode 100644
index 000000000000..7f8c7eb70ab2
--- /dev/null
+++ b/Documentation/video4linux/bttv/Cards
@@ -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
+- Bt848A
+- 4 Composite inputs, 1 S-VHS input (shared with 4th composite)
+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
+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
+ 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
+ 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
+ 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)
+ 50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps)
+ 50868 "TV/FM Tuner Pal I" (variant of 50682)
+ 50999 "TV/FM Tuner Secam" (variant of 50682)
+ Maxi-TV PCI (ZR36120)
+ Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM)
+ Maxi TV Video 3 = CPH064 (PAL BG + SECAM)
+ Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote)
+ 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
+ These are CPH series.
+ TV Master = CPH030 or CPH060
+ TV Master FM = CPH050
+ Video Wonder/Genius Internet Video Kit = LR37 Rev.C
+ Video Wonder Pro II (848 or 878) = LR26
+ VideoCap C205 (Bt848)
+ VideoCap C210 (zr36120 +Philips)
+ CaptureTV M200 (ISA)
+ CaptureTV M205 (Bt848)
+Lucky Star
+ Image World Conference TV = LR50 Rev. Q
+ 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?
+ 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
+ TV Karte = LR50 Rev.S
+ TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb"
+ 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
+ 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 ?
+ 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)
+ 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 ?)
+ 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)
+ 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)
+ Multimedia eXtension Board (MXB) (SAA7146, SAA7111)
+ SDM275,SDM250,SDM026,SDM025 (SAA7146, IBMMPEG2): MPEG2 decoder only
+ 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
+ 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 ???)
+ MXR-9565 (=Technisat Mediafocus?)
+ MXR-9571 (Bt848) (=CPH031?)
+ MXR-9575
+ MXR-9577 (Bt878) (=Prolink 878TV Rev.3x)
+ MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E)
+ Buz (zr36067, zr36060, saa7111, saa7185)
+ LML33 (zr36067, zr36060, bt819, bt856)
+ Grand Video Capture (Bt848)
+ Multi Capture Card (Bt878)
+ KW-606 (Bt848)
+ KW-607 (Bt848 capture only)
+ KW-606RSF
+ KW-607A (capture only)
+ KW-608 (Zoran capture only)
+IODATA (jp)
+ GV-VCP/PCI (capture only)
+ GV-VCP2/PCI (capture only)
+Canopus (jp)
+ WinDVR = Kworld "KW-TVL878RF"
+ Sigma Cyber TV II
+ Litte OnAir TV
+ TV/Radio-Tuner Card, PCI (Model 44677) = CPH051
+Sigma Designs
+ Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder
+ iProTV (Card for iMac Mezzanine slot, Bt848+SCSI)
+ ProTV (Bt848)
+ ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono]
+ TV-Wonder
+ TV-Wonder VE
+Diamond Multimedia
+ DTV2000 (Bt848, tda9875)
+ VA1000 Plus (w/ Stereo)
+ VA1000 Lite
+ VA1000 (=LR90)
+ Smart Video Recorder (ISA full-length)
+ Smart Video Recorder pro (ISA half-length)
+ Smart Video Recorder III (Bt848)
+ STB Gateway 6000704 (bt878)
+ STB Gateway 6000699 (bt848)
+ STB Gateway 6000402 (bt848)
+ Captivator Pro/TV (ISA?)
+ Captivator PCI/VC (Bt848 bundled with camera) (capture only)
+ 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)
+ DVB-s (Rev. 2.2, BSRV2-301A, data only?)
+Remote Vision
+ MX RV605 (Bt848 capture only)
+ 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 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
+ many many WinTV models ...
+ WinTV DVBs = Technotrend Premium 1.3
+ WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA"
+ WinTV Nova USB (=Technotrend USB 1.0)
+ WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2)
+ 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 MV-Delta
+ MATRIX-Vision MV-Delta 2
+ MVsigma-SLC (Bt848)
+Conceptronic (.net)
+ TVCON FM, TV card w/ FM = CPH05x
+ TVCON = CPH06x
+ 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
+ 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)
+ 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]
+ Wavewatcher TV (ISA)
+ AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878)
+ WaveWatcher TVR-202 TV/FM Radio Card (ISA)
+ Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK
+ Falcon Series (capture only)
+ In USA: http://www.theimagingsource.com/
+ SKnet Monster TV (saa7134)
+A-Max www.amaxhk.com (Colormax, Amax, Napa)
+ APAC Viewcomp 878
+ CyberMail AV Video Email Kit w/ PCI Capture Card (capture only)
+ CyberMail Xtreme
+ These are Flyvideo
+VCR (http://www.vcrinc.com/)
+ Video Catcher 16
+ 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 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
+ PICOLO series
+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
+ 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)
+ HART Vision 848 (H-ART Vision 848)
+ HART Vision 878 (H-Art Vision 878)
diff --git a/Documentation/video4linux/bttv/ICs b/Documentation/video4linux/bttv/ICs
new file mode 100644
index 000000000000..6b7491336967
--- /dev/null
+++ b/Documentation/video4linux/bttv/ICs
@@ -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
+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
+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?
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options
new file mode 100644
index 000000000000..7bb5a50b0779
--- /dev/null
+++ b/Documentation/video4linux/bttv/Insmod-options
@@ -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 ...
+ 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).
+ 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).
+ 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.
+ 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
+ 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.
diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV
new file mode 100644
index 000000000000..6c29ba43b6c6
--- /dev/null
+++ b/Documentation/video4linux/bttv/MAKEDEV
@@ -0,0 +1,28 @@
+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
diff --git a/Documentation/video4linux/bttv/Modprobe.conf b/Documentation/video4linux/bttv/Modprobe.conf
new file mode 100644
index 000000000000..55f14650d8cd
--- /dev/null
+++ b/Documentation/video4linux/bttv/Modprobe.conf
@@ -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
diff --git a/Documentation/video4linux/bttv/Modules.conf b/Documentation/video4linux/bttv/Modules.conf
new file mode 100644
index 000000000000..753f15956eb8
--- /dev/null
+++ b/Documentation/video4linux/bttv/Modules.conf
@@ -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
diff --git a/Documentation/video4linux/bttv/PROBLEMS b/Documentation/video4linux/bttv/PROBLEMS
new file mode 100644
index 000000000000..8e31e9e36bf7
--- /dev/null
+++ b/Documentation/video4linux/bttv/PROBLEMS
@@ -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
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README
new file mode 100644
index 000000000000..a72f4c94fb0b
--- /dev/null
+++ b/Documentation/video4linux/bttv/README
@@ -0,0 +1,90 @@
+Release notes for bttv
+You'll need at least these config options for bttv:
+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.
+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>
diff --git a/Documentation/video4linux/bttv/README.WINVIEW b/Documentation/video4linux/bttv/README.WINVIEW
new file mode 100644
index 000000000000..c61cf2864287
--- /dev/null
+++ b/Documentation/video4linux/bttv/README.WINVIEW
@@ -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
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze
new file mode 100644
index 000000000000..51f8d4379a94
--- /dev/null
+++ b/Documentation/video4linux/bttv/README.freeze
@@ -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.
+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).
diff --git a/Documentation/video4linux/bttv/README.quirks b/Documentation/video4linux/bttv/README.quirks
new file mode 100644
index 000000000000..e8edb87df711
--- /dev/null
+++ b/Documentation/video4linux/bttv/README.quirks
@@ -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).
+ 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
+430FX Compatibility Mode
+When using the 430FX PCI, the following rules will ensure
+ (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
diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ
new file mode 100644
index 000000000000..b8c9c2605ce2
--- /dev/null
+++ b/Documentation/video4linux/bttv/Sound-FAQ
@@ -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
+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
+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>
diff --git a/Documentation/video4linux/bttv/Specs b/Documentation/video4linux/bttv/Specs
new file mode 100644
index 000000000000..79b9e576fe79
--- /dev/null
+++ b/Documentation/video4linux/bttv/Specs
@@ -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
diff --git a/Documentation/video4linux/bttv/THANKS b/Documentation/video4linux/bttv/THANKS
new file mode 100644
index 000000000000..2085399da7d4
--- /dev/null
+++ b/Documentation/video4linux/bttv/THANKS
@@ -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.
diff --git a/Documentation/video4linux/bttv/Tuners b/Documentation/video4linux/bttv/Tuners
new file mode 100644
index 000000000000..d18fbc70c0e0
--- /dev/null
+++ b/Documentation/video4linux/bttv/Tuners
@@ -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]
+ A= BG+DK
+ B= BG
+ C= I+DK
+ J= NTSC-Japan
+ L= Secam LL
+ M= BG+I+DK
+ [89]: ?
+ [125]:
+ 2: No FM
+ 5: With FM
+ [DP]:
+ 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:
+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)
+(1) conexant100029b-PCI-Decoder-ApplicationNote.pdf
diff --git a/Documentation/video4linux/meye.txt b/Documentation/video4linux/meye.txt
new file mode 100644
index 000000000000..2137da97552f
--- /dev/null
+++ b/Documentation/video4linux/meye.txt
@@ -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˘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
+ 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):
+ 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.
+ 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.
+ 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.
+ 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.
diff --git a/Documentation/video4linux/radiotrack.txt b/Documentation/video4linux/radiotrack.txt
new file mode 100644
index 000000000000..2b75345f13e3
--- /dev/null
+++ b/Documentation/video4linux/radiotrack.txt
@@ -0,0 +1,147 @@
+by Stephen M. Benoit (benoits@servicepro.com) Dec 14, 1996
+Document version 1.0
+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.
+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.
+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.
+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
+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)
diff --git a/Documentation/video4linux/w9966.txt b/Documentation/video4linux/w9966.txt
new file mode 100644
index 000000000000..e7ac33a7eb06
--- /dev/null
+++ b/Documentation/video4linux/w9966.txt
@@ -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.
+ modprobe w9966.o pardev=parport0(or whatever) parmode=0 (0=auto, 1=ecp, 2=epp)
+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
diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt
new file mode 100644
index 000000000000..4af6c52595eb
--- /dev/null
+++ b/Documentation/video4linux/zr36120.txt
@@ -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
+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
+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