diff options
| author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
| commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
| tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/video4linux | |
| download | linux-1da177e4c3f41524e886b7f1b8a0c1fc7321cac2.tar.gz linux-1da177e4c3f41524e886b7f1b8a0c1fc7321cac2.tar.bz2 linux-1da177e4c3f41524e886b7f1b8a0c1fc7321cac2.zip | |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
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 @@ +<HTML><HEAD> +<TITLE>Video4Linux Kernel API Reference v0.1:19990430</TITLE> +</HEAD> +<! Revision History: > +<! 4/30/1999 - Fred Gleason (fredg@wava.com)> +<! Documented extensions for the Radio Data System (RDS) extensions > +<BODY bgcolor="#ffffff"> +<H3>Devices</H3> +Video4Linux provides the following sets of device files. These live on the +character device formerly known as "/dev/bttv". /dev/bttv should be a +symlink to /dev/video0 for most people. +<P> +<TABLE> +<TR><TH>Device Name</TH><TH>Minor Range</TH><TH>Function</TH> +<TR><TD>/dev/video</TD><TD>0-63</TD><TD>Video Capture Interface</TD> +<TR><TD>/dev/radio</TD><TD>64-127</TD><TD>AM/FM Radio Devices</TD> +<TR><TD>/dev/vtx</TD><TD>192-223</TD><TD>Teletext Interface Chips</TD> +<TR><TD>/dev/vbi</TD><TD>224-239</TD><TD>Raw VBI Data (Intercast/teletext)</TD> +</TABLE> +<P> +Video4Linux programs open and scan the devices to find what they are looking +for. Capability queries define what each interface supports. The +described API is only defined for video capture cards. The relevant subset +applies to radio cards. Teletext interfaces talk the existing VTX API. +<P> +<H3>Capability Query Ioctl</H3> +The <B>VIDIOCGCAP</B> ioctl call is used to obtain the capability +information for a video device. The <b>struct video_capability</b> object +passed to the ioctl is completed and returned. It contains the following +information +<P> +<TABLE> +<TR><TD><b>name[32]</b><TD>Canonical name for this interface</TD> +<TR><TD><b>type</b><TD>Type of interface</TD> +<TR><TD><b>channels</b><TD>Number of radio/tv channels if appropriate</TD> +<TR><TD><b>audios</b><TD>Number of audio devices if appropriate</TD> +<TR><TD><b>maxwidth</b><TD>Maximum capture width in pixels</TD> +<TR><TD><b>maxheight</b><TD>Maximum capture height in pixels</TD> +<TR><TD><b>minwidth</b><TD>Minimum capture width in pixels</TD> +<TR><TD><b>minheight</b><TD>Minimum capture height in pixels</TD> +</TABLE> +<P> +The type field lists the capability flags for the device. These are +as follows +<P> +<TABLE> +<TR><TH>Name</TH><TH>Description</TH> +<TR><TD><b>VID_TYPE_CAPTURE</b><TD>Can capture to memory</TD> +<TR><TD><b>VID_TYPE_TUNER</b><TD>Has a tuner of some form</TD> +<TR><TD><b>VID_TYPE_TELETEXT</b><TD>Has teletext capability</TD> +<TR><TD><b>VID_TYPE_OVERLAY</b><TD>Can overlay its image onto the frame buffer</TD> +<TR><TD><b>VID_TYPE_CHROMAKEY</b><TD>Overlay is Chromakeyed</TD> +<TR><TD><b>VID_TYPE_CLIPPING</b><TD>Overlay clipping is supported</TD> +<TR><TD><b>VID_TYPE_FRAMERAM</b><TD>Overlay overwrites frame buffer memory</TD> +<TR><TD><b>VID_TYPE_SCALES</b><TD>The hardware supports image scaling</TD> +<TR><TD><b>VID_TYPE_MONOCHROME</b><TD>Image capture is grey scale only</TD> +<TR><TD><b>VID_TYPE_SUBCAPTURE</b><TD>Capture can be of only part of the image</TD> +</TABLE> +<P> +The minimum and maximum sizes listed for a capture device do not imply all +that all height/width ratios or sizes within the range are possible. A +request to set a size will be honoured by the largest available capture +size whose capture is no large than the requested rectangle in either +direction. For example the quickcam has 3 fixed settings. +<P> +<H3>Frame Buffer</H3> +Capture cards that drop data directly onto the frame buffer must be told the +base address of the frame buffer, its size and organisation. This is a +privileged ioctl and one that eventually X itself should set. +<P> +The <b>VIDIOCSFBUF</b> ioctl sets the frame buffer parameters for a capture +card. If the card does not do direct writes to the frame buffer then this +ioctl will be unsupported. The <b>VIDIOCGFBUF</b> ioctl returns the +currently used parameters. The structure used in both cases is a +<b>struct video_buffer</b>. +<P> +<TABLE> +<TR><TD><b>void *base</b></TD><TD>Base physical address of the buffer</TD> +<TR><TD><b>int height</b></TD><TD>Height of the frame buffer</TD> +<TR><TD><b>int width</b></TD><TD>Width of the frame buffer</TD> +<TR><TD><b>int depth</b></TD><TD>Depth of the frame buffer</TD> +<TR><TD><b>int bytesperline</b></TD><TD>Number of bytes of memory between the start of two adjacent lines</TD> +</TABLE> +<P> +Note that these values reflect the physical layout of the frame buffer. +The visible area may be smaller. In fact under XFree86 this is commonly the +case. XFree86 DGA can provide the parameters required to set up this ioctl. +Setting the base address to NULL indicates there is no physical frame buffer +access. +<P> +<H3>Capture Windows</H3> +The capture area is described by a <b>struct video_window</b>. This defines +a capture area and the clipping information if relevant. The +<b>VIDIOCGWIN</b> ioctl recovers the current settings and the +<b>VIDIOCSWIN</b> sets new values. A successful call to <b>VIDIOCSWIN</b> +indicates that a suitable set of parameters have been chosen. They do not +indicate that exactly what was requested was granted. The program should +call <b>VIDIOCGWIN</b> to check if the nearest match was suitable. The +<b>struct video_window</b> contains the following fields. +<P> +<TABLE> +<TR><TD><b>x</b><TD>The X co-ordinate specified in X windows format.</TD> +<TR><TD><b>y</b><TD>The Y co-ordinate specified in X windows format.</TD> +<TR><TD><b>width</b><TD>The width of the image capture.</TD> +<TR><TD><b>height</b><TD>The height of the image capture.</TD> +<TR><TD><b>chromakey</b><TD>A host order RGB32 value for the chroma key.</TD> +<TR><TD><b>flags</b><TD>Additional capture flags.</TD> +<TR><TD><b>clips</b><TD>A list of clipping rectangles. <em>(Set only)</em></TD> +<TR><TD><b>clipcount</b><TD>The number of clipping rectangles. <em>(Set only)</em></TD> +</TABLE> +<P> +Clipping rectangles are passed as an array. Each clip consists of the following +fields available to the user. +<P> +<TABLE> +<TR><TD><b>x</b></TD><TD>X co-ordinate of rectangle to skip</TD> +<TR><TD><b>y</b></TD><TD>Y co-ordinate of rectangle to skip</TD> +<TR><TD><b>width</b></TD><TD>Width of rectangle to skip</TD> +<TR><TD><b>height</b></TD><TD>Height of rectangle to skip</TD> +</TABLE> +<P> +Merely setting the window does not enable capturing. Overlay capturing +(i.e. PCI-PCI transfer to the frame buffer of the video card) +is activated by passing the <b>VIDIOCCAPTURE</b> ioctl a value of 1, and +disabled by passing it a value of 0. +<P> +Some capture devices can capture a subfield of the image they actually see. +This is indicated when VIDEO_TYPE_SUBCAPTURE is defined. +The video_capture describes the time and special subfields to capture. +The video_capture structure contains the following fields. +<P> +<TABLE> +<TR><TD><b>x</b></TD><TD>X co-ordinate of source rectangle to grab</TD> +<TR><TD><b>y</b></TD><TD>Y co-ordinate of source rectangle to grab</TD> +<TR><TD><b>width</b></TD><TD>Width of source rectangle to grab</TD> +<TR><TD><b>height</b></TD><TD>Height of source rectangle to grab</TD> +<TR><TD><b>decimation</b></TD><TD>Decimation to apply</TD> +<TR><TD><b>flags</b></TD><TD>Flag settings for grabbing</TD> +</TABLE> +The available flags are +<P> +<TABLE> +<TR><TH>Name</TH><TH>Description</TH> +<TR><TD><b>VIDEO_CAPTURE_ODD</b><TD>Capture only odd frames</TD> +<TR><TD><b>VIDEO_CAPTURE_EVEN</b><TD>Capture only even frames</TD> +</TABLE> +<P> +<H3>Video Sources</H3> +Each video4linux video or audio device captures from one or more +source <b>channels</b>. Each channel can be queries with the +<b>VDIOCGCHAN</b> ioctl call. Before invoking this function the caller +must set the channel field to the channel that is being queried. On return +the <b>struct video_channel</b> is filled in with information about the +nature of the channel itself. +<P> +The <b>VIDIOCSCHAN</b> ioctl takes an integer argument and switches the +capture to this input. It is not defined whether parameters such as colour +settings or tuning are maintained across a channel switch. The caller should +maintain settings as desired for each channel. (This is reasonable as +different video inputs may have different properties). +<P> +The <b>struct video_channel</b> consists of the following +<P> +<TABLE> +<TR><TD><b>channel</b></TD><TD>The channel number</TD> +<TR><TD><b>name</b></TD><TD>The input name - preferably reflecting the label +on the card input itself</TD> +<TR><TD><b>tuners</b></TD><TD>Number of tuners for this input</TD> +<TR><TD><b>flags</b></TD><TD>Properties the tuner has</TD> +<TR><TD><b>type</b></TD><TD>Input type (if known)</TD> +<TR><TD><b>norm</b><TD>The norm for this channel</TD> +</TABLE> +<P> +The flags defined are +<P> +<TABLE> +<TR><TD><b>VIDEO_VC_TUNER</b><TD>Channel has tuners.</TD> +<TR><TD><b>VIDEO_VC_AUDIO</b><TD>Channel has audio.</TD> +<TR><TD><b>VIDEO_VC_NORM</b><TD>Channel has norm setting.</TD> +</TABLE> +<P> +The types defined are +<P> +<TABLE> +<TR><TD><b>VIDEO_TYPE_TV</b><TD>The input is a TV input.</TD> +<TR><TD><b>VIDEO_TYPE_CAMERA</b><TD>The input is a camera.</TD> +</TABLE> +<P> +<H3>Image Properties</H3> +The image properties of the picture can be queried with the <b>VIDIOCGPICT</b> +ioctl which fills in a <b>struct video_picture</b>. The <b>VIDIOCSPICT</b> +ioctl allows values to be changed. All values except for the palette type +are scaled between 0-65535. +<P> +The <b>struct video_picture</b> consists of the following fields +<P> +<TABLE> +<TR><TD><b>brightness</b><TD>Picture brightness</TD> +<TR><TD><b>hue</b><TD>Picture hue (colour only)</TD> +<TR><TD><b>colour</b><TD>Picture colour (colour only)</TD> +<TR><TD><b>contrast</b><TD>Picture contrast</TD> +<TR><TD><b>whiteness</b><TD>The whiteness (greyscale only)</TD> +<TR><TD><b>depth</b><TD>The capture depth (may need to match the frame buffer depth)</TD> +<TR><TD><b>palette</b><TD>Reports the palette that should be used for this image</TD> +</TABLE> +<P> +The following palettes are defined +<P> +<TABLE> +<TR><TD><b>VIDEO_PALETTE_GREY</b><TD>Linear intensity grey scale (255 is brightest).</TD> +<TR><TD><b>VIDEO_PALETTE_HI240</b><TD>The BT848 8bit colour cube.</TD> +<TR><TD><b>VIDEO_PALETTE_RGB565</b><TD>RGB565 packed into 16 bit words.</TD> +<TR><TD><b>VIDEO_PALETTE_RGB555</b><TD>RGV555 packed into 16 bit words, top bit undefined.</TD> +<TR><TD><b>VIDEO_PALETTE_RGB24</b><TD>RGB888 packed into 24bit words.</TD> +<TR><TD><b>VIDEO_PALETTE_RGB32</b><TD>RGB888 packed into the low 3 bytes of 32bit words. The top 8bits are undefined.</TD> +<TR><TD><b>VIDEO_PALETTE_YUV422</b><TD>Video style YUV422 - 8bits packed 4bits Y 2bits U 2bits V</TD> +<TR><TD><b>VIDEO_PALETTE_YUYV</b><TD>Describe me</TD> +<TR><TD><b>VIDEO_PALETTE_UYVY</b><TD>Describe me</TD> +<TR><TD><b>VIDEO_PALETTE_YUV420</b><TD>YUV420 capture</TD> +<TR><TD><b>VIDEO_PALETTE_YUV411</b><TD>YUV411 capture</TD> +<TR><TD><b>VIDEO_PALETTE_RAW</b><TD>RAW capture (BT848)</TD> +<TR><TD><b>VIDEO_PALETTE_YUV422P</b><TD>YUV 4:2:2 Planar</TD> +<TR><TD><b>VIDEO_PALETTE_YUV411P</b><TD>YUV 4:1:1 Planar</TD> +</TABLE> +<P> +<H3>Tuning</H3> +Each video input channel can have one or more tuners associated with it. Many +devices will not have tuners. TV cards and radio cards will have one or more +tuners attached. +<P> +Tuners are described by a <b>struct video_tuner</b> which can be obtained by +the <b>VIDIOCGTUNER</b> ioctl. Fill in the tuner number in the structure +then pass the structure to the ioctl to have the data filled in. The +tuner can be switched using <b>VIDIOCSTUNER</b> which takes an integer argument +giving the tuner to use. A struct tuner has the following fields +<P> +<TABLE> +<TR><TD><b>tuner</b><TD>Number of the tuner</TD> +<TR><TD><b>name</b><TD>Canonical name for this tuner (eg FM/AM/TV)</TD> +<TR><TD><b>rangelow</b><TD>Lowest tunable frequency</TD> +<TR><TD><b>rangehigh</b><TD>Highest tunable frequency</TD> +<TR><TD><b>flags</b><TD>Flags describing the tuner</TD> +<TR><TD><b>mode</b><TD>The video signal mode if relevant</TD> +<TR><TD><b>signal</b><TD>Signal strength if known - between 0-65535</TD> +</TABLE> +<P> +The following flags exist +<P> +<TABLE> +<TR><TD><b>VIDEO_TUNER_PAL</b><TD>PAL tuning is supported</TD> +<TR><TD><b>VIDEO_TUNER_NTSC</b><TD>NTSC tuning is supported</TD> +<TR><TD><b>VIDEO_TUNER_SECAM</b><TD>SECAM tuning is supported</TD> +<TR><TD><b>VIDEO_TUNER_LOW</b><TD>Frequency is in a lower range</TD> +<TR><TD><b>VIDEO_TUNER_NORM</b><TD>The norm for this tuner is settable</TD> +<TR><TD><b>VIDEO_TUNER_STEREO_ON</b><TD>The tuner is seeing stereo audio</TD> +<TR><TD><b>VIDEO_TUNER_RDS_ON</b><TD>The tuner is seeing a RDS datastream</TD> +<TR><TD><b>VIDEO_TUNER_MBS_ON</b><TD>The tuner is seeing a MBS datastream</TD> +</TABLE> +<P> +The following modes are defined +<P> +<TABLE> +<TR><TD><b>VIDEO_MODE_PAL</b><TD>The tuner is in PAL mode</TD> +<TR><TD><b>VIDEO_MODE_NTSC</b><TD>The tuner is in NTSC mode</TD> +<TR><TD><b>VIDEO_MODE_SECAM</b><TD>The tuner is in SECAM mode</TD> +<TR><TD><b>VIDEO_MODE_AUTO</b><TD>The tuner auto switches, or mode does not apply</TD> +</TABLE> +<P> +Tuning frequencies are an unsigned 32bit value in 1/16th MHz or if the +<b>VIDEO_TUNER_LOW</b> flag is set they are in 1/16th KHz. The current +frequency is obtained as an unsigned long via the <b>VIDIOCGFREQ</b> ioctl and +set by the <b>VIDIOCSFREQ</b> ioctl. +<P> +<H3>Audio</H3> +TV and Radio devices have one or more audio inputs that may be selected. +The audio properties are queried by passing a <b>struct video_audio</b> to <b>VIDIOCGAUDIO</b> ioctl. The +<b>VIDIOCSAUDIO</b> ioctl sets audio properties. +<P> +The structure contains the following fields +<P> +<TABLE> +<TR><TD><b>audio</b><TD>The channel number</TD> +<TR><TD><b>volume</b><TD>The volume level</TD> +<TR><TD><b>bass</b><TD>The bass level</TD> +<TR><TD><b>treble</b><TD>The treble level</TD> +<TR><TD><b>flags</b><TD>Flags describing the audio channel</TD> +<TR><TD><b>name</b><TD>Canonical name for the audio input</TD> +<TR><TD><b>mode</b><TD>The mode the audio input is in</TD> +<TR><TD><b>balance</b><TD>The left/right balance</TD> +<TR><TD><b>step</b><TD>Actual step used by the hardware</TD> +</TABLE> +<P> +The following flags are defined +<P> +<TABLE> +<TR><TD><b>VIDEO_AUDIO_MUTE</b><TD>The audio is muted</TD> +<TR><TD><b>VIDEO_AUDIO_MUTABLE</b><TD>Audio muting is supported</TD> +<TR><TD><b>VIDEO_AUDIO_VOLUME</b><TD>The volume is controllable</TD> +<TR><TD><b>VIDEO_AUDIO_BASS</b><TD>The bass is controllable</TD> +<TR><TD><b>VIDEO_AUDIO_TREBLE</b><TD>The treble is controllable</TD> +<TR><TD><b>VIDEO_AUDIO_BALANCE</b><TD>The balance is controllable</TD> +</TABLE> +<P> +The following decoding modes are defined +<P> +<TABLE> +<TR><TD><b>VIDEO_SOUND_MONO</b><TD>Mono signal</TD> +<TR><TD><b>VIDEO_SOUND_STEREO</b><TD>Stereo signal (NICAM for TV)</TD> +<TR><TD><b>VIDEO_SOUND_LANG1</b><TD>European TV alternate language 1</TD> +<TR><TD><b>VIDEO_SOUND_LANG2</b><TD>European TV alternate language 2</TD> +</TABLE> +<P> +<H3>Reading Images</H3> +Each call to the <b>read</b> syscall returns the next available image +from the device. It is up to the caller to set format and size (using +the VIDIOCSPICT and VIDIOCSWIN ioctls) and then to pass a suitable +size buffer and length to the function. Not all devices will support +read operations. +<P> +A second way to handle image capture is via the mmap interface if supported. +To use the mmap interface a user first sets the desired image size and depth +properties. Next the VIDIOCGMBUF ioctl is issued. This reports the size +of buffer to mmap and the offset within the buffer for each frame. The +number of frames supported is device dependent and may only be one. +<P> +The video_mbuf structure contains the following fields +<P> +<TABLE> +<TR><TD><b>size</b><TD>The number of bytes to map</TD> +<TR><TD><b>frames</b><TD>The number of frames</TD> +<TR><TD><b>offsets</b><TD>The offset of each frame</TD> +</TABLE> +<P> +Once the mmap has been made the VIDIOCMCAPTURE ioctl starts the +capture to a frame using the format and image size specified in the +video_mmap (which should match or be below the initial query size). +When the VIDIOCMCAPTURE ioctl returns the frame is <em>not</em> +captured yet, the driver just instructed the hardware to start the +capture. The application has to use the VIDIOCSYNC ioctl to wait +until the capture of a frame is finished. VIDIOCSYNC takes the frame +number you want to wait for as argument. +<p> +It is allowed to call VIDIOCMCAPTURE multiple times (with different +frame numbers in video_mmap->frame of course) and thus have multiple +outstanding capture requests. A simple way do to double-buffering +using this feature looks like this: +<pre> +/* setup everything */ +VIDIOCMCAPTURE(0) +while (whatever) { + VIDIOCMCAPTURE(1) + VIDIOCSYNC(0) + /* process frame 0 while the hardware captures frame 1 */ + VIDIOCMCAPTURE(0) + VIDIOCSYNC(1) + /* process frame 1 while the hardware captures frame 0 */ +} +</pre> +Note that you are <em>not</em> limited to only two frames. The API +allows up to 32 frames, the VIDIOCGMBUF ioctl returns the number of +frames the driver granted. Thus it is possible to build deeper queues +to avoid loosing frames on load peaks. +<p> +While capturing to memory the driver will make a "best effort" attempt +to capture to screen as well if requested. This normally means all +frames that "miss" memory mapped capture will go to the display. +<P> +A final ioctl exists to allow a device to obtain related devices if a +driver has multiple components (for example video0 may not be associated +with vbi0 which would cause an intercast display program to make a bad +mistake). The VIDIOCGUNIT ioctl reports the unit numbers of the associated +devices if any exist. The video_unit structure has the following fields. +<P> +<TABLE> +<TR><TD><b>video</b><TD>Video capture device</TD> +<TR><TD><b>vbi</b><TD>VBI capture device</TD> +<TR><TD><b>radio</b><TD>Radio device</TD> +<TR><TD><b>audio</b><TD>Audio mixer</TD> +<TR><TD><b>teletext</b><TD>Teletext device</TD> +</TABLE> +<P> +<H3>RDS Datastreams</H3> +For radio devices that support it, it is possible to receive Radio Data +System (RDS) data by means of a read() on the device. The data is packed in +groups of three, as follows: +<TABLE> +<TR><TD>First Octet</TD><TD>Least Significant Byte of RDS Block</TD></TR> +<TR><TD>Second Octet</TD><TD>Most Significant Byte of RDS Block +<TR><TD>Third Octet</TD><TD>Bit 7:</TD><TD>Error bit. Indicates that +an uncorrectable error occurred during reception of this block.</TD></TR> +<TR><TD> </TD><TD>Bit 6:</TD><TD>Corrected bit. Indicates that +an error was corrected for this data block.</TD></TR> +<TR><TD> </TD><TD>Bits 5-3:</TD><TD>Received Offset. Indicates the +offset received by the sync system.</TD></TR> +<TR><TD> </TD><TD>Bits 2-0:</TD><TD>Offset Name. Indicates the +offset applied to this data.</TD></TR> +</TABLE> +</BODY> +</HTML> 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 @@ + 0 -> UNKNOWN/GENERIC + 1 -> Proteus Pro [philips reference design] [1131:2001,1131:2001] + 2 -> LifeView FlyVIDEO3000 [5168:0138,4e42:0138] + 3 -> LifeView FlyVIDEO2000 [5168:0138] + 4 -> EMPRESS [1131:6752] + 5 -> SKNet Monster TV [1131:4e85] + 6 -> Tevion MD 9717 + 7 -> KNC One TV-Station RDS / Typhoon TV Tuner RDS [1131:fe01,1894:fe01] + 8 -> Terratec Cinergy 400 TV [153B:1142] + 9 -> Medion 5044 + 10 -> Kworld/KuroutoShikou SAA7130-TVPCI + 11 -> Terratec Cinergy 600 TV [153B:1143] + 12 -> Medion 7134 [16be:0003] + 13 -> Typhoon TV+Radio 90031 + 14 -> ELSA EX-VISION 300TV [1048:226b] + 15 -> ELSA EX-VISION 500TV [1048:226b] + 16 -> ASUS TV-FM 7134 [1043:4842,1043:4830,1043:4840] + 17 -> AOPEN VA1000 POWER [1131:7133] + 18 -> BMK MPEX No Tuner + 19 -> Compro VideoMate TV [185b:c100] + 20 -> Matrox CronosPlus [102B:48d0] + 21 -> 10MOONS PCI TV CAPTURE CARD [1131:2001] + 22 -> Medion 2819/ AverMedia M156 [1461:a70b,1461:2115] + 23 -> BMK MPEX Tuner + 24 -> KNC One TV-Station DVR [1894:a006] + 25 -> ASUS TV-FM 7133 [1043:4843] + 26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b] + 27 -> Manli MuchTV M-TV002 + 28 -> Manli MuchTV M-TV001 + 29 -> Nagase Sangyo TransGear 3000TV [1461:050c] + 30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4] + 31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5] + 32 -> AVACS SmartTV + 33 -> AVerMedia DVD EZMaker [1461:10ff] + 34 -> LifeView FlyTV Platinum33 mini [5168:0212] 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 +Quickcam. + +1.1 Motivation + + I spent a number of hours trying to get my camera to work, and I +hope this document saves you some time. My camera will not work with +the 2.2.13 kernel as distributed, but with a few patches to the +module, I was able to grab some frames. See 4.0, Future Work. + + + +2.0 Compilation, Installation, and Configuration + + The c-qcam depends on parallel port support, video4linux, and the +Color Quickcam. It is also nice to have the parallel port readback +support enabled. I enabled these as modules during the kernel +configuration. The appropriate flags are: + + CONFIG_PRINTER M for lp.o, parport.o parport_pc.o modules + CONFIG_PNP_PARPORT M for autoprobe.o IEEE1284 readback module + CONFIG_PRINTER_READBACK M for parport_probe.o IEEE1284 readback module + CONFIG_VIDEO_DEV M for videodev.o video4linux module + CONFIG_VIDEO_CQCAM M for c-qcam.o Color Quickcam module + + With these flags, the kernel should compile and install the modules. +To record and monitor the compilation, I use: + + (make zlilo ; \ + make modules; \ + make modules_install ; + depmod -a ) &>log & + less log # then a capital 'F' to watch the progress + +But that is my personal preference. + +2.2 Configuration + + The configuration requires module configuration and device +configuration. I like kmod or kerneld process with the +/etc/modprobe.conf file so the modules can automatically load/unload as +they are used. The video devices could already exist, be generated +using MAKEDEV, or need to be created. The following sections detail +these procedures. + + +2.1 Module Configuration + + Using modules requires a bit of work to install and pass the +parameters. Understand that entries in /etc/modprobe.conf of: + + alias parport_lowlevel parport_pc + options parport_pc io=0x378 irq=none + alias char-major-81 videodev + alias char-major-81-0 c-qcam + +will cause the kmod/modprobe to do certain things. If you are +using kmod, then a request for a 'char-major-81-0' will cause +the 'c-qcam' module to load. If you have other video sources with +modules, you might want to assign the different minor numbers to +different modules. + +2.2 Device Configuration + + At this point, we need to ensure that the device files exist. +Video4linux used the /dev/video* files, and we want to attach the +Quickcam to one of these. + + ls -lad /dev/video* # should produce a list of the video devices + +If the video devices do not exist, you can create them with: + + su + cd /dev + for ii in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do + mknod video$ii c 81 $ii # char-major-81-[0-16] + chown root.root video$ii # owned by root + chmod 600 video$ii # read/writable by root only + done + + Lots of people connect video0 to video and bttv, but you might want +your c-qcam to mean something more: + + ln -s video0 c-qcam # make /dev/c-qcam a working file + ln -s c-qcam video # make /dev/c-qcam your default video source + + But these are conveniences. The important part is to make the proper +special character files with the right major and minor numbers. All +of the special device files are listed in ../devices.txt. If you +would like the c-qcam readable by non-root users, you will need to +change the permissions. + +3.0 Troubleshooting + + If the sample program below, v4lgrab, gives you output then +everything is working. + + v4lgrab | wc # should give you a count of characters + + Otherwise, you have some problem. + + The c-qcam is IEEE1284 compatible, so if you are using the proc file +system (CONFIG_PROC_FS), the parallel printer support +(CONFIG_PRINTER), the IEEE 1284 system,(CONFIG_PRINTER_READBACK), you +should be able to read some identification from your quickcam with + + modprobe -v parport + modprobe -v parport_probe + cat /proc/parport/PORTNUMBER/autoprobe +Returns: + CLASS:MEDIA; + MODEL:Color QuickCam 2.0; + MANUFACTURER:Connectix; + + A good response to this indicates that your color quickcam is alive +and well. A common problem is that the current driver does not +reliably detect a c-qcam, even though one is attached. In this case, + + modprobe -v c-qcam +or + insmod -v c-qcam + + Returns a message saying "Device or resource busy" Development is +currently underway, but a workaround is to patch the module to skip +the detection code and attach to a defined port. Check the +video4linux mailing list and archive for more current information. + +3.1 Checklist: + + Can you get an image? + v4lgrab >qcam.ppm ; wc qcam.ppm ; xv qcam.ppm + + Is a working c-qcam connected to the port? + grep ^ /proc/parport/?/autoprobe + + Do the /dev/video* files exist? + ls -lad /dev/video + + Is the c-qcam module loaded? + modprobe -v c-qcam ; lsmod + + Does the camera work with alternate programs? cqcam, etc? + + + + +4.0 Future Work / current workarounds + + It is hoped that this section will soon become obsolete, but if it +isn't, you might try patching the c-qcam module to add a parport=xxx +option as in the bw-qcam module so you can specify the parallel port: + + insmod -v c-qcam parport=0 + +And bypass the detection code, see ../../drivers/char/c-qcam.c and +look for the 'qc_detect' code and call. + + Note that there is work in progress to change the video4linux API, +this work is documented at the video4linux2 site listed below. + + +9.0 --- A sample program using v4lgrabber, + +This program is a simple image grabber that will copy a frame from the +first video device, /dev/video0 to standard output in portable pixmap +format (.ppm) Using this like: 'v4lgrab | convert - c-qcam.jpg' +produced this picture of me at + http://mug.sys.virginia.edu/~drf5n/extras/c-qcam.jpg + +-------------------- 8< ---------------- 8< ----------------------------- + +/* Simple Video4Linux image grabber. */ +/* + * Video4Linux Driver Test/Example Framegrabbing Program + * + * Compile with: + * gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab + * Use as: + * v4lgrab >image.ppm + * + * Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org> + * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c + * with minor modifications (Dave Forrest, drf5n@virginia.edu). + * + */ + +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <stdio.h> +#include <sys/ioctl.h> +#include <stdlib.h> + +#include <linux/types.h> +#include <linux/videodev.h> + +#define FILE "/dev/video0" + +/* Stole this from tvset.c */ + +#define READ_VIDEO_PIXEL(buf, format, depth, r, g, b) \ +{ \ + switch (format) \ + { \ + case VIDEO_PALETTE_GREY: \ + switch (depth) \ + { \ + case 4: \ + case 6: \ + case 8: \ + (r) = (g) = (b) = (*buf++ << 8);\ + break; \ + \ + case 16: \ + (r) = (g) = (b) = \ + *((unsigned short *) buf); \ + buf += 2; \ + break; \ + } \ + break; \ + \ + \ + case VIDEO_PALETTE_RGB565: \ + { \ + unsigned short tmp = *(unsigned short *)buf; \ + (r) = tmp&0xF800; \ + (g) = (tmp<<5)&0xFC00; \ + (b) = (tmp<<11)&0xF800; \ + buf += 2; \ + } \ + break; \ + \ + case VIDEO_PALETTE_RGB555: \ + (r) = (buf[0]&0xF8)<<8; \ + (g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8; \ + (b) = ((buf[1] << 2 ) & 0xF8)<<8; \ + buf += 2; \ + break; \ + \ + case VIDEO_PALETTE_RGB24: \ + (r) = buf[0] << 8; (g) = buf[1] << 8; \ + (b) = buf[2] << 8; \ + buf += 3; \ + break; \ + \ + default: \ + fprintf(stderr, \ + "Format %d not yet supported\n", \ + format); \ + } \ +} + +int get_brightness_adj(unsigned char *image, long size, int *brightness) { + long i, tot = 0; + for (i=0;i<size*3;i++) + tot += image[i]; + *brightness = (128 - tot/(size*3))/3; + return !((tot/(size*3)) >= 126 && (tot/(size*3)) <= 130); +} + +int main(int argc, char ** argv) +{ + int fd = open(FILE, O_RDONLY), f; + struct video_capability cap; + struct video_window win; + struct video_picture vpic; + + unsigned char *buffer, *src; + int bpp = 24, r, g, b; + unsigned int i, src_depth; + + if (fd < 0) { + perror(FILE); + exit(1); + } + + if (ioctl(fd, VIDIOCGCAP, &cap) < 0) { + perror("VIDIOGCAP"); + fprintf(stderr, "(" FILE " not a video4linux device?)\n"); + close(fd); + exit(1); + } + + if (ioctl(fd, VIDIOCGWIN, &win) < 0) { + perror("VIDIOCGWIN"); + close(fd); + exit(1); + } + + if (ioctl(fd, VIDIOCGPICT, &vpic) < 0) { + perror("VIDIOCGPICT"); + close(fd); + exit(1); + } + + if (cap.type & VID_TYPE_MONOCHROME) { + vpic.depth=8; + vpic.palette=VIDEO_PALETTE_GREY; /* 8bit grey */ + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + vpic.depth=6; + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + vpic.depth=4; + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + fprintf(stderr, "Unable to find a supported capture format.\n"); + close(fd); + exit(1); + } + } + } + } else { + vpic.depth=24; + vpic.palette=VIDEO_PALETTE_RGB24; + + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + vpic.palette=VIDEO_PALETTE_RGB565; + vpic.depth=16; + + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { + vpic.palette=VIDEO_PALETTE_RGB555; + vpic.depth=15; + + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { + fprintf(stderr, "Unable to find a supported capture format.\n"); + return -1; + } + } + } + } + + buffer = malloc(win.width * win.height * bpp); + if (!buffer) { + fprintf(stderr, "Out of memory.\n"); + exit(1); + } + + do { + int newbright; + read(fd, buffer, win.width * win.height * bpp); + f = get_brightness_adj(buffer, win.width * win.height, &newbright); + if (f) { + vpic.brightness += (newbright << 8); + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { + perror("VIDIOSPICT"); + break; + } + } + } while (f); + + fprintf(stdout, "P6\n%d %d 255\n", win.width, win.height); + + src = buffer; + + for (i = 0; i < win.width * win.height; i++) { + READ_VIDEO_PIXEL(src, vpic.palette, src_depth, r, g, b); + fputc(r>>8, stdout); + fputc(g>>8, stdout); + fputc(b>>8, stdout); + } + + close(fd); + return 0; +} +-------------------- 8< ---------------- 8< ----------------------------- + + +10.0 --- Other Information + +Use the ../../Maintainers file, particularly the VIDEO FOR LINUX and PARALLEL +PORT SUPPORT sections + +The video4linux page: + http://roadrunner.swansea.linux.org.uk/v4l.shtml + +The video4linux2 page: + http://millennium.diads.com/bdirks/v4l2.htm + +Some web pages about the quickcams: + http://www.dkfz-heidelberg.de/Macromol/wedemann/mini-HOWTO-cqcam.html + + http://www.crynwr.com/qcpc/ QuickCam Third-Party Drivers + http://www.crynwr.com/qcpc/re.html Some Reverse Engineering + http://cse.unl.edu/~cluening/gqcam/ v4l client + http://phobos.illtel.denver.co.us/pub/qcread/ doesn't use v4l + ftp://ftp.cs.unm.edu/pub/chris/quickcam/ Has lots of drivers + http://www.cs.duke.edu/~reynolds/quickcam/ Has lots of information + + 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 + +--------------------------------------------------------------------------- + +USAGE: + +General: +======== + +1) Make sure you have created the video devices (/dev/video*): + +- if you have a recent MAKEDEV do a 'cd /dev;./MAKEDEV video' +- otherwise do a: + +cd /dev +mknod video0 c 81 0 +ln -s video0 video + +2) Compile the kernel (see below for the list of options to use), + configure your parport and reboot. + +3) If all worked well you should get messages similar + to the following (your versions may be different) on the console: + +V4L-Driver for Vision CPiA based cameras v0.7.4 +parport0: read2 timeout. +parport0: Multimedia device, VLSI Vision Ltd PPC2 +Parallel port driver for Vision CPiA based camera + CPIA Version: 1.20 (2.0) + CPIA PnP-ID: 0553:0002:0100 + VP-Version: 1.0 0100 + 1 camera(s) found + + +As modules: +=========== + +Make sure you have selected the following kernel options (you can +select all stuff as modules): + +The cpia-stuff is in the section 'Character devices -> Video For Linux'. + +CONFIG_PARPORT=m +CONFIG_PARPORT_PC=m +CONFIG_PARPORT_PC_FIFO=y +CONFIG_PARPORT_1284=y +CONFIG_VIDEO_DEV=m +CONFIG_VIDEO_CPIA=m +CONFIG_VIDEO_CPIA_PP=m + +For autoloading of all those modules you need to tell module-init-tools +some stuff. Add the following line to your module-init-tools config-file +(e.g. /etc/modprobe.conf or wherever your distribution does store that +stuff): + +options parport_pc io=0x378 irq=7 dma=3 +alias char-major-81 cpia_pp + +The first line tells the dma/irq channels to use. Those _must_ match +the settings of your BIOS. Do NOT simply use the values above. See +Documentation/parport.txt for more information about this. The second +line associates the video-device file with the driver. Of cause you +can also load the modules once upon boot (usually done in /etc/modules). + +Linked into the kernel: +======================= + +Make sure you have selected the following kernel options. Note that +you cannot compile the parport-stuff as modules and the cpia-driver +statically (the other way round is okay though). + +The cpia-stuff is in the section 'Character devices -> Video For Linux'. + +CONFIG_PARPORT=y +CONFIG_PARPORT_PC=y +CONFIG_PARPORT_PC_FIFO=y +CONFIG_PARPORT_1284=y +CONFIG_VIDEO_DEV=y +CONFIG_VIDEO_CPIA=y +CONFIG_VIDEO_CPIA_PP=y + +To use DMA/irq you will need to tell the kernel upon boot time the +hardware configuration of the parport. You can give the boot-parameter +at the LILO-prompt or specify it in lilo.conf. I use the following +append-line in lilo.conf: + + append="parport=0x378,7,3" + +See Documentation/parport.txt for more information about the +configuration of the parport and the values given above. Do not simply +use the values given above. + +--------------------------------------------------------------------------- +FEATURES: + +- mmap/read v4l-interface (but no overlay) +- image formats: CIF/QCIF, SIF/QSIF, various others used by isabel; + note: all sizes except CIF/QCIF are implemented by clipping, i.e. + pixels are not uploaded from the camera +- palettes: VIDEO_PALETTE_GRAY, VIDEO_PALETTE_RGB565, VIDEO_PALETTE_RGB555, + VIDEO_PALETTE_RGB24, VIDEO_PALETTE_RGB32, VIDEO_PALETTE_YUYV, + VIDEO_PALETTE_UYVY, VIDEO_PALETTE_YUV422 +- state information (color balance, exposure, ...) is preserved between + device opens +- complete control over camera via proc-interface (_all_ camera settings are + supported), there is also a python-gtk application available for this [3] +- works under SMP (but the driver is completely serialized and synchronous) + so you get no benefit from SMP, but at least it does not crash your box +- might work for non-Intel architecture, let us know about this + +--------------------------------------------------------------------------- +TESTED APPLICATIONS: + +- a simple test application based on Xt is available at [3] +- another test-application based on gqcam-0.4 (uses GTK) +- gqcam-0.6 should work +- xawtv-3.x (also the webcam software) +- xawtv-2.46 +- w3cam (cgi-interface and vidcat, e.g. you may try out 'vidcat |xv + -maxpect -root -quit +noresetroot -rmode 5 -') +- vic, the MBONE video conferencing tool (version 2.8ucl4-1) +- isabel 3R4beta (barely working, but AFAICT all the problems are on + their side) +- camserv-0.40 + +See [3] for pointers to v4l-applications. + +--------------------------------------------------------------------------- +KNOWN PROBLEMS: + +- some applications do not handle the image format correctly, you will + see strange horizontal stripes instead of a nice picture -> make sure + your application does use a supported image size or queries the driver + for the actually used size (reason behind this: the camera cannot + provide any image format, so if size NxM is requested the driver will + use a format to the closest fitting N1xM1, the application should now + query for this granted size, most applications do not). +- all the todo ;) +- if there is not enough light and the picture is too dark try to + adjust the SetSensorFPS setting, automatic frame rate adjustment + has its price +- do not try out isabel 3R4beta (built 135), you will be disappointed + +--------------------------------------------------------------------------- +TODO: + +- multiple camera support (struct camera or something) - This should work, + but hasn't been tested yet. +- architecture independence? +- SMP-safe asynchronous mmap interface +- nibble mode for old parport interfaces +- streaming capture, this should give a performance gain + +--------------------------------------------------------------------------- +IMPLEMENTATION NOTES: + +The camera can act in two modes, streaming or grabbing. Right now a +polling grab-scheme is used. Maybe interrupt driven streaming will be +used for a asynchronous mmap interface in the next major release of the +driver. This might give a better frame rate. + +--------------------------------------------------------------------------- +THANKS (in no particular order): + +- Scott J. Bertin <sbertin@mindspring.com> for cleanups, the proc-filesystem + and much more +- Henry Bruce <whb@vvl.co.uk> for providing developers information about + the CPiA chip, I wish all companies would treat Linux as seriously +- Karoly Erdei <Karoly.Erdei@risc.uni-linz.ac.at> and RISC-Linz for being + my boss ;) resp. my employer and for providing me the hardware and + allow me to devote some working time to this project +- Manuel J. Petit de Gabriel <mpetit@dit.upm.es> for providing help + with Isabel (http://isabel.dit.upm.es/) +- Bas Huisman <bhuism@cs.utwente.nl> for writing the initial parport code +- Jarl Totland <Jarl.Totland@bdc.no> for setting up the mailing list + and maintaining the web-server[3] +- Chris Whiteford <Chris@informinteractive.com> for fixes related to the + 1.02 firmware +- special kudos to all the tester whose machines crashed and/or + will crash. :) + +--------------------------------------------------------------------------- +REFERENCES + + 1. http://www.risc.uni-linz.ac.at/people/ppregler + mailto:Peter_Pregler@email.com + 2. see the file COPYING in the top directory of the kernel tree + 3. http://webcam.sourceforge.net/ 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 +============== + +video + - Basically works. + - Some minor image quality glitches. + - For now only capture, overlay support isn't completed yet. + +audio + - The chip specs for the on-chip TV sound decoder are next + to useless :-/ + - Neverless the builtin TV sound decoder starts working now, + at least for PAL-BG. Other TV norms need other code ... + FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE + USING. + - Most tuner chips do provide mono sound, which may or may not + be useable depending on the board design. With the Hauppauge + cards it works, so there is mono sound available as fallback. + - audio data dma (i.e. recording without loopback cable to the + sound card) should be possible, but there is no code yet ... + +vbi + - some code present. Doesn't crash any more, but also doesn't + work yet ... + + +how to add support for new cards +================================ + +The driver needs some config info for the TV cards. This stuff is in +cx88-cards.c. If the driver doesn't work well you likely need a new +entry for your card in that file. Check the kernel log (using dmesg) +to see whenever the driver knows your card or not. There is a line +like this one: + + cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \ + 34xxx models [card=1,autodetected] + +If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to +the driver. What to do then? + + (1) Try upgrading to the latest snapshot, maybe it has been added + meanwhile. + (2) You can try to create a new entry yourself, have a look at + cx88-cards.c. If that worked, mail me your changes as unified + diff ("diff -u"). + (3) Or you can mail me the config information. I need at least the + following informations to add the card: + + * the PCI Subsystem ID ("0070:3400" from the line above, + "lspci -v" output is fine too). + * the tuner type used by the card. You can try to find one by + trial-and-error using the tuner=<n> insmod option. If you + know which one the card has you can also have a look at the + list in CARDLIST.tuner + +Have fun, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> [SuSE Labs] 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 +====================================================== + + +basics +------ + +Current versions use the linux input layer to support infrared +remote controls. I suggest to download my input layer tools +from http://bytesex.org/snapshot/input-<date>.tar.gz + +Modules you have to load: + + saa7134 statically built in, i.e. just the driver :) + bttv ir-kbd-gpio or ir-kbd-i2c depending on your + card. + +ir-kbd-gpio and ir-kbd-i2c don't support all cards lirc supports +(yet), mainly for the reason that the code of lirc_i2c and lirc_gpio +was very confusing and I decided to basically start over from scratch. +Feel free to contact me in case of trouble. Note that the ir-kbd-* +modules work on 2.6.x kernels only through ... + + +how it works +------------ + +The modules register the remote as keyboard within the linux input +layer, i.e. you'll see the keys of the remote as normal key strokes +(if CONFIG_INPUT_KEYBOARD is enabled). + +Using the event devices (CONFIG_INPUT_EVDEV) it is possible for +applications to access the remote via /dev/input/event<n> devices. +You might have to create the special files using "/sbin/MAKEDEV +input". The input layer tools mentioned above use the event device. + +The input layer tools are nice for trouble shooting, i.e. to check +whenever the input device is really present, which of the devices it +is, check whenever pressing keys on the remote actually generates +events and the like. You can also use the kbd utility to change the +keymaps (2.6.x kernels only through). + + +using with lircd +================ + +The cvs version of the lircd daemon supports reading events from the +linux input layer (via event device). The input layer tools tarball +comes with a lircd config file. + + +using without lircd +=================== + +XFree86 likely can be configured to recognise the remote keys. Once I +simply tried to configure one of the multimedia keyboards as input +device, which had the effect that XFree86 recognised some of the keys +of my remote control and passed volume up/down key presses as +XF86AudioRaiseVolume and XF86AudioLowerVolume key events to the X11 +clients. + +It likely is possible to make that fly with a nice xkb config file, +I know next to nothing about that through. + + +Have fun, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> 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 +description. + + +Status +====== + +Almost everything is working. video, sound, tuner, radio, mpeg ts, ... + +As with bttv, card-specific tweaks are needed. Check CARDLIST for a +list of known TV cards and saa7134-cards.c for the drivers card +configuration info. + + +Build +===== + +Pick up videodev + v4l2 patches from http://bytesex.org/patches/. +Configure, build, install + boot the new kernel. You'll need at least +these config options: + + CONFIG_I2C=m + CONFIG_VIDEO_DEV=m + +Type "make" to build the driver now. "make install" installs the +driver. "modprobe saa7134" should load it. Depending on the card you +might have to pass card=<nr> as insmod option, check CARDLIST for +valid choices. + + +Changes / Fixes +=============== + +Please mail me unified diffs ("diff -u") with your changes, and don't +forget to tell me what it changes / which problem it fixes / whatever +it is good for ... + + +Known Problems +============== + +* The tuner for the flyvideos isn't detected automatically and the + default might not work for you depending on which version you have. + There is a tuner= insmod option to override the driver's default. + +Card Variations: +================ + +Cards can use either of these two crystals (xtal): + - 32.11 MHz -> .audio_clock=0x187de7 + - 24.576MHz -> .audio_clock=0x200000 +(xtal * .audio_clock = 51539600) + + +Credits +======= + +andrew.stevens@philips.com + werner.leeb@philips.com for providing +saa7134 hardware specs and sample board. + + +Have fun, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> [SuSE Labs] 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: +http://www.sony.jp/ServiceArea/Voltage_map/ +http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/ +and http://www.cabl.com/restaurant/channel.html + +Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly +used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same +as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would +be the same as NTSC 4.43. +NTSC Combs seems to be a decoder mode where the decoder uses a comb filter +to split coma and luma instead of a Delay line. + +But I did not defiantly find out what NTSC Comb is. + +Philips saa7111 TV decoder +was introduced in 1997, is used in the BUZ and +can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM + +Philips saa7110a TV decoder +was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and +can handle: PAL B/G, NTSC M and SECAM + +Philips saa7114 TV decoder +was introduced in 2000, is used in the LML33R10 and +can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM + +Brooktree bt819 TV decoder +was introduced in 1996, and is used in the LML33 and +can handle: PAL B/D/G/H/I, NTSC M + +Micronas vpx3220a TV decoder +was introduced in 1996, is used in the DC30 and DC30+ and +can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb + +=========================== + +1.2 What the TV encoder can do an what not + +The TV encoder are doing the "same" as the decoder, but in the oder direction. +You feed them digital data and the generate a Composite or SVHS signal. +For information about the colorsystems and TV norm take a look in the +TV decoder section. + +Philips saa7185 TV Encoder +was introduced in 1996, is used in the BUZ +can generate: PAL B/G, NTSC M + +Brooktree bt856 TV Encoder +was introduced in 1994, is used in the LML33 +can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina) + +Analog Devices adv7170 TV Encoder +was introduced in 2000, is used in the LML300R10 +can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60 + +Analog Devices adv7175 TV Encoder +was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+ +can generate: PAL B/D/G/H/I/N, PAL M, NTSC M + +ITT mse3000 TV encoder +was introduced in 1991, is used in the DC10 old +can generate: PAL , NTSC , SECAM + +The adv717x, should be able to produce PAL N. But you find nothing PAL N +specific in the the registers. Seem that you have to reuse a other standard +to generate PAL N, maybe it would work if you use the PAL M settings. + +========================== + +2. How do I get this damn thing to work + +Load zr36067.o. If it can't autodetect your card, use the card=X insmod +option with X being the card number as given in the previous section. +To have more than one card, use card=X1[,X2[,X3,[X4[..]]]] + +To automate this, add the following to your /etc/modprobe.conf: + +options zr36067 card=X1[,X2[,X3[,X4[..]]]] +alias char-major-81-0 zr36067 + +One thing to keep in mind is that this doesn't load zr36067.o itself yet. It +just automates loading. If you start using xawtv, the device won't load on +some systems, since you're trying to load modules as a user, which is not +allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to +XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in +one of your startup scripts (normally rc.local) if you don't use X. Both +make sure that the modules are loaded on startup, under the root account. + +=========================== + +3. What mainboard should I use (or why doesn't my card work) + +<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA. + +Experience tells us that people with a Buz, on average, have more problems +than users with a DC10+/LML33. Also, it tells us that people owning a VIA- +based mainboard (ktXXX, MVP3) have more problems than users with a mainboard +based on a different chipset. Here's some notes from Andrew Stevens: +-- +Here's my experience of using LML33 and Buz on various motherboards: + +VIA MVP3 + Forget it. Pointless. Doesn't work. +Intel 430FX (Pentium 200) + LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie) +Intel 440BX (early stepping) + LML33 tolerable. Buz starting to get annoying (6-10 frames/hour) +Intel 440BX (late stepping) + Buz tolerable, LML3 almost perfect (occasional single frame drops) +SiS735 + LML33 perfect, Buz tolerable. +VIA KT133(*) + LML33 starting to get annoying, Buz poor enough that I have up. + +Both 440BX boards were dual CPU versions. +-- +Bernhard Praschinger later added: +-- +AMD 751 + Buz perfect-tolerable +AMD 760 + Buz perfect-tolerable +-- +In general, people on the user mailinglist won't give you much of a chance +if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd +rather want to spend some more money on better boards. In general, VIA +mainboard's IDE/PCI performance will also suck badly compared to others. +You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview. +Basically, you can assume that if the Buz works, the LML33 will work too. If +the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to +different mainboard chipsets from all of the supported cards. + +If you experience timeouts during capture, buy a better mainboard or lower +the quality/buffersize during capture (see 'Concerning buffer sizes, quality, +output size etc.'). If it hangs, there's little we can do as of now. Check +your IRQs and make sure the card has its own interrupts. + +=========================== + +4. Programming interface + +This driver conforms to video4linux and video4linux2, both can be used to +use the driver. Since video4linux didn't provide adequate calls to fully +use the cards' features, we've introduced several programming extensions, +which are currently officially accepted in the 2.4.x branch of the kernel. +These extensions are known as the v4l/mjpeg extensions. See zoran.h for +details (structs/ioctls). + +Information - video4linux: +http://roadrunner.swansea.linux.org.uk/v4lapi.shtml +Documentation/video4linux/API.html +/usr/include/linux/videodev.h + +Information - video4linux/mjpeg extensions: +./zoran.h +(also see below) + +Information - video4linux2: +http://www.thedirks.org/v4l2/ +/usr/include/linux/videodev2.h +http://www.bytesex.org/v4l/ + +More information on the video4linux/mjpeg extensions, by Serguei +Miridonovi and Rainer Johanni: +-- +The ioctls for that interface are as follows: + +BUZIOC_G_PARAMS +BUZIOC_S_PARAMS + +Get and set the parameters of the buz. The user should always do a +BUZIOC_G_PARAMS (with a struct buz_params) to obtain the default +settings, change what he likes and then make a BUZIOC_S_PARAMS call. + +BUZIOC_REQBUFS + +Before being able to capture/playback, the user has to request +the buffers he is wanting to use. Fill the structure +zoran_requestbuffers with the size (recommended: 256*1024) and +the number (recommended 32 up to 256). There are no such restrictions +as for the Video for Linux buffers, you should LEAVE SUFFICIENT +MEMORY for your system however, else strange things will happen .... +On return, the zoran_requestbuffers structure contains number and +size of the actually allocated buffers. +You should use these numbers for doing a mmap of the buffers +into the user space. +The BUZIOC_REQBUFS ioctl also makes it happen, that the next mmap +maps the MJPEG buffer instead of the V4L buffers. + +BUZIOC_QBUF_CAPT +BUZIOC_QBUF_PLAY + +Queue a buffer for capture or playback. The first call also starts +streaming capture. When streaming capture is going on, you may +only queue further buffers or issue syncs until streaming +capture is switched off again with a argument of -1 to +a BUZIOC_QBUF_CAPT/BUZIOC_QBUF_PLAY ioctl. + +BUZIOC_SYNC + +Issue this ioctl when all buffers are queued. This ioctl will +block until the first buffer becomes free for saving its +data to disk (after BUZIOC_QBUF_CAPT) or for reuse (after BUZIOC_QBUF_PLAY). + +BUZIOC_G_STATUS + +Get the status of the input lines (video source connected/norm). + +For programming example, please, look at lavrec.c and lavplay.c code in +lavtools-1.2p2 package (URL: http://www.cicese.mx/~mirsev/DC10plus/) +and the 'examples' directory in the original Buz driver distribution. + +Additional notes for software developers: + + The driver returns maxwidth and maxheight parameters according to + the current TV standard (norm). Therefore, the software which + communicates with the driver and "asks" for these parameters should + first set the correct norm. Well, it seems logically correct: TV + standard is "more constant" for current country than geometry + settings of a variety of TV capture cards which may work in ITU or + square pixel format. Remember that users now can lock the norm to + avoid any ambiguity. +-- +Please note that lavplay/lavrec are also included in the MJPEG-tools +(http://mjpeg.sf.net/). + +=========================== + +5. Applications + +Applications known to work with this driver: + +TV viewing: +* xawtv +* kwintv +* probably any TV application that supports video4linux or video4linux2. + +MJPEG capture/playback: +* mjpegtools/lavtools (or Linux Video Studio) +* gstreamer +* mplayer + +General raw capture: +* xawtv +* gstreamer +* probably any application that supports video4linux or video4linux2 + +Video editing: +* Cinelerra +* MainActor +* mjpegtools (or Linux Video Studio) + +=========================== + +6. Concerning buffer sizes, quality, output size etc. + +The zr36060 can do 1:2 JPEG compression. This is really the theoretical +maximum that the chipset can reach. The driver can, however, limit compression +to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz) +can't handle 1:2 compression without stopping capture after only a few minutes. +With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into +1:4 max. compression mode. + +100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame +(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the +fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 = +414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT +(quantization) tables, and you'll get to something like 512kB per frame for +1:2 compression. For 1:4 compression, you'd have frames of half this size. + +Some additional explanation by Martin Samuelsson, which also explains the +importance of buffer sizes: +-- +> Hmm, I do not think it is really that way. With the current (downloaded +> at 18:00 Monday) driver I get that output sizes for 10 sec: +> -q 50 -b 128 : 24.283.332 Bytes +> -q 50 -b 256 : 48.442.368 +> -q 25 -b 128 : 24.655.992 +> -q 25 -b 256 : 25.859.820 + +I woke up, and can't go to sleep again. I'll kill some time explaining why +this doesn't look strange to me. + +Let's do some math using a width of 704 pixels. I'm not sure whether the Buz +actually use that number or not, but that's not too important right now. + +704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block; +3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block; +1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum +output becomes 512 bits per block. Actually 510, but 512 is simpler to use +for calculations. + +Let's say that we specify d1q50. We thus want 256 bits per block; times 3168 +becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes +here, so we don't need to do any fancy corrections for bits-per-pixel or such +things. 101376 bytes per field. + +d1 video contains two fields per frame. Those sum up to 202752 bytes per +frame, and one of those frames goes into each buffer. + +But wait a second! -b128 gives 128kB buffers! It's not possible to cram +202752 bytes of JPEG data into 128kB! + +This is what the driver notice and automatically compensate for in your +examples. Let's do some math using this information: + +128kB is 131072 bytes. In this buffer, we want to store two fields, which +leaves 65536 bytes for each field. Using 3168 blocks per field, we get +20.68686868... available bytes per block; 165 bits. We can't allow the +request for 256 bits per block when there's only 165 bits available! The -q50 +option is silently overridden, and the -b128 option takes precedence, leaving +us with the equivalence of -q32. + +This gives us a data rate of 165 bits per block, which, times 3168, sums up +to 65340 bytes per field, out of the allowed 65536. The current driver has +another level of rate limiting; it won't accept -q values that fill more than +6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be +a safe bet. Personally, I think I would have lowered requested-bits-per-block +by one, or something like that.) We can't use 165 bits per block, but have to +lower it again, to 6/8 of the available buffer space: We end up with 124 bits +per block, the equivalence of -q24. With 128kB buffers, you can't use greater +than -q24 at -d1. (And PAL, and 704 pixels width...) + +The third example is limited to -q24 through the same process. The second +example, using very similar calculations, is limited to -q48. The only +example that actually grab at the specified -q value is the last one, which +is clearly visible, looking at the file size. +-- + +Conclusion: the quality of the resulting movie depends on buffer size, quality, +whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c +module to do 1:4 instead of 1:2 compression, etc. + +If you experience timeouts, lowering the quality/buffersize or using +'low_bitrate=1 as insmod option for zr36060.o might actually help, as is +proven by the Buz. + +=========================== + +7. It hangs/crashes/fails/whatevers! Help! + +Make sure that the card has its own interrupts (see /proc/interrupts), check +the output of dmesg at high verbosity (load zr36067.o with debug=2, +load all other modules with debug=1). Check that your mainboard is favorable +(see question 2) and if not, test the card in another computer. Also see the +notes given in question 3 and try lowering quality/buffersize/capturesize +if recording fails after a period of time. + +If all this doesn't help, give a clear description of the problem including +detailed hardware information (memory+brand, mainboard+chipset+brand, which +MJPEG card, processor, other PCI cards that might be of interest), give the +system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give +the kernel version, driver version, glibc version, gcc version and any other +information that might possibly be of interest. Also provide the dmesg output +at high verbosity. See 'Contacting' on how to contact the developers. + +=========================== + +8. Maintainers/Contacting + +The driver is currently maintained by Laurent Pinchart and Ronald Bultje +(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug +reports or questions, please contact the mailinglist instead of the developers +individually. For user questions (i.e. bug reports or how-to questions), send +an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to +help programming), send an email to <mjpeg-developer@lists.sf.net>. See +http://www.sf.net/projects/mjpeg/ for subscription information. + +For bug reports, be sure to include all the information as described in +the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure +you're using the latest version (http://mjpeg.sf.net/driver-zoran/). + +Previous maintainers/developers of this driver include Serguei Miridonov +<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks +<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>. + +=========================== + +9. License + +This driver is distributed under the terms of the General Public License. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +See http://www.gnu.org/ for more information. 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 +------------- + +MV-Delta +- Bt848A +- 4 Composite inputs, 1 S-VHS input (shared with 4th composite) +- EEPROM + +http://www.matrix-vision.de/ + +This card has no tuner but supports all 4 composite (1 shared with an +S-VHS input) of the Bt848A. +Very nice card if you only have satellite TV but several tuners connected +to the card via composite. + +Many thanks to Matrix-Vision for giving us 2 cards for free which made +Bt848a/Bt849 single crytal operation support possible!!! + + + +Miro/Pinnacle PCTV +------------------ + +- Bt848 + some (all??) come with 2 crystals for PAL/SECAM and NTSC +- PAL, SECAM or NTSC TV tuner (Philips or TEMIC) +- MSP34xx sound decoder on add on board + decoder is supported but AFAIK does not yet work + (other sound MUX setting in GPIO port needed??? somebody who fixed this???) +- 1 tuner, 1 composite and 1 S-VHS input +- tuner type is autodetected + +http://www.miro.de/ +http://www.miro.com/ + + +Many thanks for the free card which made first NTSC support possible back +in 1997! + + +Hauppauge Win/TV pci +-------------------- + +There are many different versions of the Hauppauge cards with different +tuners (TV+Radio ...), teletext decoders. +Note that even cards with same model numbers have (depending on the revision) +different chips on it. + +- Bt848 (and others but always in 2 crystal operation???) + newer cards have a Bt878 +- PAL, SECAM, NTSC or tuner with or without Radio support + +e.g.: + PAL: + TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners + TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3 + + NTSC: + TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners + TSA5518: no datasheet available on Philips site +- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip + with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM) + SAA5246 (I2C 0x22) is supported +- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y + with configuration information + I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf) +- 1 tuner, 1 composite and (depending on model) 1 S-VHS input +- 14052B: mux for selection of sound source +- sound decoder: TDA9800, MSP34xx (stereo cards) + + +Askey CPH-Series +---------------- +Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink) + + Card series: + CPH01x: BT848 capture only + CPH03x: BT848 + CPH05x: BT878 with FM + CPH06x: BT878 (w/o FM) + CPH07x: BT878 capture only + + TV standards: + CPH0x0: NTSC-M/M + CPH0x1: PAL-B/G + CPH0x2: PAL-I/I + CPH0x3: PAL-D/K + CPH0x4: SECAM-L/L + CPH0x5: SECAM-B/G + CPH0x6: SECAM-D/K + CPH0x7: PAL-N/N + CPH0x8: PAL-B/H + CPH0x9: PAL-M/M + + CPH03x was often sold as "TV capturer". + + Identifying: + 1) 878 cards can be identified by PCI Subsystem-ID: + 144f:3000 = CPH06x + 144F:3002 = CPH05x w/ FM + 144F:3005 = CPH06x_LC (w/o remote control) + 1) The cards have a sticker with "CPH"-model on the back. + 2) These cards have a number printed on the PCB just above the tuner metal box: + "80-CP2000300-x" = CPH03X + "80-CP2000500-x" = CPH05X + "80-CP2000600-x" = CPH06X / CPH06x_LC + + Askey sells these cards as "Magic TView series", Brand "MagicXpress". + Other OEM often call these "Tview", "TView99" or else. + +Lifeview Flyvideo Series: +------------------------- + The naming of these series differs in time and space. + + Identifying: + 1) Some models can be identified by PCI subsystem ID: + 1852:1852 = Flyvideo 98 FM + 1851:1850 = Flyvideo 98 + 1851:1851 = Flyvideo 98 EZ (capture only) + 2) There is a print on the PCB: + LR25 = Flyvideo (Zoran ZR36120, SAA7110A) + LR26 Rev.N = Flyvideo II (Bt848) + Rev.O = Flyvideo II (Bt878) + LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110) + LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only) + LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID) + Rev.W = Flyvideo 98 (no eeprom) + LR51 Rev.E = Flyvideo 98 EZ (capture only) + LR90 = Flyvideo 2000 (Bt878) + Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard) + LR91 = Stereo daughter card for LR90 + LR97 = Flyvideo DVBS + LR99 Rev.E = Low profile card for OEM integration (only internal audio!) bt878 + LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134) + LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394) + LR138 Rev.C= Flyvideo 2000 (SAA7130) + or Flyvideo 3000 (SAA7134) w/Stereo TV + These exist in variations w/FM and w/Remote sometimes denoted + by suffixes "FM" and "R". + 3) You have a laptop (miniPCI card): + Product = FlyTV Platinum Mini + Model/Chip = LR212/saa7135 + + Lifeview.com.tw states (Feb. 2002): + "The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98." + Their Bt8x8 cards are listed as discontinued. + Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?). + The new Flyvideo 2000/3000 are SAA7130/SAA7134 based. + + "Flyvideo II" had been the name for the 848 cards, nowadays (in Germany) + this name is re-used for LR50 Rev.W. + The Lifeview website mentioned Flyvideo III at some time, but such a card + has not yet been seen (perhaps it was the german name for LR90 [stereo]). + These cards are sold by many OEMs too. + + FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Germany} + Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134 + + +Typhoon TV card series: +----------------------- + These can be CPH, Flyvideo, Pixelview or KNC1 series. + Typhoon is the brand of Anubis. + Model 50680 got re-used, some model no. had different contents over time. + + Models: + 50680 "TV Tuner PCI Pal BG"(old,red package)=can be CPH03x(bt848) or CPH06x(bt878) + 50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B) + 50681 "TV Tuner PCI Pal I" (variant of 50680) + 50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q) + Note: The package has a picture of CPH05x (which would be a real TView) + 50683 "TV Tuner PCI SECAM" (variant of 50680) + 50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D) + 50686 "TV Tuner" = KNC1 TV Station + 50687 "TV Tuner stereo" = KNC1 TV Station pro + 50688 "TV Tuner RDS" (black package) = KNC1 TV Station RDS + 50689 TV SAT DVB-S CARD CI PCI (SAA7146AH, SU1278?) = "KNC1 TV Station DVB-S" + 50692 "TV/FM Tuner" (small PCB) + 50694 TV TUNER CARD RDS (PHILIPS CHIPSET SAA7134HL) + 50696 TV TUNER STEREO (PHILIPS CHIPSET SAA7134HL, MK3ME Tuner) + 50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps) + 50866 TVIEW SAT RECEIVER+ADR + 50868 "TV/FM Tuner Pal I" (variant of 50682) + 50999 "TV/FM Tuner Secam" (variant of 50682) + + +Guillemot +--------- + Maxi-TV PCI (ZR36120) + Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM) + Maxi TV Video 3 = CPH064 (PAL BG + SECAM) + +Mentor +------ + Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote) + +Prolink +------- + TV cards: + PixelView Play TV pro - (Model: PV-BT878P+ REV 8E) + PixelView Play TV pro - (Model: PV-BT878P+ REV 9D) + PixelView Play TV pro - (Model: PV-BT878P+ REV 4C / 8D / 10A ) + PixelView Play TV - (Model: PV-BT848P+) + 878TV - (Model: PV-BT878TV) + + Multimedia TV packages (card + software pack): + PixelView Play TV Theater - (Model: PV-M4200) = PixelView Play TV pro + Software + PixelView Play TV PAK - (Model: PV-BT878P+ REV 4E) + PixelView Play TV/VCR - (Model: PV-M3200 REV 4C / 8D / 10A ) + PixelView Studio PAK - (Model: M2200 REV 4C / 8D / 10A ) + PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E) + PixelView DigitalVCR PAK - (Model: PV-M2400 REV 4C / 8D / 10A ) + + PixelView PlayTV PAK II (TV/FM card + usb camera) PV-M3800 + PixelView PlayTV XP PV-M4700,PV-M4700(w/FM) + PixelView PlayTV DVR PV-M4600 package contents:PixelView PlayTV pro, windvr & videoMail s/w + + Further Cards: + PV-BT878P+rev.9B (Play TV Pro, opt. w/FM w/NICAM) + PV-BT878P+rev.2F + PV-BT878P Rev.1D (bt878, capture only) + + XCapture PV-CX881P (cx23881) + PlayTV HD PV-CX881PL+, PV-CX881PL+(w/FM) (cx23881) + + DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030 + DTV2000 DVB-S = Twinhan VP-1020 + + Video Conferencing: + PixelView Meeting PAK - (Model: PV-BT878P) + PixelView Meeting PAK Lite - (Model: PV-BT878P) + PixelView Meeting PAK plus - (Model: PV-BT878P+rev 4C/8D/10A) + PixelView Capture - (Model: PV-BT848P) + + PixelView PlayTV USB pro + Model No. PV-NT1004+, PV-NT1004+ (w/FM) = NT1004 USB decoder chip + SAA7113 video decoder chip + +Dynalink +-------- + These are CPH series. + +Phoebemicro +----------- + TV Master = CPH030 or CPH060 + TV Master FM = CPH050 + +Genius/Kye +---------- + Video Wonder/Genius Internet Video Kit = LR37 Rev.C + Video Wonder Pro II (848 or 878) = LR26 + +Tekram +------ + VideoCap C205 (Bt848) + VideoCap C210 (zr36120 +Philips) + CaptureTV M200 (ISA) + CaptureTV M205 (Bt848) + +Lucky Star +---------- + Image World Conference TV = LR50 Rev. Q + +Leadtek +------- + WinView 601 (Bt848) + WinView 610 (Zoran) + WinFast2000 + WinFast2000 XP + +KNC One +------- + TV-Station + TV-Station SE (+Software Bundle) + TV-Station pro (+TV stereo) + TV-Station FM (+Radio) + TV-Station RDS (+RDS) + TV Station SAT (analog satellite) + TV-Station DVB-S + + newer Cards have saa7134, but model name stayed the same? + +Provideo +-------- + PV951 or PV-951 (also are sold as: + Boeder TV-FM Video Capture Card + Titanmedia Supervision TV-2400 + Provideo PV951 TF + 3DeMon PV951 + MediaForte TV-Vision PV951 + Yoko PV951 + Vivanco Tuner Card PCI Art.-Nr.: 68404 + ) now named PV-951T + + Surveillance Series + PV-141 + PV-143 + PV-147 + PV-148 (capture only) + PV-150 + PV-151 + + TV-FM Tuner Series + PV-951TDV (tv tuner + 1394) + PV-951T/TF + PV-951PT/TF + PV-956T/TF Low Profile + PV-911 + +Highscreen +---------- + TV Karte = LR50 Rev.S + TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb" + +Zoltrix +------- + Face to Face Capture (Bt848 capture only) (PCB "VP-2848") + Face To Face TV MAX (Bt848) (PCB "VP-8482 Rev1.3") + Genie TV (Bt878) (PCB "VP-8790 Rev 2.1") + Genie Wonder Pro + +AVerMedia +--------- + AVer FunTV Lite (ISA, AV3001 chipset) "M101.C" + AVerTV + AVerTV Stereo + AVerTV Studio (w/FM) + AVerMedia TV98 with Remote + AVerMedia TV/FM98 Stereo + AVerMedia TVCAM98 + TVCapture (Bt848) + TVPhone (Bt848) + TVCapture98 (="AVerMedia TV98" in USA) (Bt878) + TVPhone98 (Bt878, w/FM) + + PCB PCI-ID Model-Name Eeprom Tuner Sound Country + -------------------------------------------------------------------- + M101.C ISA ! + M108-B Bt848 -- FR1236 US (2),(3) + M1A8-A Bt848 AVer TV-Phone FM1216 -- + M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D (1) w/FM w/Remote + M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote + M168II-B 1461:0003 Medion MD9592 48:16 FM1216 TDA9873H D w/FM + + (1) Daughterboard MB68-A with TDA9820T and TDA9840T + (2) Sony NE41S soldered (stereo sound?) + (3) Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz + + US site has different drivers for (as of 09/2002): + EZ Capture/InterCam PCI (BT-848 chip) + EZ Capture/InterCam PCI (BT-878 chip) + TV-Phone (BT-848 chip) + TV98 (BT-848 chip) + TV98 With Remote (BT-848 chip) + TV98 (BT-878 chip) + TV98 With Remote (BT-878) + TV/FM98 (BT-878 chip) + AVerTV + AverTV Stereo + AVerTV Studio + + DE hat diverse Treiber fuer diese Modelle (Stand 09/2002): + TVPhone (848) mit Philips tuner FR12X6 (w/ FM radio) + TVPhone (848) mit Philips tuner FM12X6 (w/ FM radio) + TVCapture (848) w/Philips tuner FI12X6 + TVCapture (848) non-Philips tuner + TVCapture98 (Bt878) + TVPhone98 (Bt878) + AVerTV und TVCapture98 w/VCR (Bt 878) + AVerTVStudio und TVPhone98 w/VCR (Bt878) + AVerTV GO Serie (Kein SVideo Input) + AVerTV98 (BT-878 chip) + AVerTV98 mit Fernbedienung (BT-878 chip) + AVerTV/FM98 (BT-878 chip) + + VDOmate (www.averm.com.cn) = M168U ? + +Aimslab +------- + Video Highway or "Video Highway TR200" (ISA) + Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757) + +IXMicro (former: IMS=Integrated Micro Solutions) +------- + IXTV BT848 (=TurboTV) + IXTV BT878 + IMS TurboTV (Bt848) + +Lifetec/Medion/Tevion/Aldi +-------------------------- + LT9306/MD9306 = CPH061 + LT9415/MD9415 = LR90 Rev.F or Rev.G + MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H) + MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner) + MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner) + +Modular Technologies (www.modulartech.com) UK +--------------------------------------------- + MM100 PCTV (Bt848) + MM201 PCTV (Bt878, Bt832) w/ Quartzsight camera + MM202 PCTV (Bt878, Bt832, tda9874) + MM205 PCTV (Bt878) + MM210 PCTV (Bt878) (Galaxy TV, Galaxymedia ?) + +Terratec +-------- + Terra TV+ Version 1.0 (Bt848), "ceb105.PCB" printed on the PCB, TDA9821 + Terra TV+ Version 1.1 (Bt878), "LR74 Rev.E" printed on the PCB, TDA9821 + Terra TValueRadio, "LR102 Rev.C" printed on the PCB + Terra TV/Radio+ Version 1.0, "80-CP2830100-0" TTTV3 printed on the PCB, + "CPH010-E83" on the back, SAA6588T, TDA9873H + Terra TValue Version BT878, "80-CP2830110-0 TTTV4" printed on the PCB, + "CPH011-D83" on back + Terra TValue Version 1.0 "ceb105.PCB" (really identical to Terra TV+ Version 1.0) + Terra TValue New Revision "LR102 Rec.C" + Terra Active Radio Upgrade (tea5757h, saa6588t) + + LR74 is a newer PCB revision of ceb105 (both incl. connector for Active Radio Upgrade) + + Cinergy 400 (saa7134), "E877 11(S)", "PM820092D" printed on PCB + Cinergy 600 (saa7134) + +Technisat +--------- + Discos ADR PC-Karte ISA (no TV!) + Discos ADR PC-Karte PCI (probably no TV?) + Techni-PC-Sat (Sat. analog) + Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A) + Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio) + Mediafocus II (saa7146, Sat. analog) + SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A) + SkyStar 1 DVB (AV7110) = Technotrend Premium + SkyStar 2 DVB (B2C2) (=Sky2PC) + +Siemens +------- + Multimedia eXtension Board (MXB) (SAA7146, SAA7111) + +Stradis +------- + SDM275,SDM250,SDM026,SDM025 (SAA7146, IBMMPEG2): MPEG2 decoder only + +Powercolor +---------- + MTV878 + Package comes with different contents: + a) pcb "MTV878" (CARD=75) + b) Pixelview Rev. 4_ + MTV878R w/Remote Control + MTV878F w/Remote Control w/FM radio + +Pinnacle +-------- + Mirovideo PCTV (Bt848) + Mirovideo PCTV SE (Bt848) + Mirovideo PCTV Pro (Bt848 + Daughterboard for TV Stereo and FM) + Studio PCTV Rave (Bt848 Version = Mirovideo PCTV) + Studio PCTV Rave (Bt878 package w/o infrared) + Studio PCTV (Bt878) + Studio PCTV Pro (Bt878 stereo w/ FM) + Pinnacle PCTV (Bt878, MT2032) + Pinnacle PCTV Pro (Bt878, MT2032) + Pinncale PCTV Sat (bt878a, HM1821/1221) ["Conexant CX24110 with CX24108 tuner, aka HM1221/HM1811"] + Pinnacle PCTV Sat XE + + M(J)PEG capture and playback: + DC1+ (ISA) + DC10 (zr36057, zr36060, saa7110, adv7176) + DC10+ (zr36067, zr36060, saa7110, adv7176) + DC20 (ql16x24b,zr36050, zr36016, saa7110, saa7187 ...) + DC30 (zr36057, zr36050, zr36016, vpx3220, adv7176, ad1843, tea6415, miro FST97A1) + DC30+ (zr36067, zr36050, zr36016, vpx3220, adv7176) + DC50 (zr36067, zr36050, zr36016, saa7112, adv7176 (2 pcs.?), ad1843, miro FST97A1, Lattice ???) + +Lenco +----- + MXR-9565 (=Technisat Mediafocus?) + MXR-9571 (Bt848) (=CPH031?) + MXR-9575 + MXR-9577 (Bt878) (=Prolink 878TV Rev.3x) + MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E) + +Iomega +------ + Buz (zr36067, zr36060, saa7111, saa7185) + +LML +--- + LML33 (zr36067, zr36060, bt819, bt856) + +Grandtec +-------- + Grand Video Capture (Bt848) + Multi Capture Card (Bt878) + +Koutech +------- + KW-606 (Bt848) + KW-607 (Bt848 capture only) + KW-606RSF + KW-607A (capture only) + KW-608 (Zoran capture only) + +IODATA (jp) +------ + GV-BCTV/PCI + GV-BCTV2/PCI + GV-BCTV3/PCI + GV-BCTV4/PCI + GV-VCP/PCI (capture only) + GV-VCP2/PCI (capture only) + +Canopus (jp) +------- + WinDVR = Kworld "KW-TVL878RF" + +www.sigmacom.co.kr +------------------ + Sigma Cyber TV II + +www.sasem.co.kr +--------------- + Litte OnAir TV + +hama +---- + TV/Radio-Tuner Card, PCI (Model 44677) = CPH051 + +Sigma Designs +------------- + Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder + +Formac +------ + iProTV (Card for iMac Mezzanine slot, Bt848+SCSI) + ProTV (Bt848) + ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono] + +ATI +--- + TV-Wonder + TV-Wonder VE + +Diamond Multimedia +------------------ + DTV2000 (Bt848, tda9875) + +Aopen +----- + VA1000 Plus (w/ Stereo) + VA1000 Lite + VA1000 (=LR90) + +Intel +----- + Smart Video Recorder (ISA full-length) + Smart Video Recorder pro (ISA half-length) + Smart Video Recorder III (Bt848) + +STB +--- + STB Gateway 6000704 (bt878) + STB Gateway 6000699 (bt848) + STB Gateway 6000402 (bt848) + STB TV130 PCI + +Videologic +---------- + Captivator Pro/TV (ISA?) + Captivator PCI/VC (Bt848 bundled with camera) (capture only) + +Technotrend +------------ + TT-SAT PCI (PCB "Sat-PCI Rev.:1.3.1"; zr36125, vpx3225d, stc0056a, Tuner:BSKE6-155A + TT-DVB-Sat + revisions 1.1, 1.3, 1.5, 1.6 and 2.1 + This card is sold as OEM from: + Siemens DVB-s Card + Hauppauge WinTV DVB-S + Technisat SkyStar 1 DVB + Galaxis DVB Sat + Now this card is called TT-PCline Premium Family + TT-Budget (saa7146, bsru6-701a) + This card is sold as OEM from: + Hauppauge WinTV Nova + Satelco Standard PCI (DVB-S) + TT-DVB-C PCI + +Teles +----- + DVB-s (Rev. 2.2, BSRV2-301A, data only?) + +Remote Vision +------------- + MX RV605 (Bt848 capture only) + +Boeder +------ + PC ChatCam (Model 68252) (Bt848 capture only) + Tv/Fm Capture Card (Model 68404) = PV951 + +Media-Surfer (esc-kathrein.de) +------------------------------- + Sat-Surfer (ISA) + Sat-Surfer PCI = Techni-PC-Sat + Cable-Surfer 1 + Cable-Surfer 2 + Cable-Surfer PCI (zr36120) + Audio-Surfer (ISA Radio card) + +Jetway (www.jetway.com.tw) +-------------------------- + JW-TV 878M + JW-TV 878 = KWorld KW-TV878RF + +Galaxis +------- + Galaxis DVB Card S CI + Galaxis DVB Card C CI + Galaxis DVB Card S + Galaxis DVB Card C + Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI + +Hauppauge +--------- + many many WinTV models ... + WinTV DVBs = Technotrend Premium 1.3 + WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA" + WinTV NOVA-CI "SDVBACI" + WinTV Nova USB (=Technotrend USB 1.0) + WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2) + WinTV PVR + WinTV PVR 250 + WinTV PVR 450 + + US models + 990 WinTV-PVR-350 (249USD) (iTVC15 chipset + radio) + 980 WinTV-PVR-250 (149USD) (iTVC15 chipset) + 880 WinTV-PVR-PCI (199USD) (KFIR chipset + bt878) + 881 WinTV-PVR-USB + 190 WinTV-GO + 191 WinTV-GO-FM + 404 WinTV + 401 WinTV-radio + 495 WinTV-Theater + 602 WinTV-USB + 621 WinTV-USB-FM + 600 USB-Live + 698 WinTV-HD + 697 WinTV-D + 564 WinTV-Nexus-S + + Deutsche Modelle + 603 WinTV GO + 719 WinTV Primio-FM + 718 WinTV PCI-FM + 497 WinTV Theater + 569 WinTV USB + 568 WinTV USB-FM + 882 WinTV PVR + 981 WinTV PVR 250 + 891 WinTV-PVR-USB + 541 WinTV Nova + 488 WinTV Nova-Ci + 564 WinTV-Nexus-s + 727 WinTV-DVB-c + 545 Common Interface + 898 WinTV-Nova-USB + + UK models + 607 WinTV Go + 693,793 WinTV Primio FM + 647,747 WinTV PCI FM + 498 WinTV Theater + 883 WinTV PVR + 893 WinTV PVR USB (Duplicate entry) + 566 WinTV USB (UK) + 573 WinTV USB FM + 429 Impact VCB (bt848) + 600 USB Live (Video-In 1x Comp, 1xSVHS) + 542 WinTV Nova + 717 WinTV DVB-S + 909 Nova-t PCI + 893 Nova-t USB (Duplicate entry) + 802 MyTV + 804 MyView + 809 MyVideo + 872 MyTV2Go FM + + + 546 WinTV Nova-S CI + 543 WinTV Nova + 907 Nova-S USB + 908 Nova-T USB + 717 WinTV Nexus-S + 157 DEC3000-s Standalone + USB + + Spain + 685 WinTV-Go + 690 WinTV-PrimioFM + 416 WinTV-PCI Nicam Estereo + 677 WinTV-PCI-FM + 699 WinTV-Theater + 683 WinTV-USB + 678 WinTV-USB-FM + 983 WinTV-PVR-250 + 883 WinTV-PVR-PCI + 993 WinTV-PVR-350 + 893 WinTV-PVR-USB + 728 WinTV-DVB-C PCI + 832 MyTV2Go + 869 MyTV2Go-FM + 805 MyVideo (USB) + + +Matrix-Vision +------------- + MATRIX-Vision MV-Delta + MATRIX-Vision MV-Delta 2 + MVsigma-SLC (Bt848) + +Conceptronic (.net) +------------ + TVCON FM, TV card w/ FM = CPH05x + TVCON = CPH06x + +BestData +-------- + HCC100 = VCC100rev1 + camera + VCC100 rev1 (bt848) + VCC100 rev2 (bt878) + +Gallant (www.gallantcom.com) www.minton.com.tw +----------------------------------------------- + Intervision IV-510 (capture only bt8x8) + Intervision IV-550 (bt8x8) + Intervision IV-100 (zoran) + Intervision IV-1000 (bt8x8) + +Asonic (www.asonic.com.cn) (website down) +----------------------------------------- + SkyEye tv 878 + +Hoontech +-------- + 878TV/FM + +Teppro (www.itcteppro.com.tw) +----------------------------- + ITC PCITV (Card Ver 1.0) "Teppro TV1/TVFM1 Card" + ITC PCITV (Card Ver 2.0) + ITC PCITV (Card Ver 3.0) = "PV-BT878P+ (REV.9D)" + ITC PCITV (Card Ver 4.0) + TEPPRO IV-550 (For BT848 Main Chip) + ITC DSTTV (bt878, satellite) + ITC VideoMaker (saa7146, StreamMachine sm2110, tvtuner) "PV-SM2210P+ (REV:1C)" + +Kworld (www.kworld.com.tw) +-------------------------- + PC TV Station + KWORLD KW-TV878R TV (no radio) + KWORLD KW-TV878RF TV (w/ radio) + + KWORLD KW-TVL878RF (low profile) + + KWORLD KW-TV713XRF (saa7134) + + + MPEG TV Station (same cards as above plus WinDVR Software MPEG en/decoder) + KWORLD KW-TV878R -Pro TV (no Radio) + KWORLD KW-TV878RF-Pro TV (w/ Radio) + KWORLD KW-TV878R -Ultra TV (no Radio) + KWORLD KW-TV878RF-Ultra TV (w/ Radio) + + + +JTT/ Justy Corp.http://www.justy.co.jp/ (www.jtt.com.jp website down) +--------------------------------------------------------------------- + JTT-02 (JTT TV) "TV watchmate pro" (bt848) + +ADS www.adstech.com +------------------- + Channel Surfer TV ( CHX-950 ) + Channel Surfer TV+FM ( CHX-960FM ) + +AVEC www.prochips.com +--------------------- + AVEC Intercapture (bt848, tea6320) + +NoBrand +------- + TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_" + +Mach www.machspeed.com +---- + Mach TV 878 + +Eline www.eline-net.com/ +----- + Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878) + Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x) + +Spirit http://www.spiritmodems.com.au/ +------ + Spirit TV Tuner/Video Capture Card (bt848) + +Boser www.boser.com.tw +----- + HS-878 Mini PCI Capture Add-on Card + HS-879 Mini PCI 3D Audio and Capture Add-on Card (w/ ES1938 Solo-1) + +Satelco www.citycom-gmbh.de, www.satelco.de +------- + TV-FM =KNC1 saa7134 + Standard PCI (DVB-S) = Technotrend Budget + Standard PCI (DVB-S) w/ CI + Satelco Highend PCI (DVB-S) = Technotrend Premium + + +Sensoray www.sensoray.com +-------- + Sensoray 311 (PC/104 bus) + Sensoray 611 (PCI) + +CEI (Chartered Electronics Industries Pte Ltd [CEI] [FCC ID HBY]) +--- + TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips + TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV + Primetime TV (ISA) + acquired by Singapore Technologies + now operating as Chartered Semiconductor Manufacturing + Manufacturer of video cards is listed as: + Cogent Electronics Industries [CEI] + +AITech +------ + Wavewatcher TV (ISA) + AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878) + WaveWatcher TVR-202 TV/FM Radio Card (ISA) + +MAXRON +------ + Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK + +www.ids-imaging.de +------------------ + Falcon Series (capture only) + In USA: http://www.theimagingsource.com/ + DFG/LC1 + +www.sknet-web.co.jp +------------------- + SKnet Monster TV (saa7134) + +A-Max www.amaxhk.com (Colormax, Amax, Napa) +------------------- + APAC Viewcomp 878 + +Cybertainment +------------- + CyberMail AV Video Email Kit w/ PCI Capture Card (capture only) + CyberMail Xtreme + These are Flyvideo + +VCR (http://www.vcrinc.com/) +--- + Video Catcher 16 + +Twinhan +------- + DST Card/DST-IP (bt878, twinhan asic) VP-1020 + Sold as: + KWorld DVBS Satellite TV-Card + Powercolor DSTV Satellite Tuner Card + Prolink Pixelview DTV2000 + Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ? + DST-CI Card (DVB Satellite) VP-1030 + DCT Card (DVB cable) + +MSI +--- + MSI TV@nywhere Tuner Card (MS-8876) (CX23881/883) Not Bt878 compatible. + MS-8401 DVB-S + +Focus www.focusinfo.com +----- + InVideo PCI (bt878) + +Sdisilk www.sdisilk.com/ +------- + SDI Silk 100 + SDI Silk 200 SDI Input Card + +www.euresys.com + PICOLO series + +PMC/Pace +www.pacecom.co.uk website closed + +Mercury www.kobian.com (UK and FR) + LR50 + LR138RBG-Rx == LR138 + +TEC sound (package and manuals don't have any other manufacturer info) TecSound + Though educated googling found: www.techmakers.com + TV-Mate = Zoltrix VP-8482 + +Lorenzen www.lorenzen.de +-------- + SL DVB-S PCI = Technotrend Budget PCI (su1278 or bsru version) + +Origo (.uk) www.origo2000.com + PC TV Card = LR50 + +I/O Magic www.iomagic.com +--------- + PC PVR - Desktop TV Personal Video Recorder DR-PCTV100 = Pinnacle ROB2D-51009464 4.0 + Cyberlink PowerVCR II + +Arowana +------- + TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?) + +iTVC15 boards: +------------- +kuroutoshikou.com ITVC15 +yuan.com MPG160 PCI TV (Internal PCI MPEG2 encoder card plus TV-tuner) + +Asus www.asuscom.com + Asus TV Tuner Card 880 NTSC (low profile, cx23880) + Asus TV (saa7134) + +Hoontech +-------- +http://www.hoontech.com/korean/download/down_driver_list03.html + HART Vision 848 (H-ART Vision 848) + HART Vision 878 (H-Art Vision 878) 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 + +PAL: +TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners +TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3 + +NTSC: +TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners +TSA5518: no datasheet available on Philips site + + + +STB TV pci: + +??? +if you want better support for STB cards send me info! +Look at the board! What chips are on it? 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 ... + +========================================================================== + +bttv.o + the bt848/878 (grabber chip) driver + + insmod args: + card=n card type, see CARDLIST for a list. + tuner=n tuner type, see CARDLIST for a list. + radio=0/1 card supports radio + pll=0/1/2 pll settings + 0: don't use PLL + 1: 28 MHz crystal installed + 2: 35 MHz crystal installed + + triton1=0/1 for Triton1 (+others) compatibility + vsfx=0/1 yet another chipset bug compatibility bit + see README.quirks for details on these two. + + bigendian=n Set the endianness of the gfx framebuffer. + Default is native endian. + fieldnr=0/1 Count fields. Some TV descrambling software + needs this, for others it only generates + 50 useless IRQs/sec. default is 0 (off). + autoload=0/1 autoload helper modules (tuner, audio). + default is 1 (on). + bttv_verbose=0/1/2 verbose level (at insmod time, while + looking at the hardware). default is 1. + bttv_debug=0/1 debug messages (for capture). + default is 0 (off). + irq_debug=0/1 irq handler debug messages. + default is 0 (off). + gbuffers=2-32 number of capture buffers for mmap'ed capture. + default is 4. + gbufsize= size of capture buffers. default and + maximum value is 0x208000 (~2MB) + no_overlay=0 Enable overlay on broken hardware. There + are some chipsets (SIS for example) which + are known to have problems with the PCI DMA + push used by bttv. bttv will disable overlay + by default on this hardware to avoid crashes. + With this insmod option you can override this. + automute=0/1 Automatically mutes the sound if there is + no TV signal, on by default. You might try + to disable this if you have bad input signal + quality which leading to unwanted sound + dropouts. + chroma_agc=0/1 AGC of chroma signal, off by default. + adc_crush=0/1 Luminance ADC crush, on by default. + + bttv_gpio=0/1 + gpiomask= + audioall= + audiomux= + See Sound-FAQ for a detailed description. + + remap, card, radio and pll accept up to four comma-separated arguments + (for multiple boards). + +tuner.o + The tuner driver. You need this unless you want to use only + with a camera or external tuner ... + + insmod args: + debug=1 print some debug info to the syslog + type=n type of the tuner chip. n as follows: + see CARDLIST for a complete list. + pal=[bdgil] select PAL variant (used for some tuners + only, important for the audio carrier). + +tvmixer.o + registers a mixer device for the TV card's volume/bass/treble + controls (requires a i2c audio control chip like the msp3400). + + insmod args: + debug=1 print some debug info to the syslog. + devnr=n allocate device #n (0 == /dev/mixer, + 1 = /dev/mixer1, ...), default is to + use the first free one. + +tvaudio.o + new, experimental module which is supported to provide a single + driver for all simple i2c audio control chips (tda/tea*). + + insmod args: + tda8425 = 1 enable/disable the support for the + tda9840 = 1 various chips. + tda9850 = 1 The tea6300 can't be autodetected and is + tda9855 = 1 therefore off by default, if you have + tda9873 = 1 this one on your card (STB uses these) + tda9874a = 1 you have to enable it explicitly. + tea6300 = 0 The two tda985x chips use the same i2c + tea6420 = 1 address and can't be disturgished from + pic16c54 = 1 each other, you might have to disable + the wrong one. + debug = 1 print debug messages + + insmod args for tda9874a: + tda9874a_SIF=1/2 select sound IF input pin (1 or 2) + (default is pin 1) + tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0) + Please read note 3 below! + tda9874a_STD=n select TV sound standard (0..8): + 0 - A2, B/G + 1 - A2, M (Korea) + 2 - A2, D/K (1) + 3 - A2, D/K (2) + 4 - A2, D/K (3) + 5 - NICAM, I + 6 - NICAM, B/G + 7 - NICAM, D/K (default) + 8 - NICAM, L + + Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips. + Note 2: tda9874h/a and tda9875 (which is supported separately by + tda9875.o) use the same i2c address so both modules should not be + used at the same time. + Note 3: Using tda9874a_AMSEL option depends on your TV card design! + AMSEL=0: auto-mute will switch between NICAM sound + and the sound on 1st carrier (i.e. FM mono or AM). + AMSEL=1: auto-mute will switch between NICAM sound + and the analog mono input (MONOIN pin). + If tda9874a decoder on your card has MONOIN pin not connected, then + use only tda9874_AMSEL=0 or don't specify this option at all. + For example: + card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0 + card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only + +msp3400.o + The driver for the msp34xx sound processor chips. If you have a + stereo card, you probably want to insmod this one. + + insmod args: + debug=1/2 print some debug info to the syslog, + 2 is more verbose. + simple=1 Use the "short programming" method. Newer + msp34xx versions support this. You need this + for dbx stereo. Default is on if supported by + the chip. + once=1 Don't check the TV-stations Audio mode + every few seconds, but only once after + channel switches. + amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This + should improve things for french people, the + carrier autoscan seems to work with FM only... + +tea6300.o - OBSOLETE (use tvaudio instead) + The driver for the tea6300 fader chip. If you have a stereo + card and the msp3400.o doesn't work, you might want to try this + one. This chip is seen on most STB TV/FM cards (usually from + Gateway OEM sold surplus on auction sites). + + insmod args: + debug=1 print some debug info to the syslog. + +tda8425.o - OBSOLETE (use tvaudio instead) + The driver for the tda8425 fader chip. This driver used to be + part of bttv.c, so if your sound used to work but does not + anymore, try loading this module. + + insmod args: + debug=1 print some debug info to the syslog. + +tda985x.o - OBSOLETE (use tvaudio instead) + The driver for the tda9850/55 audio chips. + + insmod args: + debug=1 print some debug info to the syslog. + chip=9850/9855 set the chip type. 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 @@ +#!/bin/bash + +function makedev () { + + for dev in 0 1 2 3; do + echo "/dev/$1$dev: char 81 $[ $2 + $dev ]" + rm -f /dev/$1$dev + mknod /dev/$1$dev c 81 $[ $2 + $dev ] + chmod 666 /dev/$1$dev + done + + # symlink for default device + rm -f /dev/$1 + ln -s /dev/${1}0 /dev/$1 +} + +# see http://roadrunner.swansea.uk.linux.org/v4lapi.shtml + +echo "*** new device names ***" +makedev video 0 +makedev radio 64 +makedev vtx 192 +makedev vbi 224 + +#echo "*** old device names (for compatibility only) ***" +#makedev bttv 0 +#makedev bttv-fm 64 +#makedev bttv-vbi 224 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: + CONFIG_I2C=m + CONFIG_I2C_ALGOBIT=m + CONFIG_VIDEO_DEV=m + +The latest bttv version is available from http://bytesex.org/bttv/ + + +Make bttv work with your card +----------------------------- + +Just try "modprobe bttv" and see if that works. + +If it doesn't bttv likely could not autodetect your card and needs some +insmod options. The most important insmod option for bttv is "card=n" +to select the correct card type. If you get video but no sound you've +very likely specified the wrong (or no) card type. A list of supported +cards is in CARDLIST.bttv + +If bttv takes very long to load (happens sometimes with the cheap +cards which have no tuner), try adding this to your modules.conf: + options i2c-algo-bit bit_test=1 + +For the WinTV/PVR you need one firmware file from the driver CD: +hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting +zip file, unzip can unpack it). Put it into the /etc/pvr directory or +use the firm_altera=<path> insmod option to point the driver to the +location of the file. + +If your card isn't listed in CARDLIST.bttv or if you have trouble making +audio work, you should read the Sound-FAQ. + + +Autodetecting cards +------------------- + +bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists +the Subsystem ID in the second line, looks like this: + +00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) + Subsystem: Hauppauge computer works Inc. WinTV/GO + Flags: bus master, medium devsel, latency 32, IRQ 5 + Memory at e2000000 (32-bit, prefetchable) [size=4K] + +only bt878-based cards can have a subsystem ID (which does not mean +that every card really has one). bt848 cards can't have a Subsystem +ID and therefore can't be autodetected. There is a list with the ID's +in bttv-cards.c (in case you are intrested or want to mail patches +with updates). + + +Still doesn't work? +------------------- + +I do NOT have a lab with 30+ different grabber boards and a +PAL/NTSC/SECAM test signal generator at home, so I often can't +reproduce your problems. This makes debugging very difficult for me. +If you have some knowledge and spare time, please try to fix this +yourself (patches very welcome of course...) You know: The linux +slogan is "Do it yourself". + +There is a mailing list: video4linux-list@redhat.com. +https://listman.redhat.com/mailman/listinfo/video4linux-list + +If you have trouble with some specific TV card, try to ask there +instead of mailing me directly. The chance that someone with the +same card listens there is much higher... + +For problems with sound: There are alot of different systems used +for TV sound all over the world. And there are also different chips +which decode the audio signal. Reports about sound problems ("stereo +does'nt work") are pretty useless unless you include some details +about your hardware and the TV sound scheme used in your country (or +at least the country you are living in). + + +Finally: If you mail some patches for bttv around the world (to +linux-kernel/Alan/Linus/...), please Cc: me. + + +Have fun with bttv, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> 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. + + +other +----- + +If you use some binary-only yunk (like nvidia module) try to reproduce +the problem without. + +IRQ sharing is known to cause problems in some cases. It works just +fine in theory and many configurations. Neverless it might be worth a +try to shuffle around the PCI cards to give bttv another IRQ or make +it share the IRQ with some other piece of hardware. IRQ sharing with +VGA cards seems to cause trouble sometimes. I've also seen funny +effects with bttv sharing the IRQ with the ACPI bridge (and +apci-enabled kernel). + 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). + +HTH, + + Gerd + +---------------------------- cut here -------------------------- + +Normal PCI Mode +--------------- + +The PCI REQ signal is the logical-or of the incoming function requests. +The inter-nal GNT[0:1] signals are gated asynchronously with GNT and +demultiplexed by the audio request signal. Thus the arbiter defaults to +the video function at power-up and parks there during no requests for +bus access. This is desirable since the video will request the bus more +often. However, the audio will have highest bus access priority. Thus +the audio will have first access to the bus even when issuing a request +after the video request but before the PCI external arbiter has granted +access to the Bt879. Neither function can preempt the other once on the +bus. The duration to empty the entire video PCI FIFO onto the PCI bus is +very short compared to the bus access latency the audio PCI FIFO can +tolerate. + + +430FX Compatibility Mode +------------------------ + +When using the 430FX PCI, the following rules will ensure +compatibility: + + (1) Deassert REQ at the same time as asserting FRAME. + (2) Do not reassert REQ to request another bus transaction until after + finish-ing the previous transaction. + +Since the individual bus masters do not have direct control of REQ, a +simple logical-or of video and audio requests would violate the rules. +Thus, both the arbiter and the initiator contain 430FX compatibility +mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in +Device Control Register on page 104. + +When EN_TBFX is enabled, the arbiter ensures that the two compatibility +rules are satisfied. Before GNT is asserted by the PCI arbiter, this +internal arbiter may still logical-or the two requests. However, once +the GNT is issued, this arbiter must lock in its decision and now route +only the granted request to the REQ pin. The arbiter decision lock +happens regardless of the state of FRAME because it does not know when +FRAME will be asserted (typically - each initiator will assert FRAME on +the cycle following GNT). When FRAME is asserted, it is the initiator s +responsibility to remove its request at the same time. It is the +arbiters responsibility to allow this request to flow through to REQ and +not allow the other request to hold REQ asserted. The decision lock may +be removed at the end of the transaction: for example, when the bus is +idle (FRAME and IRDY). The arbiter decision may then continue +asynchronously until GNT is again asserted. + + +Interfacing with Non-PCI 2.1 Compliant Core Logic +------------------------------------------------- + +A small percentage of core logic devices may start a bus transaction +during the same cycle that GNT is de-asserted. This is non PCI 2.1 +compliant. To ensure compatibility when using PCs with these PCI +controllers, the EN_VSFX bit must be enabled (refer to Device Control +Register on page 104). When in this mode, the arbiter does not pass GNT +to the internal functions unless REQ is asserted. This prevents a bus +transaction from starting the same cycle as GNT is de-asserted. This +also has the side effect of not being able to take advantage of bus +parking, thus lowering arbitration performance. The Bt879 drivers must +query for these non-compliant devices, and set the EN_VSFX bit only if +required. + 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 +mux. + + +What you have to do is figure out the correct values for gpiomask and +the audiomux array. If you have Windows and the drivers four your +card installed, you might to check out if you can read these registers +values used by the windows driver. A tool to do this is available +from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it +does'nt work with bt878 boards according to some reports I received. +Another one with bt878 suport is available from +http://btwincap.sourceforge.net/Files/btspy2.00.zip + +You might also dig around in the *.ini files of the Windows applications. +You can have a look at the board to see which of the gpio pins are +connected at all and then start trial-and-error ... + + +Starting with release 0.7.41 bttv has a number of insmod options to +make the gpio debugging easier: + +bttv_gpio=0/1 enable/disable gpio debug messages +gpiomask=n set the gpiomask value +audiomux=i,j,... set the values of the audiomux array +audioall=a set the values of the audiomux array (one + value for all array elements, useful to check + out which effect the particular value has). + +The messages printed with bttv_gpio=1 look like this: + + bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off] + +en = output _en_able register (BT848_GPIO_OUT_EN) +out = _out_put bits of the data register (BT848_GPIO_DATA), + i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN +in = _in_put bits of the data register, + i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN + + + +Other elements of the tvcards array +=================================== + +If you are trying to make a new card work you might find it useful to +know what the other elements in the tvcards array are good for: + +video_inputs - # of video inputs the card has +audio_inputs - historical cruft, not used any more. +tuner - which input is the tuner +svhs - which input is svhs (all others are labeled composite) +muxsel - video mux, input->registervalue mapping +pll - same as pll= insmod option +tuner_type - same as tuner= insmod option +*_modulename - hint whenever some card needs this or that audio + module loaded to work properly. +has_radio - whenever this TV card has a radio tuner. +no_msp34xx - "1" disables loading of msp3400.o module +no_tda9875 - "1" disables loading of tda9875.o module +needs_tvaudio - set to "1" to load tvaudio.o module + +If some config item is specified both from the tvcards array and as +insmod option, the insmod option takes precedence. + + + +Good luck, + + Gerd + + +PS: If you have a new working entry, mail it to me. + +-- +Gerd Knorr <kraxel@bytesex.org> 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] + [ABCJLMNQ]: + A= BG+DK + B= BG + C= I+DK + J= NTSC-Japan + L= Secam LL + M= BG+I+DK + N= NTSC + Q= BG+I+DK+LL + [89]: ? + [125]: + 2: No FM + 5: With FM + [DP]: + D= NTSC + P= PAL + [ACD]: + A= F-connector + C= Phono connector + D= Din Jack + [ABCD]: + 3-wire/I2C tuning, 2-band/3-band + + These Tuners are PHILIPS_API compatible. + +Philips Tuner identification: (e.g. FM1216MF) + F[IRMQ]12[1345]6{MF|ME|MP} + F[IRMQ]: + FI12x6: Tuner Series + FR12x6: Tuner + Radio IF + FM12x6: Tuner + FM + FQ12x6: special + FMR12x6: special + TD15xx: Digital Tuner ATSC + 12[1345]6: + 1216: PAL BG + 1236: NTSC + 1246: PAL I + 1256: Pal DK + {MF|ME|MP} + MF: BG LL w/ Secam (Multi France) + ME: BG DK I LL (Multi Europe) + MP: BG DK I (Multi PAL) + MR: BG DK M (?) + MG: BG DKI M (?) + MK2 series PHILIPS_API, most tuners are compatible to this one ! + MK3 series introduced in 2002 w/ PHILIPS_MK3_API + +Temic Tuner identification: (.e.g 4006FH5) + 4[01][0136][269]F[HYNR]5 + 40x2: Tuner (5V/33V), TEMIC_API. + 40x6: Tuner 5V + 41xx: Tuner compact + 40x9: Tuner+FM compact + [0136] + xx0x: PAL BG + xx1x: Pal DK, Secam LL + xx3x: NTSC + xx6x: PAL I + F[HYNR]5 + FH5: Pal BG + FY5: others + FN5: multistandard + FR5: w/ FM radio + 3X xxxx: order number with specific connector + Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API. + +LG Innotek Tuner: + TPI8NSR11 : NTSC J/M (TPI8NSR01 w/FM) (P,210/497) + TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM) (P,170/450) + TAPC-I701 : PAL I (TAPC-I001 w/FM) (P,170/450) + TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM) (P,170/450) + TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450) + TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450) + TAPC-W701P: PAL I (TAPC-W001P w/FM) (L,170/450) + TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450) + TAPC-Q704P: PAL D/K+I (L,170/450) + TAPC-G702P: PAL D/K+B/G (L,170/450) + + TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69) + TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8) + TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69) + Suffix: + P= Standard phono female socket + D= IEC female socket + F= F-connector + +Other Tuners: +TCL2002MB-1 : PAL BG + DK =TUNER_LG_PAL_NEW_TAPC +TCL2002MB-1F: PAL BG + DK w/FM =PHILIPS_PAL +TCL2002MI-2 : PAL I = ?? + +ALPS Tuners: + Most are LG_API compatible + TSCH6 has ALPS_API (TSCH5 ?) + TSBE1 has extra API 05,02,08 Control_byte=0xCB Source:(1) + +Lit. +(1) conexant100029b-PCI-Decoder-ApplicationNote.pdf 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 + +Usage: +------ + + xawtv >= 3.49 (<http://bytesex.org/xawtv/>) + for display and uncompressed video capture: + + xawtv -c /dev/video0 -geometry 640x480 + or + xawtv -c /dev/video0 -geometry 320x240 + + motioneye (<http://popies.net/meye/>) + for getting ppm or jpg snapshots, mjpeg video + +Private API: +------------ + + The driver supports frame grabbing with the video4linux API + (either v4l1 or v4l2), so all video4linux tools (like xawtv) + should work with this driver. + + Besides the video4linux interface, the driver has a private interface + for accessing the Motion Eye extended parameters (camera sharpness, + agc, video framerate), the shapshot and the MJPEG capture facilities. + + This interface consists of several ioctls (prototypes and structures + can be found in include/linux/meye.h): + + MEYEIOC_G_PARAMS + MEYEIOC_S_PARAMS + Get and set the extended parameters of the motion eye camera. + The user should always query the current parameters with + MEYEIOC_G_PARAMS, change what he likes and then issue the + MEYEIOC_S_PARAMS call (checking for -EINVAL). The extended + parameters are described by the meye_params structure. + + + MEYEIOC_QBUF_CAPT + Queue a buffer for capture (the buffers must have been + obtained with a VIDIOCGMBUF call and mmap'ed by the + application). The argument to MEYEIOC_QBUF_CAPT is the + buffer number to queue (or -1 to end capture). The first + call to MEYEIOC_QBUF_CAPT starts the streaming capture. + + MEYEIOC_SYNC + Takes as an argument the buffer number you want to sync. + This ioctl blocks until the buffer is filled and ready + for the application to use. It returns the buffer size. + + MEYEIOC_STILLCAPT + MEYEIOC_STILLJCAPT + Takes a snapshot in an uncompressed or compressed jpeg format. + This ioctl blocks until the snapshot is done and returns (for + jpeg snapshot) the size of the image. The image data is + available from the first mmap'ed buffer. + + Look at the 'motioneye' application code for an actual example. + +Bugs / Todo: +------------ + + - the driver could be much cleaned up by removing the v4l1 support. + However, this means all v4l1-only applications will stop working. + + - 'motioneye' still uses the meye private v4l1 API extensions. 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 @@ +NOTES ON RADIOTRACK CARD CONTROL +by Stephen M. Benoit (benoits@servicepro.com) Dec 14, 1996 +---------------------------------------------------------------------------- + +Document version 1.0 + +ACKNOWLEDGMENTS +---------------- +This document was made based on 'C' code for Linux from Gideon le Grange +(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from +Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from +experiments that the author performed on his own setup, so your mileage may +vary... I make no guarantees, claims or warranties to the suitability or +validity of this information. No other documentation on the AIMS +Lab (http://www.aimslab.com/) RadioTrack card was made available to the +author. This document is offered in the hopes that it might help users who +want to use the RadioTrack card in an environment other than MS Windows. + +WHY THIS DOCUMENT? +------------------ +I have a RadioTrack card from back when I ran an MS-Windows platform. After +converting to Linux, I found Gideon le Grange's command-line software for +running the card, and found that it was good! Frans Brinkman made a +comfortable X-windows interface, and added a scanning feature. For hack +value, I wanted to see if the tuner could be tuned beyond the usual FM radio +broadcast band, so I could pick up the audio carriers from North American +broadcast TV channels, situated just below and above the 87.0-109.0 MHz range. +I did not get much success, but I learned about programming ioports under +Linux and gained some insights about the hardware design used for the card. + +So, without further delay, here are the details. + + +PHYSICAL DESCRIPTION +-------------------- +The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF) +input is simply an antenna lead, and the output is a power audio signal +available through a miniature phone plug. Its RF frequencies of operation are +more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast +band). Although the registers can be programmed to request frequencies beyond +these limits, experiments did not give promising results. The variable +frequency oscillator (VFO) that demodulates the intermediate frequency (IF) +signal probably has a small range of useful frequencies, and wraps around or +gets clipped beyond the limits mentioned above. + + +CONTROLLING THE CARD WITH IOPORT +-------------------------------- +The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one +ioport seems to be involved. The ioport decoding circuitry must be pretty +simple, as individual ioport bits are directly matched to specific functions +(or blocks) of the radio card. This way, many functions can be changed in +parallel with one write to the ioport. The only feedback available through +the ioports appears to be the "Stereo Detect" bit. + +The bits of the ioport are arranged as follows: + + MSb LSb ++------+------+------+--------+--------+-------+---------+--------+ +| VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune | +| (+) | (-) | | Detect | Audio | (bit) | (latch) | Update | +| | | | Enable | Enable | | | Enable | ++------+------+------+--------+--------+-------+---------+--------+ + + +VolA . VolB [AB......] +----------- +0 0 : audio mute +0 1 : volume + (some delay required) +1 0 : volume - (some delay required) +1 1 : stay at present volume + +Stereo Detect Enable [...S....] +-------------------- +0 : No Detect +1 : Detect + + Results available by reading ioport >60 msec after last port write. + 0xff ==> no stereo detected, 0xfd ==> stereo detected. + +Radio to Audio (path) Enable [....R...] +---------------------------- +0 : Disable path (silence) +1 : Enable path (audio produced) + +TuneA . TuneB [.....AB.] +------------- +0 0 : "zero" bit phase 1 +0 1 : "zero" bit phase 2 + +1 0 : "one" bit phase 1 +1 1 : "one" bit phase 2 + + 24-bit code, where bits = (freq*40) + 10486188. + The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid. + The bits are shifted in LSb first. + +Tune Update Enable [.......T] +------------------ +0 : Tuner held constant +1 : Tuner updating in progress + + +PROGRAMMING EXAMPLES +-------------------- +Default: BASE <-- 0xc8 (current volume, no stereo detect, + radio enable, tuner adjust disable) + +Card Off: BASE <-- 0x00 (audio mute, no stereo detect, + radio disable, tuner adjust disable) + +Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business) + BASE <-- 0xc8 (see "Default") + +Volume Down: BASE <-- 0x48 (volume down, no stereo detect, + radio enable, tuner adjust disable) + * wait 10 msec * + BASE <-- 0xc8 (see "Default") + +Volume Up: BASE <-- 0x88 (volume up, no stereo detect, + radio enable, tuner adjust disable) + * wait 10 msec * + BASE <-- 0xc8 (see "Default") + +Check Stereo: BASE <-- 0xd8 (current volume, stereo detect, + radio enable, tuner adjust disable) + * wait 100 msec * + x <-- BASE (read ioport) + BASE <-- 0xc8 (see "Default") + + x=0xff ==> "not stereo", x=0xfd ==> "stereo detected" + +Set Frequency: code = (freq*40) + 10486188 + foreach of the 24 bits in code, + (from Least to Most Significant): + to write a "zero" bit, + BASE <-- 0x01 (audio mute, no stereo detect, radio + disable, "zero" bit phase 1, tuner adjust) + BASE <-- 0x03 (audio mute, no stereo detect, radio + disable, "zero" bit phase 2, tuner adjust) + to write a "one" bit, + BASE <-- 0x05 (audio mute, no stereo detect, radio + disable, "one" bit phase 1, tuner adjust) + BASE <-- 0x07 (audio mute, no stereo detect, radio + disable, "one" bit phase 2, tuner adjust) + +---------------------------------------------------------------------------- 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. + +Options: + modprobe w9966.o pardev=parport0(or whatever) parmode=0 (0=auto, 1=ecp, 2=epp) +voila! + +you can also type 'modinfo -p w9966.o' for option usage +(or checkout w9966.c) + +The only thing to keep in mind is that the image format is in Y-U-Y-V format +where every two pixels take 4 bytes. In SDL (www.libsdl.org) this format +is called VIDEO_PALETTE_YUV422 (16 bpp). + +A minimal test application (with source) is available from: + http://hem.fyristorg.com/mogul/w9966.html + +The slow framerate is due to missing DMA ECP read support in the +parport drivers. I might add working EPP support later. + +Good luck! + /Jakob Kemi 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 +zr36120.c + +After some testing, I discovered that the carddesigner messed up +on the I2C interface. The Zoran chip includes 2 lines SDA and SCL +which (s)he connected reversely. So we have to clock on the SDA +and r/w data on the SCL pin. Life is fun... Each cardtype now has +a bit which signifies if you have a card with the same deficiency. + +Oh, for the completeness of this story I must mention that my +card delivers the VSYNC pulse of the SAA chip to GIRQ1, not +GIRQ0 as some other cards have. This is also incorporated in +the driver be clearing/setting the 'useirq1' bit in the tvcard +description. + +Another problems of continuous capturing data with a Zoran chip +is something nasty inside the chip. It effectively halves the +fps we ought to get... Here is the scenario: capturing frames +to memory is done in the so-called snapshot mode. In this mode +the Zoran stops after capturing a frame worth of data and wait +till the application set GRAB bit to indicate readiness for the +next frame. After detecting a set bit, the chip neatly waits +till the start of a frame, captures it and it goes back to off. +Smart ppl will notice the problem here. Its the waiting on the +_next_ frame each time we set the GRAB bit... Oh well, 12,5 fps +is still plenty fast for me. +-- update 28/7/1999 -- +Don't believe a word I just said... Proof is the output +of `streamer -t 300 -r 25 -f avi15 -o /dev/null` + ++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 + +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- + syncer: done + writer: done +(note the /dev/null is prudent here, my system is not able to + grab /and/ write 25 fps to a file... gifts welcome :) ) +The technical reasoning follows: The zoran completed the last +frame, the VSYNC goes low, and GRAB is cleared. The interrupt +routine starts to work since its VSYNC driven, and again +activates the GRAB bit. A few ms later the VSYNC (re-)rises and +the zoran starts to work on a new and freshly broadcasted frame.... + +For pointers I used the specs of both chips. Below are the URLs: + http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf + http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf + +The documentation has very little on absolute numbers or timings +needed for the various modes/resolutions, but there are other +programs you can borrow those from. + +------ Install -------------------------------------------- +Read the file called TODO. Note its long list of limitations. + +Build a kernel with VIDEO4LINUX enabled. Activate the +BT848 driver; we need this because we have need for the +other modules (i2c and videodev) it enables. + +To install this software, extract it into a suitable directory. +Examine the makefile and change anything you don't like. Type "make". + +After making the modules check if you have the much needed +/dev/video devices. If not, execute the following 4 lines: + mknod /dev/video c 81 0 + mknod /dev/video1 c 81 1 + mknod /dev/video2 c 81 2 + mknod /dev/video3 c 81 3 + mknod /dev/video4 c 81 4 + +After making/checking the devices do: + modprobe i2c + modprobe videodev + modprobe saa7110 (optional) + modprobe saa7111 (optional) + modprobe tuner (optional) + insmod zoran cardtype=<n> + +<n> is the cardtype of the card you have. The cardnumber can +be found in the source of zr36120. Look for tvcards. If your +card is not there, please try if any other card gives some +response, and mail me if you got a working tvcard addition. + +PS. <TVCard editors behold!) + Dont forget to set video_input to the number of inputs + you defined in the video_mux part of the tvcard definition. + Its a common error to add a channel but not incrementing + video_input and getting angry with me/v4l/linux/linus :( + +You are now ready to test the framegrabber with your favorite +video4linux compatible tool + +------ Application ---------------------------------------- + +This device works with all Video4Linux compatible applications, +given the limitations in the TODO file. + +------ API ------------------------------------------------ + +This uses the V4L interface as of kernel release 2.1.116, and in +fact has not been tested on any lower version. There are a couple +of minor differences due to the fact that the amount of data returned +with each frame varies, and no doubt there are discrepancies due to my +misunderstanding of the API. I intend to convert this driver to the +new V4L2 API when it has stabilized more. + +------ Current state -------------------------------------- + +The driver is capable of overlaying a video image in screen, and +even capable of grabbing frames. It uses the BIGPHYSAREA patch +to allocate lots of large memory blocks when tis patch is +found in the kernel, but it doesn't need it. +The consequence is that, when loading the driver as a module, +the module may tell you it's out of memory, but 'free' says +otherwise. The reason is simple; the modules wants its memory +contiguous, not fragmented, and after a long uptime there +probably isn't a fragment of memory large enough... + +The driver uses a double buffering scheme, which should really +be an n-way buffer, depending on the size of allocated framebuffer +and the requested grab-size/format. +This current version also fixes a dead-lock situation during irq +time, which really, really froze my system... :) + +Good luck. + Pauline |