commit 6623e6205e36c310367009f3b01f5cbe7cc0005d · tjh.dev/kernel

+16 -399

Documentation/video4linux/API.html

··· 1 - <HTML><HEAD> 2 - <TITLE>Video4Linux Kernel API Reference v0.1:19990430</TITLE> 3 - </HEAD> 4 - <! Revision History: > 5 - <! 4/30/1999 - Fred Gleason (fredg@wava.com)> 6 - <! Documented extensions for the Radio Data System (RDS) extensions > 7 - <BODY bgcolor="#ffffff"> 8 - <H3>Devices</H3> 9 - Video4Linux provides the following sets of device files. These live on the 10 - character device formerly known as "/dev/bttv". /dev/bttv should be a 11 - symlink to /dev/video0 for most people. 12 - 13 - <TABLE> 14 - <TR><TH>Device Name</TH><TH>Minor Range</TH><TH>Function</TH> 15 - <TR><TD>/dev/video</TD><TD>0-63</TD><TD>Video Capture Interface</TD> 16 - <TR><TD>/dev/radio</TD><TD>64-127</TD><TD>AM/FM Radio Devices</TD> 17 - <TR><TD>/dev/vtx</TD><TD>192-223</TD><TD>Teletext Interface Chips</TD> 18 - <TR><TD>/dev/vbi</TD><TD>224-239</TD><TD>Raw VBI Data (Intercast/teletext)</TD> 19 - </TABLE> 20 - 21 - Video4Linux programs open and scan the devices to find what they are looking 22 - for. Capability queries define what each interface supports. The 23 - described API is only defined for video capture cards. The relevant subset 24 - applies to radio cards. Teletext interfaces talk the existing VTX API. 25 - 26 - <H3>Capability Query Ioctl</H3> 27 - The VIDIOCGCAP ioctl call is used to obtain the capability 28 - information for a video device. The struct video_capability object 29 - passed to the ioctl is completed and returned. It contains the following 30 - information 31 - 32 - <TABLE> 33 - <TR><TD>name[32]<TD>Canonical name for this interface</TD> 34 - <TR><TD>type<TD>Type of interface</TD> 35 - <TR><TD>channels<TD>Number of radio/tv channels if appropriate</TD> 36 - <TR><TD>audios<TD>Number of audio devices if appropriate</TD> 37 - <TR><TD>maxwidth<TD>Maximum capture width in pixels</TD> 38 - <TR><TD>maxheight<TD>Maximum capture height in pixels</TD> 39 - <TR><TD>minwidth<TD>Minimum capture width in pixels</TD> 40 - <TR><TD>minheight<TD>Minimum capture height in pixels</TD> 41 - </TABLE> 42 - 43 - The type field lists the capability flags for the device. These are 44 - as follows 45 - 46 - <TABLE> 47 - <TR><TH>Name</TH><TH>Description</TH> 48 - <TR><TD>VID_TYPE_CAPTURE<TD>Can capture to memory</TD> 49 - <TR><TD>VID_TYPE_TUNER<TD>Has a tuner of some form</TD> 50 - <TR><TD>VID_TYPE_TELETEXT<TD>Has teletext capability</TD> 51 - <TR><TD>VID_TYPE_OVERLAY<TD>Can overlay its image onto the frame buffer</TD> 52 - <TR><TD>VID_TYPE_CHROMAKEY<TD>Overlay is Chromakeyed</TD> 53 - <TR><TD>VID_TYPE_CLIPPING<TD>Overlay clipping is supported</TD> 54 - <TR><TD>VID_TYPE_FRAMERAM<TD>Overlay overwrites frame buffer memory</TD> 55 - <TR><TD>VID_TYPE_SCALES<TD>The hardware supports image scaling</TD> 56 - <TR><TD>VID_TYPE_MONOCHROME<TD>Image capture is grey scale only</TD> 57 - <TR><TD>VID_TYPE_SUBCAPTURE<TD>Capture can be of only part of the image</TD> 58 - </TABLE> 59 - 60 - The minimum and maximum sizes listed for a capture device do not imply all 61 - that all height/width ratios or sizes within the range are possible. A 62 - request to set a size will be honoured by the largest available capture 63 - size whose capture is no large than the requested rectangle in either 64 - direction. For example the quickcam has 3 fixed settings. 65 - 66 - <H3>Frame Buffer</H3> 67 - Capture cards that drop data directly onto the frame buffer must be told the 68 - base address of the frame buffer, its size and organisation. This is a 69 - privileged ioctl and one that eventually X itself should set. 70 - 71 - The VIDIOCSFBUF ioctl sets the frame buffer parameters for a capture 72 - card. If the card does not do direct writes to the frame buffer then this 73 - ioctl will be unsupported. The VIDIOCGFBUF ioctl returns the 74 - currently used parameters. The structure used in both cases is a 75 - struct video_buffer. 76 - 77 - <TABLE> 78 - <TR><TD>void *base</TD><TD>Base physical address of the buffer</TD> 79 - <TR><TD>int height</TD><TD>Height of the frame buffer</TD> 80 - <TR><TD>int width</TD><TD>Width of the frame buffer</TD> 81 - <TR><TD>int depth</TD><TD>Depth of the frame buffer</TD> 82 - <TR><TD>int bytesperline</TD><TD>Number of bytes of memory between the start of two adjacent lines</TD> 83 - </TABLE> 84 - 85 - Note that these values reflect the physical layout of the frame buffer. 86 - The visible area may be smaller. In fact under XFree86 this is commonly the 87 - case. XFree86 DGA can provide the parameters required to set up this ioctl. 88 - Setting the base address to NULL indicates there is no physical frame buffer 89 - access. 90 - 91 - <H3>Capture Windows</H3> 92 - The capture area is described by a struct video_window. This defines 93 - a capture area and the clipping information if relevant. The 94 - VIDIOCGWIN ioctl recovers the current settings and the 95 - VIDIOCSWIN sets new values. A successful call to VIDIOCSWIN 96 - indicates that a suitable set of parameters have been chosen. They do not 97 - indicate that exactly what was requested was granted. The program should 98 - call VIDIOCGWIN to check if the nearest match was suitable. The 99 - struct video_window contains the following fields. 100 - 101 - <TABLE> 102 - <TR><TD>x<TD>The X co-ordinate specified in X windows format.</TD> 103 - <TR><TD>y<TD>The Y co-ordinate specified in X windows format.</TD> 104 - <TR><TD>width<TD>The width of the image capture.</TD> 105 - <TR><TD>height<TD>The height of the image capture.</TD> 106 - <TR><TD>chromakey<TD>A host order RGB32 value for the chroma key.</TD> 107 - <TR><TD>flags<TD>Additional capture flags.</TD> 108 - <TR><TD>clips<TD>A list of clipping rectangles. (Set only)</TD> 109 - <TR><TD>clipcount<TD>The number of clipping rectangles. (Set only)</TD> 110 - </TABLE> 111 - 112 - Clipping rectangles are passed as an array. Each clip consists of the following 113 - fields available to the user. 114 - 115 - <TABLE> 116 - <TR><TD>x</TD><TD>X co-ordinate of rectangle to skip</TD> 117 - <TR><TD>y</TD><TD>Y co-ordinate of rectangle to skip</TD> 118 - <TR><TD>width</TD><TD>Width of rectangle to skip</TD> 119 - <TR><TD>height</TD><TD>Height of rectangle to skip</TD> 120 - </TABLE> 121 - 122 - Merely setting the window does not enable capturing. Overlay capturing 123 - (i.e. PCI-PCI transfer to the frame buffer of the video card) 124 - is activated by passing the VIDIOCCAPTURE ioctl a value of 1, and 125 - disabled by passing it a value of 0. 126 - 127 - Some capture devices can capture a subfield of the image they actually see. 128 - This is indicated when VIDEO_TYPE_SUBCAPTURE is defined. 129 - The video_capture describes the time and special subfields to capture. 130 - The video_capture structure contains the following fields. 131 - 132 - <TABLE> 133 - <TR><TD>x</TD><TD>X co-ordinate of source rectangle to grab</TD> 134 - <TR><TD>y</TD><TD>Y co-ordinate of source rectangle to grab</TD> 135 - <TR><TD>width</TD><TD>Width of source rectangle to grab</TD> 136 - <TR><TD>height</TD><TD>Height of source rectangle to grab</TD> 137 - <TR><TD>decimation</TD><TD>Decimation to apply</TD> 138 - <TR><TD>flags</TD><TD>Flag settings for grabbing</TD> 139 - </TABLE> 140 - The available flags are 141 - 142 - <TABLE> 143 - <TR><TH>Name</TH><TH>Description</TH> 144 - <TR><TD>VIDEO_CAPTURE_ODD<TD>Capture only odd frames</TD> 145 - <TR><TD>VIDEO_CAPTURE_EVEN<TD>Capture only even frames</TD> 146 - </TABLE> 147 - 148 - <H3>Video Sources</H3> 149 - Each video4linux video or audio device captures from one or more 150 - source channels. Each channel can be queries with the 151 - VDIOCGCHAN ioctl call. Before invoking this function the caller 152 - must set the channel field to the channel that is being queried. On return 153 - the struct video_channel is filled in with information about the 154 - nature of the channel itself. 155 - 156 - The VIDIOCSCHAN ioctl takes an integer argument and switches the 157 - capture to this input. It is not defined whether parameters such as colour 158 - settings or tuning are maintained across a channel switch. The caller should 159 - maintain settings as desired for each channel. (This is reasonable as 160 - different video inputs may have different properties). 161 - 162 - The struct video_channel consists of the following 163 - 164 - <TABLE> 165 - <TR><TD>channel</TD><TD>The channel number</TD> 166 - <TR><TD>name</TD><TD>The input name - preferably reflecting the label 167 - on the card input itself</TD> 168 - <TR><TD>tuners</TD><TD>Number of tuners for this input</TD> 169 - <TR><TD>flags</TD><TD>Properties the tuner has</TD> 170 - <TR><TD>type</TD><TD>Input type (if known)</TD> 171 - <TR><TD>norm<TD>The norm for this channel</TD> 172 - </TABLE> 173 - 174 - The flags defined are 175 - 176 - <TABLE> 177 - <TR><TD>VIDEO_VC_TUNER<TD>Channel has tuners.</TD> 178 - <TR><TD>VIDEO_VC_AUDIO<TD>Channel has audio.</TD> 179 - <TR><TD>VIDEO_VC_NORM<TD>Channel has norm setting.</TD> 180 - </TABLE> 181 - 182 - The types defined are 183 - 184 - <TABLE> 185 - <TR><TD>VIDEO_TYPE_TV<TD>The input is a TV input.</TD> 186 - <TR><TD>VIDEO_TYPE_CAMERA<TD>The input is a camera.</TD> 187 - </TABLE> 188 - 189 - <H3>Image Properties</H3> 190 - The image properties of the picture can be queried with the VIDIOCGPICT 191 - ioctl which fills in a struct video_picture. The VIDIOCSPICT 192 - ioctl allows values to be changed. All values except for the palette type 193 - are scaled between 0-65535. 194 - 195 - The struct video_picture consists of the following fields 196 - 197 - <TABLE> 198 - <TR><TD>brightness<TD>Picture brightness</TD> 199 - <TR><TD>hue<TD>Picture hue (colour only)</TD> 200 - <TR><TD>colour<TD>Picture colour (colour only)</TD> 201 - <TR><TD>contrast<TD>Picture contrast</TD> 202 - <TR><TD>whiteness<TD>The whiteness (greyscale only)</TD> 203 - <TR><TD>depth<TD>The capture depth (may need to match the frame buffer depth)</TD> 204 - <TR><TD>palette<TD>Reports the palette that should be used for this image</TD> 205 - </TABLE> 206 - 207 - The following palettes are defined 208 - 209 - <TABLE> 210 - <TR><TD>VIDEO_PALETTE_GREY<TD>Linear intensity grey scale (255 is brightest).</TD> 211 - <TR><TD>VIDEO_PALETTE_HI240<TD>The BT848 8bit colour cube.</TD> 212 - <TR><TD>VIDEO_PALETTE_RGB565<TD>RGB565 packed into 16 bit words.</TD> 213 - <TR><TD>VIDEO_PALETTE_RGB555<TD>RGV555 packed into 16 bit words, top bit undefined.</TD> 214 - <TR><TD>VIDEO_PALETTE_RGB24<TD>RGB888 packed into 24bit words.</TD> 215 - <TR><TD>VIDEO_PALETTE_RGB32<TD>RGB888 packed into the low 3 bytes of 32bit words. The top 8bits are undefined.</TD> 216 - <TR><TD>VIDEO_PALETTE_YUV422<TD>Video style YUV422 - 8bits packed 4bits Y 2bits U 2bits V</TD> 217 - <TR><TD>VIDEO_PALETTE_YUYV<TD>Describe me</TD> 218 - <TR><TD>VIDEO_PALETTE_UYVY<TD>Describe me</TD> 219 - <TR><TD>VIDEO_PALETTE_YUV420<TD>YUV420 capture</TD> 220 - <TR><TD>VIDEO_PALETTE_YUV411<TD>YUV411 capture</TD> 221 - <TR><TD>VIDEO_PALETTE_RAW<TD>RAW capture (BT848)</TD> 222 - <TR><TD>VIDEO_PALETTE_YUV422P<TD>YUV 4:2:2 Planar</TD> 223 - <TR><TD>VIDEO_PALETTE_YUV411P<TD>YUV 4:1:1 Planar</TD> 224 - </TABLE> 225 - 226 - <H3>Tuning</H3> 227 - Each video input channel can have one or more tuners associated with it. Many 228 - devices will not have tuners. TV cards and radio cards will have one or more 229 - tuners attached. 230 - 231 - Tuners are described by a struct video_tuner which can be obtained by 232 - the VIDIOCGTUNER ioctl. Fill in the tuner number in the structure 233 - then pass the structure to the ioctl to have the data filled in. The 234 - tuner can be switched using VIDIOCSTUNER which takes an integer argument 235 - giving the tuner to use. A struct tuner has the following fields 236 - 237 - <TABLE> 238 - <TR><TD>tuner<TD>Number of the tuner</TD> 239 - <TR><TD>name<TD>Canonical name for this tuner (eg FM/AM/TV)</TD> 240 - <TR><TD>rangelow<TD>Lowest tunable frequency</TD> 241 - <TR><TD>rangehigh<TD>Highest tunable frequency</TD> 242 - <TR><TD>flags<TD>Flags describing the tuner</TD> 243 - <TR><TD>mode<TD>The video signal mode if relevant</TD> 244 - <TR><TD>signal<TD>Signal strength if known - between 0-65535</TD> 245 - </TABLE> 246 - 247 - The following flags exist 248 - 249 - <TABLE> 250 - <TR><TD>VIDEO_TUNER_PAL<TD>PAL tuning is supported</TD> 251 - <TR><TD>VIDEO_TUNER_NTSC<TD>NTSC tuning is supported</TD> 252 - <TR><TD>VIDEO_TUNER_SECAM<TD>SECAM tuning is supported</TD> 253 - <TR><TD>VIDEO_TUNER_LOW<TD>Frequency is in a lower range</TD> 254 - <TR><TD>VIDEO_TUNER_NORM<TD>The norm for this tuner is settable</TD> 255 - <TR><TD>VIDEO_TUNER_STEREO_ON<TD>The tuner is seeing stereo audio</TD> 256 - <TR><TD>VIDEO_TUNER_RDS_ON<TD>The tuner is seeing a RDS datastream</TD> 257 - <TR><TD>VIDEO_TUNER_MBS_ON<TD>The tuner is seeing a MBS datastream</TD> 258 - </TABLE> 259 - 260 - The following modes are defined 261 - 262 - <TABLE> 263 - <TR><TD>VIDEO_MODE_PAL<TD>The tuner is in PAL mode</TD> 264 - <TR><TD>VIDEO_MODE_NTSC<TD>The tuner is in NTSC mode</TD> 265 - <TR><TD>VIDEO_MODE_SECAM<TD>The tuner is in SECAM mode</TD> 266 - <TR><TD>VIDEO_MODE_AUTO<TD>The tuner auto switches, or mode does not apply</TD> 267 - </TABLE> 268 - 269 - Tuning frequencies are an unsigned 32bit value in 1/16th MHz or if the 270 - VIDEO_TUNER_LOW flag is set they are in 1/16th KHz. The current 271 - frequency is obtained as an unsigned long via the VIDIOCGFREQ ioctl and 272 - set by the VIDIOCSFREQ ioctl. 273 - 274 - <H3>Audio</H3> 275 - TV and Radio devices have one or more audio inputs that may be selected. 276 - The audio properties are queried by passing a struct video_audio to VIDIOCGAUDIO ioctl. The 277 - VIDIOCSAUDIO ioctl sets audio properties. 278 - 279 - The structure contains the following fields 280 - 281 - <TABLE> 282 - <TR><TD>audio<TD>The channel number</TD> 283 - <TR><TD>volume<TD>The volume level</TD> 284 - <TR><TD>bass<TD>The bass level</TD> 285 - <TR><TD>treble<TD>The treble level</TD> 286 - <TR><TD>flags<TD>Flags describing the audio channel</TD> 287 - <TR><TD>name<TD>Canonical name for the audio input</TD> 288 - <TR><TD>mode<TD>The mode the audio input is in</TD> 289 - <TR><TD>balance<TD>The left/right balance</TD> 290 - <TR><TD>step<TD>Actual step used by the hardware</TD> 291 - </TABLE> 292 - 293 - The following flags are defined 294 - 295 - <TABLE> 296 - <TR><TD>VIDEO_AUDIO_MUTE<TD>The audio is muted</TD> 297 - <TR><TD>VIDEO_AUDIO_MUTABLE<TD>Audio muting is supported</TD> 298 - <TR><TD>VIDEO_AUDIO_VOLUME<TD>The volume is controllable</TD> 299 - <TR><TD>VIDEO_AUDIO_BASS<TD>The bass is controllable</TD> 300 - <TR><TD>VIDEO_AUDIO_TREBLE<TD>The treble is controllable</TD> 301 - <TR><TD>VIDEO_AUDIO_BALANCE<TD>The balance is controllable</TD> 302 - </TABLE> 303 - 304 - The following decoding modes are defined 305 - 306 - <TABLE> 307 - <TR><TD>VIDEO_SOUND_MONO<TD>Mono signal</TD> 308 - <TR><TD>VIDEO_SOUND_STEREO<TD>Stereo signal (NICAM for TV)</TD> 309 - <TR><TD>VIDEO_SOUND_LANG1<TD>European TV alternate language 1</TD> 310 - <TR><TD>VIDEO_SOUND_LANG2<TD>European TV alternate language 2</TD> 311 - </TABLE> 312 - 313 - <H3>Reading Images</H3> 314 - Each call to the read syscall returns the next available image 315 - from the device. It is up to the caller to set format and size (using 316 - the VIDIOCSPICT and VIDIOCSWIN ioctls) and then to pass a suitable 317 - size buffer and length to the function. Not all devices will support 318 - read operations. 319 - 320 - A second way to handle image capture is via the mmap interface if supported. 321 - To use the mmap interface a user first sets the desired image size and depth 322 - properties. Next the VIDIOCGMBUF ioctl is issued. This reports the size 323 - of buffer to mmap and the offset within the buffer for each frame. The 324 - number of frames supported is device dependent and may only be one. 325 - 326 - The video_mbuf structure contains the following fields 327 - 328 - <TABLE> 329 - <TR><TD>size<TD>The number of bytes to map</TD> 330 - <TR><TD>frames<TD>The number of frames</TD> 331 - <TR><TD>offsets<TD>The offset of each frame</TD> 332 - </TABLE> 333 - 334 - Once the mmap has been made the VIDIOCMCAPTURE ioctl starts the 335 - capture to a frame using the format and image size specified in the 336 - video_mmap (which should match or be below the initial query size). 337 - When the VIDIOCMCAPTURE ioctl returns the frame is not 338 - captured yet, the driver just instructed the hardware to start the 339 - capture. The application has to use the VIDIOCSYNC ioctl to wait 340 - until the capture of a frame is finished. VIDIOCSYNC takes the frame 341 - number you want to wait for as argument. 342 - 343 - It is allowed to call VIDIOCMCAPTURE multiple times (with different 344 - frame numbers in video_mmap->frame of course) and thus have multiple 345 - outstanding capture requests. A simple way do to double-buffering 346 - using this feature looks like this: 347 - <pre> 348 - /* setup everything */ 349 - VIDIOCMCAPTURE(0) 350 - while (whatever) { 351 - VIDIOCMCAPTURE(1) 352 - VIDIOCSYNC(0) 353 - /* process frame 0 while the hardware captures frame 1 */ 354 - VIDIOCMCAPTURE(0) 355 - VIDIOCSYNC(1) 356 - /* process frame 1 while the hardware captures frame 0 */ 357 - } 358 - </pre> 359 - Note that you are not limited to only two frames. The API 360 - allows up to 32 frames, the VIDIOCGMBUF ioctl returns the number of 361 - frames the driver granted. Thus it is possible to build deeper queues 362 - to avoid loosing frames on load peaks. 363 - 364 - While capturing to memory the driver will make a "best effort" attempt 365 - to capture to screen as well if requested. This normally means all 366 - frames that "miss" memory mapped capture will go to the display. 367 - 368 - A final ioctl exists to allow a device to obtain related devices if a 369 - driver has multiple components (for example video0 may not be associated 370 - with vbi0 which would cause an intercast display program to make a bad 371 - mistake). The VIDIOCGUNIT ioctl reports the unit numbers of the associated 372 - devices if any exist. The video_unit structure has the following fields. 373 - 374 - <TABLE> 375 - <TR><TD>video<TD>Video capture device</TD> 376 - <TR><TD>vbi<TD>VBI capture device</TD> 377 - <TR><TD>radio<TD>Radio device</TD> 378 - <TR><TD>audio<TD>Audio mixer</TD> 379 - <TR><TD>teletext<TD>Teletext device</TD> 380 - </TABLE> 381 - 382 - <H3>RDS Datastreams</H3> 383 - For radio devices that support it, it is possible to receive Radio Data 384 - System (RDS) data by means of a read() on the device. The data is packed in 385 - groups of three, as follows: 386 - <TABLE> 387 - <TR><TD>First Octet</TD><TD>Least Significant Byte of RDS Block</TD></TR> 388 - <TR><TD>Second Octet</TD><TD>Most Significant Byte of RDS Block 389 - <TR><TD>Third Octet</TD><TD>Bit 7:</TD><TD>Error bit. Indicates that 390 - an uncorrectable error occurred during reception of this block.</TD></TR> 391 - <TR><TD> </TD><TD>Bit 6:</TD><TD>Corrected bit. Indicates that 392 - an error was corrected for this data block.</TD></TR> 393 - <TR><TD> </TD><TD>Bits 5-3:</TD><TD>Received Offset. Indicates the 394 - offset received by the sync system.</TD></TR> 395 - <TR><TD> </TD><TD>Bits 2-0:</TD><TD>Offset Name. Indicates the 396 - offset applied to this data.</TD></TR> 397 - </TABLE> 398 - </BODY> 399 - </HTML> 1 + <TITLE>V4L API</TITLE> 2 + <H1>Video For Linux APIs</H1> 3 + <table border=0> 4 + <tr> 5 + <td> 6 + <A HREF=http://www.linuxtv.org/downloads/video4linux/API/V4L1_API.html> 7 + V4L original API</a> 8 + </td><td> 9 + Obsoleted by V4L2 API 10 + </td></tr><tr><td> 11 + <A HREF=http://www.linuxtv.org/downloads/video4linux/API/V4L2_API.html> 12 + V4L2 API</a> 13 + </td><td> 14 + Should be used for new projects 15 + </td></tr> 16 + </table>

+4 -4

Documentation/video4linux/CARDLIST.cx88

··· 13 13 card=12 - ASUS PVR-416 14 14 card=13 - MSI TV-@nywhere 15 15 card=14 - KWorld/VStream XPert DVB-T 16 - card=15 - DVICO FusionHDTV DVB-T1 16 + card=15 - DViCO FusionHDTV DVB-T1 17 17 card=16 - KWorld LTV883RF 18 - card=17 - DViCO - FusionHDTV 3 Gold 18 + card=17 - DViCO FusionHDTV 3 Gold-Q 19 19 card=18 - Hauppauge Nova-T DVB-T 20 20 card=19 - Conexant DVB-T reference design 21 21 card=20 - Provideo PV259 22 - card=21 - DVICO FusionHDTV DVB-T Plus 22 + card=21 - DViCO FusionHDTV DVB-T Plus 23 23 card=22 - digitalnow DNTV Live! DVB-T 24 24 card=23 - pcHDTV HD3000 HDTV 25 25 card=24 - Hauppauge WinTV 28xxx (Roslyn) models 26 26 card=25 - Digital-Logic MICROSPACE Entertainment Center (MEC) 27 27 card=26 - IODATA GV/BCTV7E 28 28 card=27 - PixelView PlayTV Ultra Pro (Stereo) 29 - card=28 - DViCO - FusionHDTV 3 Gold-T 29 + card=28 - DViCO FusionHDTV 3 Gold-T

+6

Documentation/video4linux/CARDLIST.saa7134

··· 54 54 55 -> LifeView FlyDVB-T DUO [5168:0306] 55 55 56 -> Avermedia AVerTV 307 [1461:a70a] 56 56 57 -> Avermedia AVerTV GO 007 FM [1461:f31f] 57 + 58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0370] 58 + 59 -> Kworld/Tevion V-Stream Xpert TV PVR7134 59 + 60 -> Typhoon DVB-T Duo Digital/Analog Cardbus 60 + 61 -> Philips TOUGH DVB-T reference design 61 + 62 -> Compro VideoMate TV Gold+II 62 + 63 -> Kworld Xpert TV PVR7134

+3

Documentation/video4linux/CARDLIST.tuner

··· 59 59 tuner=58 - Ymec TVision TVF-8531MF 60 60 tuner=59 - Ymec TVision TVF-5533MF 61 61 tuner=60 - Thomson DDT 7611 (ATSC/NTSC) 62 + tuner=61 - Tena TNF9533-D/IF 63 + tuner=62 - Philips TEA5767HN FM Radio 64 + tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner

+9

Documentation/video4linux/README.saa7134

··· 57 57 - 24.576MHz -> .audio_clock=0x200000 58 58 (xtal * .audio_clock = 51539600) 59 59 60 + Some details about 30/34/35: 61 + 62 + - saa7130 - low-price chip, doesn't have mute, that is why all those 63 + cards should have .mute field defined in their tuner structure. 64 + 65 + - saa7134 - usual chip 66 + 67 + - saa7133/35 - saa7135 is probably a marketing decision, since all those 68 + chips identifies itself as 33 on pci. 60 69 61 70 Credits 62 71 =======