diff options
Diffstat (limited to 'Documentation/video4linux')
72 files changed, 0 insertions, 12961 deletions
diff --git a/Documentation/video4linux/4CCs.txt b/Documentation/video4linux/4CCs.txt deleted file mode 100644 index 41241af1e..000000000 --- a/Documentation/video4linux/4CCs.txt +++ /dev/null @@ -1,32 +0,0 @@ -Guidelines for Linux4Linux pixel format 4CCs -============================================ - -Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are -specified in this document. First of the characters defines the nature of -the pixel format, compression and colour space. The interpretation of the -other three characters depends on the first one. - -Existing 4CCs may not obey these guidelines. - -Formats -======= - -Raw bayer ---------- - -The following first characters are used by raw bayer formats: - - B: raw bayer, uncompressed - b: raw bayer, DPCM compressed - a: A-law compressed - u: u-law compressed - -2nd character: pixel order - B: BGGR - G: GBRG - g: GRBG - R: RGGB - -3rd character: uncompressed bits-per-pixel 0--9, A-- - -4th character: compressed bits-per-pixel 0--9, A-- diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html deleted file mode 100644 index eaf948cf1..000000000 --- a/Documentation/video4linux/API.html +++ /dev/null @@ -1,27 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> - <head> - <meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type" /> - <title>V4L API</title> - </head> - <body> - <h1>Video For Linux APIs</h1> - <table border="0"> - <tr> - <td> - <a href="https://linuxtv.org/downloads/legacy/video4linux/API/V4L1_API.html">V4L original API</a> - </td> - <td> - Obsoleted by V4L2 API - </td> - </tr> - <tr> - <td> - <a href="http://v4l2spec.bytesex.org/spec-single/v4l2.html">V4L2 API</a> - </td> - <td>Should be used for new projects - </td> - </tr> - </table> - </body> -</html> diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 deleted file mode 100644 index 55a21deab..000000000 --- a/Documentation/video4linux/CARDLIST.au0828 +++ /dev/null @@ -1,6 +0,0 @@ - 0 -> Unknown board (au0828) - 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213,2040:7270] - 2 -> Hauppauge HVR850 (au0828) [2040:7240] - 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] - 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] - 5 -> Hauppauge Woodbury (au0828) [05e1:0480,2040:8200] diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv deleted file mode 100644 index b092c0a14..000000000 --- a/Documentation/video4linux/CARDLIST.bttv +++ /dev/null @@ -1,167 +0,0 @@ - 0 -> *** UNKNOWN/GENERIC *** - 1 -> MIRO PCTV - 2 -> Hauppauge (bt848) - 3 -> STB, Gateway P/N 6000699 (bt848) - 4 -> Intel Create and Share PCI/ Smart Video Recorder III - 5 -> Diamond DTV2000 - 6 -> AVerMedia TVPhone - 7 -> MATRIX-Vision MV-Delta - 8 -> Lifeview FlyVideo II (Bt848) LR26 / MAXI TV Video PCI2 LR26 - 9 -> IMS/IXmicro TurboTV - 10 -> Hauppauge (bt878) [0070:13eb,0070:3900,2636:10b4] - 11 -> MIRO PCTV pro - 12 -> ADS Technologies Channel Surfer TV (bt848) - 13 -> AVerMedia TVCapture 98 [1461:0002,1461:0004,1461:0300] - 14 -> Aimslab Video Highway Xtreme (VHX) - 15 -> Zoltrix TV-Max [a1a0:a0fc] - 16 -> Prolink Pixelview PlayTV (bt878) - 17 -> Leadtek WinView 601 - 18 -> AVEC Intercapture - 19 -> Lifeview FlyVideo II EZ /FlyKit LR38 Bt848 (capture only) - 20 -> CEI Raffles Card - 21 -> Lifeview FlyVideo 98/ Lucky Star Image World ConferenceTV LR50 - 22 -> Askey CPH050/ Phoebe Tv Master + FM [14ff:3002] - 23 -> Modular Technology MM201/MM202/MM205/MM210/MM215 PCTV, bt878 [14c7:0101] - 24 -> Askey CPH05X/06X (bt878) [many vendors] [144f:3002,144f:3005,144f:5000,14ff:3000] - 25 -> Terratec TerraTV+ Version 1.0 (Bt848)/ Terra TValue Version 1.0/ Vobis TV-Boostar - 26 -> Hauppauge WinCam newer (bt878) - 27 -> Lifeview FlyVideo 98/ MAXI TV Video PCI2 LR50 - 28 -> Terratec TerraTV+ Version 1.1 (bt878) [153b:1127,1852:1852] - 29 -> Imagenation PXC200 [1295:200a] - 30 -> Lifeview FlyVideo 98 LR50 [1f7f:1850] - 31 -> Formac iProTV, Formac ProTV I (bt848) - 32 -> Intel Create and Share PCI/ Smart Video Recorder III - 33 -> Terratec TerraTValue Version Bt878 [153b:1117,153b:1118,153b:1119,153b:111a,153b:1134,153b:5018] - 34 -> Leadtek WinFast 2000/ WinFast 2000 XP [107d:6606,107d:6609,6606:217d,f6ff:fff6] - 35 -> Lifeview FlyVideo 98 LR50 / Chronos Video Shuttle II [1851:1850,1851:a050] - 36 -> Lifeview FlyVideo 98FM LR50 / Typhoon TView TV/FM Tuner [1852:1852] - 37 -> Prolink PixelView PlayTV pro - 38 -> Askey CPH06X TView99 [144f:3000,144f:a005,a04f:a0fc] - 39 -> Pinnacle PCTV Studio/Rave [11bd:0012,bd11:1200,bd11:ff00,11bd:ff12] - 40 -> STB TV PCI FM, Gateway P/N 6000704 (bt878), 3Dfx VoodooTV 100 [10b4:2636,10b4:2645,121a:3060] - 41 -> AVerMedia TVPhone 98 [1461:0001,1461:0003] - 42 -> ProVideo PV951 [aa0c:146c] - 43 -> Little OnAir TV - 44 -> Sigma TVII-FM - 45 -> MATRIX-Vision MV-Delta 2 - 46 -> Zoltrix Genie TV/FM [15b0:4000,15b0:400a,15b0:400d,15b0:4010,15b0:4016] - 47 -> Terratec TV/Radio+ [153b:1123] - 48 -> Askey CPH03x/ Dynalink Magic TView - 49 -> IODATA GV-BCTV3/PCI [10fc:4020] - 50 -> Prolink PV-BT878P+4E / PixelView PlayTV PAK / Lenco MXTV-9578 CP - 51 -> Eagle Wireless Capricorn2 (bt878A) - 52 -> Pinnacle PCTV Studio Pro - 53 -> Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS - 54 -> Lifeview FlyVideo 2000 /FlyVideo A2/ Lifetec LT 9415 TV [LR90] - 55 -> Askey CPH031/ BESTBUY Easy TV - 56 -> Lifeview FlyVideo 98FM LR50 [a051:41a0] - 57 -> GrandTec 'Grand Video Capture' (Bt848) [4344:4142] - 58 -> Askey CPH060/ Phoebe TV Master Only (No FM) - 59 -> Askey CPH03x TV Capturer - 60 -> Modular Technology MM100PCTV - 61 -> AG Electronics GMV1 [15cb:0101] - 62 -> Askey CPH061/ BESTBUY Easy TV (bt878) - 63 -> ATI TV-Wonder [1002:0001] - 64 -> ATI TV-Wonder VE [1002:0003] - 65 -> Lifeview FlyVideo 2000S LR90 - 66 -> Terratec TValueRadio [153b:1135,153b:ff3b] - 67 -> IODATA GV-BCTV4/PCI [10fc:4050] - 68 -> 3Dfx VoodooTV FM (Euro) [10b4:2637] - 69 -> Active Imaging AIMMS - 70 -> Prolink Pixelview PV-BT878P+ (Rev.4C,8E) - 71 -> Lifeview FlyVideo 98EZ (capture only) LR51 [1851:1851] - 72 -> Prolink Pixelview PV-BT878P+9B (PlayTV Pro rev.9B FM+NICAM) [1554:4011] - 73 -> Sensoray 311/611 [6000:0311,6000:0611] - 74 -> RemoteVision MX (RV605) - 75 -> Powercolor MTV878/ MTV878R/ MTV878F - 76 -> Canopus WinDVR PCI (COMPAQ Presario 3524JP, 5112JP) [0e11:0079] - 77 -> GrandTec Multi Capture Card (Bt878) - 78 -> Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF [0a01:17de] - 79 -> DSP Design TCVIDEO - 80 -> Hauppauge WinTV PVR [0070:4500] - 81 -> IODATA GV-BCTV5/PCI [10fc:4070,10fc:d018] - 82 -> Osprey 100/150 (878) [0070:ff00] - 83 -> Osprey 100/150 (848) - 84 -> Osprey 101 (848) - 85 -> Osprey 101/151 - 86 -> Osprey 101/151 w/ svid - 87 -> Osprey 200/201/250/251 - 88 -> Osprey 200/250 [0070:ff01] - 89 -> Osprey 210/220/230 - 90 -> Osprey 500 [0070:ff02] - 91 -> Osprey 540 [0070:ff04] - 92 -> Osprey 2000 [0070:ff03] - 93 -> IDS Eagle - 94 -> Pinnacle PCTV Sat [11bd:001c] - 95 -> Formac ProTV II (bt878) - 96 -> MachTV - 97 -> Euresys Picolo - 98 -> ProVideo PV150 [aa00:1460,aa01:1461,aa02:1462,aa03:1463,aa04:1464,aa05:1465,aa06:1466,aa07:1467] - 99 -> AD-TVK503 -100 -> Hercules Smart TV Stereo -101 -> Pace TV & Radio Card -102 -> IVC-200 [0000:a155,0001:a155,0002:a155,0003:a155,0100:a155,0101:a155,0102:a155,0103:a155,0800:a155,0801:a155,0802:a155,0803:a155] -103 -> Grand X-Guard / Trust 814PCI [0304:0102] -104 -> Nebula Electronics DigiTV [0071:0101] -105 -> ProVideo PV143 [aa00:1430,aa00:1431,aa00:1432,aa00:1433,aa03:1433] -106 -> PHYTEC VD-009-X1 VD-011 MiniDIN (bt878) -107 -> PHYTEC VD-009-X1 VD-011 Combi (bt878) -108 -> PHYTEC VD-009 MiniDIN (bt878) -109 -> PHYTEC VD-009 Combi (bt878) -110 -> IVC-100 [ff00:a132] -111 -> IVC-120G [ff00:a182,ff01:a182,ff02:a182,ff03:a182,ff04:a182,ff05:a182,ff06:a182,ff07:a182,ff08:a182,ff09:a182,ff0a:a182,ff0b:a182,ff0c:a182,ff0d:a182,ff0e:a182,ff0f:a182] -112 -> pcHDTV HD-2000 TV [7063:2000] -113 -> Twinhan DST + clones [11bd:0026,1822:0001,270f:fc00,1822:0026] -114 -> Winfast VC100 [107d:6607] -115 -> Teppro TEV-560/InterVision IV-560 -116 -> SIMUS GVC1100 [aa6a:82b2] -117 -> NGS NGSTV+ -118 -> LMLBT4 -119 -> Tekram M205 PRO -120 -> Conceptronic CONTVFMi -121 -> Euresys Picolo Tetra [1805:0105,1805:0106,1805:0107,1805:0108] -122 -> Spirit TV Tuner -123 -> AVerMedia AVerTV DVB-T 771 [1461:0771] -124 -> AverMedia AverTV DVB-T 761 [1461:0761] -125 -> MATRIX Vision Sigma-SQ -126 -> MATRIX Vision Sigma-SLC -127 -> APAC Viewcomp 878(AMAX) -128 -> DViCO FusionHDTV DVB-T Lite [18ac:db10,18ac:db11] -129 -> V-Gear MyVCD -130 -> Super TV Tuner -131 -> Tibet Systems 'Progress DVR' CS16 -132 -> Kodicom 4400R (master) -133 -> Kodicom 4400R (slave) -134 -> Adlink RTV24 -135 -> DViCO FusionHDTV 5 Lite [18ac:d500] -136 -> Acorp Y878F [9511:1540] -137 -> Conceptronic CTVFMi v2 [036e:109e] -138 -> Prolink Pixelview PV-BT878P+ (Rev.2E) -139 -> Prolink PixelView PlayTV MPEG2 PV-M4900 -140 -> Osprey 440 [0070:ff07] -141 -> Asound Skyeye PCTV -142 -> Sabrent TV-FM (bttv version) -143 -> Hauppauge ImpactVCB (bt878) [0070:13eb] -144 -> MagicTV -145 -> SSAI Security Video Interface [4149:5353] -146 -> SSAI Ultrasound Video Interface [414a:5353] -147 -> VoodooTV 200 (USA) [121a:3000] -148 -> DViCO FusionHDTV 2 [dbc0:d200] -149 -> Typhoon TV-Tuner PCI (50684) -150 -> Geovision GV-600 [008a:763c] -151 -> Kozumi KTV-01C -152 -> Encore ENL TV-FM-2 [1000:1801] -153 -> PHYTEC VD-012 (bt878) -154 -> PHYTEC VD-012-X1 (bt878) -155 -> PHYTEC VD-012-X2 (bt878) -156 -> IVCE-8784 [0000:f050,0001:f050,0002:f050,0003:f050] -157 -> Geovision GV-800(S) (master) [800a:763d] -158 -> Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d] -159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540] -160 -> Tongwei Video Technology TD-3116 [f200:3116] -161 -> Aposonic W-DVR [0279:0228] -162 -> Adlink MPG24 -163 -> Bt848 Capture 14MHz -164 -> CyberVision CV06 (SV) -165 -> Kworld V-Stream Xpert TV PVR878 -166 -> PCI-8604PW diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 deleted file mode 100644 index 85a8fdcfc..000000000 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ /dev/null @@ -1,56 +0,0 @@ - 0 -> UNKNOWN/GENERIC [0070:3400] - 1 -> Hauppauge WinTV-HVR1800lp [0070:7600] - 2 -> Hauppauge WinTV-HVR1800 [0070:7800,0070:7801,0070:7809] - 3 -> Hauppauge WinTV-HVR1250 [0070:7911] - 4 -> DViCO FusionHDTV5 Express [18ac:d500] - 5 -> Hauppauge WinTV-HVR1500Q [0070:7790,0070:7797] - 6 -> Hauppauge WinTV-HVR1500 [0070:7710,0070:7717] - 7 -> Hauppauge WinTV-HVR1200 [0070:71d1,0070:71d3] - 8 -> Hauppauge WinTV-HVR1700 [0070:8101] - 9 -> Hauppauge WinTV-HVR1400 [0070:8010] - 10 -> DViCO FusionHDTV7 Dual Express [18ac:d618] - 11 -> DViCO FusionHDTV DVB-T Dual Express [18ac:db78] - 12 -> Leadtek Winfast PxDVR3200 H [107d:6681] - 13 -> Compro VideoMate E650F [185b:e800] - 14 -> TurboSight TBS 6920 [6920:8888] - 15 -> TeVii S470 [d470:9022] - 16 -> DVBWorld DVB-S2 2005 [0001:2005] - 17 -> NetUP Dual DVB-S2 CI [1b55:2a2c] - 18 -> Hauppauge WinTV-HVR1270 [0070:2211] - 19 -> Hauppauge WinTV-HVR1275 [0070:2215,0070:221d,0070:22f2] - 20 -> Hauppauge WinTV-HVR1255 [0070:2251,0070:22f1] - 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295,0070:2299,0070:229d,0070:22f0,0070:22f3,0070:22f4,0070:22f5] - 22 -> Mygica X8506 DMB-TH [14f1:8651] - 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] - 24 -> Hauppauge WinTV-HVR1850 [0070:8541] - 25 -> Compro VideoMate E800 [1858:e800] - 26 -> Hauppauge WinTV-HVR1290 [0070:8551] - 27 -> Mygica X8558 PRO DMB-TH [14f1:8578] - 28 -> LEADTEK WinFast PxTV1200 [107d:6f22] - 29 -> GoTView X5 3D Hybrid [5654:2390] - 30 -> NetUP Dual DVB-T/C-CI RF [1b55:e2e4] - 31 -> Leadtek Winfast PxDVR3200 H XC4000 [107d:6f39] - 32 -> MPX-885 - 33 -> Mygica X8502/X8507 ISDB-T [14f1:8502] - 34 -> TerraTec Cinergy T PCIe Dual [153b:117e] - 35 -> TeVii S471 [d471:9022] - 36 -> Hauppauge WinTV-HVR1255 [0070:2259] - 37 -> Prof Revolution DVB-S2 8000 [8000:3034] - 38 -> Hauppauge WinTV-HVR4400/HVR5500 [0070:c108,0070:c138,0070:c1f8] - 39 -> AVerTV Hybrid Express Slim HC81R [1461:d939] - 40 -> TurboSight TBS 6981 [6981:8888] - 41 -> TurboSight TBS 6980 [6980:8888] - 42 -> Leadtek Winfast PxPVR2200 [107d:6f21] - 43 -> Hauppauge ImpactVCB-e [0070:7133] - 44 -> DViCO FusionHDTV DVB-T Dual Express2 [18ac:db98] - 45 -> DVBSky T9580 [4254:9580] - 46 -> DVBSky T980C [4254:980c] - 47 -> DVBSky S950C [4254:950c] - 48 -> Technotrend TT-budget CT2-4500 CI [13c2:3013] - 49 -> DVBSky S950 [4254:0950] - 50 -> DVBSky S952 [4254:0952] - 51 -> DVBSky T982 [4254:0982] - 52 -> Hauppauge WinTV-HVR5525 [0070:f038] - 53 -> Hauppauge WinTV Starburst [0070:c12a] - 54 -> ViewCast 260e [1576:0260] - 55 -> ViewCast 460e [1576:0460] diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 deleted file mode 100644 index fa4b3f947..000000000 --- a/Documentation/video4linux/CARDLIST.cx88 +++ /dev/null @@ -1,91 +0,0 @@ - 0 -> UNKNOWN/GENERIC - 1 -> Hauppauge WinTV 34xxx models [0070:3400,0070:3401] - 2 -> GDI Black Gold [14c7:0106,14c7:0107] - 3 -> PixelView [1554:4811] - 4 -> ATI TV Wonder Pro [1002:00f8,1002:00f9] - 5 -> Leadtek Winfast 2000XP Expert [107d:6611,107d:6613] - 6 -> AverTV Studio 303 (M126) [1461:000b] - 7 -> MSI TV-@nywhere Master [1462:8606] - 8 -> Leadtek Winfast DV2000 [107d:6620,107d:6621] - 9 -> Leadtek PVR 2000 [107d:663b,107d:663c,107d:6632,107d:6630,107d:6638,107d:6631,107d:6637,107d:663d] - 10 -> IODATA GV-VCP3/PCI [10fc:d003] - 11 -> Prolink PlayTV PVR - 12 -> ASUS PVR-416 [1043:4823,1461:c111] - 13 -> MSI TV-@nywhere - 14 -> KWorld/VStream XPert DVB-T [17de:08a6] - 15 -> DViCO FusionHDTV DVB-T1 [18ac:db00] - 16 -> KWorld LTV883RF - 17 -> DViCO FusionHDTV 3 Gold-Q [18ac:d810,18ac:d800] - 18 -> Hauppauge Nova-T DVB-T [0070:9002,0070:9001,0070:9000] - 19 -> Conexant DVB-T reference design [14f1:0187] - 20 -> Provideo PV259 [1540:2580] - 21 -> DViCO FusionHDTV DVB-T Plus [18ac:db10,18ac:db11] - 22 -> pcHDTV HD3000 HDTV [7063:3000] - 23 -> digitalnow DNTV Live! DVB-T [17de:a8a6] - 24 -> Hauppauge WinTV 28xxx (Roslyn) models [0070:2801] - 25 -> Digital-Logic MICROSPACE Entertainment Center (MEC) [14f1:0342] - 26 -> IODATA GV/BCTV7E [10fc:d035] - 27 -> PixelView PlayTV Ultra Pro (Stereo) - 28 -> DViCO FusionHDTV 3 Gold-T [18ac:d820] - 29 -> ADS Tech Instant TV DVB-T PCI [1421:0334] - 30 -> TerraTec Cinergy 1400 DVB-T [153b:1166] - 31 -> DViCO FusionHDTV 5 Gold [18ac:d500] - 32 -> AverMedia UltraTV Media Center PCI 550 [1461:8011] - 33 -> Kworld V-Stream Xpert DVD - 34 -> ATI HDTV Wonder [1002:a101] - 35 -> WinFast DTV1000-T [107d:665f] - 36 -> AVerTV 303 (M126) [1461:000a] - 37 -> Hauppauge Nova-S-Plus DVB-S [0070:9201,0070:9202] - 38 -> Hauppauge Nova-SE2 DVB-S [0070:9200] - 39 -> KWorld DVB-S 100 [17de:08b2,1421:0341] - 40 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid [0070:9400,0070:9402] - 41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile) [0070:9800,0070:9802] - 42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025,1822:0019] - 43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1,12ab:2300] - 44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54] - 45 -> KWorld HardwareMpegTV XPert [17de:0840,1421:0305] - 46 -> DViCO FusionHDTV DVB-T Hybrid [18ac:db40,18ac:db44] - 47 -> pcHDTV HD5500 HDTV [7063:5500] - 48 -> Kworld MCE 200 Deluxe [17de:0841] - 49 -> PixelView PlayTV P7000 [1554:4813] - 50 -> NPG Tech Real TV FM Top 10 [14f1:0842] - 51 -> WinFast DTV2000 H [107d:665e] - 52 -> Geniatech DVB-S [14f1:0084] - 53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404,0070:1400,0070:1401,0070:1402] - 54 -> Norwood Micro TV Tuner - 55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980] - 56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602] - 57 -> ADS Tech Instant Video PCI [1421:0390] - 58 -> Pinnacle PCTV HD 800i [11bd:0051] - 59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530] - 60 -> Pinnacle Hybrid PCTV [12ab:1788] - 61 -> Leadtek TV2000 XP Global [107d:6f18,107d:6618,107d:6619] - 62 -> PowerColor RA330 [14f1:ea3d] - 63 -> Geniatech X8000-MT DVBT [14f1:8852] - 64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30] - 65 -> DViCO FusionHDTV 7 Gold [18ac:d610] - 66 -> Prolink Pixelview MPEG 8000GT [1554:4935] - 67 -> Kworld PlusTV HD PCI 120 (ATSC 120) [17de:08c1] - 68 -> Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [0070:6900,0070:6904,0070:6902] - 69 -> Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [0070:6905,0070:6906] - 70 -> TeVii S460 DVB-S/S2 [d460:9022] - 71 -> Omicom SS4 DVB-S/S2 PCI [A044:2011] - 72 -> TBS 8920 DVB-S/S2 [8920:8888] - 73 -> TeVii S420 DVB-S [d420:9022] - 74 -> Prolink Pixelview Global Extreme [1554:4976] - 75 -> PROF 7300 DVB-S/S2 [B033:3033] - 76 -> SATTRADE ST4200 DVB-S/S2 [b200:4200] - 77 -> TBS 8910 DVB-S [8910:8888] - 78 -> Prof 6200 DVB-S [b022:3022] - 79 -> Terratec Cinergy HT PCI MKII [153b:1177] - 80 -> Hauppauge WinTV-IR Only [0070:9290] - 81 -> Leadtek WinFast DTV1800 Hybrid [107d:6654] - 82 -> WinFast DTV2000 H rev. J [107d:6f2b] - 83 -> Prof 7301 DVB-S/S2 [b034:3034] - 84 -> Samsung SMT 7020 DVB-S [18ac:dc00,18ac:dccd] - 85 -> Twinhan VP-1027 DVB-S [1822:0023] - 86 -> TeVii S464 DVB-S/S2 [d464:9022] - 87 -> Leadtek WinFast DTV2000 H PLUS [107d:6f42] - 88 -> Leadtek WinFast DTV1800 H (XC4000) [107d:6f38] - 89 -> Leadtek TV2000 XP Global (SC4100) [107d:6f36] - 90 -> Leadtek TV2000 XP Global (XC4100) [107d:6f43] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx deleted file mode 100644 index 6784220c6..000000000 --- a/Documentation/video4linux/CARDLIST.em28xx +++ /dev/null @@ -1,100 +0,0 @@ - 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] - 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2863,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868,eb1a:2875] - 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] - 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] - 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] - 5 -> MSI VOX USB 2.0 (em2820/em2840) - 6 -> Terratec Cinergy 200 USB (em2800) - 7 -> Leadtek Winfast USB II (em2800) [0413:6023] - 8 -> Kworld USB2800 (em2800) - 9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a,093b:a003] - 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] - 11 -> Terratec Hybrid XS (em2880) - 12 -> Kworld PVR TV 2800 RF (em2820/em2840) - 13 -> Terratec Prodigy XS (em2880) - 14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) - 15 -> V-Gear PocketTV (em2800) - 16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b] - 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] - 18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502] - 19 -> EM2860/SAA711X Reference Design (em2860) - 20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002] - 21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801] - 22 -> EM2710/EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751] - 23 -> Huaqi DLCW-130 (em2750) - 24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112] - 25 -> Gadmei UTV310 (em2820/em2840) - 26 -> Hercules Smart TV USB 2.0 (em2820/em2840) - 27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) (em2820/em2840) - 28 -> Leadtek Winfast USB II Deluxe (em2820/em2840) - 29 -> EM2860/TVP5150 Reference Design (em2860) - 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) - 31 -> Usbgear VD204v9 (em2821) - 32 -> Supercomp USB 2.0 TV (em2821) - 33 -> Elgato Video Capture (em2860) [0fd9:0033] - 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] - 35 -> Typhoon DVD Maker (em2860) - 36 -> NetGMBH Cam (em2860) - 37 -> Gadmei UTV330 (em2860) [eb1a:50a6] - 38 -> Yakumo MovieMixer (em2861) - 39 -> KWorld PVRTV 300U (em2861) [eb1a:e300] - 40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005] - 41 -> Kworld 350 U DVB-T (em2870) [eb1a:e350] - 42 -> Kworld 355 U DVB-T (em2870) [eb1a:e355,eb1a:e357,eb1a:e359] - 43 -> Terratec Cinergy T XS (em2870) - 44 -> Terratec Cinergy T XS (MT2060) (em2870) [0ccd:0043] - 45 -> Pinnacle PCTV DVB-T (em2870) - 46 -> Compro, VideoMate U3 (em2870) [185b:2870] - 47 -> KWorld DVB-T 305U (em2880) [eb1a:e305] - 48 -> KWorld DVB-T 310U (em2880) - 49 -> MSI DigiVox A/D (em2880) [eb1a:e310] - 50 -> MSI DigiVox A/D II (em2880) [eb1a:e320] - 51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c] - 52 -> DNT DA2 Hybrid (em2881) - 53 -> Pinnacle Hybrid Pro (em2881) - 54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323] - 55 -> Terratec Cinnergy Hybrid T USB XS (em2882) (em2882) [0ccd:005e,0ccd:0042] - 56 -> Pinnacle Hybrid Pro (330e) (em2882) [2304:0226] - 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] - 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] - 59 -> Pinnacle PCTV HD Mini (em2874) [2304:023f] - 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] - 61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840) - 62 -> Gadmei TVR200 (em2820/em2840) - 63 -> Kaiomy TVnPC U2 (em2860) [eb1a:e303] - 64 -> Easy Cap Capture DC-60 (em2860) [1b80:e309] - 65 -> IO-DATA GV-MVP/SZ (em2820/em2840) [04bb:0515] - 66 -> Empire dual TV (em2880) - 67 -> Terratec Grabby (em2860) [0ccd:0096,0ccd:10AF] - 68 -> Terratec AV350 (em2860) [0ccd:0084] - 69 -> KWorld ATSC 315U HDTV TV Box (em2882) [eb1a:a313] - 70 -> Evga inDtube (em2882) - 71 -> Silvercrest Webcam 1.3mpix (em2820/em2840) - 72 -> Gadmei UTV330+ (em2861) - 73 -> Reddo DVB-C USB TV Box (em2870) - 74 -> Actionmaster/LinXcel/Digitus VC211A (em2800) - 75 -> Dikom DK300 (em2882) - 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] - 77 -> EM2874 Leadership ISDBT (em2874) - 78 -> PCTV nanoStick T2 290e (em28174) [2013:024f] - 79 -> Terratec Cinergy H5 (em2884) [eb1a:2885,0ccd:10a2,0ccd:10ad,0ccd:10b6] - 80 -> PCTV DVB-S2 Stick (460e) (em28174) [2013:024c] - 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] - 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] - 83 -> Honestech Vidbox NW03 (em2860) [eb1a:5006] - 84 -> MaxMedia UB425-TC (em2874) [1b80:e425] - 85 -> PCTV QuatroStick (510e) (em2884) [2304:0242] - 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] - 87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac] - 88 -> C3 Tech Digital Duo HDTV/SDTV USB (em2884) [1b80:e755] - 89 -> Delock 61959 (em2874) [1b80:e1cc] - 90 -> KWorld USB ATSC TV Stick UB435-Q V2 (em2874) [1b80:e346] - 91 -> SpeedLink Vicious And Devine Laplace webcam (em2765) [1ae7:9003,1ae7:9004] - 92 -> PCTV DVB-S2 Stick (461e) (em28178) [2013:0258] - 93 -> KWorld USB ATSC TV Stick UB435-Q V3 (em2874) [1b80:e34c] - 94 -> PCTV tripleStick (292e) (em28178) [2013:025f,2040:0264] - 95 -> Leadtek VC100 (em2861) [0413:6f07] - 96 -> Terratec Cinergy T2 Stick HD (em28178) [eb1a:8179] - 97 -> Elgato EyeTV Hybrid 2008 INT (em2884) [0fd9:0018] - 98 -> PLEX PX-BCUD (em28178) [3275:0085] - 99 -> Hauppauge WinTV-dualHD DVB (em28174) [2040:0265] diff --git a/Documentation/video4linux/CARDLIST.ivtv b/Documentation/video4linux/CARDLIST.ivtv deleted file mode 100644 index a019e27e4..000000000 --- a/Documentation/video4linux/CARDLIST.ivtv +++ /dev/null @@ -1,24 +0,0 @@ - 1 -> Hauppauge WinTV PVR-250 - 2 -> Hauppauge WinTV PVR-350 - 3 -> Hauppauge WinTV PVR-150 or PVR-500 - 4 -> AVerMedia M179 [1461:a3ce,1461:a3cf] - 5 -> Yuan MPG600/Kuroutoshikou iTVC16-STVLP [12ab:fff3,12ab:ffff] - 6 -> Yuan MPG160/Kuroutoshikou iTVC15-STVLP [12ab:0000,10fc:40a0] - 7 -> Yuan PG600/DiamondMM PVR-550 [ff92:0070,ffab:0600] - 8 -> Adaptec AVC-2410 [9005:0093] - 9 -> Adaptec AVC-2010 [9005:0092] -10 -> NAGASE TRANSGEAR 5000TV [1461:bfff] -11 -> AOpen VA2000MAX-STN6 [0000:ff5f] -12 -> YUAN MPG600GR/Kuroutoshikou CX23416GYC-STVLP [12ab:0600,fbab:0600,1154:0523] -13 -> I/O Data GV-MVP/RX [10fc:d01e,10fc:d038,10fc:d039] -14 -> I/O Data GV-MVP/RX2E [10fc:d025] -15 -> GOTVIEW PCI DVD (partial support only) [12ab:0600] -16 -> GOTVIEW PCI DVD2 Deluxe [ffac:0600] -17 -> Yuan MPC622 [ff01:d998] -18 -> Digital Cowboy DCT-MTVP1 [1461:bfff] -19 -> Yuan PG600V2/GotView PCI DVD Lite [ffab:0600,ffad:0600] -20 -> Club3D ZAP-TV1x01 [ffab:0600] -21 -> AverTV MCE 116 Plus [1461:c439] -22 -> ASUS Falcon2 [1043:4b66,1043:462e,1043:4b2e] -23 -> AverMedia PVR-150 Plus [1461:c035] -24 -> AverMedia EZMaker PCI Deluxe [1461:c03f] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 deleted file mode 100644 index 335c24338..000000000 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ /dev/null @@ -1,197 +0,0 @@ - 0 -> UNKNOWN/GENERIC - 1 -> Proteus Pro [philips reference design] [1131:2001,1131:2001] - 2 -> LifeView FlyVIDEO3000 [5168:0138,4e42:0138] - 3 -> LifeView/Typhoon FlyVIDEO2000 [5168:0138,4e42: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,16be:5000] - 13 -> Typhoon TV+Radio 90031 - 14 -> ELSA EX-VISION 300TV [1048:226b] - 15 -> ELSA EX-VISION 500TV [1048:226a] - 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 -> AverMedia M156 / Medion 2819 [1461:a70b] - 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 -> Noval Prime TV 7133 - 35 -> AverMedia AverTV Studio 305 [1461:2115] - 36 -> UPMOST PURPLE TV [12ab:0800] - 37 -> Items MuchTV Plus / IT-005 - 38 -> Terratec Cinergy 200 TV [153b:1152] - 39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212,5169:1502] - 40 -> Compro VideoMate TV PVR/FM [185b:c100] - 41 -> Compro VideoMate TV Gold+ [185b:c100] - 42 -> Sabrent SBT-TVFM (saa7130) - 43 -> :Zolid Xpert TV7134 - 44 -> Empire PCI TV-Radio LE - 45 -> Avermedia AVerTV Studio 307 [1461:9715] - 46 -> AVerMedia Cardbus TV/Radio (E500) [1461:d6ee] - 47 -> Terratec Cinergy 400 mobile [153b:1162] - 48 -> Terratec Cinergy 600 TV MK3 [153b:1158] - 49 -> Compro VideoMate Gold+ Pal [185b:c200] - 50 -> Pinnacle PCTV 300i DVB-T + PAL [11bd:002d] - 51 -> ProVideo PV952 [1540:9524] - 52 -> AverMedia AverTV/305 [1461:2108] - 53 -> ASUS TV-FM 7135 [1043:4845] - 54 -> LifeView FlyTV Platinum FM / Gold [5168:0214,5168:5214,1489:0214,5168:0304] - 55 -> LifeView FlyDVB-T DUO / MSI TV@nywhere Duo [5168:0306,4E42:0306] - 56 -> Avermedia AVerTV 307 [1461:a70a] - 57 -> Avermedia AVerTV GO 007 FM [1461:f31f] - 58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370] - 59 -> Kworld/Tevion V-Stream Xpert TV PVR7134 - 60 -> LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [5168:0502,4e42:0502,1489:0502] - 61 -> Philips TOUGH DVB-T reference design [1131:2004] - 62 -> Compro VideoMate TV Gold+II - 63 -> Kworld Xpert TV PVR7134 - 64 -> FlyTV mini Asus Digimatrix [1043:0210] - 65 -> V-Stream Studio TV Terminator - 66 -> Yuan TUN-900 (saa7135) - 67 -> Beholder BeholdTV 409 FM [0000:4091] - 68 -> GoTView 7135 PCI [5456:7135] - 69 -> Philips EUROPA V3 reference design [1131:2004] - 70 -> Compro Videomate DVB-T300 [185b:c900] - 71 -> Compro Videomate DVB-T200 [185b:c901] - 72 -> RTD Embedded Technologies VFG7350 [1435:7350] - 73 -> RTD Embedded Technologies VFG7330 [1435:7330] - 74 -> LifeView FlyTV Platinum Mini2 [14c0:1212] - 75 -> AVerMedia AVerTVHD MCE A180 [1461:1044] - 76 -> SKNet MonsterTV Mobile [1131:4ee9] - 77 -> Pinnacle PCTV 40i/50i/110i (saa7133) [11bd:002e] - 78 -> ASUSTeK P7131 Dual [1043:4862] - 79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B) - 80 -> ASUS Digimatrix TV [1043:0210] - 81 -> Philips Tiger reference design [1131:2018] - 82 -> MSI TV@Anywhere plus [1462:6231,1462:8624] - 83 -> Terratec Cinergy 250 PCI TV [153b:1160] - 84 -> LifeView FlyDVB Trio [5168:0319] - 85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05] - 86 -> LifeView FlyDVB-T / Genius VideoWonder DVB-T [5168:0301,1489:0301] - 87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421] - 88 -> Tevion/KWorld DVB-T 220RF [17de:7201] - 89 -> ELSA EX-VISION 700TV [1048:226c] - 90 -> Kworld ATSC110/115 [17de:7350,17de:7352] - 91 -> AVerMedia A169 B [1461:7360] - 92 -> AVerMedia A169 B1 [1461:6360] - 93 -> Medion 7134 Bridge #2 [16be:0005] - 94 -> LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [5168:3306,5168:3502,5168:3307,4e42:3502] - 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138] - 96 -> Medion Md8800 Quadro [16be:0007,16be:0008,16be:000d] - 97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300] - 98 -> Proteus Pro 2309 [0919:2003] - 99 -> AVerMedia TV Hybrid A16AR [1461:2c00] -100 -> Asus Europa2 OEM [1043:4860] -101 -> Pinnacle PCTV 310i [11bd:002f] -102 -> Avermedia AVerTV Studio 507 [1461:9715] -103 -> Compro Videomate DVB-T200A -104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6700,0070:6701,0070:6702,0070:6703,0070:6704,0070:6705] -105 -> Terratec Cinergy HT PCMCIA [153b:1172] -106 -> Encore ENLTV [1131:2342,1131:2341,3016:2344] -107 -> Encore ENLTV-FM [1131:230f] -108 -> Terratec Cinergy HT PCI [153b:1175] -109 -> Philips Tiger - S Reference design -110 -> Avermedia M102 [1461:f31e] -111 -> ASUS P7131 4871 [1043:4871] -112 -> ASUSTeK P7131 Hybrid [1043:4876] -113 -> Elitegroup ECS TVP3XP FM1246 Tuner Card (PAL,FM) [1019:4cb6] -114 -> KWorld DVB-T 210 [17de:7250] -115 -> Sabrent PCMCIA TV-PCB05 [0919:2003] -116 -> 10MOONS TM300 TV Card [1131:2304] -117 -> Avermedia Super 007 [1461:f01d] -118 -> Beholder BeholdTV 401 [0000:4016] -119 -> Beholder BeholdTV 403 [0000:4036] -120 -> Beholder BeholdTV 403 FM [0000:4037] -121 -> Beholder BeholdTV 405 [0000:4050] -122 -> Beholder BeholdTV 405 FM [0000:4051] -123 -> Beholder BeholdTV 407 [0000:4070] -124 -> Beholder BeholdTV 407 FM [0000:4071] -125 -> Beholder BeholdTV 409 [0000:4090] -126 -> Beholder BeholdTV 505 FM [5ace:5050] -127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090] -128 -> Beholder BeholdTV Columbus TV/FM [0000:5201] -129 -> Beholder BeholdTV 607 FM [5ace:6070] -130 -> Beholder BeholdTV M6 [5ace:6190] -131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] -132 -> Genius TVGO AM11MCE -133 -> NXP Snake DVB-S reference design -134 -> Medion/Creatix CTX953 Hybrid [16be:0010] -135 -> MSI TV@nywhere A/D v1.1 [1462:8625] -136 -> AVerMedia Cardbus TV/Radio (E506R) [1461:f436] -137 -> AVerMedia Hybrid TV/Radio (A16D) [1461:f936] -138 -> Avermedia M115 [1461:a836] -139 -> Compro VideoMate T750 [185b:c900] -140 -> Avermedia DVB-S Pro A700 [1461:a7a1] -141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2] -142 -> Beholder BeholdTV H6 [5ace:6290] -143 -> Beholder BeholdTV M63 [5ace:6191] -144 -> Beholder BeholdTV M6 Extra [5ace:6193] -145 -> AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636,1461:f736] -146 -> ASUSTeK P7131 Analog -147 -> Asus Tiger 3in1 [1043:4878] -148 -> Encore ENLTV-FM v5.3 [1a7f:2008] -149 -> Avermedia PCI pure analog (M135A) [1461:f11d] -150 -> Zogis Real Angel 220 -151 -> ADS Tech Instant HDTV [1421:0380] -152 -> Asus Tiger Rev:1.00 [1043:4857] -153 -> Kworld Plus TV Analog Lite PCI [17de:7128] -154 -> Avermedia AVerTV GO 007 FM Plus [1461:f31d] -155 -> Hauppauge WinTV-HVR1150 ATSC/QAM-Hybrid [0070:6706,0070:6708] -156 -> Hauppauge WinTV-HVR1120 DVB-T/Hybrid [0070:6707,0070:6709,0070:670a] -157 -> Avermedia AVerTV Studio 507UA [1461:a11b] -158 -> AVerMedia Cardbus TV/Radio (E501R) [1461:b7e9] -159 -> Beholder BeholdTV 505 RDS [0000:505B] -160 -> Beholder BeholdTV 507 RDS [0000:5071] -161 -> Beholder BeholdTV 507 RDS [0000:507B] -162 -> Beholder BeholdTV 607 FM [5ace:6071] -163 -> Beholder BeholdTV 609 FM [5ace:6090] -164 -> Beholder BeholdTV 609 FM [5ace:6091] -165 -> Beholder BeholdTV 607 RDS [5ace:6072] -166 -> Beholder BeholdTV 607 RDS [5ace:6073] -167 -> Beholder BeholdTV 609 RDS [5ace:6092] -168 -> Beholder BeholdTV 609 RDS [5ace:6093] -169 -> Compro VideoMate S350/S300 [185b:c900] -170 -> AverMedia AverTV Studio 505 [1461:a115] -171 -> Beholder BeholdTV X7 [5ace:7595] -172 -> RoverMedia TV Link Pro FM [19d1:0138] -173 -> Zolid Hybrid TV Tuner PCI [1131:2004] -174 -> Asus Europa Hybrid OEM [1043:4847] -175 -> Leadtek Winfast DTV1000S [107d:6655] -176 -> Beholder BeholdTV 505 RDS [0000:5051] -177 -> Hawell HW-404M7 -178 -> Beholder BeholdTV H7 [5ace:7190] -179 -> Beholder BeholdTV A7 [5ace:7090] -180 -> Avermedia PCI M733A [1461:4155,1461:4255] -181 -> TechoTrend TT-budget T-3000 [13c2:2804] -182 -> Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid [17de:b136] -183 -> Compro VideoMate Vista M1F [185b:c900] -184 -> Encore ENLTV-FM 3 [1a7f:2108] -185 -> MagicPro ProHDTV Pro2 DMB-TH/Hybrid [17de:d136] -186 -> Beholder BeholdTV 501 [5ace:5010] -187 -> Beholder BeholdTV 503 FM [5ace:5030] -188 -> Sensoray 811/911 [6000:0811,6000:0911] -189 -> Kworld PC150-U [17de:a134] -190 -> Asus My Cinema PS3-100 [1043:48cd] -191 -> Hawell HW-9004V1 -192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055] -193 -> WIS Voyager or compatible [1905:7007] -194 -> AverMedia AverTV/505 [1461:a10a] -195 -> Leadtek Winfast TV2100 FM [107d:6f3a] -196 -> SnaZio* TVPVR PRO [1779:13cf] diff --git a/Documentation/video4linux/CARDLIST.saa7164 b/Documentation/video4linux/CARDLIST.saa7164 deleted file mode 100644 index 6eb057220..000000000 --- a/Documentation/video4linux/CARDLIST.saa7164 +++ /dev/null @@ -1,14 +0,0 @@ - 0 -> Unknown - 1 -> Generic Rev2 - 2 -> Generic Rev3 - 3 -> Hauppauge WinTV-HVR2250 [0070:8880,0070:8810] - 4 -> Hauppauge WinTV-HVR2200 [0070:8980] - 5 -> Hauppauge WinTV-HVR2200 [0070:8900] - 6 -> Hauppauge WinTV-HVR2200 [0070:8901] - 7 -> Hauppauge WinTV-HVR2250 [0070:8891,0070:8851] - 8 -> Hauppauge WinTV-HVR2250 [0070:88A1] - 9 -> Hauppauge WinTV-HVR2200 [0070:8940] - 10 -> Hauppauge WinTV-HVR2200 [0070:8953] - 11 -> Hauppauge WinTV-HVR2255(proto) - 12 -> Hauppauge WinTV-HVR2255 [0070:f111] - 13 -> Hauppauge WinTV-HVR2205 [0070:f123,0070:f120] diff --git a/Documentation/video4linux/CARDLIST.tm6000 b/Documentation/video4linux/CARDLIST.tm6000 deleted file mode 100644 index b5edce487..000000000 --- a/Documentation/video4linux/CARDLIST.tm6000 +++ /dev/null @@ -1,16 +0,0 @@ - 1 -> Generic tm5600 board (tm5600) [6000:0001] - 2 -> Generic tm6000 board (tm6000) [6000:0001] - 3 -> Generic tm6010 board (tm6010) [6000:0002] - 4 -> 10Moons UT821 (tm5600) [6000:0001] - 5 -> 10Moons UT330 (tm5600) - 6 -> ADSTech Dual TV (tm6000) [06e1:f332] - 7 -> FreeCom and similar (tm6000) [14aa:0620] - 8 -> ADSTech Mini Dual TV (tm6000) [06e1:b339] - 9 -> Hauppauge WinTV HVR-900H/USB2 Stick (tm6010) [2040:6600,2040:6601,2040:6610,2040:6611] - 10 -> Beholder Wander (tm6010) [6000:dec0] - 11 -> Beholder Voyager (tm6010) [6000:dec1] - 12 -> TerraTec Cinergy Hybrid XE/Cinergy Hybrid Stick (tm6010) [0ccd:0086,0ccd:00a5] - 13 -> TwinHan TU501 (tm6010) [13d3:3240,13d3:3241,13d3:3243,13d3:3264] - 14 -> Beholder Wander Lite (tm6010) [6000:dec2] - 15 -> Beholder Voyager Lite (tm6010) [6000:dec3] - diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner deleted file mode 100644 index ac8862184..000000000 --- a/Documentation/video4linux/CARDLIST.tuner +++ /dev/null @@ -1,91 +0,0 @@ -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 FCV1236D ATSC/NTSC dual 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 -tuner=46 - Panasonic VP27s/ENGE4324D -tuner=47 - LG NTSC (TAPE series) -tuner=48 - Tenna TNF 8831 BGFF) -tuner=49 - Microtune 4042 FI5 ATSC/NTSC dual in -tuner=50 - TCL 2002N -tuner=51 - Philips PAL/SECAM_D (FM 1256 I-H3) -tuner=52 - Thomson DTT 7610 (ATSC/NTSC) -tuner=53 - Philips FQ1286 -tuner=54 - Philips/NXP TDA 8290/8295 + 8275/8275A/18271 -tuner=55 - TCL 2002MB -tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4) -tuner=57 - Philips FQ1236A MK4 -tuner=58 - Ymec TVision TVF-8531MF/8831MF/8731MF -tuner=59 - Ymec TVision TVF-5533MF -tuner=60 - Thomson DTT 761X (ATSC/NTSC) -tuner=61 - Tena TNF9533-D/IF/TNF9533-B/DF -tuner=62 - Philips TEA5767HN FM Radio -tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner -tuner=64 - LG TDVS-H06xF -tuner=65 - Ymec TVF66T5-B/DFF -tuner=66 - LG TALN series -tuner=67 - Philips TD1316 Hybrid Tuner -tuner=68 - Philips TUV1236D ATSC/NTSC dual in -tuner=69 - Tena TNF 5335 and similar models -tuner=70 - Samsung TCPN 2121P30A -tuner=71 - Xceive xc2028/xc3028 tuner -tuner=72 - Thomson FE6600 -tuner=73 - Samsung TCPG 6121P30A -tuner=75 - Philips TEA5761 FM Radio -tuner=76 - Xceive 5000 tuner -tuner=77 - TCL tuner MF02GIP-5N-E -tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner -tuner=79 - Philips PAL/SECAM multi (FM1216 MK5) -tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough -tuner=81 - Partsnic (Daewoo) PTI-5NF05 -tuner=82 - Philips CU1216L -tuner=83 - NXP TDA18271 -tuner=84 - Sony BTF-Pxn01Z -tuner=85 - Philips FQ1236 MK5 -tuner=86 - Tena TNF5337 MFD -tuner=87 - Xceive 4000 tuner -tuner=88 - Xceive 5000C tuner -tuner=89 - Sony BTF-PG472Z PAL/SECAM -tuner=90 - Sony BTF-PK467Z NTSC-M-JP -tuner=91 - Sony BTF-PB463Z NTSC-M diff --git a/Documentation/video4linux/CARDLIST.usbvision b/Documentation/video4linux/CARDLIST.usbvision deleted file mode 100644 index 6fd1af365..000000000 --- a/Documentation/video4linux/CARDLIST.usbvision +++ /dev/null @@ -1,67 +0,0 @@ - 0 -> Xanboo [0a6f:0400] - 1 -> Belkin USB VideoBus II Adapter [050d:0106] - 2 -> Belkin Components USB VideoBus [050d:0207] - 3 -> Belkin USB VideoBus II [050d:0208] - 4 -> echoFX InterView Lite [0571:0002] - 5 -> USBGear USBG-V1 resp. HAMA USB [0573:0003] - 6 -> D-Link V100 [0573:0400] - 7 -> X10 USB Camera [0573:2000] - 8 -> Hauppauge WinTV USB Live (PAL B/G) [0573:2d00] - 9 -> Hauppauge WinTV USB Live Pro (NTSC M/N) [0573:2d01] - 10 -> Zoran Co. PMD (Nogatech) AV-grabber Manhattan [0573:2101] - 11 -> Nogatech USB-TV (NTSC) FM [0573:4100] - 12 -> PNY USB-TV (NTSC) FM [0573:4110] - 13 -> PixelView PlayTv-USB PRO (PAL) FM [0573:4450] - 14 -> ZTV ZT-721 2.4GHz USB A/V Receiver [0573:4550] - 15 -> Hauppauge WinTV USB (NTSC M/N) [0573:4d00] - 16 -> Hauppauge WinTV USB (PAL B/G) [0573:4d01] - 17 -> Hauppauge WinTV USB (PAL I) [0573:4d02] - 18 -> Hauppauge WinTV USB (PAL/SECAM L) [0573:4d03] - 19 -> Hauppauge WinTV USB (PAL D/K) [0573:4d04] - 20 -> Hauppauge WinTV USB (NTSC FM) [0573:4d10] - 21 -> Hauppauge WinTV USB (PAL B/G FM) [0573:4d11] - 22 -> Hauppauge WinTV USB (PAL I FM) [0573:4d12] - 23 -> Hauppauge WinTV USB (PAL D/K FM) [0573:4d14] - 24 -> Hauppauge WinTV USB Pro (NTSC M/N) [0573:4d2a] - 25 -> Hauppauge WinTV USB Pro (NTSC M/N) V2 [0573:4d2b] - 26 -> Hauppauge WinTV USB Pro (PAL/SECAM B/G/I/D/K/L) [0573:4d2c] - 27 -> Hauppauge WinTV USB Pro (NTSC M/N) V3 [0573:4d20] - 28 -> Hauppauge WinTV USB Pro (PAL B/G) [0573:4d21] - 29 -> Hauppauge WinTV USB Pro (PAL I) [0573:4d22] - 30 -> Hauppauge WinTV USB Pro (PAL/SECAM L) [0573:4d23] - 31 -> Hauppauge WinTV USB Pro (PAL D/K) [0573:4d24] - 32 -> Hauppauge WinTV USB Pro (PAL/SECAM BGDK/I/L) [0573:4d25] - 33 -> Hauppauge WinTV USB Pro (PAL/SECAM BGDK/I/L) V2 [0573:4d26] - 34 -> Hauppauge WinTV USB Pro (PAL B/G) V2 [0573:4d27] - 35 -> Hauppauge WinTV USB Pro (PAL B/G,D/K) [0573:4d28] - 36 -> Hauppauge WinTV USB Pro (PAL I,D/K) [0573:4d29] - 37 -> Hauppauge WinTV USB Pro (NTSC M/N FM) [0573:4d30] - 38 -> Hauppauge WinTV USB Pro (PAL B/G FM) [0573:4d31] - 39 -> Hauppauge WinTV USB Pro (PAL I FM) [0573:4d32] - 40 -> Hauppauge WinTV USB Pro (PAL D/K FM) [0573:4d34] - 41 -> Hauppauge WinTV USB Pro (Temic PAL/SECAM B/G/I/D/K/L FM) [0573:4d35] - 42 -> Hauppauge WinTV USB Pro (Temic PAL B/G FM) [0573:4d36] - 43 -> Hauppauge WinTV USB Pro (PAL/SECAM B/G/I/D/K/L FM) [0573:4d37] - 44 -> Hauppauge WinTV USB Pro (NTSC M/N FM) V2 [0573:4d38] - 45 -> Camtel Technology USB TV Genie Pro FM Model TVB330 [0768:0006] - 46 -> Digital Video Creator I [07d0:0001] - 47 -> Global Village GV-007 (NTSC) [07d0:0002] - 48 -> Dazzle Fusion Model DVC-50 Rev 1 (NTSC) [07d0:0003] - 49 -> Dazzle Fusion Model DVC-80 Rev 1 (PAL) [07d0:0004] - 50 -> Dazzle Fusion Model DVC-90 Rev 1 (SECAM) [07d0:0005] - 51 -> Eskape Labs MyTV2Go [07f8:9104] - 52 -> Pinnacle Studio PCTV USB (PAL) [2304:010d] - 53 -> Pinnacle Studio PCTV USB (SECAM) [2304:0109] - 54 -> Pinnacle Studio PCTV USB (PAL) FM [2304:0110] - 55 -> Miro PCTV USB [2304:0111] - 56 -> Pinnacle Studio PCTV USB (NTSC) FM [2304:0112] - 57 -> Pinnacle Studio PCTV USB (PAL) FM V2 [2304:0210] - 58 -> Pinnacle Studio PCTV USB (NTSC) FM V2 [2304:0212] - 59 -> Pinnacle Studio PCTV USB (PAL) FM V3 [2304:0214] - 60 -> Pinnacle Studio Linx Video input cable (NTSC) [2304:0300] - 61 -> Pinnacle Studio Linx Video input cable (PAL) [2304:0301] - 62 -> Pinnacle PCTV Bungee USB (PAL) FM [2304:0419] - 63 -> Hauppauge WinTv-USB [2400:4200] - 64 -> Pinnacle Studio PCTV USB (NTSC) FM V3 [2304:0113] - 65 -> Nogatech USB MicroCam NTSC (NV3000N) [0573:3000] - 66 -> Nogatech USB MicroCam PAL (NV3001P) [0573:3001] diff --git a/Documentation/video4linux/README.cpia2 b/Documentation/video4linux/README.cpia2 deleted file mode 100644 index 38e742fd0..000000000 --- a/Documentation/video4linux/README.cpia2 +++ /dev/null @@ -1,130 +0,0 @@ -$Id: README,v 1.7 2005/08/29 23:39:57 sbertin Exp $ - -1. Introduction - - This is a driver for STMicroelectronics's CPiA2 (second generation -Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG -stream at up to vga size. It implements the Video4Linux interface as much as -possible. Since the V4L interface does not support compressed formats, only -an mjpeg enabled application can be used with the camera. We have modified the -gqcam application to view this stream. - - The driver is implemented as two kernel modules. The cpia2 module -contains the camera functions and the V4L interface. The cpia2_usb module -contains usb specific functions. The main reason for this was the size of the -module was getting out of hand, so I separated them. It is not likely that -there will be a parallel port version. - -FEATURES: - - Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos - sensors. I only have the vga sensor, so can't test the other. - - Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between. - VGA and QVGA are the native image sizes for the VGA camera. CIF is done - in the coprocessor by scaling QVGA. All other sizes are done by clipping. - - Palette: YCrCb, compressed with MJPEG. - - Some compression parameters are settable. - - Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA). - - Adjust brightness, color, contrast while streaming. - - Flicker control settable for 50 or 60 Hz mains frequency. - -2. Making and installing the stv672 driver modules: - - Requirements: - ------------- - This should work with 2.4 (2.4.23 and later) and 2.6 kernels, but has -only been tested on 2.6. Video4Linux must be either compiled into the kernel or -available as a module. Video4Linux2 is automatically detected and made -available at compile time. - - Compiling: - ---------- - As root, do a make install. This will compile and install the modules -into the media/video directory in the module tree. For 2.4 kernels, use -Makefile_2.4 (aka do make -f Makefile_2.4 install). - - Setup: - ------ - Use 'modprobe cpia2' to load and 'modprobe -r cpia2' to unload. This -may be done automatically by your distribution. - -3. Driver options - - Option Description - ------ ----------- - video_nr video device to register (0=/dev/video0, etc) - range -1 to 64. default is -1 (first available) - If you have more than 1 camera, this MUST be -1. - buffer_size Size for each frame buffer in bytes (default 68k) - num_buffers Number of frame buffers (1-32, default 3) - alternate USB Alternate (2-7, default 7) - flicker_freq Frequency for flicker reduction(50 or 60, default 60) - flicker_mode 0 to disable, or 1 to enable flicker reduction. - (default 0). This is only effective if the camera - uses a stv0672 coprocessor. - - Setting the options: - -------------------- - If you are using modules, edit /etc/modules.conf and add an options -line like this: - options cpia2 num_buffers=3 buffer_size=65535 - - If the driver is compiled into the kernel, at boot time specify them -like this: - cpia2.num_buffers=3 cpia2.buffer_size=65535 - - What buffer size should I use? - ------------------------------ - The maximum image size depends on the alternate you choose, and the -frame rate achieved by the camera. If the compression engine is able to -keep up with the frame rate, the maximum image size is given by the table -below. - The compression engine starts out at maximum compression, and will -increase image quality until it is close to the size in the table. As long -as the compression engine can keep up with the frame rate, after a short time -the images will all be about the size in the table, regardless of resolution. - At low alternate settings, the compression engine may not be able to -compress the image enough and will reduce the frame rate by producing larger -images. - The default of 68k should be good for most users. This will handle -any alternate at frame rates down to 15fps. For lower frame rates, it may -be necessary to increase the buffer size to avoid having frames dropped due -to insufficient space. - - Image size(bytes) - Alternate bytes/ms 15fps 30fps - 2 128 8533 4267 - 3 384 25600 12800 - 4 640 42667 21333 - 5 768 51200 25600 - 6 896 59733 29867 - 7 1023 68200 34100 - - How many buffers should I use? - ------------------------------ - For normal streaming, 3 should give the best results. With only 2, -it is possible for the camera to finish sending one image just after a -program has started reading the other. If this happens, the driver must drop -a frame. The exception to this is if you have a heavily loaded machine. In -this case use 2 buffers. You are probably not reading at the full frame rate. -If the camera can send multiple images before a read finishes, it could -overwrite the third buffer before the read finishes, leading to a corrupt -image. Single and double buffering have extra checks to avoid overwriting. - -4. Using the camera - - We are providing a modified gqcam application to view the output. In -order to avoid confusion, here it is called mview. There is also the qx5view -program which can also control the lights on the qx5 microscope. MJPEG Tools -(http://mjpeg.sourceforge.net) can also be used to record from the camera. - -5. Notes to developers: - - - This is a driver version stripped of the 2.4 back compatibility - and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support. - -6. Thanks: - - - Peter Pregler <Peter_Pregler@email.com>, - Scott J. Bertin <scottbertin@yahoo.com>, and - Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which - this one was modelled from. diff --git a/Documentation/video4linux/README.cx88 b/Documentation/video4linux/README.cx88 deleted file mode 100644 index b09ce36b9..000000000 --- a/Documentation/video4linux/README.cx88 +++ /dev/null @@ -1,67 +0,0 @@ -cx8800 release notes -==================== - -This is a v4l2 device driver for the cx2388x chip. - - -current status -============== - -video - - Basically works. - - For now, only capture and read(). Overlay isn't supported. - -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 some standards. - 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) is supported via cx88-alsa. - -vbi - - Code present. Works for NTSC closed caption. PAL and other - TV norms may or may not work. - - -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 information 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.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe deleted file mode 100644 index dc9a297f4..000000000 --- a/Documentation/video4linux/README.davinci-vpbe +++ /dev/null @@ -1,93 +0,0 @@ - - VPBE V4L2 driver design - ====================================================================== - - File partitioning - ----------------- - V4L2 display device driver - drivers/media/platform/davinci/vpbe_display.c - drivers/media/platform/davinci/vpbe_display.h - - VPBE display controller - drivers/media/platform/davinci/vpbe.c - drivers/media/platform/davinci/vpbe.h - - VPBE venc sub device driver - drivers/media/platform/davinci/vpbe_venc.c - drivers/media/platform/davinci/vpbe_venc.h - drivers/media/platform/davinci/vpbe_venc_regs.h - - VPBE osd driver - drivers/media/platform/davinci/vpbe_osd.c - drivers/media/platform/davinci/vpbe_osd.h - drivers/media/platform/davinci/vpbe_osd_regs.h - - Functional partitioning - ----------------------- - - Consists of the following (in the same order as the list under file - partitioning):- - - 1. V4L2 display driver - Implements creation of video2 and video3 device nodes and - provides v4l2 device interface to manage VID0 and VID1 layers. - - 2. Display controller - Loads up VENC, OSD and external encoders such as ths8200. It provides - a set of API calls to V4L2 drivers to set the output/standards - in the VENC or external sub devices. It also provides - a device object to access the services from OSD subdevice - using sub device ops. The connection of external encoders to VENC LCD - controller port is done at init time based on default output and standard - selection or at run time when application change the output through - V4L2 IOCTLs. - - When connected to an external encoder, vpbe controller is also responsible - for setting up the interface between VENC and external encoders based on - board specific settings (specified in board-xxx-evm.c). This allows - interfacing external encoders such as ths8200. The setup_if_config() - is implemented for this as well as configure_venc() (part of the next patch) - API to set timings in VENC for a specific display resolution. As of this - patch series, the interconnection and enabling and setting of the external - encoders is not present, and would be a part of the next patch series. - - 3. VENC subdevice module - Responsible for setting outputs provided through internal DACs and also - setting timings at LCD controller port when external encoders are connected - at the port or LCD panel timings required. When external encoder/LCD panel - is connected, the timings for a specific standard/preset is retrieved from - the board specific table and the values are used to set the timings in - venc using non-standard timing mode. - - Support LCD Panel displays using the VENC. For example to support a Logic - PD display, it requires setting up the LCD controller port with a set of - timings for the resolution supported and setting the dot clock. So we could - add the available outputs as a board specific entry (i.e add the "LogicPD" - output name to board-xxx-evm.c). A table of timings for various LCDs - supported can be maintained in the board specific setup file to support - various LCD displays.As of this patch a basic driver is present, and this - support for external encoders and displays forms a part of the next - patch series. - - 4. OSD module - OSD module implements all OSD layer management and hardware specific - features. The VPBE module interacts with the OSD for enabling and - disabling appropriate features of the OSD. - - Current status:- - - A fully functional working version of the V4L2 driver is available. This - driver has been tested with NTSC and PAL standards and buffer streaming. - - Following are TBDs. - - vpbe display controller - - Add support for external encoders. - - add support for selecting external encoder as default at probe time. - - vpbe venc sub device - - add timings for supporting ths8200 - - add support for LogicPD LCD. - - FB drivers - - Add support for fbdev drivers.- Ready and part of subsequent patches. diff --git a/Documentation/video4linux/README.ir b/Documentation/video4linux/README.ir deleted file mode 100644 index 0da47a847..000000000 --- a/Documentation/video4linux/README.ir +++ /dev/null @@ -1,72 +0,0 @@ - -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.ivtv b/Documentation/video4linux/README.ivtv deleted file mode 100644 index 2579b5b70..000000000 --- a/Documentation/video4linux/README.ivtv +++ /dev/null @@ -1,186 +0,0 @@ - -ivtv release notes -================== - -This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder. -The cx23415 can do both encoding and decoding, the cx23416 can only do MPEG -encoding. Currently the only card featuring full decoding support is the -Hauppauge PVR-350. - -NOTE: this driver requires the latest encoder firmware (version 2.06.039, size -376836 bytes). Get the firmware from here: - -http://dl.ivtvdriver.org/ivtv/firmware/ - -NOTE: 'normal' TV applications do not work with this driver, you need -an application that can handle MPEG input such as mplayer, xine, MythTV, -etc. - -The primary goal of the IVTV project is to provide a "clean room" Linux -Open Source driver implementation for video capture cards based on the -iCompression iTVC15 or Conexant CX23415/CX23416 MPEG Codec. - -Features: - * Hardware mpeg2 capture of broadcast video (and sound) via the tuner or - S-Video/Composite and audio line-in. - * Hardware mpeg2 capture of FM radio where hardware support exists - * Supports NTSC, PAL, SECAM with stereo sound - * Supports SAP and bilingual transmissions. - * Supports raw VBI (closed captions and teletext). - * Supports sliced VBI (closed captions and teletext) and is able to insert - this into the captured MPEG stream. - * Supports raw YUV and PCM input. - -Additional features for the PVR-350 (CX23415 based): - * Provides hardware mpeg2 playback - * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the - video signal) - * Provides a framebuffer (allowing X applications to appear on the video - device) - * Supports raw YUV output. - -IMPORTANT: In case of problems first read this page: - http://www.ivtvdriver.org/index.php/Troubleshooting - -See also: - -Homepage + Wiki -http://www.ivtvdriver.org - -IRC -irc://irc.freenode.net/ivtv-dev - ----------------------------------------------------------- - -Devices -======= - -A maximum of 12 ivtv boards are allowed at the moment. - -Cards that don't have a video output capability (i.e. non PVR350 cards) -lack the vbi8, vbi16, video16 and video48 devices. They also do not -support the framebuffer device /dev/fbx for OSD. - -The radio0 device may or may not be present, depending on whether the -card has a radio tuner or not. - -Here is a list of the base v4l devices: -crw-rw---- 1 root video 81, 0 Jun 19 22:22 /dev/video0 -crw-rw---- 1 root video 81, 16 Jun 19 22:22 /dev/video16 -crw-rw---- 1 root video 81, 24 Jun 19 22:22 /dev/video24 -crw-rw---- 1 root video 81, 32 Jun 19 22:22 /dev/video32 -crw-rw---- 1 root video 81, 48 Jun 19 22:22 /dev/video48 -crw-rw---- 1 root video 81, 64 Jun 19 22:22 /dev/radio0 -crw-rw---- 1 root video 81, 224 Jun 19 22:22 /dev/vbi0 -crw-rw---- 1 root video 81, 228 Jun 19 22:22 /dev/vbi8 -crw-rw---- 1 root video 81, 232 Jun 19 22:22 /dev/vbi16 - -Base devices -============ - -For every extra card you have the numbers increased by one. For example, -/dev/video0 is listed as the 'base' encoding capture device so we have: - - /dev/video0 is the encoding capture device for the first card (card 0) - /dev/video1 is the encoding capture device for the second card (card 1) - /dev/video2 is the encoding capture device for the third card (card 2) - -Note that if the first card doesn't have a feature (eg no decoder, so no -video16, the second card will still use video17. The simple rule is 'add -the card number to the base device number'. If you have other capture -cards (e.g. WinTV PCI) that are detected first, then you have to tell -the ivtv module about it so that it will start counting at 1 (or 2, or -whatever). Otherwise the device numbers can get confusing. The ivtv -'ivtv_first_minor' module option can be used for that. - - -/dev/video0 -The encoding capture device(s). -Read-only. - -Reading from this device gets you the MPEG1/2 program stream. -Example: - -cat /dev/video0 > my.mpg (you need to hit ctrl-c to exit) - - -/dev/video16 -The decoder output device(s) -Write-only. Only present if the MPEG decoder (i.e. CX23415) exists. - -An mpeg2 stream sent to this device will appear on the selected video -display, audio will appear on the line-out/audio out. It is only -available for cards that support video out. Example: - -cat my.mpg >/dev/video16 - - -/dev/video24 -The raw audio capture device(s). -Read-only - -The raw audio PCM stereo stream from the currently selected -tuner or audio line-in. Reading from this device results in a raw -(signed 16 bit Little Endian, 48000 Hz, stereo pcm) capture. -This device only captures audio. This should be replaced by an ALSA -device in the future. -Note that there is no corresponding raw audio output device, this is -not supported in the decoder firmware. - - -/dev/video32 -The raw video capture device(s) -Read-only - -The raw YUV video output from the current video input. The YUV format -is non-standard (V4L2_PIX_FMT_HM12). - -Note that the YUV and PCM streams are not synchronized, so they are of -limited use. - - -/dev/video48 -The raw video display device(s) -Write-only. Only present if the MPEG decoder (i.e. CX23415) exists. - -Writes a YUV stream to the decoder of the card. - - -/dev/radio0 -The radio tuner device(s) -Cannot be read or written. - -Used to enable the radio tuner and tune to a frequency. You cannot -read or write audio streams with this device. Once you use this -device to tune the radio, use /dev/video24 to read the raw pcm stream -or /dev/video0 to get an mpeg2 stream with black video. - - -/dev/vbi0 -The 'vertical blank interval' (Teletext, CC, WSS etc) capture device(s) -Read-only - -Captures the raw (or sliced) video data sent during the Vertical Blank -Interval. This data is used to encode teletext, closed captions, VPS, -widescreen signalling, electronic program guide information, and other -services. - - -/dev/vbi8 -Processed vbi feedback device(s) -Read-only. Only present if the MPEG decoder (i.e. CX23415) exists. - -The sliced VBI data embedded in an MPEG stream is reproduced on this -device. So while playing back a recording on /dev/video16, you can -read the embedded VBI data from /dev/vbi8. - - -/dev/vbi16 -The vbi 'display' device(s) -Write-only. Only present if the MPEG decoder (i.e. CX23415) exists. - -Can be used to send sliced VBI data to the video-out connector. - ---------------------------------- - -Hans Verkuil <hverkuil@xs4all.nl> diff --git a/Documentation/video4linux/README.pvrusb2 b/Documentation/video4linux/README.pvrusb2 deleted file mode 100644 index 2137b5892..000000000 --- a/Documentation/video4linux/README.pvrusb2 +++ /dev/null @@ -1,212 +0,0 @@ - -$Id$ -Mike Isely <isely@pobox.com> - - pvrusb2 driver - -Background: - - This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which - is a USB 2.0 hosted TV Tuner. This driver is a work in progress. - Its history started with the reverse-engineering effort by Björn - Danielsson <pvrusb2@dax.nu> whose web page can be found here: - - http://pvrusb2.dax.nu/ - - From there Aurelien Alleaume <slts@free.fr> began an effort to - create a video4linux compatible driver. I began with Aurelien's - last known snapshot and evolved the driver to the state it is in - here. - - More information on this driver can be found at: - - http://www.isely.net/pvrusb2.html - - - This driver has a strong separation of layers. They are very - roughly: - - 1a. Low level wire-protocol implementation with the device. - - 1b. I2C adaptor implementation and corresponding I2C client drivers - implemented elsewhere in V4L. - - 1c. High level hardware driver implementation which coordinates all - activities that ensure correct operation of the device. - - 2. A "context" layer which manages instancing of driver, setup, - tear-down, arbitration, and interaction with high level - interfaces appropriately as devices are hotplugged in the - system. - - 3. High level interfaces which glue the driver to various published - Linux APIs (V4L, sysfs, maybe DVB in the future). - - The most important shearing layer is between the top 2 layers. A - lot of work went into the driver to ensure that any kind of - conceivable API can be laid on top of the core driver. (Yes, the - driver internally leverages V4L to do its work but that really has - nothing to do with the API published by the driver to the outside - world.) The architecture allows for different APIs to - simultaneously access the driver. I have a strong sense of fairness - about APIs and also feel that it is a good design principle to keep - implementation and interface isolated from each other. Thus while - right now the V4L high level interface is the most complete, the - sysfs high level interface will work equally well for similar - functions, and there's no reason I see right now why it shouldn't be - possible to produce a DVB high level interface that can sit right - alongside V4L. - - NOTE: Complete documentation on the pvrusb2 driver is contained in - the html files within the doc directory; these are exactly the same - as what is on the web site at the time. Browse those files - (especially the FAQ) before asking questions. - - -Building - - To build these modules essentially amounts to just running "Make", - but you need the kernel source tree nearby and you will likely also - want to set a few controlling environment variables first in order - to link things up with that source tree. Please see the Makefile - here for comments that explain how to do that. - - -Source file list / functional overview: - - (Note: The term "module" used below generally refers to loosely - defined functional units within the pvrusb2 driver and bears no - relation to the Linux kernel's concept of a loadable module.) - - pvrusb2-audio.[ch] - This is glue logic that resides between this - driver and the msp3400.ko I2C client driver (which is found - elsewhere in V4L). - - pvrusb2-context.[ch] - This module implements the context for an - instance of the driver. Everything else eventually ties back to - or is otherwise instanced within the data structures implemented - here. Hotplugging is ultimately coordinated here. All high level - interfaces tie into the driver through this module. This module - helps arbitrate each interface's access to the actual driver core, - and is designed to allow concurrent access through multiple - instances of multiple interfaces (thus you can for example change - the tuner's frequency through sysfs while simultaneously streaming - video through V4L out to an instance of mplayer). - - pvrusb2-debug.h - This header defines a printk() wrapper and a mask - of debugging bit definitions for the various kinds of debug - messages that can be enabled within the driver. - - pvrusb2-debugifc.[ch] - This module implements a crude command line - oriented debug interface into the driver. Aside from being part - of the process for implementing manual firmware extraction (see - the pvrusb2 web site mentioned earlier), probably I'm the only one - who has ever used this. It is mainly a debugging aid. - - pvrusb2-eeprom.[ch] - This is glue logic that resides between this - driver the tveeprom.ko module, which is itself implemented - elsewhere in V4L. - - pvrusb2-encoder.[ch] - This module implements all protocol needed to - interact with the Conexant mpeg2 encoder chip within the pvrusb2 - device. It is a crude echo of corresponding logic in ivtv, - however the design goals (strict isolation) and physical layer - (proxy through USB instead of PCI) are enough different that this - implementation had to be completely different. - - pvrusb2-hdw-internal.h - This header defines the core data structure - in the driver used to track ALL internal state related to control - of the hardware. Nobody outside of the core hardware-handling - modules should have any business using this header. All external - access to the driver should be through one of the high level - interfaces (e.g. V4L, sysfs, etc), and in fact even those high - level interfaces are restricted to the API defined in - pvrusb2-hdw.h and NOT this header. - - pvrusb2-hdw.h - This header defines the full internal API for - controlling the hardware. High level interfaces (e.g. V4L, sysfs) - will work through here. - - pvrusb2-hdw.c - This module implements all the various bits of logic - that handle overall control of a specific pvrusb2 device. - (Policy, instantiation, and arbitration of pvrusb2 devices fall - within the jurisdiction of pvrusb-context not here). - - pvrusb2-i2c-chips-*.c - These modules implement the glue logic to - tie together and configure various I2C modules as they attach to - the I2C bus. There are two versions of this file. The "v4l2" - version is intended to be used in-tree alongside V4L, where we - implement just the logic that makes sense for a pure V4L - environment. The "all" version is intended for use outside of - V4L, where we might encounter other possibly "challenging" modules - from ivtv or older kernel snapshots (or even the support modules - in the standalone snapshot). - - pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1 - compatible commands to the I2C modules. It is here where state - changes inside the pvrusb2 driver are translated into V4L1 - commands that are in turn send to the various I2C modules. - - pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2 - compatible commands to the I2C modules. It is here where state - changes inside the pvrusb2 driver are translated into V4L2 - commands that are in turn send to the various I2C modules. - - pvrusb2-i2c-core.[ch] - This module provides an implementation of a - kernel-friendly I2C adaptor driver, through which other external - I2C client drivers (e.g. msp3400, tuner, lirc) may connect and - operate corresponding chips within the pvrusb2 device. It is - through here that other V4L modules can reach into this driver to - operate specific pieces (and those modules are in turn driven by - glue logic which is coordinated by pvrusb2-hdw, doled out by - pvrusb2-context, and then ultimately made available to users - through one of the high level interfaces). - - pvrusb2-io.[ch] - This module implements a very low level ring of - transfer buffers, required in order to stream data from the - device. This module is *very* low level. It only operates the - buffers and makes no attempt to define any policy or mechanism for - how such buffers might be used. - - pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch] - to provide a streaming API usable by a read() system call style of - I/O. Right now this is the only layer on top of pvrusb2-io.[ch], - however the underlying architecture here was intended to allow for - other styles of I/O to be implemented with additional modules, like - mmap()'ed buffers or something even more exotic. - - pvrusb2-main.c - This is the top level of the driver. Module level - and USB core entry points are here. This is our "main". - - pvrusb2-sysfs.[ch] - This is the high level interface which ties the - pvrusb2 driver into sysfs. Through this interface you can do - everything with the driver except actually stream data. - - pvrusb2-tuner.[ch] - This is glue logic that resides between this - driver and the tuner.ko I2C client driver (which is found - elsewhere in V4L). - - pvrusb2-util.h - This header defines some common macros used - throughout the driver. These macros are not really specific to - the driver, but they had to go somewhere. - - pvrusb2-v4l2.[ch] - This is the high level interface which ties the - pvrusb2 driver into video4linux. It is through here that V4L - applications can open and operate the driver in the usual V4L - ways. Note that **ALL** V4L functionality is published only - through here and nowhere else. - - pvrusb2-video-*.[ch] - This is glue logic that resides between this - driver and the saa711x.ko I2C client driver (which is found - elsewhere in V4L). Note that saa711x.ko used to be known as - saa7115.ko in ivtv. There are two versions of this; one is - selected depending on the particular saa711[5x].ko that is found. - - pvrusb2.h - This header contains compile time tunable parameters - (and at the moment the driver has very little that needs to be - tuned). - - - -Mike Isely - isely@pobox.com - diff --git a/Documentation/video4linux/README.saa7134 b/Documentation/video4linux/README.saa7134 deleted file mode 100644 index b911f0871..000000000 --- a/Documentation/video4linux/README.saa7134 +++ /dev/null @@ -1,82 +0,0 @@ - - -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) - -Some details about 30/34/35: - - - saa7130 - low-price chip, doesn't have mute, that is why all those - cards should have .mute field defined in their tuner structure. - - - saa7134 - usual chip - - - saa7133/35 - saa7135 is probably a marketing decision, since all those - chips identifies itself as 33 on pci. - -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 deleted file mode 100644 index b5a911fd0..000000000 --- a/Documentation/video4linux/Zoran +++ /dev/null @@ -1,510 +0,0 @@ -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 - -AverMedia 6 Eyes AVS6EYES: -* Zoran zr36067 PCI controller -* Zoran zr36060 MJPEG codec -* Samsung ks0127 TV decoder -* Conexant bt866 TV encoder -Drivers to use: videodev, i2c-core, i2c-algo-bit, - videocodec, ks0127, bt866, zr36060, zr36067 -Inputs/outputs: Six physical inputs. 1-6 are composite, - 1-2, 3-4, 5-6 doubles as S-video, - 1-3 triples as component. - One composite output. -Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) -Card number: 8 -Not autodetected, card=8 is necessary. - -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 - -=========================== - -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 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/support/ -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 - -Samsung ks0127 TV decoder -is used in the AVS6EYES card and -can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM - -=========================== - -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 - -Conexant bt866 TV encoder -is used in AVS6EYES, and -can generate: NTSC/PAL, PALÂM, PALÂN - -The adv717x, should be able to produce PAL N. But you find nothing PAL N -specific in 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.d/zoran.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 video4linux2. Support for V4L1 and for the custom -zoran ioctls has been removed in kernel 2.6.38. - -For programming example, please, look at lavrec.c and lavplay.c code in -the MJPEG-tools (http://mjpeg.sf.net/). - -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. - -=========================== - -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 deleted file mode 100644 index eb41b2650..000000000 --- a/Documentation/video4linux/bttv/CONTRIBUTORS +++ /dev/null @@ -1,25 +0,0 @@ -Contributors to bttv: - -Michael Chu <mmchu@pobox.com> - AverMedia fix and more flexible card recognition - -Alan Cox <alan@lxorguk.ukuu.org.uk> - 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 deleted file mode 100644 index a8fb6e2d3..000000000 --- a/Documentation/video4linux/bttv/Cards +++ /dev/null @@ -1,960 +0,0 @@ - -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 crystal 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) - -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.jtt.ne.jp/) ---------------------------------------------------------------------- - 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 ------- - 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.de/ - 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 deleted file mode 100644 index 611315f87..000000000 --- a/Documentation/video4linux/bttv/ICs +++ /dev/null @@ -1,37 +0,0 @@ -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 deleted file mode 100644 index 14c065fa2..000000000 --- a/Documentation/video4linux/bttv/Insmod-options +++ /dev/null @@ -1,172 +0,0 @@ - -Note: "modinfo <module>" prints various information 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. - no_overlay=1 Disable overlay. It should be used by broken - hardware that doesn't support PCI2PCI direct - transfers. - 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. - i2c_udelay= Allow reduce I2C speed. Default is 5 usecs - (meaning 66,67 Kbps). The default is the - maximum supported speed by kernel bitbang - algorithm. You may use lower numbers, if I2C - messages are lost (16 is known to work on - all supported cards). - - 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). - -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 deleted file mode 100644 index 093c0cd18..000000000 --- a/Documentation/video4linux/bttv/MAKEDEV +++ /dev/null @@ -1,27 +0,0 @@ -#!/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://linux.bytesex.org/v4l2/API.html - -echo "*** new device names ***" -makedev video 0 -makedev radio 64 -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 deleted file mode 100644 index 55f14650d..000000000 --- a/Documentation/video4linux/bttv/Modprobe.conf +++ /dev/null @@ -1,11 +0,0 @@ -# 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 deleted file mode 100644 index 8f258faf1..000000000 --- a/Documentation/video4linux/bttv/Modules.conf +++ /dev/null @@ -1,14 +0,0 @@ -# For modern kernels (2.6 or above), this belongs in /etc/modprobe.d/*.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 deleted file mode 100644 index 2b8b0079f..000000000 --- a/Documentation/video4linux/bttv/PROBLEMS +++ /dev/null @@ -1,62 +0,0 @@ -- 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 deleted file mode 100644 index 7e9cc0a45..000000000 --- a/Documentation/video4linux/bttv/README +++ /dev/null @@ -1,86 +0,0 @@ - -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 - -/*(DEBLOBBED)*/ - -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: linux-media@vger.kernel.org -http://vger.kernel.org/vger-lists.html#linux-media - -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 a lot 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 deleted file mode 100644 index c61cf2864..000000000 --- a/Documentation/video4linux/bttv/README.WINVIEW +++ /dev/null @@ -1,33 +0,0 @@ - -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 deleted file mode 100644 index 5eddfa076..000000000 --- a/Documentation/video4linux/bttv/README.freeze +++ /dev/null @@ -1,74 +0,0 @@ - -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). -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 a lot 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 deleted file mode 100644 index 92e03929a..000000000 --- a/Documentation/video4linux/bttv/README.quirks +++ /dev/null @@ -1,83 +0,0 @@ - -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 deleted file mode 100644 index 646a47de0..000000000 --- a/Documentation/video4linux/bttv/Sound-FAQ +++ /dev/null @@ -1,148 +0,0 @@ - -bttv and sound mini howto -========================= - -There are a lot 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 information 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 -information 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 support 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 deleted file mode 100644 index f32466cda..000000000 --- a/Documentation/video4linux/bttv/Specs +++ /dev/null @@ -1,3 +0,0 @@ -Philips http://www.Semiconductors.COM/pip/ -Conexant http://www.conexant.com/ -Micronas http://www.micronas.com/en/home/index.html diff --git a/Documentation/video4linux/bttv/THANKS b/Documentation/video4linux/bttv/THANKS deleted file mode 100644 index 950aa781c..000000000 --- a/Documentation/video4linux/bttv/THANKS +++ /dev/null @@ -1,24 +0,0 @@ -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 deleted file mode 100644 index 0a371d349..000000000 --- a/Documentation/video4linux/bttv/Tuners +++ /dev/null @@ -1,115 +0,0 @@ -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/cafe_ccic b/Documentation/video4linux/cafe_ccic deleted file mode 100644 index 88821022a..000000000 --- a/Documentation/video4linux/cafe_ccic +++ /dev/null @@ -1,54 +0,0 @@ -"cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera -controller. This is the controller found in first-generation OLPC systems, -and this driver was written with support from the OLPC project. - -Current status: the core driver works. It can generate data in YUV422, -RGB565, and RGB444 formats. (Anybody looking at the code will see RGB32 as -well, but that is a debugging aid which will be removed shortly). VGA and -QVGA modes work; CIF is there but the colors remain funky. Only the OV7670 -sensor is known to work with this controller at this time. - -To try it out: either of these commands will work: - - mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound - mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound - -The "xawtv" utility also works; gqcam does not, for unknown reasons. - -There are a few load-time options, most of which can be changed after -loading via sysfs as well: - - - alloc_bufs_at_load: Normally, the driver will not allocate any DMA - buffers until the time comes to transfer data. If this option is set, - then worst-case-sized buffers will be allocated at module load time. - This option nails down the memory for the life of the module, but - perhaps decreases the chances of an allocation failure later on. - - - dma_buf_size: The size of DMA buffers to allocate. Note that this - option is only consulted for load-time allocation; when buffers are - allocated at run time, they will be sized appropriately for the current - camera settings. - - - n_dma_bufs: The controller can cycle through either two or three DMA - buffers. Normally, the driver tries to use three buffers; on faster - systems, however, it will work well with only two. - - - min_buffers: The minimum number of streaming I/O buffers that the driver - will consent to work with. Default is one, but, on slower systems, - better behavior with mplayer can be achieved by setting to a higher - value (like six). - - - max_buffers: The maximum number of streaming I/O buffers; default is - ten. That number was carefully picked out of a hat and should not be - assumed to actually mean much of anything. - - - flip: If this boolean parameter is set, the sensor will be instructed to - invert the video image. Whether it makes sense is determined by how - your particular camera is mounted. - -Work is ongoing with this driver, stay tuned. - -jon - -Jonathan Corbet -corbet@lwn.net diff --git a/Documentation/video4linux/cpia2_overview.txt b/Documentation/video4linux/cpia2_overview.txt deleted file mode 100644 index ad6adbedf..000000000 --- a/Documentation/video4linux/cpia2_overview.txt +++ /dev/null @@ -1,38 +0,0 @@ - Programmer's View of Cpia2 - -Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a -division of ST Microelectronics). There are two versions. The first is the -STV0672, which is capable of up to 30 frames per second (fps) in frame sizes -up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version, -which can handle up to 30 fps VGA. Both coprocessors can be attached to two -CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will -be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors. - -The two chipsets operate almost identically. The core is an 8051 processor, -running two different versions of firmware. The 672 runs the VP4 video -processor code, the 676 runs VP5. There are a few differences in register -mappings for the two chips. In these cases, the symbols defined in the -header files are marked with VP4 or VP5 as part of the symbol name. - -The cameras appear externally as three sets of registers. Setting register -values is the only way to control the camera. Some settings are -interdependant, such as the sequence required to power up the camera. I will -try to make note of all of these cases. - -The register sets are called blocks. Block 0 is the system block. This -section is always powered on when the camera is plugged in. It contains -registers that control housekeeping functions such as powering up the video -processor. The video processor is the VP block. These registers control -how the video from the sensor is processed. Examples are timing registers, -user mode (vga, qvga), scaling, cropping, framerates, and so on. The last -block is the video compressor (VC). The video stream sent from the camera is -compressed as Motion JPEG (JPEGA). The VC controls all of the compression -parameters. Looking at the file cpia2_registers.h, you can get a full view -of these registers and the possible values for most of them. - -One or more registers can be set or read by sending a usb control message to -the camera. There are three modes for this. Block mode requests a number -of contiguous registers. Random mode reads or writes random registers with -a tuple structure containing address/value pairs. The repeat mode is only -used by VP4 to load a firmware patch. It contains a starting address and -a sequence of bytes to be written into a gpio port. diff --git a/Documentation/video4linux/cx18.txt b/Documentation/video4linux/cx18.txt deleted file mode 100644 index 4652c0f5d..000000000 --- a/Documentation/video4linux/cx18.txt +++ /dev/null @@ -1,30 +0,0 @@ -Some notes regarding the cx18 driver for the Conexant CX23418 MPEG -encoder chip: - -1) Currently supported are: - - - Hauppauge HVR-1600 - - Compro VideoMate H900 - - Yuan MPC718 - - Conexant Raptor PAL/SECAM devkit - -2) Some people have problems getting the i2c bus to work. - The symptom is that the eeprom cannot be read and the card is - unusable. This is probably fixed, but if you have problems - then post to the video4linux or ivtv-users mailing list. - -3) VBI (raw or sliced) has not yet been implemented. - -4) MPEG indexing is not yet implemented. - -5) The driver is still a bit rough around the edges, this should - improve over time. - - -Firmware: - -You can obtain the firmware files here: - -http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz - -Untar and copy the .fw files to your firmware directory. diff --git a/Documentation/video4linux/cx2341x/README.hm12 b/Documentation/video4linux/cx2341x/README.hm12 deleted file mode 100644 index b36148ea0..000000000 --- a/Documentation/video4linux/cx2341x/README.hm12 +++ /dev/null @@ -1,120 +0,0 @@ -The cx23416 can produce (and the cx23415 can also read) raw YUV output. The -format of a YUV frame is specific to this chip and is called HM12. 'HM' stands -for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would -be more accurate. - -The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per -four pixels. - -The data is encoded as two macroblock planes, the first containing the Y -values, the second containing UV macroblocks. - -The Y plane is divided into blocks of 16x16 pixels from left to right -and from top to bottom. Each block is transmitted in turn, line-by-line. - -So the first 16 bytes are the first line of the top-left block, the -second 16 bytes are the second line of the top-left block, etc. After -transmitting this block the first line of the block on the right to the -first block is transmitted, etc. - -The UV plane is divided into blocks of 16x8 UV values going from left -to right, top to bottom. Each block is transmitted in turn, line-by-line. - -So the first 16 bytes are the first line of the top-left block and -contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the -second line of 8 UV pairs of the top-left block, etc. After transmitting -this block the first line of the block on the right to the first block is -transmitted, etc. - -The code below is given as an example on how to convert HM12 to separate -Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. - -The width of a frame is always 720 pixels, regardless of the actual specified -width. - -If the height is not a multiple of 32 lines, then the captured video is -missing macroblocks at the end and is unusable. So the height must be a -multiple of 32. - --------------------------------------------------------------------------- - -#include <stdio.h> -#include <stdlib.h> -#include <string.h> - -static unsigned char frame[576*720*3/2]; -static unsigned char framey[576*720]; -static unsigned char frameu[576*720 / 4]; -static unsigned char framev[576*720 / 4]; - -static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h) -{ - unsigned int y, x, i; - - // descramble Y plane - // dstride = 720 = w - // The Y plane is divided into blocks of 16x16 pixels - // Each block in transmitted in turn, line-by-line. - for (y = 0; y < h; y += 16) { - for (x = 0; x < w; x += 16) { - for (i = 0; i < 16; i++) { - memcpy(dst + x + (y + i) * dstride, src, 16); - src += 16; - } - } - } -} - -static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h) -{ - unsigned int y, x, i; - - // descramble U/V plane - // dstride = 720 / 2 = w - // The U/V values are interlaced (UVUV...). - // Again, the UV plane is divided into blocks of 16x16 UV values. - // Each block in transmitted in turn, line-by-line. - for (y = 0; y < h; y += 16) { - for (x = 0; x < w; x += 8) { - for (i = 0; i < 16; i++) { - int idx = x + (y + i) * dstride; - - dstu[idx+0] = src[0]; dstv[idx+0] = src[1]; - dstu[idx+1] = src[2]; dstv[idx+1] = src[3]; - dstu[idx+2] = src[4]; dstv[idx+2] = src[5]; - dstu[idx+3] = src[6]; dstv[idx+3] = src[7]; - dstu[idx+4] = src[8]; dstv[idx+4] = src[9]; - dstu[idx+5] = src[10]; dstv[idx+5] = src[11]; - dstu[idx+6] = src[12]; dstv[idx+6] = src[13]; - dstu[idx+7] = src[14]; dstv[idx+7] = src[15]; - src += 16; - } - } - } -} - -/*************************************************************************/ -int main(int argc, char **argv) -{ - FILE *fin; - int i; - - if (argc == 1) fin = stdin; - else fin = fopen(argv[1], "r"); - - if (fin == NULL) { - fprintf(stderr, "cannot open input\n"); - exit(-1); - } - while (fread(frame, sizeof(frame), 1, fin) == 1) { - de_macro_y(framey, frame, 720, 720, 576); - de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2); - fwrite(framey, sizeof(framey), 1, stdout); - fwrite(framev, sizeof(framev), 1, stdout); - fwrite(frameu, sizeof(frameu), 1, stdout); - } - fclose(fin); - return 0; -} - --------------------------------------------------------------------------- diff --git a/Documentation/video4linux/cx2341x/README.vbi b/Documentation/video4linux/cx2341x/README.vbi deleted file mode 100644 index 5807cf156..000000000 --- a/Documentation/video4linux/cx2341x/README.vbi +++ /dev/null @@ -1,45 +0,0 @@ - -Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data -========================================================= - -This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data -embedded in an MPEG-2 program stream. This format is in part dictated by some -hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6 -chips), in particular a maximum size for the VBI data. Anything longer is cut -off when the MPEG stream is played back through the cx23415. - -The advantage of this format is it is very compact and that all VBI data for -all lines can be stored while still fitting within the maximum allowed size. - -The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is -4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte -header and a 42 bytes payload each. Anything beyond this limit is cut off by -the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits -for a bitmask determining which lines are captured and 4 bytes for a magic cookie, -signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data. -If all lines are used, then there is no longer room for the bitmask. To solve this -two different magic numbers were introduced: - -'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first -unsigned long denote which lines of the first field are captured. Bits 18-31 of -the first unsigned long and bits 0-3 of the second unsigned long are used for the -second field. - -'ITV0': This magic number assumes all VBI lines are captured, i.e. it implicitly -implies that the bitmasks are 0xffffffff and 0xf. - -After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the -captured VBI lines start: - -For each line the least significant 4 bits of the first byte contain the data type. -Possible values are shown in the table below. The payload is in the following 42 -bytes. - -Here is the list of possible data types: - -#define IVTV_SLICED_TYPE_TELETEXT 0x1 // Teletext (uses lines 6-22 for PAL) -#define IVTV_SLICED_TYPE_CC 0x4 // Closed Captions (line 21 NTSC) -#define IVTV_SLICED_TYPE_WSS 0x5 // Wide Screen Signal (line 23 PAL) -#define IVTV_SLICED_TYPE_VPS 0x7 // Video Programming System (PAL) (line 16) - -Hans Verkuil <hverkuil@xs4all.nl> diff --git a/Documentation/video4linux/cx2341x/fw-calling.txt b/Documentation/video4linux/cx2341x/fw-calling.txt deleted file mode 100644 index 8d21181de..000000000 --- a/Documentation/video4linux/cx2341x/fw-calling.txt +++ /dev/null @@ -1,69 +0,0 @@ -This page describes how to make calls to the firmware api. - -How to call -=========== - -The preferred calling convention is known as the firmware mailbox. The -mailboxes are basically a fixed length array that serves as the call-stack. - -Firmware mailboxes can be located by searching the encoder and decoder memory -for a 16 byte signature. That signature will be located on a 256-byte boundary. - -Signature: -0x78, 0x56, 0x34, 0x12, 0x12, 0x78, 0x56, 0x34, -0x34, 0x12, 0x78, 0x56, 0x56, 0x34, 0x12, 0x78 - -The firmware implements 20 mailboxes of 20 32-bit words. The first 10 are -reserved for API calls. The second 10 are used by the firmware for event -notification. - - Index Name - ----- ---- - 0 Flags - 1 Command - 2 Return value - 3 Timeout - 4-19 Parameter/Result - - -The flags are defined in the following table. The direction is from the -perspective of the firmware. - - Bit Direction Purpose - --- --------- ------- - 2 O Firmware has processed the command. - 1 I Driver has finished setting the parameters. - 0 I Driver is using this mailbox. - - -The command is a 32-bit enumerator. The API specifics may be found in the -fw-*-api.txt documents. - -The return value is a 32-bit enumerator. Only two values are currently defined: -0=success and -1=command undefined. - -There are 16 parameters/results 32-bit fields. The driver populates these fields -with values for all the parameters required by the call. The driver overwrites -these fields with result values returned by the call. The API specifics may be -found in the fw-*-api.txt documents. - -The timeout value protects the card from a hung driver thread. If the driver -doesn't handle the completed call within the timeout specified, the firmware -will reset that mailbox. - -To make an API call, the driver iterates over each mailbox looking for the -first one available (bit 0 has been cleared). The driver sets that bit, fills -in the command enumerator, the timeout value and any required parameters. The -driver then sets the parameter ready bit (bit 1). The firmware scans the -mailboxes for pending commands, processes them, sets the result code, populates -the result value array with that call's return values and sets the call -complete bit (bit 2). Once bit 2 is set, the driver should retrieve the results -and clear all the flags. If the driver does not perform this task within the -time set in the timeout register, the firmware will reset that mailbox. - -Event notifications are sent from the firmware to the host. The host tells the -firmware which events it is interested in via an API call. That call tells the -firmware which notification mailbox to use. The firmware signals the host via -an interrupt. Only the 16 Results fields are used, the Flags, Command, Return -value and Timeout words are not used. - diff --git a/Documentation/video4linux/cx2341x/fw-decoder-api.txt b/Documentation/video4linux/cx2341x/fw-decoder-api.txt deleted file mode 100644 index 8c317b7a4..000000000 --- a/Documentation/video4linux/cx2341x/fw-decoder-api.txt +++ /dev/null @@ -1,297 +0,0 @@ -Decoder firmware API description -================================ - -Note: this API is part of the decoder firmware, so it's cx23415 only. - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_PING_FW -Enum 0/0x00 -Description - This API call does nothing. It may be used to check if the firmware - is responding. - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_START_PLAYBACK -Enum 1/0x01 -Description - Begin or resume playback. -Param[0] - 0 based frame number in GOP to begin playback from. -Param[1] - Specifies the number of muted audio frames to play before normal - audio resumes. (This is not implemented in the firmware, leave at 0) - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_STOP_PLAYBACK -Enum 2/0x02 -Description - Ends playback and clears all decoder buffers. If PTS is not zero, - playback stops at specified PTS. -Param[0] - Display 0=last frame, 1=black - Note: this takes effect immediately, so if you want to wait for a PTS, - then use '0', otherwise the screen goes to black at once. - You can call this later (even if there is no playback) with a 1 value - to set the screen to black. -Param[1] - PTS low -Param[2] - PTS high - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_PLAYBACK_SPEED -Enum 3/0x03 -Description - Playback stream at speed other than normal. There are two modes of - operation: - Smooth: host transfers entire stream and firmware drops unused - frames. - Coarse: host drops frames based on indexing as required to achieve - desired speed. -Param[0] - Bitmap: - 0:7 0 normal - 1 fast only "1.5 times" - n nX fast, 1/nX slow - 30 Framedrop: - '0' during 1.5 times play, every other B frame is dropped - '1' during 1.5 times play, stream is unchanged (bitrate - must not exceed 8mbps) - 31 Speed: - '0' slow - '1' fast - Note: n is limited to 2. Anything higher does not result in - faster playback. Instead the host should start dropping frames. -Param[1] - Direction: 0=forward, 1=reverse - Note: to make reverse playback work you have to write full GOPs in - reverse order. -Param[2] - Picture mask: - 1=I frames - 3=I, P frames - 7=I, P, B frames -Param[3] - B frames per GOP (for reverse play only) - Note: for reverse playback the Picture Mask should be set to I or I, P. - Adding B frames to the mask will result in corrupt video. This field - has to be set to the correct value in order to keep the timing correct. -Param[4] - Mute audio: 0=disable, 1=enable -Param[5] - Display 0=frame, 1=field -Param[6] - Specifies the number of muted audio frames to play before normal audio - resumes. (Not implemented in the firmware, leave at 0) - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_STEP_VIDEO -Enum 5/0x05 -Description - Each call to this API steps the playback to the next unit defined below - in the current playback direction. -Param[0] - 0=frame, 1=top field, 2=bottom field - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_DMA_BLOCK_SIZE -Enum 8/0x08 -Description - Set DMA transfer block size. Counterpart to API 0xC9 -Param[0] - DMA transfer block size in bytes. A different size may be specified - when issuing the DMA transfer command. - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_GET_XFER_INFO -Enum 9/0x09 -Description - This API call may be used to detect an end of stream condition. -Result[0] - Stream type -Result[1] - Address offset -Result[2] - Maximum bytes to transfer -Result[3] - Buffer fullness - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_GET_DMA_STATUS -Enum 10/0x0A -Description - Status of the last DMA transfer -Result[0] - Bit 1 set means transfer complete - Bit 2 set means DMA error - Bit 3 set means linked list error -Result[1] - DMA type: 0=MPEG, 1=OSD, 2=YUV - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SCHED_DMA_FROM_HOST -Enum 11/0x0B -Description - Setup DMA from host operation. Counterpart to API 0xCC -Param[0] - Memory address of link list -Param[1] - Total # of bytes to transfer -Param[2] - DMA type (0=MPEG, 1=OSD, 2=YUV) - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_PAUSE_PLAYBACK -Enum 13/0x0D -Description - Freeze playback immediately. In this mode, when internal buffers are - full, no more data will be accepted and data request IRQs will be - masked. -Param[0] - Display: 0=last frame, 1=black - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_HALT_FW -Enum 14/0x0E -Description - The firmware is halted and no further API calls are serviced until - the firmware is uploaded again. - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_STANDARD -Enum 16/0x10 -Description - Selects display standard -Param[0] - 0=NTSC, 1=PAL - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_GET_VERSION -Enum 17/0x11 -Description - Returns decoder firmware version information -Result[0] - Version bitmask: - Bits 0:15 build - Bits 16:23 minor - Bits 24:31 major - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_STREAM_INPUT -Enum 20/0x14 -Description - Select decoder stream input port -Param[0] - 0=memory (default), 1=streaming - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_GET_TIMING_INFO -Enum 21/0x15 -Description - Returns timing information from start of playback -Result[0] - Frame count by decode order -Result[1] - Video PTS bits 0:31 by display order -Result[2] - Video PTS bit 32 by display order -Result[3] - SCR bits 0:31 by display order -Result[4] - SCR bit 32 by display order - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_AUDIO_MODE -Enum 22/0x16 -Description - Select audio mode -Param[0] - Dual mono mode action - 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged -Param[1] - Stereo mode action: - 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_EVENT_NOTIFICATION -Enum 23/0x17 -Description - Setup firmware to notify the host about a particular event. - Counterpart to API 0xD5 -Param[0] - Event: 0=Audio mode change between mono, (joint) stereo and dual channel. - Event: 3=Decoder started - Event: 4=Unknown: goes off 10-15 times per second while decoding. - Event: 5=Some sync event: goes off once per frame. -Param[1] - Notification 0=disabled, 1=enabled -Param[2] - Interrupt bit -Param[3] - Mailbox slot, -1 if no mailbox required. - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_DISPLAY_BUFFERS -Enum 24/0x18 -Description - Number of display buffers. To decode all frames in reverse playback you - must use nine buffers. -Param[0] - 0=six buffers, 1=nine buffers - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_EXTRACT_VBI -Enum 25/0x19 -Description - Extracts VBI data -Param[0] - 0=extract from extension & user data, 1=extract from private packets -Result[0] - VBI table location -Result[1] - VBI table size - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_DECODER_SOURCE -Enum 26/0x1A -Description - Selects decoder source. Ensure that the parameters passed to this - API match the encoder settings. -Param[0] - Mode: 0=MPEG from host, 1=YUV from encoder, 2=YUV from host -Param[1] - YUV picture width -Param[2] - YUV picture height -Param[3] - Bitmap: see Param[0] of API 0xBD - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_PREBUFFERING -Enum 30/0x1E -Description - Decoder prebuffering, when enabled up to 128KB are buffered for - streams <8mpbs or 640KB for streams >8mbps -Param[0] - 0=off, 1=on diff --git a/Documentation/video4linux/cx2341x/fw-decoder-regs.txt b/Documentation/video4linux/cx2341x/fw-decoder-regs.txt deleted file mode 100644 index cf52c8f20..000000000 --- a/Documentation/video4linux/cx2341x/fw-decoder-regs.txt +++ /dev/null @@ -1,817 +0,0 @@ -PVR350 Video decoder registers 0x02002800 -> 0x02002B00 -======================================================= - -This list has been worked out through trial and error. There will be mistakes -and omissions. Some registers have no obvious effect so it's hard to say what -they do, while others interact with each other, or require a certain load -sequence. Horizontal filter setup is one example, with six registers working -in unison and requiring a certain load sequence to correctly configure. The -indexed colour palette is much easier to set at just two registers, but again -it requires a certain load sequence. - -Some registers are fussy about what they are set to. Load in a bad value & the -decoder will fail. A firmware reload will often recover, but sometimes a reset -is required. For registers containing size information, setting them to 0 is -generally a bad idea. For other control registers i.e. 2878, you'll only find -out what values are bad when it hangs. - --------------------------------------------------------------------------------- -2800 - bit 0 - Decoder enable - 0 = disable - 1 = enable --------------------------------------------------------------------------------- -2804 - bits 0:31 - Decoder horizontal Y alias register 1 ---------------- -2808 - bits 0:31 - Decoder horizontal Y alias register 2 ---------------- -280C - bits 0:31 - Decoder horizontal Y alias register 3 ---------------- -2810 - bits 0:31 - Decoder horizontal Y alias register 4 ---------------- -2814 - bits 0:31 - Decoder horizontal Y alias register 5 ---------------- -2818 - bits 0:31 - Decoder horizontal Y alias trigger - - These six registers control the horizontal aliasing filter for the Y plane. - The first five registers must all be loaded before accessing the trigger - (2818), as this register actually clocks the data through for the first - five. - - To correctly program set the filter, this whole procedure must be done 16 - times. The actual register contents are copied from a lookup-table in the - firmware which contains 4 different filter settings. - --------------------------------------------------------------------------------- -281C - bits 0:31 - Decoder horizontal UV alias register 1 ---------------- -2820 - bits 0:31 - Decoder horizontal UV alias register 2 ---------------- -2824 - bits 0:31 - Decoder horizontal UV alias register 3 ---------------- -2828 - bits 0:31 - Decoder horizontal UV alias register 4 ---------------- -282C - bits 0:31 - Decoder horizontal UV alias register 5 ---------------- -2830 - bits 0:31 - Decoder horizontal UV alias trigger - - These six registers control the horizontal aliasing for the UV plane. - Operation is the same as the Y filter, with 2830 being the trigger - register. - --------------------------------------------------------------------------------- -2834 - bits 0:15 - Decoder Y source width in pixels - - bits 16:31 - Decoder Y destination width in pixels ---------------- -2838 - bits 0:15 - Decoder UV source width in pixels - - bits 16:31 - Decoder UV destination width in pixels - - NOTE: For both registers, the resulting image must be fully visible on - screen. If the image exceeds the right edge both the source and destination - size must be adjusted to reflect the visible portion. For the source width, - you must take into account the scaling when calculating the new value. --------------------------------------------------------------------------------- - -283C - bits 0:31 - Decoder Y horizontal scaling - Normally = Reg 2854 >> 2 ---------------- -2840 - bits 0:31 - Decoder ?? unknown - horizontal scaling - Usually 0x00080514 ---------------- -2844 - bits 0:31 - Decoder UV horizontal scaling - Normally = Reg 2854 >> 2 ---------------- -2848 - bits 0:31 - Decoder ?? unknown - horizontal scaling - Usually 0x00100514 ---------------- -284C - bits 0:31 - Decoder ?? unknown - Y plane - Usually 0x00200020 ---------------- -2850 - bits 0:31 - Decoder ?? unknown - UV plane - Usually 0x00200020 ---------------- -2854 - bits 0:31 - Decoder 'master' value for horizontal scaling ---------------- -2858 - bits 0:31 - Decoder ?? unknown - Usually 0 ---------------- -285C - bits 0:31 - Decoder ?? unknown - Normally = Reg 2854 >> 1 ---------------- -2860 - bits 0:31 - Decoder ?? unknown - Usually 0 ---------------- -2864 - bits 0:31 - Decoder ?? unknown - Normally = Reg 2854 >> 1 ---------------- -2868 - bits 0:31 - Decoder ?? unknown - Usually 0 - - Most of these registers either control horizontal scaling, or appear linked - to it in some way. Register 2854 contains the 'master' value & the other - registers can be calculated from that one. You must also remember to - correctly set the divider in Reg 2874. - - To enlarge: - Reg 2854 = (source_width * 0x00200000) / destination_width - Reg 2874 = No divide - - To reduce from full size down to half size: - Reg 2854 = (source_width/2 * 0x00200000) / destination width - Reg 2874 = Divide by 2 - - To reduce from half size down to quarter size: - Reg 2854 = (source_width/4 * 0x00200000) / destination width - Reg 2874 = Divide by 4 - - The result is always rounded up. - --------------------------------------------------------------------------------- -286C - bits 0:15 - Decoder horizontal Y buffer offset - - bits 15:31 - Decoder horizontal UV buffer offset - - Offset into the video image buffer. If the offset is gradually incremented, - the on screen image will move left & wrap around higher up on the right. - --------------------------------------------------------------------------------- -2870 - bits 0:15 - Decoder horizontal Y output offset - - bits 16:31 - Decoder horizontal UV output offset - - Offsets the actual video output. Controls output alignment of the Y & UV - planes. The higher the value, the greater the shift to the left. Use - reg 2890 to move the image right. - --------------------------------------------------------------------------------- -2874 - bits 0:1 - Decoder horizontal Y output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 3 - - bits 4:5 - Decoder horizontal UV output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 3 - - bit 8 - Decoder ?? unknown - 0 = Normal - 1 = Affects video output levels - - bit 16 - Decoder ?? unknown - 0 = Normal - 1 = Disable horizontal filter - --------------------------------------------------------------------------------- -2878 - bit 0 - ?? unknown - - bit 1 - osd on/off - 0 = osd off - 1 = osd on - - bit 2 - Decoder + osd video timing - 0 = NTSC - 1 = PAL - - bits 3:4 - ?? unknown - - bit 5 - Decoder + osd - Swaps upper & lower fields - --------------------------------------------------------------------------------- -287C - bits 0:10 - Decoder & osd ?? unknown - Moves entire screen horizontally. Starts at 0x005 with the screen - shifted heavily to the right. Incrementing in steps of 0x004 will - gradually shift the screen to the left. - - bits 11:31 - ?? unknown - - Normally contents are 0x00101111 (NTSC) or 0x1010111d (PAL) - --------------------------------------------------------------------------------- -2880 -------- ?? unknown -2884 -------- ?? unknown --------------------------------------------------------------------------------- -2888 - bit 0 - Decoder + osd ?? unknown - 0 = Normal - 1 = Misaligned fields (Correctable through 289C & 28A4) - - bit 4 - ?? unknown - - bit 8 - ?? unknown - - Warning: Bad values will require a firmware reload to recover. - Known to be bad are 0x000,0x011,0x100,0x111 --------------------------------------------------------------------------------- -288C - bits 0:15 - osd ?? unknown - Appears to affect the osd position stability. The higher the value the - more unstable it becomes. Decoder output remains stable. - - bits 16:31 - osd ?? unknown - Same as bits 0:15 - --------------------------------------------------------------------------------- -2890 - bits 0:11 - Decoder output horizontal offset. - - Horizontal offset moves the video image right. A small left shift is - possible, but it's better to use reg 2870 for that due to its greater - range. - - NOTE: Video corruption will occur if video window is shifted off the right - edge. To avoid this read the notes for 2834 & 2838. --------------------------------------------------------------------------------- -2894 - bits 0:23 - Decoder output video surround colour. - - Contains the colour (in yuv) used to fill the screen when the video is - running in a window. --------------------------------------------------------------------------------- -2898 - bits 0:23 - Decoder video window colour - Contains the colour (in yuv) used to fill the video window when the - video is turned off. - - bit 24 - Decoder video output - 0 = Video on - 1 = Video off - - bit 28 - Decoder plane order - 0 = Y,UV - 1 = UV,Y - - bit 29 - Decoder second plane byte order - 0 = Normal (UV) - 1 = Swapped (VU) - - In normal usage, the first plane is Y & the second plane is UV. Though the - order of the planes can be swapped, only the byte order of the second plane - can be swapped. This isn't much use for the Y plane, but can be useful for - the UV plane. - --------------------------------------------------------------------------------- -289C - bits 0:15 - Decoder vertical field offset 1 - - bits 16:31 - Decoder vertical field offset 2 - - Controls field output vertical alignment. The higher the number, the lower - the image on screen. Known starting values are 0x011E0017 (NTSC) & - 0x01500017 (PAL) --------------------------------------------------------------------------------- -28A0 - bits 0:15 - Decoder & osd width in pixels - - bits 16:31 - Decoder & osd height in pixels - - All output from the decoder & osd are disabled beyond this area. Decoder - output will simply go black outside of this region. If the osd tries to - exceed this area it will become corrupt. --------------------------------------------------------------------------------- -28A4 - bits 0:11 - osd left shift. - - Has a range of 0x770->0x7FF. With the exception of 0, any value outside of - this range corrupts the osd. --------------------------------------------------------------------------------- -28A8 - bits 0:15 - osd vertical field offset 1 - - bits 16:31 - osd vertical field offset 2 - - Controls field output vertical alignment. The higher the number, the lower - the image on screen. Known starting values are 0x011E0017 (NTSC) & - 0x01500017 (PAL) --------------------------------------------------------------------------------- -28AC -------- ?? unknown - | - V -28BC -------- ?? unknown --------------------------------------------------------------------------------- -28C0 - bit 0 - Current output field - 0 = first field - 1 = second field - - bits 16:31 - Current scanline - The scanline counts from the top line of the first field - through to the last line of the second field. --------------------------------------------------------------------------------- -28C4 -------- ?? unknown - | - V -28F8 -------- ?? unknown --------------------------------------------------------------------------------- -28FC - bit 0 - ?? unknown - 0 = Normal - 1 = Breaks decoder & osd output --------------------------------------------------------------------------------- -2900 - bits 0:31 - Decoder vertical Y alias register 1 ---------------- -2904 - bits 0:31 - Decoder vertical Y alias register 2 ---------------- -2908 - bits 0:31 - Decoder vertical Y alias trigger - - These three registers control the vertical aliasing filter for the Y plane. - Operation is similar to the horizontal Y filter (2804). The only real - difference is that there are only two registers to set before accessing - the trigger register (2908). As for the horizontal filter, the values are - taken from a lookup table in the firmware, and the procedure must be - repeated 16 times to fully program the filter. --------------------------------------------------------------------------------- -290C - bits 0:31 - Decoder vertical UV alias register 1 ---------------- -2910 - bits 0:31 - Decoder vertical UV alias register 2 ---------------- -2914 - bits 0:31 - Decoder vertical UV alias trigger - - These three registers control the vertical aliasing filter for the UV - plane. Operation is the same as the Y filter, with 2914 being the trigger. --------------------------------------------------------------------------------- -2918 - bits 0:15 - Decoder Y source height in pixels - - bits 16:31 - Decoder Y destination height in pixels ---------------- -291C - bits 0:15 - Decoder UV source height in pixels divided by 2 - - bits 16:31 - Decoder UV destination height in pixels - - NOTE: For both registers, the resulting image must be fully visible on - screen. If the image exceeds the bottom edge both the source and - destination size must be adjusted to reflect the visible portion. For the - source height, you must take into account the scaling when calculating the - new value. --------------------------------------------------------------------------------- -2920 - bits 0:31 - Decoder Y vertical scaling - Normally = Reg 2930 >> 2 ---------------- -2924 - bits 0:31 - Decoder Y vertical scaling - Normally = Reg 2920 + 0x514 ---------------- -2928 - bits 0:31 - Decoder UV vertical scaling - When enlarging = Reg 2930 >> 2 - When reducing = Reg 2930 >> 3 ---------------- -292C - bits 0:31 - Decoder UV vertical scaling - Normally = Reg 2928 + 0x514 ---------------- -2930 - bits 0:31 - Decoder 'master' value for vertical scaling ---------------- -2934 - bits 0:31 - Decoder ?? unknown - Y vertical scaling ---------------- -2938 - bits 0:31 - Decoder Y vertical scaling - Normally = Reg 2930 ---------------- -293C - bits 0:31 - Decoder ?? unknown - Y vertical scaling ---------------- -2940 - bits 0:31 - Decoder UV vertical scaling - When enlarging = Reg 2930 >> 1 - When reducing = Reg 2930 ---------------- -2944 - bits 0:31 - Decoder ?? unknown - UV vertical scaling ---------------- -2948 - bits 0:31 - Decoder UV vertical scaling - Normally = Reg 2940 ---------------- -294C - bits 0:31 - Decoder ?? unknown - UV vertical scaling - - Most of these registers either control vertical scaling, or appear linked - to it in some way. Register 2930 contains the 'master' value & all other - registers can be calculated from that one. You must also remember to - correctly set the divider in Reg 296C - - To enlarge: - Reg 2930 = (source_height * 0x00200000) / destination_height - Reg 296C = No divide - - To reduce from full size down to half size: - Reg 2930 = (source_height/2 * 0x00200000) / destination height - Reg 296C = Divide by 2 - - To reduce from half down to quarter. - Reg 2930 = (source_height/4 * 0x00200000) / destination height - Reg 296C = Divide by 4 - --------------------------------------------------------------------------------- -2950 - bits 0:15 - Decoder Y line index into display buffer, first field - - bits 16:31 - Decoder Y vertical line skip, first field --------------------------------------------------------------------------------- -2954 - bits 0:15 - Decoder Y line index into display buffer, second field - - bits 16:31 - Decoder Y vertical line skip, second field --------------------------------------------------------------------------------- -2958 - bits 0:15 - Decoder UV line index into display buffer, first field - - bits 16:31 - Decoder UV vertical line skip, first field --------------------------------------------------------------------------------- -295C - bits 0:15 - Decoder UV line index into display buffer, second field - - bits 16:31 - Decoder UV vertical line skip, second field --------------------------------------------------------------------------------- -2960 - bits 0:15 - Decoder destination height minus 1 - - bits 16:31 - Decoder destination height divided by 2 --------------------------------------------------------------------------------- -2964 - bits 0:15 - Decoder Y vertical offset, second field - - bits 16:31 - Decoder Y vertical offset, first field - - These two registers shift the Y plane up. The higher the number, the - greater the shift. --------------------------------------------------------------------------------- -2968 - bits 0:15 - Decoder UV vertical offset, second field - - bits 16:31 - Decoder UV vertical offset, first field - - These two registers shift the UV plane up. The higher the number, the - greater the shift. --------------------------------------------------------------------------------- -296C - bits 0:1 - Decoder vertical Y output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 4 - - bits 8:9 - Decoder vertical UV output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 4 --------------------------------------------------------------------------------- -2970 - bit 0 - Decoder ?? unknown - 0 = Normal - 1 = Affect video output levels - - bit 16 - Decoder ?? unknown - 0 = Normal - 1 = Disable vertical filter - --------------------------------------------------------------------------------- -2974 -------- ?? unknown - | - V -29EF -------- ?? unknown --------------------------------------------------------------------------------- -2A00 - bits 0:2 - osd colour mode - 000 = 8 bit indexed - 001 = 16 bit (565) - 010 = 15 bit (555) - 011 = 12 bit (444) - 100 = 32 bit (8888) - - bits 4:5 - osd display bpp - 01 = 8 bit - 10 = 16 bit - 11 = 32 bit - - bit 8 - osd global alpha - 0 = Off - 1 = On - - bit 9 - osd local alpha - 0 = Off - 1 = On - - bit 10 - osd colour key - 0 = Off - 1 = On - - bit 11 - osd ?? unknown - Must be 1 - - bit 13 - osd colour space - 0 = ARGB - 1 = AYVU - - bits 16:31 - osd ?? unknown - Must be 0x001B (some kind of buffer pointer ?) - - When the bits-per-pixel is set to 8, the colour mode is ignored and - assumed to be 8 bit indexed. For 16 & 32 bits-per-pixel the colour depth - is honoured, and when using a colour depth that requires fewer bytes than - allocated the extra bytes are used as padding. So for a 32 bpp with 8 bit - index colour, there are 3 padding bytes per pixel. It's also possible to - select 16bpp with a 32 bit colour mode. This results in the pixel width - being doubled, but the color key will not work as expected in this mode. - - Colour key is as it suggests. You designate a colour which will become - completely transparent. When using 565, 555 or 444 colour modes, the - colour key is always 16 bits wide. The colour to key on is set in Reg 2A18. - - Local alpha works differently depending on the colour mode. For 32bpp & 8 - bit indexed, local alpha is a per-pixel 256 step transparency, with 0 being - transparent and 255 being solid. For the 16bpp modes 555 & 444, the unused - bit(s) act as a simple transparency switch, with 0 being solid & 1 being - fully transparent. There is no local alpha support for 16bit 565. - - Global alpha is a 256 step transparency that applies to the entire osd, - with 0 being transparent & 255 being solid. - - It's possible to combine colour key, local alpha & global alpha. --------------------------------------------------------------------------------- -2A04 - bits 0:15 - osd x coord for left edge - - bits 16:31 - osd y coord for top edge ---------------- -2A08 - bits 0:15 - osd x coord for right edge - - bits 16:31 - osd y coord for bottom edge - - For both registers, (0,0) = top left corner of the display area. These - registers do not control the osd size, only where it's positioned & how - much is visible. The visible osd area cannot exceed the right edge of the - display, otherwise the osd will become corrupt. See reg 2A10 for - setting osd width. --------------------------------------------------------------------------------- -2A0C - bits 0:31 - osd buffer index - - An index into the osd buffer. Slowly incrementing this moves the osd left, - wrapping around onto the right edge --------------------------------------------------------------------------------- -2A10 - bits 0:11 - osd buffer 32 bit word width - - Contains the width of the osd measured in 32 bit words. This means that all - colour modes are restricted to a byte width which is divisible by 4. --------------------------------------------------------------------------------- -2A14 - bits 0:15 - osd height in pixels - - bits 16:32 - osd line index into buffer - osd will start displaying from this line. --------------------------------------------------------------------------------- -2A18 - bits 0:31 - osd colour key - - Contains the colour value which will be transparent. --------------------------------------------------------------------------------- -2A1C - bits 0:7 - osd global alpha - - Contains the global alpha value (equiv ivtvfbctl --alpha XX) --------------------------------------------------------------------------------- -2A20 -------- ?? unknown - | - V -2A2C -------- ?? unknown --------------------------------------------------------------------------------- -2A30 - bits 0:7 - osd colour to change in indexed palette ---------------- -2A34 - bits 0:31 - osd colour for indexed palette - - To set the new palette, first load the index of the colour to change into - 2A30, then load the new colour into 2A34. The full palette is 256 colours, - so the index range is 0x00-0xFF --------------------------------------------------------------------------------- -2A38 -------- ?? unknown -2A3C -------- ?? unknown --------------------------------------------------------------------------------- -2A40 - bits 0:31 - osd ?? unknown - - Affects overall brightness, wrapping around to black --------------------------------------------------------------------------------- -2A44 - bits 0:31 - osd ?? unknown - - Green tint --------------------------------------------------------------------------------- -2A48 - bits 0:31 - osd ?? unknown - - Red tint --------------------------------------------------------------------------------- -2A4C - bits 0:31 - osd ?? unknown - - Affects overall brightness, wrapping around to black --------------------------------------------------------------------------------- -2A50 - bits 0:31 - osd ?? unknown - - Colour shift --------------------------------------------------------------------------------- -2A54 - bits 0:31 - osd ?? unknown - - Colour shift --------------------------------------------------------------------------------- -2A58 -------- ?? unknown - | - V -2AFC -------- ?? unknown --------------------------------------------------------------------------------- -2B00 - bit 0 - osd filter control - 0 = filter off - 1 = filter on - - bits 1:4 - osd ?? unknown - --------------------------------------------------------------------------------- - -v0.4 - 12 March 2007 - Ian Armstrong (ian@iarmst.demon.co.uk) - diff --git a/Documentation/video4linux/cx2341x/fw-dma.txt b/Documentation/video4linux/cx2341x/fw-dma.txt deleted file mode 100644 index be52b6fd1..000000000 --- a/Documentation/video4linux/cx2341x/fw-dma.txt +++ /dev/null @@ -1,96 +0,0 @@ -This page describes the structures and procedures used by the cx2341x DMA -engine. - -Introduction -============ - -The cx2341x PCI interface is busmaster capable. This means it has a DMA -engine to efficiently transfer large volumes of data between the card and main -memory without requiring help from a CPU. Like most hardware, it must operate -on contiguous physical memory. This is difficult to come by in large quantities -on virtual memory machines. - -Therefore, it also supports a technique called "scatter-gather". The card can -transfer multiple buffers in one operation. Instead of allocating one large -contiguous buffer, the driver can allocate several smaller buffers. - -In practice, I've seen the average transfer to be roughly 80K, but transfers -above 128K were not uncommon, particularly at startup. The 128K figure is -important, because that is the largest block that the kernel can normally -allocate. Even still, 128K blocks are hard to come by, so the driver writer is -urged to choose a smaller block size and learn the scatter-gather technique. - -Mailbox #10 is reserved for DMA transfer information. - -Note: the hardware expects little-endian data ('intel format'). - -Flow -==== - -This section describes, in general, the order of events when handling DMA -transfers. Detailed information follows this section. - -- The card raises the Encoder interrupt. -- The driver reads the transfer type, offset and size from Mailbox #10. -- The driver constructs the scatter-gather array from enough free dma buffers - to cover the size. -- The driver schedules the DMA transfer via the ScheduleDMAtoHost API call. -- The card raises the DMA Complete interrupt. -- The driver checks the DMA status register for any errors. -- The driver post-processes the newly transferred buffers. - -NOTE! It is possible that the Encoder and DMA Complete interrupts get raised -simultaneously. (End of the last, start of the next, etc.) - -Mailbox #10 -=========== - -The Flags, Command, Return Value and Timeout fields are ignored. - -Name: Mailbox #10 -Results[0]: Type: 0: MPEG. -Results[1]: Offset: The position relative to the card's memory space. -Results[2]: Size: The exact number of bytes to transfer. - -My speculation is that since the StartCapture API has a capture type of "RAW" -available, that the type field will have other values that correspond to YUV -and PCM data. - -Scatter-Gather Array -==================== - -The scatter-gather array is a contiguously allocated block of memory that -tells the card the source and destination of each data-block to transfer. -Card "addresses" are derived from the offset supplied by Mailbox #10. Host -addresses are the physical memory location of the target DMA buffer. - -Each S-G array element is a struct of three 32-bit words. The first word is -the source address, the second is the destination address. Both take up the -entire 32 bits. The lowest 18 bits of the third word is the transfer byte -count. The high-bit of the third word is the "last" flag. The last-flag tells -the card to raise the DMA_DONE interrupt. From hard personal experience, if -you forget to set this bit, the card will still "work" but the stream will -most likely get corrupted. - -The transfer count must be a multiple of 256. Therefore, the driver will need -to track how much data in the target buffer is valid and deal with it -accordingly. - -Array Element: - -- 32-bit Source Address -- 32-bit Destination Address -- 14-bit reserved (high bit is the last flag) -- 18-bit byte count - -DMA Transfer Status -=================== - -Register 0x0004 holds the DMA Transfer Status: - -Bit -0 read completed -1 write completed -2 DMA read error -3 DMA write error -4 Scatter-Gather array error diff --git a/Documentation/video4linux/cx2341x/fw-encoder-api.txt b/Documentation/video4linux/cx2341x/fw-encoder-api.txt deleted file mode 100644 index 5a27af2ee..000000000 --- a/Documentation/video4linux/cx2341x/fw-encoder-api.txt +++ /dev/null @@ -1,709 +0,0 @@ -Encoder firmware API description -================================ - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_PING_FW -Enum 128/0x80 -Description - Does nothing. Can be used to check if the firmware is responding. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_START_CAPTURE -Enum 129/0x81 -Description - Commences the capture of video, audio and/or VBI data. All encoding - parameters must be initialized prior to this API call. Captures frames - continuously or until a predefined number of frames have been captured. -Param[0] - Capture stream type: - 0=MPEG - 1=Raw - 2=Raw passthrough - 3=VBI - -Param[1] - Bitmask: - Bit 0 when set, captures YUV - Bit 1 when set, captures PCM audio - Bit 2 when set, captures VBI (same as param[0]=3) - Bit 3 when set, the capture destination is the decoder - (same as param[0]=2) - Bit 4 when set, the capture destination is the host - Note: this parameter is only meaningful for RAW capture type. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_STOP_CAPTURE -Enum 130/0x82 -Description - Ends a capture in progress -Param[0] - 0=stop at end of GOP (generates IRQ) - 1=stop immediate (no IRQ) -Param[1] - Stream type to stop, see param[0] of API 0x81 -Param[2] - Subtype, see param[1] of API 0x81 - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_AUDIO_ID -Enum 137/0x89 -Description - Assigns the transport stream ID of the encoded audio stream -Param[0] - Audio Stream ID - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_VIDEO_ID -Enum 139/0x8B -Description - Set video transport stream ID -Param[0] - Video stream ID - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_PCR_ID -Enum 141/0x8D -Description - Assigns the transport stream ID for PCR packets -Param[0] - PCR Stream ID - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_FRAME_RATE -Enum 143/0x8F -Description - Set video frames per second. Change occurs at start of new GOP. -Param[0] - 0=30fps - 1=25fps - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_FRAME_SIZE -Enum 145/0x91 -Description - Select video stream encoding resolution. -Param[0] - Height in lines. Default 480 -Param[1] - Width in pixels. Default 720 - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_BIT_RATE -Enum 149/0x95 -Description - Assign average video stream bitrate. Note on the last three params: - Param[3] and [4] seem to be always 0, param [5] doesn't seem to be used. -Param[0] - 0=variable bitrate, 1=constant bitrate -Param[1] - bitrate in bits per second -Param[2] - peak bitrate in bits per second, divided by 400 -Param[3] - Mux bitrate in bits per second, divided by 400. May be 0 (default). -Param[4] - Rate Control VBR Padding -Param[5] - VBV Buffer used by encoder - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_GOP_PROPERTIES -Enum 151/0x97 -Description - Setup the GOP structure -Param[0] - GOP size (maximum is 34) -Param[1] - Number of B frames between the I and P frame, plus 1. - For example: IBBPBBPBBPBB --> GOP size: 12, number of B frames: 2+1 = 3 - Note that GOP size must be a multiple of (B-frames + 1). - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_ASPECT_RATIO -Enum 153/0x99 -Description - Sets the encoding aspect ratio. Changes in the aspect ratio take effect - at the start of the next GOP. -Param[0] - '0000' forbidden - '0001' 1:1 square - '0010' 4:3 - '0011' 16:9 - '0100' 2.21:1 - '0101' reserved - .... - '1111' reserved - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_DNR_FILTER_MODE -Enum 155/0x9B -Description - Assign Dynamic Noise Reduction operating mode -Param[0] - Bit0: Spatial filter, set=auto, clear=manual - Bit1: Temporal filter, set=auto, clear=manual -Param[1] - Median filter: - 0=Disabled - 1=Horizontal - 2=Vertical - 3=Horiz/Vert - 4=Diagonal - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_DNR_FILTER_PROPS -Enum 157/0x9D -Description - These Dynamic Noise Reduction filter values are only meaningful when - the respective filter is set to "manual" (See API 0x9B) -Param[0] - Spatial filter: default 0, range 0:15 -Param[1] - Temporal filter: default 0, range 0:31 - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_CORING_LEVELS -Enum 159/0x9F -Description - Assign Dynamic Noise Reduction median filter properties. -Param[0] - Threshold above which the luminance median filter is enabled. - Default: 0, range 0:255 -Param[1] - Threshold below which the luminance median filter is enabled. - Default: 255, range 0:255 -Param[2] - Threshold above which the chrominance median filter is enabled. - Default: 0, range 0:255 -Param[3] - Threshold below which the chrominance median filter is enabled. - Default: 255, range 0:255 - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_SPATIAL_FILTER_TYPE -Enum 161/0xA1 -Description - Assign spatial prefilter parameters -Param[0] - Luminance filter - 0=Off - 1=1D Horizontal - 2=1D Vertical - 3=2D H/V Separable (default) - 4=2D Symmetric non-separable -Param[1] - Chrominance filter - 0=Off - 1=1D Horizontal (default) - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_VBI_LINE -Enum 183/0xB7 -Description - Selects VBI line number. -Param[0] - Bits 0:4 line number - Bit 31 0=top_field, 1=bottom_field - Bits 0:31 all set specifies "all lines" -Param[1] - VBI line information features: 0=disabled, 1=enabled -Param[2] - Slicing: 0=None, 1=Closed Caption - Almost certainly not implemented. Set to 0. -Param[3] - Luminance samples in this line. - Almost certainly not implemented. Set to 0. -Param[4] - Chrominance samples in this line - Almost certainly not implemented. Set to 0. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_STREAM_TYPE -Enum 185/0xB9 -Description - Assign stream type - Note: Transport stream is not working in recent firmwares. - And in older firmwares the timestamps in the TS seem to be - unreliable. -Param[0] - 0=Program stream - 1=Transport stream - 2=MPEG1 stream - 3=PES A/V stream - 5=PES Video stream - 7=PES Audio stream - 10=DVD stream - 11=VCD stream - 12=SVCD stream - 13=DVD_S1 stream - 14=DVD_S2 stream - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_OUTPUT_PORT -Enum 187/0xBB -Description - Assign stream output port. Normally 0 when the data is copied through - the PCI bus (DMA), and 1 when the data is streamed to another chip - (pvrusb and cx88-blackbird). -Param[0] - 0=Memory (default) - 1=Streaming - 2=Serial -Param[1] - Unknown, but leaving this to 0 seems to work best. Indications are that - this might have to do with USB support, although passing anything but 0 - only breaks things. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_AUDIO_PROPERTIES -Enum 189/0xBD -Description - Set audio stream properties, may be called while encoding is in progress. - Note: all bitfields are consistent with ISO11172 documentation except - bits 2:3 which ISO docs define as: - '11' Layer I - '10' Layer II - '01' Layer III - '00' Undefined - This discrepancy may indicate a possible error in the documentation. - Testing indicated that only Layer II is actually working, and that - the minimum bitrate should be 192 kbps. -Param[0] - Bitmask: - 0:1 '00' 44.1Khz - '01' 48Khz - '10' 32Khz - '11' reserved - - 2:3 '01'=Layer I - '10'=Layer II - - 4:7 Bitrate: - Index | Layer I | Layer II - ------+-------------+------------ - '0000' | free format | free format - '0001' | 32 kbit/s | 32 kbit/s - '0010' | 64 kbit/s | 48 kbit/s - '0011' | 96 kbit/s | 56 kbit/s - '0100' | 128 kbit/s | 64 kbit/s - '0101' | 160 kbit/s | 80 kbit/s - '0110' | 192 kbit/s | 96 kbit/s - '0111' | 224 kbit/s | 112 kbit/s - '1000' | 256 kbit/s | 128 kbit/s - '1001' | 288 kbit/s | 160 kbit/s - '1010' | 320 kbit/s | 192 kbit/s - '1011' | 352 kbit/s | 224 kbit/s - '1100' | 384 kbit/s | 256 kbit/s - '1101' | 416 kbit/s | 320 kbit/s - '1110' | 448 kbit/s | 384 kbit/s - Note: For Layer II, not all combinations of total bitrate - and mode are allowed. See ISO11172-3 3-Annex B, Table 3-B.2 - - 8:9 '00'=Stereo - '01'=JointStereo - '10'=Dual - '11'=Mono - Note: the cx23415 cannot decode Joint Stereo properly. - - 10:11 Mode Extension used in joint_stereo mode. - In Layer I and II they indicate which subbands are in - intensity_stereo. All other subbands are coded in stereo. - '00' subbands 4-31 in intensity_stereo, bound==4 - '01' subbands 8-31 in intensity_stereo, bound==8 - '10' subbands 12-31 in intensity_stereo, bound==12 - '11' subbands 16-31 in intensity_stereo, bound==16 - - 12:13 Emphasis: - '00' None - '01' 50/15uS - '10' reserved - '11' CCITT J.17 - - 14 CRC: - '0' off - '1' on - - 15 Copyright: - '0' off - '1' on - - 16 Generation: - '0' copy - '1' original - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_HALT_FW -Enum 195/0xC3 -Description - The firmware is halted and no further API calls are serviced until the - firmware is uploaded again. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_GET_VERSION -Enum 196/0xC4 -Description - Returns the version of the encoder firmware. -Result[0] - Version bitmask: - Bits 0:15 build - Bits 16:23 minor - Bits 24:31 major - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_GOP_CLOSURE -Enum 197/0xC5 -Description - Assigns the GOP open/close property. -Param[0] - 0=Open - 1=Closed - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_GET_SEQ_END -Enum 198/0xC6 -Description - Obtains the sequence end code of the encoder's buffer. When a capture - is started a number of interrupts are still generated, the last of - which will have Result[0] set to 1 and Result[1] will contain the size - of the buffer. -Result[0] - State of the transfer (1 if last buffer) -Result[1] - If Result[0] is 1, this contains the size of the last buffer, undefined - otherwise. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_PGM_INDEX_INFO -Enum 199/0xC7 -Description - Sets the Program Index Information. - The information is stored as follows: - - struct info { - u32 length; // Length of this frame - u32 offset_low; // Offset in the file of the - u32 offset_high; // start of this frame - u32 mask1; // Bits 0-2 are the type mask: - // 1=I, 2=P, 4=B - // 0=End of Program Index, other fields - // are invalid. - u32 pts; // The PTS of the frame - u32 mask2; // Bit 0 is bit 32 of the pts. - }; - u32 table_ptr; - struct info index[400]; - - The table_ptr is the encoder memory address in the table were - *new* entries will be written. Note that this is a ringbuffer, - so the table_ptr will wraparound. -Param[0] - Picture Mask: - 0=No index capture - 1=I frames - 3=I,P frames - 7=I,P,B frames - (Seems to be ignored, it always indexes I, P and B frames) -Param[1] - Elements requested (up to 400) -Result[0] - Offset in the encoder memory of the start of the table. -Result[1] - Number of allocated elements up to a maximum of Param[1] - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_VBI_CONFIG -Enum 200/0xC8 -Description - Configure VBI settings -Param[0] - Bitmap: - 0 Mode '0' Sliced, '1' Raw - 1:3 Insertion: - '000' insert in extension & user data - '001' insert in private packets - '010' separate stream and user data - '111' separate stream and private data - 8:15 Stream ID (normally 0xBD) -Param[1] - Frames per interrupt (max 8). Only valid in raw mode. -Param[2] - Total raw VBI frames. Only valid in raw mode. -Param[3] - Start codes -Param[4] - Stop codes -Param[5] - Lines per frame -Param[6] - Byte per line -Result[0] - Observed frames per interrupt in raw mode only. Rage 1 to Param[1] -Result[1] - Observed number of frames in raw mode. Range 1 to Param[2] -Result[2] - Memory offset to start or raw VBI data - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_DMA_BLOCK_SIZE -Enum 201/0xC9 -Description - Set DMA transfer block size -Param[0] - DMA transfer block size in bytes or frames. When unit is bytes, - supported block sizes are 2^7, 2^8 and 2^9 bytes. -Param[1] - Unit: 0=bytes, 1=frames - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_GET_PREV_DMA_INFO_MB_10 -Enum 202/0xCA -Description - Returns information on the previous DMA transfer in conjunction with - bit 27 of the interrupt mask. Uses mailbox 10. -Result[0] - Type of stream -Result[1] - Address Offset -Result[2] - Maximum size of transfer - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_GET_PREV_DMA_INFO_MB_9 -Enum 203/0xCB -Description - Returns information on the previous DMA transfer in conjunction with - bit 27 or 18 of the interrupt mask. Uses mailbox 9. -Result[0] - Status bits: - 0 read completed - 1 write completed - 2 DMA read error - 3 DMA write error - 4 Scatter-Gather array error -Result[1] - DMA type -Result[2] - Presentation Time Stamp bits 0..31 -Result[3] - Presentation Time Stamp bit 32 - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SCHED_DMA_TO_HOST -Enum 204/0xCC -Description - Setup DMA to host operation -Param[0] - Memory address of link list -Param[1] - Length of link list (wtf: what units ???) -Param[2] - DMA type (0=MPEG) - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_INITIALIZE_INPUT -Enum 205/0xCD -Description - Initializes the video input - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_FRAME_DROP_RATE -Enum 208/0xD0 -Description - For each frame captured, skip specified number of frames. -Param[0] - Number of frames to skip - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_PAUSE_ENCODER -Enum 210/0xD2 -Description - During a pause condition, all frames are dropped instead of being encoded. -Param[0] - 0=Pause encoding - 1=Continue encoding - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_REFRESH_INPUT -Enum 211/0xD3 -Description - Refreshes the video input - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_COPYRIGHT -Enum 212/0xD4 -Description - Sets stream copyright property -Param[0] - 0=Stream is not copyrighted - 1=Stream is copyrighted - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_EVENT_NOTIFICATION -Enum 213/0xD5 -Description - Setup firmware to notify the host about a particular event. Host must - unmask the interrupt bit. -Param[0] - Event (0=refresh encoder input) -Param[1] - Notification 0=disabled 1=enabled -Param[2] - Interrupt bit -Param[3] - Mailbox slot, -1 if no mailbox required. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_NUM_VSYNC_LINES -Enum 214/0xD6 -Description - Depending on the analog video decoder used, this assigns the number - of lines for field 1 and 2. -Param[0] - Field 1 number of lines: - 0x00EF for SAA7114 - 0x00F0 for SAA7115 - 0x0105 for Micronas -Param[1] - Field 2 number of lines: - 0x00EF for SAA7114 - 0x00F0 for SAA7115 - 0x0106 for Micronas - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_PLACEHOLDER -Enum 215/0xD7 -Description - Provides a mechanism of inserting custom user data in the MPEG stream. -Param[0] - 0=extension & user data - 1=private packet with stream ID 0xBD -Param[1] - Rate at which to insert data, in units of frames (for private packet) - or GOPs (for ext. & user data) -Param[2] - Number of data DWORDs (below) to insert -Param[3] - Custom data 0 -Param[4] - Custom data 1 -Param[5] - Custom data 2 -Param[6] - Custom data 3 -Param[7] - Custom data 4 -Param[8] - Custom data 5 -Param[9] - Custom data 6 -Param[10] - Custom data 7 -Param[11] - Custom data 8 - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_MUTE_VIDEO -Enum 217/0xD9 -Description - Video muting -Param[0] - Bit usage: - 0 '0'=video not muted - '1'=video muted, creates frames with the YUV color defined below - 1:7 Unused - 8:15 V chrominance information - 16:23 U chrominance information - 24:31 Y luminance information - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_MUTE_AUDIO -Enum 218/0xDA -Description - Audio muting -Param[0] - 0=audio not muted - 1=audio muted (produces silent mpeg audio stream) - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_SET_VERT_CROP_LINE -Enum 219/0xDB -Description - Something to do with 'Vertical Crop Line' -Param[0] - If saa7114 and raw VBI capture and 60 Hz, then set to 10001. - Else 0. - -------------------------------------------------------------------------------- - -Name CX2341X_ENC_MISC -Enum 220/0xDC -Description - Miscellaneous actions. Not known for 100% what it does. It's really a - sort of ioctl call. The first parameter is a command number, the second - the value. -Param[0] - Command number: - 1=set initial SCR value when starting encoding (works). - 2=set quality mode (apparently some test setting). - 3=setup advanced VIM protection handling. - Always 1 for the cx23416 and 0 for cx23415. - 4=generate DVD compatible PTS timestamps - 5=USB flush mode - 6=something to do with the quantization matrix - 7=set navigation pack insertion for DVD: adds 0xbf (private stream 2) - packets to the MPEG. The size of these packets is 2048 bytes (including - the header of 6 bytes: 0x000001bf + length). The payload is zeroed and - it is up to the application to fill them in. These packets are apparently - inserted every four frames. - 8=enable scene change detection (seems to be a failure) - 9=set history parameters of the video input module - 10=set input field order of VIM - 11=set quantization matrix - 12=reset audio interface after channel change or input switch (has no argument). - Needed for the cx2584x, not needed for the mspx4xx, but it doesn't seem to - do any harm calling it regardless. - 13=set audio volume delay - 14=set audio delay - -Param[1] - Command value. diff --git a/Documentation/video4linux/cx2341x/fw-memory.txt b/Documentation/video4linux/cx2341x/fw-memory.txt deleted file mode 100644 index 9d736fe8d..000000000 --- a/Documentation/video4linux/cx2341x/fw-memory.txt +++ /dev/null @@ -1,139 +0,0 @@ -This document describes the cx2341x memory map and documents some of the register -space. - -Note: the memory long words are little-endian ('intel format'). - -Warning! This information was figured out from searching through the memory and -registers, this information may not be correct and is certainly not complete, and -was not derived from anything more than searching through the memory space with -commands like: - - ivtvctl -O min=0x02000000,max=0x020000ff - -So take this as is, I'm always searching for more stuff, it's a large -register space :-). - -Memory Map -========== - -The cx2341x exposes its entire 64M memory space to the PCI host via the PCI BAR0 -(Base Address Register 0). The addresses here are offsets relative to the -address held in BAR0. - -0x00000000-0x00ffffff Encoder memory space -0x00000000-0x0003ffff Encode.rom - ???-??? MPEG buffer(s) - ???-??? Raw video capture buffer(s) - ???-??? Raw audio capture buffer(s) - ???-??? Display buffers (6 or 9) - -0x01000000-0x01ffffff Decoder memory space -0x01000000-0x0103ffff Decode.rom - ???-??? MPEG buffers(s) -0x0114b000-0x0115afff Audio.rom (deprecated?) - -0x02000000-0x0200ffff Register Space - -Registers -========= - -The registers occupy the 64k space starting at the 0x02000000 offset from BAR0. -All of these registers are 32 bits wide. - -DMA Registers 0x000-0xff: - - 0x00 - Control: - 0=reset/cancel, 1=read, 2=write, 4=stop - 0x04 - DMA status: - 1=read busy, 2=write busy, 4=read error, 8=write error, 16=link list error - 0x08 - pci DMA pointer for read link list - 0x0c - pci DMA pointer for write link list - 0x10 - read/write DMA enable: - 1=read enable, 2=write enable - 0x14 - always 0xffffffff, if set any lower instability occurs, 0x00 crashes - 0x18 - ?? - 0x1c - always 0x20 or 32, smaller values slow down DMA transactions - 0x20 - always value of 0x780a010a - 0x24-0x3c - usually just random values??? - 0x40 - Interrupt status - 0x44 - Write a bit here and shows up in Interrupt status 0x40 - 0x48 - Interrupt Mask - 0x4C - always value of 0xfffdffff, - if changed to 0xffffffff DMA write interrupts break. - 0x50 - always 0xffffffff - 0x54 - always 0xffffffff (0x4c, 0x50, 0x54 seem like interrupt masks, are - 3 processors on chip, Java ones, VPU, SPU, APU, maybe these are the - interrupt masks???). - 0x60-0x7C - random values - 0x80 - first write linked list reg, for Encoder Memory addr - 0x84 - first write linked list reg, for pci memory addr - 0x88 - first write linked list reg, for length of buffer in memory addr - (|0x80000000 or this for last link) - 0x8c-0xdc - rest of write linked list reg, 8 sets of 3 total, DMA goes here - from linked list addr in reg 0x0c, firmware must push through or - something. - 0xe0 - first (and only) read linked list reg, for pci memory addr - 0xe4 - first (and only) read linked list reg, for Decoder memory addr - 0xe8 - first (and only) read linked list reg, for length of buffer - 0xec-0xff - Nothing seems to be in these registers, 0xec-f4 are 0x00000000. - -Memory locations for Encoder Buffers 0x700-0x7ff: - -These registers show offsets of memory locations pertaining to each -buffer area used for encoding, have to shift them by <<1 first. - -0x07F8: Encoder SDRAM refresh -0x07FC: Encoder SDRAM pre-charge - -Memory locations for Decoder Buffers 0x800-0x8ff: - -These registers show offsets of memory locations pertaining to each -buffer area used for decoding, have to shift them by <<1 first. - -0x08F8: Decoder SDRAM refresh -0x08FC: Decoder SDRAM pre-charge - -Other memory locations: - -0x2800: Video Display Module control -0x2D00: AO (audio output?) control -0x2D24: Bytes Flushed -0x7000: LSB I2C write clock bit (inverted) -0x7004: LSB I2C write data bit (inverted) -0x7008: LSB I2C read clock bit -0x700c: LSB I2C read data bit -0x9008: GPIO get input state -0x900c: GPIO set output state -0x9020: GPIO direction (Bit7 (GPIO 0..7) - 0:input, 1:output) -0x9050: SPU control -0x9054: Reset HW blocks -0x9058: VPU control -0xA018: Bit6: interrupt pending? -0xA064: APU command - - -Interrupt Status Register -========================= - -The definition of the bits in the interrupt status register 0x0040, and the -interrupt mask 0x0048. If a bit is cleared in the mask, then we want our ISR to -execute. - -Bit -31 Encoder Start Capture -30 Encoder EOS -29 Encoder VBI capture -28 Encoder Video Input Module reset event -27 Encoder DMA complete -24 Decoder audio mode change detection event (through event notification) -22 Decoder data request -20 Decoder DMA complete -19 Decoder VBI re-insertion -18 Decoder DMA err (linked-list bad) - -Missing -Encoder API call completed -Decoder API call completed -Encoder API post(?) -Decoder API post(?) -Decoder VTRACE event diff --git a/Documentation/video4linux/cx2341x/fw-osd-api.txt b/Documentation/video4linux/cx2341x/fw-osd-api.txt deleted file mode 100644 index 89c460104..000000000 --- a/Documentation/video4linux/cx2341x/fw-osd-api.txt +++ /dev/null @@ -1,350 +0,0 @@ -OSD firmware API description -============================ - -Note: this API is part of the decoder firmware, so it's cx23415 only. - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_FRAMEBUFFER -Enum 65/0x41 -Description - Return base and length of contiguous OSD memory. -Result[0] - OSD base address -Result[1] - OSD length - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_PIXEL_FORMAT -Enum 66/0x42 -Description - Query OSD format -Result[0] - 0=8bit index - 1=16bit RGB 5:6:5 - 2=16bit ARGB 1:5:5:5 - 3=16bit ARGB 1:4:4:4 - 4=32bit ARGB 8:8:8:8 - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_PIXEL_FORMAT -Enum 67/0x43 -Description - Assign pixel format -Param[0] - 0=8bit index - 1=16bit RGB 5:6:5 - 2=16bit ARGB 1:5:5:5 - 3=16bit ARGB 1:4:4:4 - 4=32bit ARGB 8:8:8:8 - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_STATE -Enum 68/0x44 -Description - Query OSD state -Result[0] - Bit 0 0=off, 1=on - Bits 1:2 alpha control - Bits 3:5 pixel format - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_STATE -Enum 69/0x45 -Description - OSD switch -Param[0] - 0=off, 1=on - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_OSD_COORDS -Enum 70/0x46 -Description - Retrieve coordinates of OSD area blended with video -Result[0] - OSD buffer address -Result[1] - Stride in pixels -Result[2] - Lines in OSD buffer -Result[3] - Horizontal offset in buffer -Result[4] - Vertical offset in buffer - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_OSD_COORDS -Enum 71/0x47 -Description - Assign the coordinates of the OSD area to blend with video -Param[0] - buffer address -Param[1] - buffer stride in pixels -Param[2] - lines in buffer -Param[3] - horizontal offset -Param[4] - vertical offset - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_SCREEN_COORDS -Enum 72/0x48 -Description - Retrieve OSD screen area coordinates -Result[0] - top left horizontal offset -Result[1] - top left vertical offset -Result[2] - bottom right horizontal offset -Result[3] - bottom right vertical offset - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_SCREEN_COORDS -Enum 73/0x49 -Description - Assign the coordinates of the screen area to blend with video -Param[0] - top left horizontal offset -Param[1] - top left vertical offset -Param[2] - bottom left horizontal offset -Param[3] - bottom left vertical offset - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_GLOBAL_ALPHA -Enum 74/0x4A -Description - Retrieve OSD global alpha -Result[0] - global alpha: 0=off, 1=on -Result[1] - bits 0:7 global alpha - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_GLOBAL_ALPHA -Enum 75/0x4B -Description - Update global alpha -Param[0] - global alpha: 0=off, 1=on -Param[1] - global alpha (8 bits) -Param[2] - local alpha: 0=on, 1=off - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_BLEND_COORDS -Enum 78/0x4C -Description - Move start of blending area within display buffer -Param[0] - horizontal offset in buffer -Param[1] - vertical offset in buffer - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_FLICKER_STATE -Enum 79/0x4F -Description - Retrieve flicker reduction module state -Result[0] - flicker state: 0=off, 1=on - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_FLICKER_STATE -Enum 80/0x50 -Description - Set flicker reduction module state -Param[0] - State: 0=off, 1=on - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_BLT_COPY -Enum 82/0x52 -Description - BLT copy -Param[0] -'0000' zero -'0001' ~destination AND ~source -'0010' ~destination AND source -'0011' ~destination -'0100' destination AND ~source -'0101' ~source -'0110' destination XOR source -'0111' ~destination OR ~source -'1000' ~destination AND ~source -'1001' destination XNOR source -'1010' source -'1011' ~destination OR source -'1100' destination -'1101' destination OR ~source -'1110' destination OR source -'1111' one - -Param[1] - Resulting alpha blending - '01' source_alpha - '10' destination_alpha - '11' source_alpha*destination_alpha+1 - (zero if both source and destination alpha are zero) -Param[2] - '00' output_pixel = source_pixel - - '01' if source_alpha=0: - output_pixel = destination_pixel - if 256 > source_alpha > 1: - output_pixel = ((source_alpha + 1)*source_pixel + - (255 - source_alpha)*destination_pixel)/256 - - '10' if destination_alpha=0: - output_pixel = source_pixel - if 255 > destination_alpha > 0: - output_pixel = ((255 - destination_alpha)*source_pixel + - (destination_alpha + 1)*destination_pixel)/256 - - '11' if source_alpha=0: - source_temp = 0 - if source_alpha=255: - source_temp = source_pixel*256 - if 255 > source_alpha > 0: - source_temp = source_pixel*(source_alpha + 1) - if destination_alpha=0: - destination_temp = 0 - if destination_alpha=255: - destination_temp = destination_pixel*256 - if 255 > destination_alpha > 0: - destination_temp = destination_pixel*(destination_alpha + 1) - output_pixel = (source_temp + destination_temp)/256 -Param[3] - width -Param[4] - height -Param[5] - destination pixel mask -Param[6] - destination rectangle start address -Param[7] - destination stride in dwords -Param[8] - source stride in dwords -Param[9] - source rectangle start address - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_BLT_FILL -Enum 83/0x53 -Description - BLT fill color -Param[0] - Same as Param[0] on API 0x52 -Param[1] - Same as Param[1] on API 0x52 -Param[2] - Same as Param[2] on API 0x52 -Param[3] - width -Param[4] - height -Param[5] - destination pixel mask -Param[6] - destination rectangle start address -Param[7] - destination stride in dwords -Param[8] - color fill value - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_BLT_TEXT -Enum 84/0x54 -Description - BLT for 8 bit alpha text source -Param[0] - Same as Param[0] on API 0x52 -Param[1] - Same as Param[1] on API 0x52 -Param[2] - Same as Param[2] on API 0x52 -Param[3] - width -Param[4] - height -Param[5] - destination pixel mask -Param[6] - destination rectangle start address -Param[7] - destination stride in dwords -Param[8] - source stride in dwords -Param[9] - source rectangle start address -Param[10] - color fill value - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_FRAMEBUFFER_WINDOW -Enum 86/0x56 -Description - Positions the main output window on the screen. The coordinates must be - such that the entire window fits on the screen. -Param[0] - window width -Param[1] - window height -Param[2] - top left window corner horizontal offset -Param[3] - top left window corner vertical offset - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_CHROMA_KEY -Enum 96/0x60 -Description - Chroma key switch and color -Param[0] - state: 0=off, 1=on -Param[1] - color - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_GET_ALPHA_CONTENT_INDEX -Enum 97/0x61 -Description - Retrieve alpha content index -Result[0] - alpha content index, Range 0:15 - -------------------------------------------------------------------------------- - -Name CX2341X_OSD_SET_ALPHA_CONTENT_INDEX -Enum 98/0x62 -Description - Assign alpha content index -Param[0] - alpha content index, range 0:15 diff --git a/Documentation/video4linux/cx2341x/fw-upload.txt b/Documentation/video4linux/cx2341x/fw-upload.txt deleted file mode 100644 index 60c502ce3..000000000 --- a/Documentation/video4linux/cx2341x/fw-upload.txt +++ /dev/null @@ -1,49 +0,0 @@ -This document describes how to upload the cx2341x firmware to the card. - -How to find -=========== - -See the web pages of the various projects that uses this chip for information -on how to obtain the firmware. - -The firmware stored in a Windows driver can be detected as follows: - -- Each firmware image is 256k bytes. -- The 1st 32-bit word of the Encoder image is 0x0000da7 -- The 1st 32-bit word of the Decoder image is 0x00003a7 -- The 2nd 32-bit word of both images is 0xaa55bb66 - -How to load -=========== - -- Issue the FWapi command to stop the encoder if it is running. Wait for the - command to complete. -- Issue the FWapi command to stop the decoder if it is running. Wait for the - command to complete. -- Issue the I2C command to the digitizer to stop emitting VSYNC events. -- Issue the FWapi command to halt the encoder's firmware. -- Sleep for 10ms. -- Issue the FWapi command to halt the decoder's firmware. -- Sleep for 10ms. -- Write 0x00000000 to register 0x2800 to stop the Video Display Module. -- Write 0x00000005 to register 0x2D00 to stop the AO (audio output?). -- Write 0x00000000 to register 0xA064 to ping? the APU. -- Write 0xFFFFFFFE to register 0x9058 to stop the VPU. -- Write 0xFFFFFFFF to register 0x9054 to reset the HW blocks. -- Write 0x00000001 to register 0x9050 to stop the SPU. -- Sleep for 10ms. -- Write 0x0000001A to register 0x07FC to init the Encoder SDRAM's pre-charge. -- Write 0x80000640 to register 0x07F8 to init the Encoder SDRAM's refresh to 1us. -- Write 0x0000001A to register 0x08FC to init the Decoder SDRAM's pre-charge. -- Write 0x80000640 to register 0x08F8 to init the Decoder SDRAM's refresh to 1us. -- Sleep for 512ms. (600ms is recommended) -- Transfer the encoder's firmware image to offset 0 in Encoder memory space. -- Transfer the decoder's firmware image to offset 0 in Decoder memory space. -- Use a read-modify-write operation to Clear bit 0 of register 0x9050 to - re-enable the SPU. -- Sleep for 1 second. -- Use a read-modify-write operation to Clear bits 3 and 0 of register 0x9058 - to re-enable the VPU. -- Sleep for 1 second. -- Issue status API commands to both firmware images to verify. - diff --git a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt deleted file mode 100644 index f4329a388..000000000 --- a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt +++ /dev/null @@ -1,54 +0,0 @@ -The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting. - -GPIO0 GPIO1 - 0 0 TV Audio - 1 0 FM radio - 0 1 Line-In - 1 1 Mono tuner bypass or CD passthru (tuner specific) - -GPIO 16(i believe) is tied to the IR port (if present). - ------------------------------------------------------------------------------------- - ->From the data sheet: - Register 24'h20004 PCI Interrupt Status - bit [18] IR_SMP_INT Set when 32 input samples have been collected over - gpio[16] pin into GP_SAMPLE register. - -What's missing from the data sheet: - -Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5 -compat remote) -set register 0x35C050 to 0xa80a80 - -enable sampling -set register 0x35C054 to 0x5 - -Of course, enable the IRQ bit 18 in the interrupt mask register .(and -provide for a handler) - -GP_SAMPLE register is at 0x35C058 - -Bits are then right shifted into the GP_SAMPLE register at the specified -rate; you get an interrupt when a full DWORD is received. -You need to recover the actual RC5 bits out of the (oversampled) IR sensor -bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An -actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment. - -I'm pretty sure when no IR signal is present the receiver is always in a -marking state(1); but stray light, etc can cause intermittent noise values -as well. Remember, this is a free running sample of the IR receiver state -over time, so don't assume any sample starts at any particular place. - -http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf -This data sheet (google search) seems to have a lovely description of the -RC5 basics - -http://www.nenya.be/beor/electronics/rc5.htm and more data - -http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt -and even a reference to how to decode a bi-phase data stream. - -http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm -still more info - diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt deleted file mode 100644 index 4fab231be..000000000 --- a/Documentation/video4linux/fimc.txt +++ /dev/null @@ -1,148 +0,0 @@ -Samsung S5P/EXYNOS4 FIMC driver - -Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. ---------------------------------------------------------------------------- - -The FIMC (Fully Interactive Mobile Camera) device available in Samsung -SoC Application Processors is an integrated camera host interface, color -space converter, image resizer and rotator. It's also capable of capturing -data from LCD controller (FIMD) through the SoC internal writeback data -path. There are multiple FIMC instances in the SoCs (up to 4), having -slightly different capabilities, like pixel alignment constraints, rotator -availability, LCD writeback support, etc. The driver is located at -drivers/media/platform/exynos4-is directory. - -1. Supported SoCs -================= - -S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210 - -2. Supported features -===================== - - - camera parallel interface capture (ITU-R.BT601/565); - - camera serial interface capture (MIPI-CSI2); - - memory-to-memory processing (color space conversion, scaling, mirror - and rotation); - - dynamic pipeline re-configuration at runtime (re-attachment of any FIMC - instance to any parallel video input or any MIPI-CSI front-end); - - runtime PM and system wide suspend/resume - -Not currently supported: - - LCD writeback input - - per frame clock gating (mem-to-mem) - -3. Files partitioning -===================== - -- media device driver - drivers/media/platform/exynos4-is/media-dev.[ch] - - - camera capture video device driver - drivers/media/platform/exynos4-is/fimc-capture.c - - - MIPI-CSI2 receiver subdev - drivers/media/platform/exynos4-is/mipi-csis.[ch] - - - video post-processor (mem-to-mem) - drivers/media/platform/exynos4-is/fimc-core.c - - - common files - drivers/media/platform/exynos4-is/fimc-core.h - drivers/media/platform/exynos4-is/fimc-reg.h - drivers/media/platform/exynos4-is/regs-fimc.h - -4. User space interfaces -======================== - -4.1. Media device interface - -The driver supports Media Controller API as defined at -https://linuxtv.org/downloads/v4l-dvb-apis/media_common.html -The media device driver name is "SAMSUNG S5P FIMC". - -The purpose of this interface is to allow changing assignment of FIMC instances -to the SoC peripheral camera input at runtime and optionally to control internal -connections of the MIPI-CSIS device(s) to the FIMC entities. - -The media device interface allows to configure the SoC for capturing image -data from the sensor through more than one FIMC instance (e.g. for simultaneous -viewfinder and still capture setup). -Reconfiguration is done by enabling/disabling media links created by the driver -during initialization. The internal device topology can be easily discovered -through media entity and links enumeration. - -4.2. Memory-to-memory video node - -V4L2 memory-to-memory interface at /dev/video? device node. This is standalone -video device, it has no media pads. However please note the mem-to-mem and -capture video node operation on same FIMC instance is not allowed. The driver -detects such cases but the applications should prevent them to avoid an -undefined behaviour. - -4.3. Capture video node - -The driver supports V4L2 Video Capture Interface as defined at: -https://linuxtv.org/downloads/v4l-dvb-apis/devices.html - -At the capture and mem-to-mem video nodes only the multi-planar API is -supported. For more details see: -https://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html - -4.4. Camera capture subdevs - -Each FIMC instance exports a sub-device node (/dev/v4l-subdev?), a sub-device -node is also created per each available and enabled at the platform level -MIPI-CSI receiver device (currently up to two). - -4.5. sysfs - -In order to enable more precise camera pipeline control through the sub-device -API the driver creates a sysfs entry associated with "s5p-fimc-md" platform -device. The entry path is: /sys/platform/devices/s5p-fimc-md/subdev_conf_mode. - -In typical use case there could be a following capture pipeline configuration: -sensor subdev -> mipi-csi subdev -> fimc subdev -> video node - -When we configure these devices through sub-device API at user space, the -configuration flow must be from left to right, and the video node is -configured as last one. -When we don't use sub-device user space API the whole configuration of all -devices belonging to the pipeline is done at the video node driver. -The sysfs entry allows to instruct the capture node driver not to configure -the sub-devices (format, crop), to avoid resetting the subdevs' configuration -when the last configuration steps at the video node is performed. - -For full sub-device control support (subdevs configured at user space before -starting streaming): -# echo "sub-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode - -For V4L2 video node control only (subdevs configured internally by the host -driver): -# echo "vid-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode -This is a default option. - -5. Device mapping to video and subdev device nodes -================================================== - -There are associated two video device nodes with each device instance in -hardware - video capture and mem-to-mem and additionally a subdev node for -more precise FIMC capture subsystem control. In addition a separate v4l2 -sub-device node is created per each MIPI-CSIS device. - -How to find out which /dev/video? or /dev/v4l-subdev? is assigned to which -device? - -You can either grep through the kernel log to find relevant information, i.e. -# dmesg | grep -i fimc -(note that udev, if present, might still have rearranged the video nodes), - -or retrieve the information from /dev/media? with help of the media-ctl tool: -# media-ctl -p - -7. Build -======== - -If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m) -two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and -optional s5p-csis.ko (MIPI-CSI receiver subdev). diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt deleted file mode 100644 index d2ba80bb7..000000000 --- a/Documentation/video4linux/gspca.txt +++ /dev/null @@ -1,408 +0,0 @@ -List of the webcams known by gspca. - -The modules are: - gspca_main main driver - gspca_xxxx subdriver module with xxxx as follows - -xxxx vend:prod ----- -spca501 0000:0000 MystFromOri Unknown Camera -spca508 0130:0130 Clone Digital Webcam 11043 -zc3xx 03f0:1b07 HP Premium Starter Cam -m5602 0402:5602 ALi Video Camera Controller -spca501 040a:0002 Kodak DVC-325 -spca500 040a:0300 Kodak EZ200 -zc3xx 041e:041e Creative WebCam Live! -ov519 041e:4003 Video Blaster WebCam Go Plus -spca500 041e:400a Creative PC-CAM 300 -sunplus 041e:400b Creative PC-CAM 600 -sunplus 041e:4012 PC-Cam350 -sunplus 041e:4013 Creative Pccam750 -zc3xx 041e:4017 Creative Webcam Mobile PD1090 -spca508 041e:4018 Creative Webcam Vista (PD1100) -spca561 041e:401a Creative Webcam Vista (PD1100) -zc3xx 041e:401c Creative NX -spca505 041e:401d Creative Webcam NX ULTRA -zc3xx 041e:401e Creative Nx Pro -zc3xx 041e:401f Creative Webcam Notebook PD1171 -pac207 041e:4028 Creative Webcam Vista Plus -zc3xx 041e:4029 Creative WebCam Vista Pro -zc3xx 041e:4034 Creative Instant P0620 -zc3xx 041e:4035 Creative Instant P0620D -zc3xx 041e:4036 Creative Live ! -sq930x 041e:4038 Creative Joy-IT -zc3xx 041e:403a Creative Nx Pro 2 -spca561 041e:403b Creative Webcam Vista (VF0010) -sq930x 041e:403c Creative Live! Ultra -sq930x 041e:403d Creative Live! Ultra for Notebooks -sq930x 041e:4041 Creative Live! Motion -zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) -ov519 041e:4052 Creative Live! VISTA IM -zc3xx 041e:4053 Creative Live!Cam Video IM -vc032x 041e:405b Creative Live! Cam Notebook Ultra (VC0130) -ov519 041e:405f Creative Live! VISTA VF0330 -ov519 041e:4060 Creative Live! VISTA VF0350 -ov519 041e:4061 Creative Live! VISTA VF0400 -ov519 041e:4064 Creative Live! VISTA VF0420 -ov519 041e:4067 Creative Live! Cam Video IM (VF0350) -ov519 041e:4068 Creative Live! VISTA VF0470 -spca561 0458:7004 Genius VideoCAM Express V2 -sn9c2028 0458:7005 Genius Smart 300, version 2 -sunplus 0458:7006 Genius Dsc 1.3 Smart -zc3xx 0458:7007 Genius VideoCam V2 -zc3xx 0458:700c Genius VideoCam V3 -zc3xx 0458:700f Genius VideoCam Web V2 -sonixj 0458:7025 Genius Eye 311Q -sn9c20x 0458:7029 Genius Look 320s -sonixj 0458:702e Genius Slim 310 NB -sn9c20x 0458:7045 Genius Look 1320 V2 -sn9c20x 0458:704a Genius Slim 1320 -sn9c20x 0458:704c Genius i-Look 1321 -sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650) -sonixj 045e:00f5 MicroSoft VX3000 -sonixj 045e:00f7 MicroSoft VX1000 -ov519 045e:028c Micro$oft xbox cam -spca508 0461:0815 Micro Innovation IC200 -sunplus 0461:0821 Fujifilm MV-1 -zc3xx 0461:0a00 MicroInnovation WebCam320 -stv06xx 046d:0840 QuickCam Express -stv06xx 046d:0850 LEGO cam / QuickCam Web -stv06xx 046d:0870 Dexxa WebCam USB -spca500 046d:0890 Logitech QuickCam traveler -vc032x 046d:0892 Logitech Orbicam -vc032x 046d:0896 Logitech Orbicam -vc032x 046d:0897 Logitech QuickCam for Dell notebooks -zc3xx 046d:089d Logitech QuickCam E2500 -zc3xx 046d:08a0 Logitech QC IM -zc3xx 046d:08a1 Logitech QC IM 0x08A1 +sound -zc3xx 046d:08a2 Labtec Webcam Pro -zc3xx 046d:08a3 Logitech QC Chat -zc3xx 046d:08a6 Logitech QCim -zc3xx 046d:08a7 Logitech QuickCam Image -zc3xx 046d:08a9 Logitech Notebook Deluxe -zc3xx 046d:08aa Labtec Webcam Notebook -zc3xx 046d:08ac Logitech QuickCam Cool -zc3xx 046d:08ad Logitech QCCommunicate STX -zc3xx 046d:08ae Logitech QuickCam for Notebooks -zc3xx 046d:08af Logitech QuickCam Cool -zc3xx 046d:08b9 Logitech QuickCam Express -zc3xx 046d:08d7 Logitech QCam STX -zc3xx 046d:08d9 Logitech QuickCam IM/Connect -zc3xx 046d:08d8 Logitech Notebook Deluxe -zc3xx 046d:08da Logitech QuickCam Messenger -zc3xx 046d:08dd Logitech QuickCam for Notebooks -spca500 046d:0900 Logitech Inc. ClickSmart 310 -spca500 046d:0901 Logitech Inc. ClickSmart 510 -sunplus 046d:0905 Logitech ClickSmart 820 -tv8532 046d:0920 Logitech QuickCam Express -tv8532 046d:0921 Labtec Webcam -spca561 046d:0928 Logitech QC Express Etch2 -spca561 046d:0929 Labtec Webcam Elch2 -spca561 046d:092a Logitech QC for Notebook -spca561 046d:092b Labtec Webcam Plus -spca561 046d:092c Logitech QC chat Elch2 -spca561 046d:092d Logitech QC Elch2 -spca561 046d:092e Logitech QC Elch2 -spca561 046d:092f Logitech QuickCam Express Plus -sunplus 046d:0960 Logitech ClickSmart 420 -nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring) -sunplus 0471:0322 Philips DMVC1300K -zc3xx 0471:0325 Philips SPC 200 NC -zc3xx 0471:0326 Philips SPC 300 NC -sonixj 0471:0327 Philips SPC 600 NC -sonixj 0471:0328 Philips SPC 700 NC -zc3xx 0471:032d Philips SPC 210 NC -zc3xx 0471:032e Philips SPC 315 NC -sonixj 0471:0330 Philips SPC 710 NC -spca501 0497:c001 Smile International -sunplus 04a5:3003 Benq DC 1300 -sunplus 04a5:3008 Benq DC 1500 -sunplus 04a5:300a Benq DC 3410 -spca500 04a5:300c Benq DC 1016 -benq 04a5:3035 Benq DC E300 -finepix 04cb:0104 Fujifilm FinePix 4800 -finepix 04cb:0109 Fujifilm FinePix A202 -finepix 04cb:010b Fujifilm FinePix A203 -finepix 04cb:010f Fujifilm FinePix A204 -finepix 04cb:0111 Fujifilm FinePix A205 -finepix 04cb:0113 Fujifilm FinePix A210 -finepix 04cb:0115 Fujifilm FinePix A303 -finepix 04cb:0117 Fujifilm FinePix A310 -finepix 04cb:0119 Fujifilm FinePix F401 -finepix 04cb:011b Fujifilm FinePix F402 -finepix 04cb:011d Fujifilm FinePix F410 -finepix 04cb:0121 Fujifilm FinePix F601 -finepix 04cb:0123 Fujifilm FinePix F700 -finepix 04cb:0125 Fujifilm FinePix M603 -finepix 04cb:0127 Fujifilm FinePix S300 -finepix 04cb:0129 Fujifilm FinePix S304 -finepix 04cb:012b Fujifilm FinePix S500 -finepix 04cb:012d Fujifilm FinePix S602 -finepix 04cb:012f Fujifilm FinePix S700 -finepix 04cb:0131 Fujifilm FinePix unknown model -finepix 04cb:013b Fujifilm FinePix unknown model -finepix 04cb:013d Fujifilm FinePix unknown model -finepix 04cb:013f Fujifilm FinePix F420 -sunplus 04f1:1001 JVC GC A50 -spca561 04fc:0561 Flexcam 100 -spca1528 04fc:1528 Sunplus MD80 clone -sunplus 04fc:500c Sunplus CA500C -sunplus 04fc:504a Aiptek Mini PenCam 1.3 -sunplus 04fc:504b Maxell MaxPocket LE 1.3 -sunplus 04fc:5330 Digitrex 2110 -sunplus 04fc:5360 Sunplus Generic -spca500 04fc:7333 PalmPixDC85 -sunplus 04fc:ffff Pure DigitalDakota -nw80x 0502:d001 DVC V6 -spca501 0506:00df 3Com HomeConnect Lite -sunplus 052b:1507 Megapixel 5 Pretec DC-1007 -sunplus 052b:1513 Megapix V4 -sunplus 052b:1803 MegaImage VI -nw80x 052b:d001 EZCam Pro p35u -tv8532 0545:808b Veo Stingray -tv8532 0545:8333 Veo Stingray -sunplus 0546:3155 Polaroid PDC3070 -sunplus 0546:3191 Polaroid Ion 80 -sunplus 0546:3273 Polaroid PDC2030 -ov519 054c:0154 Sonny toy4 -ov519 054c:0155 Sonny toy5 -cpia1 0553:0002 CPIA CPiA (version1) based cameras -zc3xx 055f:c005 Mustek Wcam300A -spca500 055f:c200 Mustek Gsmart 300 -sunplus 055f:c211 Kowa Bs888e Microcamera -spca500 055f:c220 Gsmart Mini -sunplus 055f:c230 Mustek Digicam 330K -sunplus 055f:c232 Mustek MDC3500 -sunplus 055f:c360 Mustek DV4000 Mpeg4 -sunplus 055f:c420 Mustek gSmart Mini 2 -sunplus 055f:c430 Mustek Gsmart LCD 2 -sunplus 055f:c440 Mustek DV 3000 -sunplus 055f:c520 Mustek gSmart Mini 3 -sunplus 055f:c530 Mustek Gsmart LCD 3 -sunplus 055f:c540 Gsmart D30 -sunplus 055f:c630 Mustek MDC4000 -sunplus 055f:c650 Mustek MDC5500Z -nw80x 055f:d001 Mustek Wcam 300 mini -zc3xx 055f:d003 Mustek WCam300A -zc3xx 055f:d004 Mustek WCam300 AN -conex 0572:0041 Creative Notebook cx11646 -ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera -ov519 05a9:0518 Creative WebCam -ov519 05a9:0519 OV519 Microphone -ov519 05a9:0530 OmniVision -ov534_9 05a9:1550 OmniVision VEHO Filmscanner -ov519 05a9:2800 OmniVision SuperCAM -ov519 05a9:4519 Webcam Classic -ov534_9 05a9:8065 OmniVision test kit ov538+ov9712 -ov519 05a9:8519 OmniVision -ov519 05a9:a511 D-Link USB Digital Video Camera -ov519 05a9:a518 D-Link DSB-C310 Webcam -sunplus 05da:1018 Digital Dream Enigma 1.3 -stk014 05e1:0893 Syntek DV4000 -gl860 05e3:0503 Genesys Logic PC Camera -gl860 05e3:f191 Genesys Logic PC Camera -spca561 060b:a001 Maxell Compact Pc PM3 -zc3xx 0698:2003 CTX M730V built in -topro 06a2:0003 TP6800 PC Camera, CmoX CX0342 webcam -topro 06a2:6810 Creative Qmax -nw80x 06a5:0000 Typhoon Webcam 100 USB -nw80x 06a5:d001 Divio based webcams -nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam -spca500 06bd:0404 Agfa CL20 -spca500 06be:0800 Optimedia -nw80x 06be:d001 EZCam Pro p35u -sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom -spca506 06e1:a190 ADS Instant VCD -ov534 06f8:3002 Hercules Blog Webcam -ov534_9 06f8:3003 Hercules Dualpix HD Weblog -sonixj 06f8:3004 Hercules Classic Silver -sonixj 06f8:3008 Hercules Deluxe Optical Glass -pac7302 06f8:3009 Hercules Classic Link -pac7302 06f8:301b Hercules Link -nw80x 0728:d001 AVerMedia Camguard -spca508 0733:0110 ViewQuest VQ110 -spca501 0733:0401 Intel Create and Share -spca501 0733:0402 ViewQuest M318B -spca505 0733:0430 Intel PC Camera Pro -sunplus 0733:1311 Digital Dream Epsilon 1.3 -sunplus 0733:1314 Mercury 2.1MEG Deluxe Classic Cam -sunplus 0733:2211 Jenoptik jdc 21 LCD -sunplus 0733:2221 Mercury Digital Pro 3.1p -sunplus 0733:3261 Concord 3045 spca536a -sunplus 0733:3281 Cyberpix S550V -spca506 0734:043b 3DeMon USB Capture aka -cpia1 0813:0001 QX3 camera -ov519 0813:0002 Dual Mode USB Camera Plus -spca500 084d:0003 D-Link DSC-350 -spca500 08ca:0103 Aiptek PocketDV -sunplus 08ca:0104 Aiptek PocketDVII 1.3 -sunplus 08ca:0106 Aiptek Pocket DV3100+ -mr97310a 08ca:0110 Trust Spyc@m 100 -mr97310a 08ca:0111 Aiptek PenCam VGA+ -sunplus 08ca:2008 Aiptek Mini PenCam 2 M -sunplus 08ca:2010 Aiptek PocketCam 3M -sunplus 08ca:2016 Aiptek PocketCam 2 Mega -sunplus 08ca:2018 Aiptek Pencam SD 2M -sunplus 08ca:2020 Aiptek Slim 3000F -sunplus 08ca:2022 Aiptek Slim 3200 -sunplus 08ca:2024 Aiptek DV3500 Mpeg4 -sunplus 08ca:2028 Aiptek PocketCam4M -sunplus 08ca:2040 Aiptek PocketDV4100M -sunplus 08ca:2042 Aiptek PocketDV5100 -sunplus 08ca:2050 Medion MD 41437 -sunplus 08ca:2060 Aiptek PocketDV5300 -tv8532 0923:010f ICM532 cams -mars 093a:050f Mars-Semi Pc-Camera -mr97310a 093a:010e All known CIF cams with this ID -mr97310a 093a:010f All known VGA cams with this ID -pac207 093a:2460 Qtec Webcam 100 -pac207 093a:2461 HP Webcam -pac207 093a:2463 Philips SPC 220 NC -pac207 093a:2464 Labtec Webcam 1200 -pac207 093a:2468 Webcam WB-1400T -pac207 093a:2470 Genius GF112 -pac207 093a:2471 Genius VideoCam ge111 -pac207 093a:2472 Genius VideoCam ge110 -pac207 093a:2474 Genius iLook 111 -pac207 093a:2476 Genius e-Messenger 112 -pac7311 093a:2600 PAC7311 Typhoon -pac7311 093a:2601 Philips SPC 610 NC -pac7311 093a:2603 Philips SPC 500 NC -pac7311 093a:2608 Trust WB-3300p -pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 -pac7311 093a:260f SnakeCam -pac7302 093a:2620 Apollo AC-905 -pac7302 093a:2621 PAC731x -pac7302 093a:2622 Genius Eye 312 -pac7302 093a:2624 PAC7302 -pac7302 093a:2625 Genius iSlim 310 -pac7302 093a:2626 Labtec 2200 -pac7302 093a:2627 Genius FaceCam 300 -pac7302 093a:2628 Genius iLook 300 -pac7302 093a:2629 Genious iSlim 300 -pac7302 093a:262a Webcam 300k -pac7302 093a:262c Philips SPC 230 NC -jl2005bcd 0979:0227 Various brands, 19 known cameras supported -jeilinj 0979:0280 Sakar 57379 -jeilinj 0979:0280 Sportscam DV15 -zc3xx 0ac8:0302 Z-star Vimicro zc0302 -vc032x 0ac8:0321 Vimicro generic vc0321 -vc032x 0ac8:0323 Vimicro Vc0323 -vc032x 0ac8:0328 A4Tech PK-130MG -zc3xx 0ac8:301b Z-Star zc301b -zc3xx 0ac8:303b Vimicro 0x303b -zc3xx 0ac8:305b Z-star Vimicro zc0305b -zc3xx 0ac8:307b PC Camera (ZS0211) -vc032x 0ac8:c001 Sony embedded vimicro -vc032x 0ac8:c002 Sony embedded vimicro -vc032x 0ac8:c301 Samsung Q1 Ultra Premium -spca508 0af9:0010 Hama USB Sightcam 100 -spca508 0af9:0011 Hama USB Sightcam 100 -ov519 0b62:0059 iBOT2 Webcam -sonixb 0c45:6001 Genius VideoCAM NB -sonixb 0c45:6005 Microdia Sweex Mini Webcam -sonixb 0c45:6007 Sonix sn9c101 + Tas5110D -sonixb 0c45:6009 spcaCam@120 -sonixb 0c45:600d spcaCam@120 -sonixb 0c45:6011 Microdia PC Camera (SN9C102) -sonixb 0c45:6019 Generic Sonix OV7630 -sonixb 0c45:6024 Generic Sonix Tas5130c -sonixb 0c45:6025 Xcam Shanga -sonixb 0c45:6028 Sonix Btc Pc380 -sonixb 0c45:6029 spcaCam@150 -sonixb 0c45:602c Generic Sonix OV7630 -sonixb 0c45:602d LIC-200 LG -sonixb 0c45:602e Genius VideoCam Messenger -sonixj 0c45:6040 Speed NVC 350K -sonixj 0c45:607c Sonix sn9c102p Hv7131R -sonixj 0c45:60c0 Sangha Sn535 -sonixj 0c45:60ce USB-PC-Camera-168 (TALK-5067) -sonixj 0c45:60ec SN9C105+MO4000 -sonixj 0c45:60fb Surfer NoName -sonixj 0c45:60fc LG-LIC300 -sonixj 0c45:60fe Microdia Audio -sonixj 0c45:6100 PC Camera (SN9C128) -sonixj 0c45:6102 PC Camera (SN9C128) -sonixj 0c45:610a PC Camera (SN9C128) -sonixj 0c45:610b PC Camera (SN9C128) -sonixj 0c45:610c PC Camera (SN9C128) -sonixj 0c45:610e PC Camera (SN9C128) -sonixj 0c45:6128 Microdia/Sonix SNP325 -sonixj 0c45:612a Avant Camera -sonixj 0c45:612b Speed-Link REFLECT2 -sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix -sonixj 0c45:6130 Sonix Pccam -sonixj 0c45:6138 Sn9c120 Mo4000 -sonixj 0c45:613a Microdia Sonix PC Camera -sonixj 0c45:613b Surfer SN-206 -sonixj 0c45:613c Sonix Pccam168 -sonixj 0c45:6142 Hama PC-Webcam AC-150 -sonixj 0c45:6143 Sonix Pccam168 -sonixj 0c45:6148 Digitus DA-70811/ZSMC USB PC Camera ZS211/Microdia -sonixj 0c45:614a Frontech E-Ccam (JIL-2225) -sn9c20x 0c45:6240 PC Camera (SN9C201 + MT9M001) -sn9c20x 0c45:6242 PC Camera (SN9C201 + MT9M111) -sn9c20x 0c45:6248 PC Camera (SN9C201 + OV9655) -sn9c20x 0c45:624c PC Camera (SN9C201 + MT9M112) -sn9c20x 0c45:624e PC Camera (SN9C201 + SOI968) -sn9c20x 0c45:624f PC Camera (SN9C201 + OV9650) -sn9c20x 0c45:6251 PC Camera (SN9C201 + OV9650) -sn9c20x 0c45:6253 PC Camera (SN9C201 + OV9650) -sn9c20x 0c45:6260 PC Camera (SN9C201 + OV7670) -sn9c20x 0c45:6270 PC Camera (SN9C201 + MT9V011/MT9V111/MT9V112) -sn9c20x 0c45:627b PC Camera (SN9C201 + OV7660) -sn9c20x 0c45:627c PC Camera (SN9C201 + HV7131R) -sn9c20x 0c45:627f PC Camera (SN9C201 + OV9650) -sn9c20x 0c45:6280 PC Camera (SN9C202 + MT9M001) -sn9c20x 0c45:6282 PC Camera (SN9C202 + MT9M111) -sn9c20x 0c45:6288 PC Camera (SN9C202 + OV9655) -sn9c20x 0c45:628c PC Camera (SN9C201 + MT9M112) -sn9c20x 0c45:628e PC Camera (SN9C202 + SOI968) -sn9c20x 0c45:628f PC Camera (SN9C202 + OV9650) -sn9c20x 0c45:62a0 PC Camera (SN9C202 + OV7670) -sn9c20x 0c45:62b0 PC Camera (SN9C202 + MT9V011/MT9V111/MT9V112) -sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655) -sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660) -sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R) -sn9c2028 0c45:8001 Wild Planet Digital Spy Camera -sn9c2028 0c45:8003 Sakar #11199, #6637x, #67480 keychain cams -sn9c2028 0c45:8008 Mini-Shotz ms-350 -sn9c2028 0c45:800a Vivitar Vivicam 3350B -sunplus 0d64:0303 Sunplus FashionCam DXG -ov519 0e96:c001 TRUST 380 USB2 SPACEC@M -etoms 102c:6151 Qcam Sangha CIF -etoms 102c:6251 Qcam xxxxxx VGA -ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go -zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 -spca561 10fd:7e50 FlyCam Usb 100 -zc3xx 10fd:8050 Typhoon Webshot II USB 300k -ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201) -pac207 145f:013a Trust WB-1300N -sn9c20x 145f:013d Trust WB-3600R -vc032x 15b8:6001 HP 2.0 Megapixel -vc032x 15b8:6002 HP 2.0 Megapixel rz406aa -spca501 1776:501c Arowana 300K CMOS Camera -t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops -vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC -pac207 2001:f115 D-Link DSB-C120 -sq905c 2770:9050 Disney pix micro (CIF) -sq905c 2770:9051 Lego Bionicle -sq905c 2770:9052 Disney pix micro 2 (VGA) -sq905c 2770:905c All 11 known cameras with this ID -sq905 2770:9120 All 24 known cameras with this ID -sq905c 2770:913d All 4 known cameras with this ID -sq930x 2770:930b Sweex Motion Tracking / I-Tec iCam Tracer -sq930x 2770:930c Trust WB-3500T / NSG Robbie 2.0 -spca500 2899:012c Toptro Industrial -ov519 8020:ef04 ov519 -spca508 8086:0110 Intel Easy PC Camera -spca500 8086:0630 Intel Pocket PC Camera -spca506 99fa:8988 Grandtec V.cap -sn9c20x a168:0610 Dino-Lite Digital Microscope (SN9C201 + HV7131R) -sn9c20x a168:0611 Dino-Lite Digital Microscope (SN9C201 + HV7131R) -sn9c20x a168:0613 Dino-Lite Digital Microscope (SN9C201 + HV7131R) -sn9c20x a168:0618 Dino-Lite Digital Microscope (SN9C201 + HV7131R) -sn9c20x a168:0614 Dino-Lite Digital Microscope (SN9C201 + MT9M111) -sn9c20x a168:0615 Dino-Lite Digital Microscope (SN9C201 + MT9M111) -sn9c20x a168:0617 Dino-Lite Digital Microscope (SN9C201 + MT9M111) -spca561 abcd:cdee Petcam diff --git a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt deleted file mode 100644 index a2fd363c4..000000000 --- a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt +++ /dev/null @@ -1,54 +0,0 @@ -The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting. - -GPIO0 GPIO1 - 0 0 TV Audio - 1 0 FM radio - 0 1 Line-In - 1 1 Mono tuner bypass or CD passthru (tuner specific) - -GPIO 16(i believe) is tied to the IR port (if present). - ------------------------------------------------------------------------------------- - ->From the data sheet: - Register 24'h20004 PCI Interrupt Status - bit [18] IR_SMP_INT Set when 32 input samples have been collected over - gpio[16] pin into GP_SAMPLE register. - -What's missing from the data sheet: - -Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5 -compat remote) -set register 0x35C050 to 0xa80a80 - -enable sampling -set register 0x35C054 to 0x5 - -Of course, enable the IRQ bit 18 in the interrupt mask register .(and -provide for a handler) - -GP_SAMPLE register is at 0x35C058 - -Bits are then right shifted into the GP_SAMPLE register at the specified -rate; you get an interrupt when a full DWORD is received. -You need to recover the actual RC5 bits out of the (oversampled) IR sensor -bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An -actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment. - -I'm pretty sure when no IR signal is present the receiver is always in a -marking state(1); but stray light, etc can cause intermittent noise values -as well. Remember, this is a free running sample of the IR receiver state -over time, so don't assume any sample starts at any particular place. - -http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf -This data sheet (google search) seems to have a lovely description of the -RC5 basics - -http://www.nenya.be/beor/electronics/rc5.htm and more data - -http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt -and even a reference to how to decode a bi-phase data stream. - -http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm -still more info - diff --git a/Documentation/video4linux/lifeview.txt b/Documentation/video4linux/lifeview.txt deleted file mode 100644 index 05f9eb57a..000000000 --- a/Documentation/video4linux/lifeview.txt +++ /dev/null @@ -1,42 +0,0 @@ -collecting data about the lifeview models and the config coding on -gpio pins 0-9 ... -================================================================== - -bt878: - LR50 rev. Q ("PARTS: 7031505116), Tuner wurde als Nr. 5 erkannt, Eingänge - SVideo, TV, Composite, Audio, Remote. CP9..1=100001001 (1: 0-Ohm-Widerstand - gegen GND unbestückt; 0: bestückt) - ------------------------------------------------------------------------------- - -saa7134: - /* LifeView FlyTV Platinum FM (LR214WF) */ - /* "Peter Missel <peter.missel@onlinehome.de> */ - .name = "LifeView FlyTV Platinum FM", - /* GP27 MDT2005 PB4 pin 10 */ - /* GP26 MDT2005 PB3 pin 9 */ - /* GP25 MDT2005 PB2 pin 8 */ - /* GP23 MDT2005 PB1 pin 7 */ - /* GP22 MDT2005 PB0 pin 6 */ - /* GP21 MDT2005 PB5 pin 11 */ - /* GP20 MDT2005 PB6 pin 12 */ - /* GP19 MDT2005 PB7 pin 13 */ - /* nc MDT2005 PA3 pin 2 */ - /* Remote MDT2005 PA2 pin 1 */ - /* GP18 MDT2005 PA1 pin 18 */ - /* nc MDT2005 PA0 pin 17 strap low */ - - /* GP17 Strap "GP7"=High */ - /* GP16 Strap "GP6"=High - 0=Radio 1=TV - Drives SA630D ENCH1 and HEF4052 A1 pins - to do FM radio through SIF input */ - /* GP15 nc */ - /* GP14 nc */ - /* GP13 nc */ - /* GP12 Strap "GP5" = High */ - /* GP11 Strap "GP4" = High */ - /* GP10 Strap "GP3" = High */ - /* GP09 Strap "GP2" = Low */ - /* GP08 Strap "GP1" = Low */ - /* GP07.00 nc */ diff --git a/Documentation/video4linux/meye.txt b/Documentation/video4linux/meye.txt deleted file mode 100644 index a051152ea..000000000 --- a/Documentation/video4linux/meye.txt +++ /dev/null @@ -1,123 +0,0 @@ -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 Laptop Extras" driver (which -can be found in the "Misc devices" 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 development 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: - - 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.d/meye.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, - 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: ------------- - - - 'motioneye' still uses the meye private v4l1 API extensions. diff --git a/Documentation/video4linux/not-in-cx2388x-datasheet.txt b/Documentation/video4linux/not-in-cx2388x-datasheet.txt deleted file mode 100644 index edbfe744d..000000000 --- a/Documentation/video4linux/not-in-cx2388x-datasheet.txt +++ /dev/null @@ -1,41 +0,0 @@ -================================================================================= -MO_OUTPUT_FORMAT (0x310164) - - Previous default from DScaler: 0x1c1f0008 - Digit 8: 31-28 - 28: PREVREMOD = 1 - - Digit 7: 27-24 (0xc = 12 = b1100 ) - 27: COMBALT = 1 - 26: PAL_INV_PHASE - (DScaler apparently set this to 1, resulted in sucky picture) - - Digits 6,5: 23-16 - 25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512) - - Digit 4: 15-12 - 15: DISIFX = 0 - 14: INVCBF = 0 - 13: DISADAPT = 0 - 12: NARROWADAPT = 0 - - Digit 3: 11-8 - 11: FORCE2H - 10: FORCEREMD - 9: NCHROMAEN - 8: NREMODEN - - Digit 2: 7-4 - 7-6: YCORE - 5-4: CCORE - - Digit 1: 3-0 - 3: RANGE = 1 - 2: HACTEXT - 1: HSFMT - -0x47 is the sync byte for MPEG-2 transport stream packets. -Datasheet incorrectly states to use 47 decimal. 188 is the length. -All DVB compliant frontends output packets with this start code. - -================================================================================= diff --git a/Documentation/video4linux/omap3isp.txt b/Documentation/video4linux/omap3isp.txt deleted file mode 100644 index b9a9f83b1..000000000 --- a/Documentation/video4linux/omap3isp.txt +++ /dev/null @@ -1,279 +0,0 @@ -OMAP 3 Image Signal Processor (ISP) driver - -Copyright (C) 2010 Nokia Corporation -Copyright (C) 2009 Texas Instruments, Inc. - -Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com> - Sakari Ailus <sakari.ailus@iki.fi> - David Cohen <dacohen@gmail.com> - - -Introduction -============ - -This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP) -driver located under drivers/media/platform/omap3isp. The original driver was -written by Texas Instruments but since that it has been rewritten (twice) at -Nokia. - -The driver has been successfully used on the following versions of OMAP 3: - - 3430 - 3530 - 3630 - -The driver implements V4L2, Media controller and v4l2_subdev interfaces. -Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel -are supported. - - -Split to subdevs -================ - -The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP -having one subdev to represent it. Each of the subdevs provide a V4L2 subdev -interface to userspace. - - OMAP3 ISP CCP2 - OMAP3 ISP CSI2a - OMAP3 ISP CCDC - OMAP3 ISP preview - OMAP3 ISP resizer - OMAP3 ISP AEWB - OMAP3 ISP AF - OMAP3 ISP histogram - -Each possible link in the ISP is modelled by a link in the Media controller -interface. For an example program see [2]. - - -Controlling the OMAP 3 ISP -========================== - -In general, the settings given to the OMAP 3 ISP take effect at the beginning -of the following frame. This is done when the module becomes idle during the -vertical blanking period on the sensor. In memory-to-memory operation the pipe -is run one frame at a time. Applying the settings is done between the frames. - -All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver, -insist on receiving complete frames. Sensors must thus never send the ISP -partial frames. - -Autoidle does have issues with some ISP blocks on the 3430, at least. -Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle -is non-zero. - - -Events -====== - -The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and -statistics (AEWB, AF and histogram) subdevs. - -The CCDC subdev produces V4L2_EVENT_FRAME_SYNC type event on HS_VS -interrupt which is used to signal frame start. Earlier version of this -driver used V4L2_EVENT_OMAP3ISP_HS_VS for this purpose. The event is -triggered exactly when the reception of the first line of the frame starts -in the CCDC module. The event can be subscribed on the CCDC subdev. - -(When using parallel interface one must pay account to correct configuration -of the VS signal polarity. This is automatically correct when using the serial -receivers.) - -Each of the statistics subdevs is able to produce events. An event is -generated whenever a statistics buffer can be dequeued by a user space -application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available -are: - - V4L2_EVENT_OMAP3ISP_AEWB - V4L2_EVENT_OMAP3ISP_AF - V4L2_EVENT_OMAP3ISP_HIST - -The type of the event data is struct omap3isp_stat_event_status for these -ioctls. If there is an error calculating the statistics, there will be an -event as usual, but no related statistics buffer. In this case -omap3isp_stat_event_status.buf_err is set to non-zero. - - -Private IOCTLs -============== - -The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where -possible and practical. Much of the functions provided by the ISP, however, -does not fall under the standard IOCTLs --- gamma tables and configuration of -statistics collection are examples of such. - -In general, there is a private ioctl for configuring each of the blocks -containing hardware-dependent functions. - -The following private IOCTLs are supported: - - VIDIOC_OMAP3ISP_CCDC_CFG - VIDIOC_OMAP3ISP_PRV_CFG - VIDIOC_OMAP3ISP_AEWB_CFG - VIDIOC_OMAP3ISP_HIST_CFG - VIDIOC_OMAP3ISP_AF_CFG - VIDIOC_OMAP3ISP_STAT_REQ - VIDIOC_OMAP3ISP_STAT_EN - -The parameter structures used by these ioctls are described in -include/linux/omap3isp.h. The detailed functions of the ISP itself related to -a given ISP block is described in the Technical Reference Manuals (TRMs) --- -see the end of the document for those. - -While it is possible to use the ISP driver without any use of these private -IOCTLs it is not possible to obtain optimal image quality this way. The AEWB, -AF and histogram modules cannot be used without configuring them using the -appropriate private IOCTLs. - - -CCDC and preview block IOCTLs -============================= - -The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to -configure, enable and disable functions in the CCDC and preview blocks, -respectively. Both IOCTLs control several functions in the blocks they -control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct -omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG -accepts a pointer to struct omap3isp_prev_update_config. The definition of -both structures is available in [1]. - -The update field in the structures tells whether to update the configuration -for the specific function and the flag tells whether to enable or disable the -function. - -The update and flag bit masks accept the following values. Each separate -functions in the CCDC and preview blocks is associated with a flag (either -disable or enable; part of the flag field in the structure) and a pointer to -configuration data for the function. - -Valid values for the update and flag fields are listed here for -VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one -function in the same IOCTL call. - - OMAP3ISP_CCDC_ALAW - OMAP3ISP_CCDC_LPF - OMAP3ISP_CCDC_BLCLAMP - OMAP3ISP_CCDC_BCOMP - OMAP3ISP_CCDC_FPC - OMAP3ISP_CCDC_CULL - OMAP3ISP_CCDC_CONFIG_LSC - OMAP3ISP_CCDC_TBL_LSC - -The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here: - - OMAP3ISP_PREV_LUMAENH - OMAP3ISP_PREV_INVALAW - OMAP3ISP_PREV_HRZ_MED - OMAP3ISP_PREV_CFA - OMAP3ISP_PREV_CHROMA_SUPP - OMAP3ISP_PREV_WB - OMAP3ISP_PREV_BLKADJ - OMAP3ISP_PREV_RGB2RGB - OMAP3ISP_PREV_COLOR_CONV - OMAP3ISP_PREV_YC_LIMIT - OMAP3ISP_PREV_DEFECT_COR - OMAP3ISP_PREV_GAMMABYPASS - OMAP3ISP_PREV_DRK_FRM_CAPTURE - OMAP3ISP_PREV_DRK_FRM_SUBTRACT - OMAP3ISP_PREV_LENS_SHADING - OMAP3ISP_PREV_NF - OMAP3ISP_PREV_GAMMA - -The associated configuration pointer for the function may not be NULL when -enabling the function. When disabling a function the configuration pointer is -ignored. - - -Statistic blocks IOCTLs -======================= - -The statistics subdevs do offer more dynamic configuration options than the -other subdevs. They can be enabled, disable and reconfigured when the pipeline -is in streaming state. - -The statistics blocks always get the input image data from the CCDC (as the -histogram memory read isn't implemented). The statistics are dequeueable by -the user from the statistics subdev nodes using private IOCTLs. - -The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily -reflected by the register level interface offered by the ISP hardware. There -are aspects that are purely related to the driver implementation and these are -discussed next. - -VIDIOC_OMAP3ISP_STAT_EN ------------------------ - -This private IOCTL enables/disables a statistic module. If this request is -done before streaming, it will take effect as soon as the pipeline starts to -stream. If the pipeline is already streaming, it will take effect as soon as -the CCDC becomes idle. - -VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG ------------------------------------------------------------------------------ - -Those IOCTLs are used to configure the modules. They require user applications -to have an in-depth knowledge of the hardware. Most of the fields explanation -can be found on OMAP's TRMs. The two following fields common to all the above -configure private IOCTLs require explanation for better understanding as they -are not part of the TRM. - -omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size: - -The modules handle their buffers internally. The necessary buffer size for the -module's data output depends on the requested configuration. Although the -driver supports reconfiguration while streaming, it does not support a -reconfiguration which requires bigger buffer size than what is already -internally allocated if the module is enabled. It will return -EBUSY on this -case. In order to avoid such condition, either disable/reconfigure/enable the -module or request the necessary buffer size during the first configuration -while the module is disabled. - -The internal buffer size allocation considers the requested configuration's -minimum buffer size and the value set on buf_size field. If buf_size field is -out of [minimum, maximum] buffer size range, it's clamped to fit in there. -The driver then selects the biggest value. The corrected buf_size value is -written back to user application. - -omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter: - -As the configuration doesn't take effect synchronously to the request, the -driver must provide a way to track this information to provide more accurate -data. After a configuration is requested, the config_counter returned to user -space application will be an unique value associated to that request. When -user application receives an event for buffer availability or when a new -buffer is requested, this config_counter is used to match a buffer data and a -configuration. - -VIDIOC_OMAP3ISP_STAT_REQ ------------------------- - -Send to user space the oldest data available in the internal buffer queue and -discards such buffer afterwards. The field omap3isp_stat_data.frame_number -matches with the video buffer's field_count. - - -Technical reference manuals (TRMs) and other documentation -========================================================== - -OMAP 3430 TRM: -<URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip> -Referenced 2011-03-05. - -OMAP 35xx TRM: -<URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05. - -OMAP 3630 TRM: -<URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip> -Referenced 2011-03-05. - -DM 3730 TRM: -<URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06. - - -References -========== - -[1] include/linux/omap3isp.h - -[2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary diff --git a/Documentation/video4linux/omap4_camera.txt b/Documentation/video4linux/omap4_camera.txt deleted file mode 100644 index a6734aa77..000000000 --- a/Documentation/video4linux/omap4_camera.txt +++ /dev/null @@ -1,60 +0,0 @@ - OMAP4 ISS Driver - ================ - -Introduction ------------- - -The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS), -Which contains several components that can be categorized in 3 big groups: - -- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2) -- ISP (Image Signal Processor) -- SIMCOP (Still Image Coprocessor) - -For more information, please look in [1] for latest version of: - "OMAP4430 Multimedia Device Silicon Revision 2.x" - -As of Revision AB, the ISS is described in detail in section 8. - -This driver is supporting _only_ the CSI2-A/B interfaces for now. - -It makes use of the Media Controller framework [2], and inherited most of the -code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/*), -except that it doesn't need an IOMMU now for ISS buffers memory mapping. - -Supports usage of MMAP buffers only (for now). - -Tested platforms ----------------- - -- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in - which only the last one is supported, outputting YUV422 frames). - -- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in - which only the OV5650 are supported, outputting RAW10 frames). - -- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with - following sensors: - * OV5640 - * OV5650 - -- Tested on mainline kernel: - - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary - - Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7) - -File list ---------- -drivers/staging/media/omap4iss/ -include/linux/platform_data/media/omap4iss.h - -References ----------- - -[1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62 -[2] http://lwn.net/Articles/420485/ -[3] http://www.spinics.net/lists/linux-media/msg44370.html --- -Author: Sergio Aguirre <sergio.a.aguirre@gmail.com> -Copyright (C) 2012, Texas Instruments diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt deleted file mode 100644 index 51ed1578b..000000000 --- a/Documentation/video4linux/pxa_camera.txt +++ /dev/null @@ -1,174 +0,0 @@ - PXA-Camera Host Driver - ====================== - -Constraints ------------ - a) Image size for YUV422P format - All YUV422P images are enforced to have width x height % 16 = 0. - This is due to DMA constraints, which transfers only planes of 8 byte - multiples. - - -Global video workflow ---------------------- - a) QCI stopped - Initialy, the QCI interface is stopped. - When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts. - - b) QCI started - More buffers can be queued while the QCI is started without halting the - capture. The new buffers are "appended" at the tail of the DMA chain, and - smoothly captured one frame after the other. - - Once a buffer is filled in the QCI interface, it is marked as "DONE" and - removed from the active buffers list. It can be then requeud or dequeued by - userland application. - - Once the last buffer is filled in, the QCI interface stops. - - c) Capture global finite state machine schema - - +----+ +---+ +----+ - | DQ | | Q | | DQ | - | v | v | v - +-----------+ +------------------------+ - | STOP | | Wait for capture start | - +-----------+ Q +------------------------+ -+-> | QCI: stop | ------------------> | QCI: run | <------------+ -| | DMA: stop | | DMA: stop | | -| +-----------+ +-----> +------------------------+ | -| / | | -| / +---+ +----+ | | -|capture list empty / | Q | | DQ | | QCI Irq EOF | -| / | v | v v | -| +--------------------+ +----------------------+ | -| | DMA hotlink missed | | Capture running | | -| +--------------------+ +----------------------+ | -| | QCI: run | +-----> | QCI: run | <-+ | -| | DMA: stop | / | DMA: run | | | -| +--------------------+ / +----------------------+ | Other | -| ^ /DMA still | | channels | -| | capture list / running | DMA Irq End | not | -| | not empty / | | finished | -| | / v | yet | -| +----------------------+ +----------------------+ | | -| | Videobuf released | | Channel completed | | | -| +----------------------+ +----------------------+ | | -+-- | QCI: run | | QCI: run | --+ | - | DMA: run | | DMA: run | | - +----------------------+ +----------------------+ | - ^ / | | - | no overrun / | overrun | - | / v | - +--------------------+ / +----------------------+ | - | Frame completed | / | Frame overran | | - +--------------------+ <-----+ +----------------------+ restart frame | - | QCI: run | | QCI: stop | --------------+ - | DMA: run | | DMA: stop | - +--------------------+ +----------------------+ - - Legend: - each box is a FSM state - - each arrow is the condition to transition to another state - - an arrow with a comment is a mandatory transition (no condition) - - arrow "Q" means : a buffer was enqueued - - arrow "DQ" means : a buffer was dequeued - - "QCI: stop" means the QCI interface is not enabled - - "DMA: stop" means all 3 DMA channels are stopped - - "DMA: run" means at least 1 DMA channel is still running - -DMA usage ---------- - a) DMA flow - - first buffer queued for capture - Once a first buffer is queued for capture, the QCI is started, but data - transfer is not started. On "End Of Frame" interrupt, the irq handler - starts the DMA chain. - - capture of one videobuffer - The DMA chain starts transferring data into videobuffer RAM pages. - When all pages are transferred, the DMA irq is raised on "ENDINTR" status - - finishing one videobuffer - The DMA irq handler marks the videobuffer as "done", and removes it from - the active running queue - Meanwhile, the next videobuffer (if there is one), is transferred by DMA - - finishing the last videobuffer - On the DMA irq of the last videobuffer, the QCI is stopped. - - b) DMA prepared buffer will have this structure - - +------------+-----+---------------+-----------------+ - | desc-sg[0] | ... | desc-sg[last] | finisher/linker | - +------------+-----+---------------+-----------------+ - - This structure is pointed by dma->sg_cpu. - The descriptors are used as follows : - - desc-sg[i]: i-th descriptor, transferring the i-th sg - element to the video buffer scatter gather - - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN - - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0 - - For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N], - "f" stands for finisher and "l" for linker. - A typical running chain is : - - Videobuffer 1 Videobuffer 2 - +---------+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+---+ - | | - +----+ - - After the chaining is finished, the chain looks like : - - Videobuffer 1 Videobuffer 2 Videobuffer 3 - +---------+----+---+ +----+----+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ - | | | | - +----+ +----+ - new_link - - c) DMA hot chaining timeslice issue - - As DMA chaining is done while DMA _is_ running, the linking may be done - while the DMA jumps from one Videobuffer to another. On the schema, that - would be a problem if the following sequence is encountered : - - - DMA chain is Videobuffer1 + Videobuffer2 - - pxa_videobuf_queue() is called to queue Videobuffer3 - - DMA controller finishes Videobuffer2, and DMA stops - => - Videobuffer 1 Videobuffer 2 - +---------+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-^-+ - | | | - +----+ +-- DMA DDADR loads DDADR_STOP - - - pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is - replaced by a "linker" to Videobuffer3 (creation of new_link) - - pxa_videobuf_queue() finishes - - the DMA irq handler is called, which terminates Videobuffer2 - - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!) - - Videobuffer 1 Videobuffer 2 Videobuffer 3 - +---------+----+---+ +----+----+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ - | | | | - +----+ +----+ - new_link - DMA DDADR still is DDADR_STOP - - - pxa_camera_check_link_miss() is called - This checks if the DMA is finished and a buffer is still on the - pcdev->capture list. If that's the case, the capture will be restarted, - and Videobuffer3 is scheduled on DMA chain. - - the DMA irq handler finishes - - Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR() - value, we have the guarantee that the DMA irq handler will be called back - when the DMA will finish the buffer, and pxa_camera_check_link_miss() will - be called again, to reschedule Videobuffer3. - --- -Author: Robert Jarzmik <robert.jarzmik@free.fr> diff --git a/Documentation/video4linux/radiotrack.txt b/Documentation/video4linux/radiotrack.txt deleted file mode 100644 index d1f3ed199..000000000 --- a/Documentation/video4linux/radiotrack.txt +++ /dev/null @@ -1,147 +0,0 @@ -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/sh_mobile_ceu_camera.txt b/Documentation/video4linux/sh_mobile_ceu_camera.txt deleted file mode 100644 index 1e96ce6e2..000000000 --- a/Documentation/video4linux/sh_mobile_ceu_camera.txt +++ /dev/null @@ -1,139 +0,0 @@ - Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver - ======================================================================= - -Terminology ------------ - -sensor scales: horizontal and vertical scales, configured by the sensor driver -host scales: -"- host driver -combined scales: sensor_scale * host_scale - - -Generic scaling / cropping scheme ---------------------------------- - --1-- -| --2-- -\ -| --\ -| --\ -+-5-- . -- -3-- -\ -| `... -\ -| `... -4-- . - -7.. -| `. -| `. .6-- -| -| . .6'- -| .´ -| ... -4'- .´ -| ...´ - -7'. -+-5'- .´ -/ -| -- -3'- -/ -| --/ -| --/ --2'- -/ -| -| --1'- - -In the above chart minuses and slashes represent "real" data amounts, points and -accents represent "useful" data, basically, CEU scaled and cropped output, -mapped back onto the client's source plane. - -Such a configuration can be produced by user requests: - -S_CROP(left / top = (5) - (1), width / height = (5') - (5)) -S_FMT(width / height = (6') - (6)) - -Here: - -(1) to (1') - whole max width or height -(1) to (2) - sensor cropped left or top -(2) to (2') - sensor cropped width or height -(3) to (3') - sensor scale -(3) to (4) - CEU cropped left or top -(4) to (4') - CEU cropped width or height -(5) to (5') - reverse sensor scale applied to CEU cropped width or height -(2) to (5) - reverse sensor scale applied to CEU cropped left or top -(6) to (6') - CEU scale - user window - - -S_FMT ------ - -Do not touch input rectangle - it is already optimal. - -1. Calculate current sensor scales: - - scale_s = ((2') - (2)) / ((3') - (3)) - -2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at -current sensor scales onto input window - this is user S_CROP: - - width_u = (5') - (5) = ((4') - (4)) * scale_s - -3. Calculate new combined scales from "effective" input window to requested user -window: - - scale_comb = width_u / ((6') - (6)) - -4. Calculate sensor output window by applying combined scales to real input -window: - - width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb - -5. Apply iterative sensor S_FMT for sensor output window. - - subdev->video_ops->s_fmt(.width = width_s_out) - -6. Retrieve sensor output window (g_fmt) - -7. Calculate new sensor scales: - - scale_s_new = ((3')_new - (3)_new) / ((2') - (2)) - -8. Calculate new CEU crop - apply sensor scales to previously calculated -"effective" crop: - - width_ceu = (4')_new - (4)_new = width_u / scale_s_new - left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new - -9. Use CEU cropping to crop to the new window: - - ceu_crop(.width = width_ceu, .left = left_ceu) - -10. Use CEU scaling to scale to the requested user window: - - scale_ceu = width_ceu / width - - -S_CROP ------- - -The API at http://v4l2spec.bytesex.org/spec/x1904.htm says: - -"...specification does not define an origin or units. However by convention -drivers should horizontally count unscaled samples relative to 0H." - -We choose to follow the advise and interpret cropping units as client input -pixels. - -Cropping is performed in the following 6 steps: - -1. Request exactly user rectangle from the sensor. - -2. If smaller - iterate until a larger one is obtained. Result: sensor cropped - to 2 : 2', target crop 5 : 5', current output format 6' - 6. - -3. In the previous step the sensor has tried to preserve its output frame as - good as possible, but it could have changed. Retrieve it again. - -4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate - intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2) - -5. Calculate and apply host scale = (6' - 6) / (4' - 4) - -6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5) - --- -Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt deleted file mode 100644 index 98c32925e..000000000 --- a/Documentation/video4linux/si470x.txt +++ /dev/null @@ -1,129 +0,0 @@ -Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers - -Copyright (c) 2009 Tobias Lorenz <tobias.lorenz@gmx.net> - - -Information from Silicon Labs -============================= -Silicon Laboratories is the manufacturer of the radio ICs, that nowadays are the -most often used radio receivers in cell phones. Usually they are connected with -I2C. But SiLabs also provides a reference design, which integrates this IC, -together with a small microcontroller C8051F321, to form a USB radio. -Part of this reference design is also a radio application in binary and source -code. The software also contains an automatic firmware upgrade to the most -current version. Information on these can be downloaded here: -http://www.silabs.com/usbradio - - -Supported ICs -============= -The following ICs have a very similar register set, so that they are or will be -supported somewhen by the driver: -- Si4700: FM radio receiver -- Si4701: FM radio receiver, RDS Support -- Si4702: FM radio receiver -- Si4703: FM radio receiver, RDS Support -- Si4704: FM radio receiver, no external antenna required -- Si4705: FM radio receiver, no external antenna required, RDS support, Dig I/O -- Si4706: Enhanced FM RDS/TMC radio receiver, no external antenna required, RDS - Support -- Si4707: Dedicated weather band radio receiver with SAME decoder, RDS Support -- Si4708: Smallest FM receivers -- Si4709: Smallest FM receivers, RDS Support -More information on these can be downloaded here: -http://www.silabs.com/products/mcu/Pages/USBFMRadioRD.aspx - - -Supported USB devices -===================== -Currently the following USB radios (vendor:product) with the Silicon Labs si470x -chips are known to work: -- 10c4:818a: Silicon Labs USB FM Radio Reference Design -- 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) -- 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700) -- 10c5:819a: Sanei Electric, Inc. FM USB Radio (sold as DealExtreme.com PCear) - - -Software -======== -Testing is usually done with most application under Debian/testing: -- fmtools - Utility for managing FM tuner cards -- gnomeradio - FM-radio tuner for the GNOME desktop -- gradio - GTK FM radio tuner -- kradio - Comfortable Radio Application for KDE -- radio - ncurses-based radio application -- mplayer - The Ultimate Movie Player For Linux -- v4l2-ctl - Collection of command line video4linux utilities -For example, you can use: -v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all - -There is also a library libv4l, which can be used. It's going to have a function -for frequency seeking, either by using hardware functionality as in radio-si470x -or by implementing a function as we currently have in every of the mentioned -programs. Somewhen the radio programs should make use of libv4l. - -For processing RDS information, there is a project ongoing at: -http://rdsd.berlios.de/ - -There is currently no project for making TMC sentences human readable. - - -Audio Listing -============= -USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to -also select SND_USB_AUDIO, as this is required to get sound from the radio. For -listing you have to redirect the sound, for example using one of the following -commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x). - -If you just want to test audio (very poor quality): -cat /dev/dsp1 > /dev/dsp - -If you use sox + OSS try: -sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp -or using sox + alsa: -sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0 - -If you use arts try: -arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - - -If you use mplayer try: -mplayer -radio adevice=hw=1.0:arate=96000 \ - -rawaudio rate=96000 \ - radio://<frequency>/capture - -Module Parameters -================= -After loading the module, you still have access to some of them in the sysfs -mount under /sys/module/radio_si470x/parameters. The contents of read-only files -(0444) are not updated, even if space, band and de are changed using private -video controls. The others are runtime changeable. - - -Errors -====== -Increase tune_timeout, if you often get -EIO errors. - -When timed out or band limit is reached, hw_freq_seek returns -EAGAIN. - -If you get any errors from snd_usb_audio, please report them to the ALSA people. - - -Open Issues -=========== -V4L minor device allocation and parameter setting is not perfect. A solution is -currently under discussion. - -There is an USB interface for downloading/uploading new firmware images. Support -for it can be implemented using the request_firmware interface. - -There is a RDS interrupt mode. The driver is already using the same interface -for polling RDS information, but is currently not using the interrupt mode. - -There is a LED interface, which can be used to override the LED control -programmed in the firmware. This can be made available using the LED support -functions in the kernel. - - -Other useful information and links -================================== -http://www.silabs.com/usbradio diff --git a/Documentation/video4linux/si4713.txt b/Documentation/video4linux/si4713.txt deleted file mode 100644 index 2ddc6b095..000000000 --- a/Documentation/video4linux/si4713.txt +++ /dev/null @@ -1,176 +0,0 @@ -Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters - -Copyright (c) 2009 Nokia Corporation -Contact: Eduardo Valentin <eduardo.valentin@nokia.com> - - -Information about the Device -============================ -This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address. -Basically, it has transmission and signal noise level measurement features. - -The Si4713 integrates transmit functions for FM broadcast stereo transmission. -The chip also allows integrated receive power scanning to identify low signal -power FM channels. - -The chip is programmed using commands and responses. There are also several -properties which can change the behavior of this chip. - -Users must comply with local regulations on radio frequency (RF) transmission. - -Device driver description -========================= -There are two modules to handle this device. One is a I2C device driver -and the other is a platform driver. - -The I2C device driver exports a v4l2-subdev interface to the kernel. -All properties can also be accessed by v4l2 extended controls interface, by -using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls). - -The platform device driver exports a v4l2 radio device interface to user land. -So, it uses the I2C device driver as a sub device in order to send the user -commands to the actual device. Basically it is a wrapper to the I2C device driver. - -Applications can use v4l2 radio API to specify frequency of operation, mute state, -etc. But mostly of its properties will be present in the extended controls. - -When the v4l2 mute property is set to 1 (true), the driver will turn the chip off. - -Properties description -====================== - -The properties can be accessed using v4l2 extended controls. -Here is an output from v4l2-ctl util: -/ # v4l2-ctl -d /dev/radio0 --all -L -Driver Info: - Driver name : radio-si4713 - Card type : Silicon Labs Si4713 Modulator - Bus info : - Driver version: 0 - Capabilities : 0x00080800 - RDS Output - Modulator -Audio output: 0 (FM Modulator Audio Out) -Frequency: 1408000 (88.000000 MHz) -Video Standard = 0x00000000 -Modulator: - Name : FM Modulator - Capabilities : 62.5 Hz stereo rds - Frequency range : 76.0 MHz - 108.0 MHz - Subchannel modulation: stereo+rds - -User Controls - - mute (bool) : default=1 value=0 - -FM Radio Modulator Controls - - rds_signal_deviation (int) : min=0 max=90000 step=10 default=200 value=200 flags=slider - rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0 - rds_program_type (int) : min=0 max=31 step=1 default=0 value=0 - rds_ps_name (str) : min=0 max=96 step=8 value='si4713 ' - rds_radio_text (str) : min=0 max=384 step=32 value='' - audio_limiter_feature_enabled (bool) : default=1 value=1 - audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider - audio_limiter_deviation (int) : min=0 max=90000 step=10 default=66250 value=66250 flags=slider -audio_compression_feature_enabl (bool) : default=1 value=1 - audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider - audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider - audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=0 flags=slider - audio_compression_release_time (int) : min=100000 max=1000000 step=100000 default=1000000 value=1000000 flags=slider - pilot_tone_feature_enabled (bool) : default=1 value=1 - pilot_tone_deviation (int) : min=0 max=90000 step=10 default=6750 value=6750 flags=slider - pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider - pre_emphasis_settings (menu) : min=0 max=2 default=1 value=1 - tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider - tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider -/ # - -Here is a summary of them: - -* Pilot is an audible tone sent by the device. - -pilot_frequency - Configures the frequency of the stereo pilot tone. -pilot_deviation - Configures pilot tone frequency deviation level. -pilot_enabled - Enables or disables the pilot tone feature. - -* The si4713 device is capable of applying audio compression to the transmitted signal. - -acomp_enabled - Enables or disables the audio dynamic range control feature. -acomp_gain - Sets the gain for audio dynamic range control. -acomp_threshold - Sets the threshold level for audio dynamic range control. -acomp_attack_time - Sets the attack time for audio dynamic range control. -acomp_release_time - Sets the release time for audio dynamic range control. - -* Limiter setups audio deviation limiter feature. Once a over deviation occurs, -it is possible to adjust the front-end gain of the audio input and always -prevent over deviation. - -limiter_enabled - Enables or disables the limiter feature. -limiter_deviation - Configures audio frequency deviation level. -limiter_release_time - Sets the limiter release time. - -* Tuning power - -power_level - Sets the output power level for signal transmission. -antenna_capacitor - This selects the value of antenna tuning capacitor manually -or automatically if set to zero. - -* RDS related - -rds_ps_name - Sets the RDS ps name field for transmission. -rds_radio_text - Sets the RDS radio text for transmission. -rds_pi - Sets the RDS PI field for transmission. -rds_pty - Sets the RDS PTY field for transmission. - -* Region related - -preemphasis - sets the preemphasis to be applied for transmission. - -RNL -=== - -This device also has an interface to measure received noise level. To do that, you should -ioctl the device node. Here is an code of example: - -int main (int argc, char *argv[]) -{ - struct si4713_rnl rnl; - int fd = open("/dev/radio0", O_RDWR); - int rval; - - if (argc < 2) - return -EINVAL; - - if (fd < 0) - return fd; - - sscanf(argv[1], "%d", &rnl.frequency); - - rval = ioctl(fd, SI4713_IOC_MEASURE_RNL, &rnl); - if (rval < 0) - return rval; - - printf("received noise level: %d\n", rnl.rnl); - - close(fd); -} - -The struct si4713_rnl and SI4713_IOC_MEASURE_RNL are defined under -include/linux/platform_data/media/si4713.h. - -Stereo/Mono and RDS subchannels -=============================== - -The device can also be configured using the available sub channels for -transmission. To do that use S/G_MODULATOR ioctl and configure txsubchans properly. -Refer to the V4L2 API specification for proper use of this ioctl. - -Testing -======= -Testing is usually done with v4l2-ctl utility for managing FM tuner cards. -The tool can be found in v4l-dvb repository under v4l2-apps/util directory. - -Example for setting rds ps name: -# v4l2-ctl -d /dev/radio0 --set-ctrl=rds_ps_name="Dummy" - diff --git a/Documentation/video4linux/si476x.txt b/Documentation/video4linux/si476x.txt deleted file mode 100644 index 616607955..000000000 --- a/Documentation/video4linux/si476x.txt +++ /dev/null @@ -1,187 +0,0 @@ -SI476x Driver Readme ------------------------------------------------- - Copyright (C) 2013 Andrey Smirnov <andrew.smirnov@gmail.com> - -TODO for the driver ------------------------------- - -- According to the SiLabs' datasheet it is possible to update the - firmware of the radio chip in the run-time, thus bringing it to the - most recent version. Unfortunately I couldn't find any mentioning of - the said firmware update for the old chips that I tested the driver - against, so for chips like that the driver only exposes the old - functionality. - - -Parameters exposed over debugfs -------------------------------- -SI476x allow user to get multiple characteristics that can be very -useful for EoL testing/RF performance estimation, parameters that have -very little to do with V4L2 subsystem. Such parameters are exposed via -debugfs and can be accessed via regular file I/O operations. - -The drivers exposes following files: - -* /sys/kernel/debug/<device-name>/acf - This file contains ACF(Automatically Controlled Features) status - information. The contents of the file is binary data of the - following layout: - - Offset | Name | Description - ==================================================================== - 0x00 | blend_int | Flag, set when stereo separation has - | | crossed below the blend threshold - -------------------------------------------------------------------- - 0x01 | hblend_int | Flag, set when HiBlend cutoff - | | frequency is lower than threshold - -------------------------------------------------------------------- - 0x02 | hicut_int | Flag, set when HiCut cutoff - | | frequency is lower than threshold - -------------------------------------------------------------------- - 0x03 | chbw_int | Flag, set when channel filter - | | bandwidth is less than threshold - -------------------------------------------------------------------- - 0x04 | softmute_int | Flag indicating that softmute - | | attenuation has increased above - | | softmute threshold - -------------------------------------------------------------------- - 0x05 | smute | 0 - Audio is not soft muted - | | 1 - Audio is soft muted - -------------------------------------------------------------------- - 0x06 | smattn | Soft mute attenuation level in dB - -------------------------------------------------------------------- - 0x07 | chbw | Channel filter bandwidth in kHz - -------------------------------------------------------------------- - 0x08 | hicut | HiCut cutoff frequency in units of - | | 100Hz - -------------------------------------------------------------------- - 0x09 | hiblend | HiBlend cutoff frequency in units - | | of 100 Hz - -------------------------------------------------------------------- - 0x10 | pilot | 0 - Stereo pilot is not present - | | 1 - Stereo pilot is present - -------------------------------------------------------------------- - 0x11 | stblend | Stereo blend in % - -------------------------------------------------------------------- - - -* /sys/kernel/debug/<device-name>/rds_blckcnt - This file contains statistics about RDS receptions. It's binary data - has the following layout: - - Offset | Name | Description - ==================================================================== - 0x00 | expected | Number of expected RDS blocks - -------------------------------------------------------------------- - 0x02 | received | Number of received RDS blocks - -------------------------------------------------------------------- - 0x04 | uncorrectable | Number of uncorrectable RDS blocks - -------------------------------------------------------------------- - -* /sys/kernel/debug/<device-name>/agc - This file contains information about parameters pertaining to - AGC(Automatic Gain Control) - - The layout is: - Offset | Name | Description - ==================================================================== - 0x00 | mxhi | 0 - FM Mixer PD high threshold is - | | not tripped - | | 1 - FM Mixer PD high threshold is - | | tripped - -------------------------------------------------------------------- - 0x01 | mxlo | ditto for FM Mixer PD low - -------------------------------------------------------------------- - 0x02 | lnahi | ditto for FM LNA PD high - -------------------------------------------------------------------- - 0x03 | lnalo | ditto for FM LNA PD low - -------------------------------------------------------------------- - 0x04 | fmagc1 | FMAGC1 attenuator resistance - | | (see datasheet for more detail) - -------------------------------------------------------------------- - 0x05 | fmagc2 | ditto for FMAGC2 - -------------------------------------------------------------------- - 0x06 | pgagain | PGA gain in dB - -------------------------------------------------------------------- - 0x07 | fmwblang | FM/WB LNA Gain in dB - -------------------------------------------------------------------- - -* /sys/kernel/debug/<device-name>/rsq - This file contains information about parameters pertaining to - RSQ(Received Signal Quality) - - The layout is: - Offset | Name | Description - ==================================================================== - 0x00 | multhint | 0 - multipath value has not crossed - | | the Multipath high threshold - | | 1 - multipath value has crossed - | | the Multipath high threshold - -------------------------------------------------------------------- - 0x01 | multlint | ditto for Multipath low threshold - -------------------------------------------------------------------- - 0x02 | snrhint | 0 - received signal's SNR has not - | | crossed high threshold - | | 1 - received signal's SNR has - | | crossed high threshold - -------------------------------------------------------------------- - 0x03 | snrlint | ditto for low threshold - -------------------------------------------------------------------- - 0x04 | rssihint | ditto for RSSI high threshold - -------------------------------------------------------------------- - 0x05 | rssilint | ditto for RSSI low threshold - -------------------------------------------------------------------- - 0x06 | bltf | Flag indicating if seek command - | | reached/wrapped seek band limit - -------------------------------------------------------------------- - 0x07 | snr_ready | Indicates that SNR metrics is ready - -------------------------------------------------------------------- - 0x08 | rssiready | ditto for RSSI metrics - -------------------------------------------------------------------- - 0x09 | injside | 0 - Low-side injection is being used - | | 1 - High-side injection is used - -------------------------------------------------------------------- - 0x10 | afcrl | Flag indicating if AFC rails - -------------------------------------------------------------------- - 0x11 | valid | Flag indicating if channel is valid - -------------------------------------------------------------------- - 0x12 | readfreq | Current tuned frequency - -------------------------------------------------------------------- - 0x14 | freqoff | Signed frequency offset in units of - | | 2ppm - -------------------------------------------------------------------- - 0x15 | rssi | Signed value of RSSI in dBuV - -------------------------------------------------------------------- - 0x16 | snr | Signed RF SNR in dB - -------------------------------------------------------------------- - 0x17 | issi | Signed Image Strength Signal - | | indicator - -------------------------------------------------------------------- - 0x18 | lassi | Signed Low side adjacent Channel - | | Strength indicator - -------------------------------------------------------------------- - 0x19 | hassi | ditto fpr High side - -------------------------------------------------------------------- - 0x20 | mult | Multipath indicator - -------------------------------------------------------------------- - 0x21 | dev | Frequency deviation - -------------------------------------------------------------------- - 0x24 | assi | Adjacent channel SSI - -------------------------------------------------------------------- - 0x25 | usn | Ultrasonic noise indicator - -------------------------------------------------------------------- - 0x26 | pilotdev | Pilot deviation in units of 100 Hz - -------------------------------------------------------------------- - 0x27 | rdsdev | ditto for RDS - -------------------------------------------------------------------- - 0x28 | assidev | ditto for ASSI - -------------------------------------------------------------------- - 0x29 | strongdev | Frequency deviation - -------------------------------------------------------------------- - 0x30 | rdspi | RDS PI code - -------------------------------------------------------------------- - -* /sys/kernel/debug/<device-name>/rsq_primary - This file contains information about parameters pertaining to - RSQ(Received Signal Quality) for primary tuner only. Layout is as - the one above. diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt deleted file mode 100644 index 84f41cf1f..000000000 --- a/Documentation/video4linux/soc-camera.txt +++ /dev/null @@ -1,164 +0,0 @@ - Soc-Camera Subsystem - ==================== - -Terminology ------------ - -The following terms are used in this document: - - camera / camera device / camera sensor - a video-camera sensor chip, capable - of connecting to a variety of systems and interfaces, typically uses i2c for - control and configuration, and a parallel or a serial bus for data. - - camera host - an interface, to which a camera is connected. Typically a - specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH, - AVR32, i.MX27, i.MX31. - - camera host bus - a connection between a camera host and a camera. Can be - parallel or serial, consists of data and control lines, e.g. clock, vertical - and horizontal synchronization signals. - -Purpose of the soc-camera subsystem ------------------------------------ - -The soc-camera subsystem initially provided a unified API between camera host -drivers and camera sensor drivers. Later the soc-camera sensor API has been -replaced with the V4L2 standard subdev API. This also made camera driver re-use -with non-soc-camera hosts possible. The camera host API to the soc-camera core -has been preserved. - -Soc-camera implements a V4L2 interface to the user, currently only the "mmap" -method is supported by host drivers. However, the soc-camera core also provides -support for the "read" method. - -The subsystem has been designed to support multiple camera host interfaces and -multiple cameras per interface, although most applications have only one camera -sensor. - -Existing drivers ----------------- - -As of 3.7 there are seven host drivers in the mainline: atmel-isi.c, -mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c, -omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor -drivers under drivers/media/i2c/soc_camera/. - -Camera host API ---------------- - -A host camera driver is registered using the - -soc_camera_host_register(struct soc_camera_host *); - -function. The host object can be initialized as follows: - - struct soc_camera_host *ici; - ici->drv_name = DRV_NAME; - ici->ops = &camera_host_ops; - ici->priv = pcdev; - ici->v4l2_dev.dev = &pdev->dev; - ici->nr = pdev->id; - -All camera host methods are passed in a struct soc_camera_host_ops: - -static struct soc_camera_host_ops camera_host_ops = { - .owner = THIS_MODULE, - .add = camera_add_device, - .remove = camera_remove_device, - .set_fmt = camera_set_fmt_cap, - .try_fmt = camera_try_fmt_cap, - .init_videobuf2 = camera_init_videobuf2, - .poll = camera_poll, - .querycap = camera_querycap, - .set_bus_param = camera_set_bus_param, - /* The rest of host operations are optional */ -}; - -.add and .remove methods are called when a sensor is attached to or detached -from the host. .set_bus_param is used to configure physical connection -parameters between the host and the sensor. .init_videobuf2 is called by -soc-camera core when a video-device is opened, the host driver would typically -call vb2_queue_init() in this method. Further video-buffer management is -implemented completely by the specific camera host driver. If the host driver -supports non-standard pixel format conversion, it should implement a -.get_formats and, possibly, a .put_formats operations. See below for more -details about format conversion. The rest of the methods are called from -respective V4L2 operations. - -Camera API ----------- - -Sensor drivers can use struct soc_camera_link, typically provided by the -platform, and used to specify to which camera host bus the sensor is connected, -and optionally provide platform .power and .reset methods for the camera. This -struct is provided to the camera driver via the I2C client device platform data -and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be -taken, when using soc_camera_vdev_to_subdev() and when accessing struct -soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when -running on an soc-camera host. The actual camera driver operation is implemented -using the V4L2 subdev API. Additionally soc-camera camera drivers can use -auxiliary soc-camera helper functions like soc_camera_power_on() and -soc_camera_power_off(), which switch regulators, provided by the platform and call -board-specific power switching methods. soc_camera_apply_board_flags() takes -camera bus configuration capability flags and applies any board transformations, -e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a -pixel format descriptor, corresponding to a certain media-bus pixel format code. -soc_camera_limit_side() can be used to restrict beginning and length of a frame -side, based on camera capabilities. - -VIDIOC_S_CROP and VIDIOC_S_FMT behaviour ----------------------------------------- - -Above user ioctls modify image geometry as follows: - -VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor -pixel. Changing sensor window sizes preserves any scaling factors, therefore -user window sizes change as well. - -VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as -much as possible by modifying scaling factors. If the sensor window cannot be -preserved precisely, it may be changed too. - -In soc-camera there are two locations, where scaling and cropping can take -place: in the camera driver and in the host driver. User ioctls are first passed -to the host driver, which then generally passes them down to the camera driver. -It is more efficient to perform scaling and cropping in the camera driver to -save camera bus bandwidth and maximise the framerate. However, if the camera -driver failed to set the required parameters with sufficient precision, the host -driver may decide to also use its own scaling and cropping to fulfill the user's -request. - -Camera drivers are interfaced to the soc-camera core and to host drivers over -the v4l2-subdev API, which is completely functional, it doesn't pass any data. -Therefore all camera drivers shall reply to .g_fmt() requests with their current -output geometry. This is necessary to correctly configure the camera bus. -.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling -factors have to be maintained by camera drivers internally. According to the -V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we -rely on camera drivers implementing .cropcap(). If the camera driver does not -support cropping, it may choose to not implement .s_crop(), but to enable -cropping support by the camera host driver at least the .g_crop method must be -implemented. - -User window geometry is kept in .user_width and .user_height fields in struct -soc_camera_device and used by the soc-camera core and host drivers. The core -updates these fields upon successful completion of a .s_fmt() call, but if these -fields change elsewhere, e.g. during .s_crop() processing, the host driver is -responsible for updating them. - -Format conversion ------------------ - -V4L2 distinguishes between pixel formats, as they are stored in memory, and as -they are transferred over a media bus. Soc-camera provides support to -conveniently manage these formats. A table of standard transformations is -maintained by soc-camera core, which describes, what FOURCC pixel format will -be obtained, if a media-bus pixel format is stored in memory according to -certain rules. E.g. if MEDIA_BUS_FMT_YUYV8_2X8 data is sampled with 8 bits per -sample and stored in memory in the little-endian order with no gaps between -bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These -standard transformations will be used by soc-camera or by camera host drivers to -configure camera drivers to produce the FOURCC format, requested by the user, -using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions, -host drivers can also provide their own conversion rules by implementing a -.get_formats and, if required, a .put_formats methods. - --- -Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> diff --git a/Documentation/video4linux/uvcvideo.txt b/Documentation/video4linux/uvcvideo.txt deleted file mode 100644 index 35ce19cdd..000000000 --- a/Documentation/video4linux/uvcvideo.txt +++ /dev/null @@ -1,239 +0,0 @@ -Linux USB Video Class (UVC) driver -================================== - -This file documents some driver-specific aspects of the UVC driver, such as -driver-specific ioctls and implementation notes. - -Questions and remarks can be sent to the Linux UVC development mailing list at -linux-uvc-devel@lists.berlios.de. - - -Extension Unit (XU) support ---------------------------- - -1. Introduction - -The UVC specification allows for vendor-specific extensions through extension -units (XUs). The Linux UVC driver supports extension unit controls (XU controls) -through two separate mechanisms: - - - through mappings of XU controls to V4L2 controls - - through a driver-specific ioctl interface - -The first one allows generic V4L2 applications to use XU controls by mapping -certain XU controls onto V4L2 controls, which then show up during ordinary -control enumeration. - -The second mechanism requires uvcvideo-specific knowledge for the application to -access XU controls but exposes the entire UVC XU concept to user space for -maximum flexibility. - -Both mechanisms complement each other and are described in more detail below. - - -2. Control mappings - -The UVC driver provides an API for user space applications to define so-called -control mappings at runtime. These allow for individual XU controls or byte -ranges thereof to be mapped to new V4L2 controls. Such controls appear and -function exactly like normal V4L2 controls (i.e. the stock controls, such as -brightness, contrast, etc.). However, reading or writing of such a V4L2 controls -triggers a read or write of the associated XU control. - -The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP. -Previous driver versions (before 0.2.0) required another ioctl to be used -beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver. -This is no longer necessary as newer uvcvideo versions query the information -directly from the device. - -For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled -"IOCTL reference" below. - - -3. Driver specific XU control interface - -For applications that need to access XU controls directly, e.g. for testing -purposes, firmware upload, or accessing binary controls, a second mechanism to -access XU controls is provided in the form of a driver-specific ioctl, namely -UVCIOC_CTRL_QUERY. - -A call to this ioctl allows applications to send queries to the UVC driver that -directly map to the low-level UVC control requests. - -In order to make such a request the UVC unit ID of the control's extension unit -and the control selector need to be known. This information either needs to be -hardcoded in the application or queried using other ways such as by parsing the -UVC descriptor or, if available, using the media controller API to enumerate a -device's entities. - -Unless the control size is already known it is necessary to first make a -UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer -and set the buffer size to the correct value. Similarly, to find out whether -UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a -UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET -supported) of the resulting byte indicate which requests are valid. - -With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and -UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a -subset of the former ioctl. For the time being they are still supported but -application developers are encouraged to use UVCIOC_CTRL_QUERY instead. - -For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled -"IOCTL reference" below. - - -4. Security - -The API doesn't currently provide a fine-grained access control facility. The -UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions. - -Suggestions on how to improve this are welcome. - - -5. Debugging - -In order to debug problems related to XU controls or controls in general it is -recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'. -This causes extra output to be written into the system log. - - -6. IOCTL reference - ----- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ---- - -Argument: struct uvc_xu_control_mapping - -Description: - This ioctl creates a mapping between a UVC control or part of a UVC - control and a V4L2 control. Once mappings are defined, userspace - applications can access vendor-defined UVC control through the V4L2 - control API. - - To create a mapping, applications fill the uvc_xu_control_mapping - structure with information about an existing UVC control defined with - UVCIOC_CTRL_ADD and a new V4L2 control. - - A UVC control can be mapped to several V4L2 controls. For instance, - a UVC pan/tilt control could be mapped to separate pan and tilt V4L2 - controls. The UVC control is divided into non overlapping fields using - the 'size' and 'offset' fields and are then independently mapped to - V4L2 control. - - For signed integer V4L2 controls the data_type field should be set to - UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored. - -Return value: - On success 0 is returned. On error -1 is returned and errno is set - appropriately. - - ENOMEM - Not enough memory to perform the operation. - EPERM - Insufficient privileges (super user privileges are required). - EINVAL - No such UVC control. - EOVERFLOW - The requested offset and size would overflow the UVC control. - EEXIST - Mapping already exists. - -Data types: - * struct uvc_xu_control_mapping - - __u32 id V4L2 control identifier - __u8 name[32] V4L2 control name - __u8 entity[16] UVC extension unit GUID - __u8 selector UVC control selector - __u8 size V4L2 control size (in bits) - __u8 offset V4L2 control offset (in bits) - enum v4l2_ctrl_type - v4l2_type V4L2 control type - enum uvc_control_data_type - data_type UVC control data type - struct uvc_menu_info - *menu_info Array of menu entries (for menu controls only) - __u32 menu_count Number of menu entries (for menu controls only) - - * struct uvc_menu_info - - __u32 value Menu entry value used by the device - __u8 name[32] Menu entry name - - - * enum uvc_control_data_type - - UVC_CTRL_DATA_TYPE_RAW Raw control (byte array) - UVC_CTRL_DATA_TYPE_SIGNED Signed integer - UVC_CTRL_DATA_TYPE_UNSIGNED Unsigned integer - UVC_CTRL_DATA_TYPE_BOOLEAN Boolean - UVC_CTRL_DATA_TYPE_ENUM Enumeration - UVC_CTRL_DATA_TYPE_BITMASK Bitmask - - ----- UVCIOC_CTRL_QUERY - Query a UVC XU control ---- - -Argument: struct uvc_xu_control_query - -Description: - This ioctl queries a UVC XU control identified by its extension unit ID - and control selector. - - There are a number of different queries available that closely - correspond to the low-level control requests described in the UVC - specification. These requests are: - - UVC_GET_CUR - Obtain the current value of the control. - UVC_GET_MIN - Obtain the minimum value of the control. - UVC_GET_MAX - Obtain the maximum value of the control. - UVC_GET_DEF - Obtain the default value of the control. - UVC_GET_RES - Query the resolution of the control, i.e. the step size of the - allowed control values. - UVC_GET_LEN - Query the size of the control in bytes. - UVC_GET_INFO - Query the control information bitmap, which indicates whether - get/set requests are supported. - UVC_SET_CUR - Update the value of the control. - - Applications must set the 'size' field to the correct length for the - control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for - which the size must be set to 2 and 1, respectively. The 'data' field - must point to a valid writable buffer big enough to hold the indicated - number of data bytes. - - Data is copied directly from the device without any driver-side - processing. Applications are responsible for data buffer formatting, - including little-endian/big-endian conversion. This is particularly - important for the result of the UVC_GET_LEN requests, which is always - returned as a little-endian 16-bit integer by the device. - -Return value: - On success 0 is returned. On error -1 is returned and errno is set - appropriately. - - ENOENT - The device does not support the given control or the specified - extension unit could not be found. - ENOBUFS - The specified buffer size is incorrect (too big or too small). - EINVAL - An invalid request code was passed. - EBADRQC - The given request is not supported by the given control. - EFAULT - The data pointer references an inaccessible memory area. - -Data types: - * struct uvc_xu_control_query - - __u8 unit Extension unit ID - __u8 selector Control selector - __u8 query Request code to send to the device - __u16 size Control data size (in bytes) - __u8 *data Control value diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt deleted file mode 100644 index 5e759cab4..000000000 --- a/Documentation/video4linux/v4l2-controls.txt +++ /dev/null @@ -1,751 +0,0 @@ -Introduction -============ - -The V4L2 control API seems simple enough, but quickly becomes very hard to -implement correctly in drivers. But much of the code needed to handle controls -is actually not driver specific and can be moved to the V4L core framework. - -After all, the only part that a driver developer is interested in is: - -1) How do I add a control? -2) How do I set the control's value? (i.e. s_ctrl) - -And occasionally: - -3) How do I get the control's value? (i.e. g_volatile_ctrl) -4) How do I validate the user's proposed control value? (i.e. try_ctrl) - -All the rest is something that can be done centrally. - -The control framework was created in order to implement all the rules of the -V4L2 specification with respect to controls in a central place. And to make -life as easy as possible for the driver developer. - -Note that the control framework relies on the presence of a struct v4l2_device -for V4L2 drivers and struct v4l2_subdev for sub-device drivers. - - -Objects in the framework -======================== - -There are two main objects: - -The v4l2_ctrl object describes the control properties and keeps track of the -control's value (both the current value and the proposed new value). - -v4l2_ctrl_handler is the object that keeps track of controls. It maintains a -list of v4l2_ctrl objects that it owns and another list of references to -controls, possibly to controls owned by other handlers. - - -Basic usage for V4L2 and sub-device drivers -=========================================== - -1) Prepare the driver: - -1.1) Add the handler to your driver's top-level struct: - - struct foo_dev { - ... - struct v4l2_ctrl_handler ctrl_handler; - ... - }; - - struct foo_dev *foo; - -1.2) Initialize the handler: - - v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls); - - The second argument is a hint telling the function how many controls this - handler is expected to handle. It will allocate a hashtable based on this - information. It is a hint only. - -1.3) Hook the control handler into the driver: - -1.3.1) For V4L2 drivers do this: - - struct foo_dev { - ... - struct v4l2_device v4l2_dev; - ... - struct v4l2_ctrl_handler ctrl_handler; - ... - }; - - foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler; - - Where foo->v4l2_dev is of type struct v4l2_device. - - Finally, remove all control functions from your v4l2_ioctl_ops (if any): - vidioc_queryctrl, vidioc_query_ext_ctrl, vidioc_querymenu, vidioc_g_ctrl, - vidioc_s_ctrl, vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls. - Those are now no longer needed. - -1.3.2) For sub-device drivers do this: - - struct foo_dev { - ... - struct v4l2_subdev sd; - ... - struct v4l2_ctrl_handler ctrl_handler; - ... - }; - - foo->sd.ctrl_handler = &foo->ctrl_handler; - - Where foo->sd is of type struct v4l2_subdev. - - And set all core control ops in your struct v4l2_subdev_core_ops to these - helpers: - - .queryctrl = v4l2_subdev_queryctrl, - .querymenu = v4l2_subdev_querymenu, - .g_ctrl = v4l2_subdev_g_ctrl, - .s_ctrl = v4l2_subdev_s_ctrl, - .g_ext_ctrls = v4l2_subdev_g_ext_ctrls, - .try_ext_ctrls = v4l2_subdev_try_ext_ctrls, - .s_ext_ctrls = v4l2_subdev_s_ext_ctrls, - - Note: this is a temporary solution only. Once all V4L2 drivers that depend - on subdev drivers are converted to the control framework these helpers will - no longer be needed. - -1.4) Clean up the handler at the end: - - v4l2_ctrl_handler_free(&foo->ctrl_handler); - - -2) Add controls: - -You add non-menu controls by calling v4l2_ctrl_new_std: - - struct v4l2_ctrl *v4l2_ctrl_new_std(struct v4l2_ctrl_handler *hdl, - const struct v4l2_ctrl_ops *ops, - u32 id, s32 min, s32 max, u32 step, s32 def); - -Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu: - - struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, - const struct v4l2_ctrl_ops *ops, - u32 id, s32 max, s32 skip_mask, s32 def); - -Menu controls with a driver specific menu are added by calling -v4l2_ctrl_new_std_menu_items: - - struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items( - struct v4l2_ctrl_handler *hdl, - const struct v4l2_ctrl_ops *ops, u32 id, s32 max, - s32 skip_mask, s32 def, const char * const *qmenu); - -Integer menu controls with a driver specific menu can be added by calling -v4l2_ctrl_new_int_menu: - - struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl, - const struct v4l2_ctrl_ops *ops, - u32 id, s32 max, s32 def, const s64 *qmenu_int); - -These functions are typically called right after the v4l2_ctrl_handler_init: - - static const s64 exp_bias_qmenu[] = { - -2, -1, 0, 1, 2 - }; - static const char * const test_pattern[] = { - "Disabled", - "Vertical Bars", - "Solid Black", - "Solid White", - }; - - v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls); - v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops, - V4L2_CID_BRIGHTNESS, 0, 255, 1, 128); - v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops, - V4L2_CID_CONTRAST, 0, 255, 1, 128); - v4l2_ctrl_new_std_menu(&foo->ctrl_handler, &foo_ctrl_ops, - V4L2_CID_POWER_LINE_FREQUENCY, - V4L2_CID_POWER_LINE_FREQUENCY_60HZ, 0, - V4L2_CID_POWER_LINE_FREQUENCY_DISABLED); - v4l2_ctrl_new_int_menu(&foo->ctrl_handler, &foo_ctrl_ops, - V4L2_CID_EXPOSURE_BIAS, - ARRAY_SIZE(exp_bias_qmenu) - 1, - ARRAY_SIZE(exp_bias_qmenu) / 2 - 1, - exp_bias_qmenu); - v4l2_ctrl_new_std_menu_items(&foo->ctrl_handler, &foo_ctrl_ops, - V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0, - 0, test_pattern); - ... - if (foo->ctrl_handler.error) { - int err = foo->ctrl_handler.error; - - v4l2_ctrl_handler_free(&foo->ctrl_handler); - return err; - } - -The v4l2_ctrl_new_std function returns the v4l2_ctrl pointer to the new -control, but if you do not need to access the pointer outside the control ops, -then there is no need to store it. - -The v4l2_ctrl_new_std function will fill in most fields based on the control -ID except for the min, max, step and default values. These are passed in the -last four arguments. These values are driver specific while control attributes -like type, name, flags are all global. The control's current value will be set -to the default value. - -The v4l2_ctrl_new_std_menu function is very similar but it is used for menu -controls. There is no min argument since that is always 0 for menu controls, -and instead of a step there is a skip_mask argument: if bit X is 1, then menu -item X is skipped. - -The v4l2_ctrl_new_int_menu function creates a new standard integer menu -control with driver-specific items in the menu. It differs from -v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes -as the last argument an array of signed 64-bit integers that form an exact -menu item list. - -The v4l2_ctrl_new_std_menu_items function is very similar to -v4l2_ctrl_new_std_menu but takes an extra parameter qmenu, which is the driver -specific menu for an otherwise standard menu control. A good example for this -control is the test pattern control for capture/display/sensors devices that -have the capability to generate test patterns. These test patterns are hardware -specific, so the contents of the menu will vary from device to device. - -Note that if something fails, the function will return NULL or an error and -set ctrl_handler->error to the error code. If ctrl_handler->error was already -set, then it will just return and do nothing. This is also true for -v4l2_ctrl_handler_init if it cannot allocate the internal data structure. - -This makes it easy to init the handler and just add all controls and only check -the error code at the end. Saves a lot of repetitive error checking. - -It is recommended to add controls in ascending control ID order: it will be -a bit faster that way. - -3) Optionally force initial control setup: - - v4l2_ctrl_handler_setup(&foo->ctrl_handler); - -This will call s_ctrl for all controls unconditionally. Effectively this -initializes the hardware to the default control values. It is recommended -that you do this as this ensures that both the internal data structures and -the hardware are in sync. - -4) Finally: implement the v4l2_ctrl_ops - - static const struct v4l2_ctrl_ops foo_ctrl_ops = { - .s_ctrl = foo_s_ctrl, - }; - -Usually all you need is s_ctrl: - - static int foo_s_ctrl(struct v4l2_ctrl *ctrl) - { - struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler); - - switch (ctrl->id) { - case V4L2_CID_BRIGHTNESS: - write_reg(0x123, ctrl->val); - break; - case V4L2_CID_CONTRAST: - write_reg(0x456, ctrl->val); - break; - } - return 0; - } - -The control ops are called with the v4l2_ctrl pointer as argument. -The new control value has already been validated, so all you need to do is -to actually update the hardware registers. - -You're done! And this is sufficient for most of the drivers we have. No need -to do any validation of control values, or implement QUERYCTRL, QUERY_EXT_CTRL -and QUERYMENU. And G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically supported. - - -============================================================================== - -The remainder of this document deals with more advanced topics and scenarios. -In practice the basic usage as described above is sufficient for most drivers. - -=============================================================================== - - -Inheriting Controls -=================== - -When a sub-device is registered with a V4L2 driver by calling -v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev -and v4l2_device are set, then the controls of the subdev will become -automatically available in the V4L2 driver as well. If the subdev driver -contains controls that already exist in the V4L2 driver, then those will be -skipped (so a V4L2 driver can always override a subdev control). - -What happens here is that v4l2_device_register_subdev() calls -v4l2_ctrl_add_handler() adding the controls of the subdev to the controls -of v4l2_device. - - -Accessing Control Values -======================== - -The following union is used inside the control framework to access control -values: - -union v4l2_ctrl_ptr { - s32 *p_s32; - s64 *p_s64; - char *p_char; - void *p; -}; - -The v4l2_ctrl struct contains these fields that can be used to access both -current and new values: - - s32 val; - struct { - s32 val; - } cur; - - - union v4l2_ctrl_ptr p_new; - union v4l2_ctrl_ptr p_cur; - -If the control has a simple s32 type type, then: - - &ctrl->val == ctrl->p_new.p_s32 - &ctrl->cur.val == ctrl->p_cur.p_s32 - -For all other types use ctrl->p_cur.p<something>. Basically the val -and cur.val fields can be considered an alias since these are used so often. - -Within the control ops you can freely use these. The val and cur.val speak for -themselves. The p_char pointers point to character buffers of length -ctrl->maximum + 1, and are always 0-terminated. - -Unless the control is marked volatile the p_cur field points to the the -current cached control value. When you create a new control this value is made -identical to the default value. After calling v4l2_ctrl_handler_setup() this -value is passed to the hardware. It is generally a good idea to call this -function. - -Whenever a new value is set that new value is automatically cached. This means -that most drivers do not need to implement the g_volatile_ctrl() op. The -exception is for controls that return a volatile register such as a signal -strength read-out that changes continuously. In that case you will need to -implement g_volatile_ctrl like this: - - static int foo_g_volatile_ctrl(struct v4l2_ctrl *ctrl) - { - switch (ctrl->id) { - case V4L2_CID_BRIGHTNESS: - ctrl->val = read_reg(0x123); - break; - } - } - -Note that you use the 'new value' union as well in g_volatile_ctrl. In general -controls that need to implement g_volatile_ctrl are read-only controls. If they -are not, a V4L2_EVENT_CTRL_CH_VALUE will not be generated when the control -changes. - -To mark a control as volatile you have to set V4L2_CTRL_FLAG_VOLATILE: - - ctrl = v4l2_ctrl_new_std(&sd->ctrl_handler, ...); - if (ctrl) - ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE; - -For try/s_ctrl the new values (i.e. as passed by the user) are filled in and -you can modify them in try_ctrl or set them in s_ctrl. The 'cur' union -contains the current value, which you can use (but not change!) as well. - -If s_ctrl returns 0 (OK), then the control framework will copy the new final -values to the 'cur' union. - -While in g_volatile/s/try_ctrl you can access the value of all controls owned -by the same handler since the handler's lock is held. If you need to access -the value of controls owned by other handlers, then you have to be very careful -not to introduce deadlocks. - -Outside of the control ops you have to go through to helper functions to get -or set a single control value safely in your driver: - - s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl); - int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val); - -These functions go through the control framework just as VIDIOC_G/S_CTRL ioctls -do. Don't use these inside the control ops g_volatile/s/try_ctrl, though, that -will result in a deadlock since these helpers lock the handler as well. - -You can also take the handler lock yourself: - - mutex_lock(&state->ctrl_handler.lock); - pr_info("String value is '%s'\n", ctrl1->p_cur.p_char); - pr_info("Integer value is '%s'\n", ctrl2->cur.val); - mutex_unlock(&state->ctrl_handler.lock); - - -Menu Controls -============= - -The v4l2_ctrl struct contains this union: - - union { - u32 step; - u32 menu_skip_mask; - }; - -For menu controls menu_skip_mask is used. What it does is that it allows you -to easily exclude certain menu items. This is used in the VIDIOC_QUERYMENU -implementation where you can return -EINVAL if a certain menu item is not -present. Note that VIDIOC_QUERYCTRL always returns a step value of 1 for -menu controls. - -A good example is the MPEG Audio Layer II Bitrate menu control where the -menu is a list of standardized possible bitrates. But in practice hardware -implementations will only support a subset of those. By setting the skip -mask you can tell the framework which menu items should be skipped. Setting -it to 0 means that all menu items are supported. - -You set this mask either through the v4l2_ctrl_config struct for a custom -control, or by calling v4l2_ctrl_new_std_menu(). - - -Custom Controls -=============== - -Driver specific controls can be created using v4l2_ctrl_new_custom(): - - static const struct v4l2_ctrl_config ctrl_filter = { - .ops = &ctrl_custom_ops, - .id = V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER, - .name = "Spatial Filter", - .type = V4L2_CTRL_TYPE_INTEGER, - .flags = V4L2_CTRL_FLAG_SLIDER, - .max = 15, - .step = 1, - }; - - ctrl = v4l2_ctrl_new_custom(&foo->ctrl_handler, &ctrl_filter, NULL); - -The last argument is the priv pointer which can be set to driver-specific -private data. - -The v4l2_ctrl_config struct also has a field to set the is_private flag. - -If the name field is not set, then the framework will assume this is a standard -control and will fill in the name, type and flags fields accordingly. - - -Active and Grabbed Controls -=========================== - -If you get more complex relationships between controls, then you may have to -activate and deactivate controls. For example, if the Chroma AGC control is -on, then the Chroma Gain control is inactive. That is, you may set it, but -the value will not be used by the hardware as long as the automatic gain -control is on. Typically user interfaces can disable such input fields. - -You can set the 'active' status using v4l2_ctrl_activate(). By default all -controls are active. Note that the framework does not check for this flag. -It is meant purely for GUIs. The function is typically called from within -s_ctrl. - -The other flag is the 'grabbed' flag. A grabbed control means that you cannot -change it because it is in use by some resource. Typical examples are MPEG -bitrate controls that cannot be changed while capturing is in progress. - -If a control is set to 'grabbed' using v4l2_ctrl_grab(), then the framework -will return -EBUSY if an attempt is made to set this control. The -v4l2_ctrl_grab() function is typically called from the driver when it -starts or stops streaming. - - -Control Clusters -================ - -By default all controls are independent from the others. But in more -complex scenarios you can get dependencies from one control to another. -In that case you need to 'cluster' them: - - struct foo { - struct v4l2_ctrl_handler ctrl_handler; -#define AUDIO_CL_VOLUME (0) -#define AUDIO_CL_MUTE (1) - struct v4l2_ctrl *audio_cluster[2]; - ... - }; - - state->audio_cluster[AUDIO_CL_VOLUME] = - v4l2_ctrl_new_std(&state->ctrl_handler, ...); - state->audio_cluster[AUDIO_CL_MUTE] = - v4l2_ctrl_new_std(&state->ctrl_handler, ...); - v4l2_ctrl_cluster(ARRAY_SIZE(state->audio_cluster), state->audio_cluster); - -From now on whenever one or more of the controls belonging to the same -cluster is set (or 'gotten', or 'tried'), only the control ops of the first -control ('volume' in this example) is called. You effectively create a new -composite control. Similar to how a 'struct' works in C. - -So when s_ctrl is called with V4L2_CID_AUDIO_VOLUME as argument, you should set -all two controls belonging to the audio_cluster: - - static int foo_s_ctrl(struct v4l2_ctrl *ctrl) - { - struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler); - - switch (ctrl->id) { - case V4L2_CID_AUDIO_VOLUME: { - struct v4l2_ctrl *mute = ctrl->cluster[AUDIO_CL_MUTE]; - - write_reg(0x123, mute->val ? 0 : ctrl->val); - break; - } - case V4L2_CID_CONTRAST: - write_reg(0x456, ctrl->val); - break; - } - return 0; - } - -In the example above the following are equivalent for the VOLUME case: - - ctrl == ctrl->cluster[AUDIO_CL_VOLUME] == state->audio_cluster[AUDIO_CL_VOLUME] - ctrl->cluster[AUDIO_CL_MUTE] == state->audio_cluster[AUDIO_CL_MUTE] - -In practice using cluster arrays like this becomes very tiresome. So instead -the following equivalent method is used: - - struct { - /* audio cluster */ - struct v4l2_ctrl *volume; - struct v4l2_ctrl *mute; - }; - -The anonymous struct is used to clearly 'cluster' these two control pointers, -but it serves no other purpose. The effect is the same as creating an -array with two control pointers. So you can just do: - - state->volume = v4l2_ctrl_new_std(&state->ctrl_handler, ...); - state->mute = v4l2_ctrl_new_std(&state->ctrl_handler, ...); - v4l2_ctrl_cluster(2, &state->volume); - -And in foo_s_ctrl you can use these pointers directly: state->mute->val. - -Note that controls in a cluster may be NULL. For example, if for some -reason mute was never added (because the hardware doesn't support that -particular feature), then mute will be NULL. So in that case we have a -cluster of 2 controls, of which only 1 is actually instantiated. The -only restriction is that the first control of the cluster must always be -present, since that is the 'master' control of the cluster. The master -control is the one that identifies the cluster and that provides the -pointer to the v4l2_ctrl_ops struct that is used for that cluster. - -Obviously, all controls in the cluster array must be initialized to either -a valid control or to NULL. - -In rare cases you might want to know which controls of a cluster actually -were set explicitly by the user. For this you can check the 'is_new' flag of -each control. For example, in the case of a volume/mute cluster the 'is_new' -flag of the mute control would be set if the user called VIDIOC_S_CTRL for -mute only. If the user would call VIDIOC_S_EXT_CTRLS for both mute and volume -controls, then the 'is_new' flag would be 1 for both controls. - -The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup(). - - -Handling autogain/gain-type Controls with Auto Clusters -======================================================= - -A common type of control cluster is one that handles 'auto-foo/foo'-type -controls. Typical examples are autogain/gain, autoexposure/exposure, -autowhitebalance/red balance/blue balance. In all cases you have one control -that determines whether another control is handled automatically by the hardware, -or whether it is under manual control from the user. - -If the cluster is in automatic mode, then the manual controls should be -marked inactive and volatile. When the volatile controls are read the -g_volatile_ctrl operation should return the value that the hardware's automatic -mode set up automatically. - -If the cluster is put in manual mode, then the manual controls should become -active again and the volatile flag is cleared (so g_volatile_ctrl is no longer -called while in manual mode). In addition just before switching to manual mode -the current values as determined by the auto mode are copied as the new manual -values. - -Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since -changing that control affects the control flags of the manual controls. - -In order to simplify this a special variation of v4l2_ctrl_cluster was -introduced: - -void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls, - u8 manual_val, bool set_volatile); - -The first two arguments are identical to v4l2_ctrl_cluster. The third argument -tells the framework which value switches the cluster into manual mode. The -last argument will optionally set V4L2_CTRL_FLAG_VOLATILE for the non-auto controls. -If it is false, then the manual controls are never volatile. You would typically -use that if the hardware does not give you the option to read back to values as -determined by the auto mode (e.g. if autogain is on, the hardware doesn't allow -you to obtain the current gain value). - -The first control of the cluster is assumed to be the 'auto' control. - -Using this function will ensure that you don't need to handle all the complex -flag and volatile handling. - - -VIDIOC_LOG_STATUS Support -========================= - -This ioctl allow you to dump the current status of a driver to the kernel log. -The v4l2_ctrl_handler_log_status(ctrl_handler, prefix) can be used to dump the -value of the controls owned by the given handler to the log. You can supply a -prefix as well. If the prefix didn't end with a space, then ': ' will be added -for you. - - -Different Handlers for Different Video Nodes -============================================ - -Usually the V4L2 driver has just one control handler that is global for -all video nodes. But you can also specify different control handlers for -different video nodes. You can do that by manually setting the ctrl_handler -field of struct video_device. - -That is no problem if there are no subdevs involved but if there are, then -you need to block the automatic merging of subdev controls to the global -control handler. You do that by simply setting the ctrl_handler field in -struct v4l2_device to NULL. Now v4l2_device_register_subdev() will no longer -merge subdev controls. - -After each subdev was added, you will then have to call v4l2_ctrl_add_handler -manually to add the subdev's control handler (sd->ctrl_handler) to the desired -control handler. This control handler may be specific to the video_device or -for a subset of video_device's. For example: the radio device nodes only have -audio controls, while the video and vbi device nodes share the same control -handler for the audio and video controls. - -If you want to have one handler (e.g. for a radio device node) have a subset -of another handler (e.g. for a video device node), then you should first add -the controls to the first handler, add the other controls to the second -handler and finally add the first handler to the second. For example: - - v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_VOLUME, ...); - v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...); - v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...); - v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...); - v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler, NULL); - -The last argument to v4l2_ctrl_add_handler() is a filter function that allows -you to filter which controls will be added. Set it to NULL if you want to add -all controls. - -Or you can add specific controls to a handler: - - volume = v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_AUDIO_VOLUME, ...); - v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_BRIGHTNESS, ...); - v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_CONTRAST, ...); - -What you should not do is make two identical controls for two handlers. -For example: - - v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...); - v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_AUDIO_MUTE, ...); - -This would be bad since muting the radio would not change the video mute -control. The rule is to have one control for each hardware 'knob' that you -can twiddle. - - -Finding Controls -================ - -Normally you have created the controls yourself and you can store the struct -v4l2_ctrl pointer into your own struct. - -But sometimes you need to find a control from another handler that you do -not own. For example, if you have to find a volume control from a subdev. - -You can do that by calling v4l2_ctrl_find: - - struct v4l2_ctrl *volume; - - volume = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_AUDIO_VOLUME); - -Since v4l2_ctrl_find will lock the handler you have to be careful where you -use it. For example, this is not a good idea: - - struct v4l2_ctrl_handler ctrl_handler; - - v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...); - v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...); - -...and in video_ops.s_ctrl: - - case V4L2_CID_BRIGHTNESS: - contrast = v4l2_find_ctrl(&ctrl_handler, V4L2_CID_CONTRAST); - ... - -When s_ctrl is called by the framework the ctrl_handler.lock is already taken, so -attempting to find another control from the same handler will deadlock. - -It is recommended not to use this function from inside the control ops. - - -Inheriting Controls -=================== - -When one control handler is added to another using v4l2_ctrl_add_handler, then -by default all controls from one are merged to the other. But a subdev might -have low-level controls that make sense for some advanced embedded system, but -not when it is used in consumer-level hardware. In that case you want to keep -those low-level controls local to the subdev. You can do this by simply -setting the 'is_private' flag of the control to 1: - - static const struct v4l2_ctrl_config ctrl_private = { - .ops = &ctrl_custom_ops, - .id = V4L2_CID_..., - .name = "Some Private Control", - .type = V4L2_CTRL_TYPE_INTEGER, - .max = 15, - .step = 1, - .is_private = 1, - }; - - ctrl = v4l2_ctrl_new_custom(&foo->ctrl_handler, &ctrl_private, NULL); - -These controls will now be skipped when v4l2_ctrl_add_handler is called. - - -V4L2_CTRL_TYPE_CTRL_CLASS Controls -================================== - -Controls of this type can be used by GUIs to get the name of the control class. -A fully featured GUI can make a dialog with multiple tabs with each tab -containing the controls belonging to a particular control class. The name of -each tab can be found by querying a special control with ID <control class | 1>. - -Drivers do not have to care about this. The framework will automatically add -a control of this type whenever the first control belonging to a new control -class is added. - - -Adding Notify Callbacks -======================= - -Sometimes the platform or bridge driver needs to be notified when a control -from a sub-device driver changes. You can set a notify callback by calling -this function: - -void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, - void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv); - -Whenever the give control changes value the notify callback will be called -with a pointer to the control and the priv pointer that was passed with -v4l2_ctrl_notify. Note that the control's handler lock is held when the -notify function is called. - -There can be only one notify function per control handler. Any attempt -to set another notify function will cause a WARN_ON. diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt deleted file mode 100644 index cbefc7902..000000000 --- a/Documentation/video4linux/v4l2-framework.txt +++ /dev/null @@ -1,1160 +0,0 @@ -Overview of the V4L2 driver framework -===================================== - -This text documents the various structures provided by the V4L2 framework and -their relationships. - - -Introduction ------------- - -The V4L2 drivers tend to be very complex due to the complexity of the -hardware: most devices have multiple ICs, export multiple device nodes in -/dev, and create also non-V4L2 devices such as DVB, ALSA, FB, I2C and input -(IR) devices. - -Especially the fact that V4L2 drivers have to setup supporting ICs to -do audio/video muxing/encoding/decoding makes it more complex than most. -Usually these ICs are connected to the main bridge driver through one or -more I2C busses, but other busses can also be used. Such devices are -called 'sub-devices'. - -For a long time the framework was limited to the video_device struct for -creating V4L device nodes and video_buf for handling the video buffers -(note that this document does not discuss the video_buf framework). - -This meant that all drivers had to do the setup of device instances and -connecting to sub-devices themselves. Some of this is quite complicated -to do right and many drivers never did do it correctly. - -There is also a lot of common code that could never be refactored due to -the lack of a framework. - -So this framework sets up the basic building blocks that all drivers -need and this same framework should make it much easier to refactor -common code into utility functions shared by all drivers. - -A good example to look at as a reference is the v4l2-pci-skeleton.c -source that is available in samples/v4l/. It is a skeleton driver for -a PCI capture card, and demonstrates how to use the V4L2 driver -framework. It can be used as a template for real PCI video capture driver. - -Structure of a driver ---------------------- - -All drivers have the following structure: - -1) A struct for each device instance containing the device state. - -2) A way of initializing and commanding sub-devices (if any). - -3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX) - and keeping track of device-node specific data. - -4) Filehandle-specific structs containing per-filehandle data; - -5) video buffer handling. - -This is a rough schematic of how it all relates: - - device instances - | - +-sub-device instances - | - \-V4L2 device nodes - | - \-filehandle instances - - -Structure of the framework --------------------------- - -The framework closely resembles the driver structure: it has a v4l2_device -struct for the device instance data, a v4l2_subdev struct to refer to -sub-device instances, the video_device struct stores V4L2 device node data -and the v4l2_fh struct keeps track of filehandle instances. - -The V4L2 framework also optionally integrates with the media framework. If a -driver sets the struct v4l2_device mdev field, sub-devices and video nodes -will automatically appear in the media framework as entities. - - -struct v4l2_device ------------------- - -Each device instance is represented by a struct v4l2_device (v4l2-device.h). -Very simple devices can just allocate this struct, but most of the time you -would embed this struct inside a larger struct. - -You must register the device instance: - - v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); - -Registration will initialize the v4l2_device struct. If the dev->driver_data -field is NULL, it will be linked to v4l2_dev. - -Drivers that want integration with the media device framework need to set -dev->driver_data manually to point to the driver-specific device structure -that embed the struct v4l2_device instance. This is achieved by a -dev_set_drvdata() call before registering the V4L2 device instance. They must -also set the struct v4l2_device mdev field to point to a properly initialized -and registered media_device instance. - -If v4l2_dev->name is empty then it will be set to a value derived from dev -(driver name followed by the bus_id, to be precise). If you set it up before -calling v4l2_device_register then it will be untouched. If dev is NULL, then -you *must* setup v4l2_dev->name before calling v4l2_device_register. - -You can use v4l2_device_set_name() to set the name based on a driver name and -a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1, -etc. If the name ends with a digit, then it will insert a dash: cx18-0, -cx18-1, etc. This function returns the instance number. - -The first 'dev' argument is normally the struct device pointer of a pci_dev, -usb_interface or platform_device. It is rare for dev to be NULL, but it happens -with ISA devices or when one device creates multiple PCI devices, thus making -it impossible to associate v4l2_dev with a particular parent. - -You can also supply a notify() callback that can be called by sub-devices to -notify you of events. Whether you need to set this depends on the sub-device. -Any notifications a sub-device supports must be defined in a header in -include/media/<subdevice>.h. - -You unregister with: - - v4l2_device_unregister(struct v4l2_device *v4l2_dev); - -If the dev->driver_data field points to v4l2_dev, it will be reset to NULL. -Unregistering will also automatically unregister all subdevs from the device. - -If you have a hotpluggable device (e.g. a USB device), then when a disconnect -happens the parent device becomes invalid. Since v4l2_device has a pointer to -that parent device it has to be cleared as well to mark that the parent is -gone. To do this call: - - v4l2_device_disconnect(struct v4l2_device *v4l2_dev); - -This does *not* unregister the subdevs, so you still need to call the -v4l2_device_unregister() function for that. If your driver is not hotpluggable, -then there is no need to call v4l2_device_disconnect(). - -Sometimes you need to iterate over all devices registered by a specific -driver. This is usually the case if multiple device drivers use the same -hardware. E.g. the ivtvfb driver is a framebuffer driver that uses the ivtv -hardware. The same is true for alsa drivers for example. - -You can iterate over all registered devices as follows: - -static int callback(struct device *dev, void *p) -{ - struct v4l2_device *v4l2_dev = dev_get_drvdata(dev); - - /* test if this device was inited */ - if (v4l2_dev == NULL) - return 0; - ... - return 0; -} - -int iterate(void *p) -{ - struct device_driver *drv; - int err; - - /* Find driver 'ivtv' on the PCI bus. - pci_bus_type is a global. For USB busses use usb_bus_type. */ - drv = driver_find("ivtv", &pci_bus_type); - /* iterate over all ivtv device instances */ - err = driver_for_each_device(drv, NULL, p, callback); - put_driver(drv); - return err; -} - -Sometimes you need to keep a running counter of the device instance. This is -commonly used to map a device instance to an index of a module option array. - -The recommended approach is as follows: - -static atomic_t drv_instance = ATOMIC_INIT(0); - -static int drv_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id) -{ - ... - state->instance = atomic_inc_return(&drv_instance) - 1; -} - -If you have multiple device nodes then it can be difficult to know when it is -safe to unregister v4l2_device for hotpluggable devices. For this purpose -v4l2_device has refcounting support. The refcount is increased whenever -video_register_device is called and it is decreased whenever that device node -is released. When the refcount reaches zero, then the v4l2_device release() -callback is called. You can do your final cleanup there. - -If other device nodes (e.g. ALSA) are created, then you can increase and -decrease the refcount manually as well by calling: - -void v4l2_device_get(struct v4l2_device *v4l2_dev); - -or: - -int v4l2_device_put(struct v4l2_device *v4l2_dev); - -Since the initial refcount is 1 you also need to call v4l2_device_put in the -disconnect() callback (for USB devices) or in the remove() callback (for e.g. -PCI devices), otherwise the refcount will never reach 0. - -struct v4l2_subdev ------------------- - -Many drivers need to communicate with sub-devices. These devices can do all -sort of tasks, but most commonly they handle audio and/or video muxing, -encoding or decoding. For webcams common sub-devices are sensors and camera -controllers. - -Usually these are I2C devices, but not necessarily. In order to provide the -driver with a consistent interface to these sub-devices the v4l2_subdev struct -(v4l2-subdev.h) was created. - -Each sub-device driver must have a v4l2_subdev struct. This struct can be -stand-alone for simple sub-devices or it might be embedded in a larger struct -if more state information needs to be stored. Usually there is a low-level -device struct (e.g. i2c_client) that contains the device data as setup -by the kernel. It is recommended to store that pointer in the private -data of v4l2_subdev using v4l2_set_subdevdata(). That makes it easy to go -from a v4l2_subdev to the actual low-level bus-specific device data. - -You also need a way to go from the low-level struct to v4l2_subdev. For the -common i2c_client struct the i2c_set_clientdata() call is used to store a -v4l2_subdev pointer, for other busses you may have to use other methods. - -Bridges might also need to store per-subdev private data, such as a pointer to -bridge-specific per-subdev private data. The v4l2_subdev structure provides -host private data for that purpose that can be accessed with -v4l2_get_subdev_hostdata() and v4l2_set_subdev_hostdata(). - -From the bridge driver perspective you load the sub-device module and somehow -obtain the v4l2_subdev pointer. For i2c devices this is easy: you call -i2c_get_clientdata(). For other busses something similar needs to be done. -Helper functions exists for sub-devices on an I2C bus that do most of this -tricky work for you. - -Each v4l2_subdev contains function pointers that sub-device drivers can -implement (or leave NULL if it is not applicable). Since sub-devices can do -so many different things and you do not want to end up with a huge ops struct -of which only a handful of ops are commonly implemented, the function pointers -are sorted according to category and each category has its own ops struct. - -The top-level ops struct contains pointers to the category ops structs, which -may be NULL if the subdev driver does not support anything from that category. - -It looks like this: - -struct v4l2_subdev_core_ops { - int (*log_status)(struct v4l2_subdev *sd); - int (*init)(struct v4l2_subdev *sd, u32 val); - ... -}; - -struct v4l2_subdev_tuner_ops { - ... -}; - -struct v4l2_subdev_audio_ops { - ... -}; - -struct v4l2_subdev_video_ops { - ... -}; - -struct v4l2_subdev_pad_ops { - ... -}; - -struct v4l2_subdev_ops { - const struct v4l2_subdev_core_ops *core; - const struct v4l2_subdev_tuner_ops *tuner; - const struct v4l2_subdev_audio_ops *audio; - const struct v4l2_subdev_video_ops *video; - const struct v4l2_subdev_pad_ops *video; -}; - -The core ops are common to all subdevs, the other categories are implemented -depending on the sub-device. E.g. a video device is unlikely to support the -audio ops and vice versa. - -This setup limits the number of function pointers while still making it easy -to add new ops and categories. - -A sub-device driver initializes the v4l2_subdev struct using: - - v4l2_subdev_init(sd, &ops); - -Afterwards you need to initialize subdev->name with a unique name and set the -module owner. This is done for you if you use the i2c helper functions. - -If integration with the media framework is needed, you must initialize the -media_entity struct embedded in the v4l2_subdev struct (entity field) by -calling media_entity_pads_init(), if the entity has pads: - - struct media_pad *pads = &my_sd->pads; - int err; - - err = media_entity_pads_init(&sd->entity, npads, pads); - -The pads array must have been previously initialized. There is no need to -manually set the struct media_entity function and name fields, but the -revision field must be initialized if needed. - -A reference to the entity will be automatically acquired/released when the -subdev device node (if any) is opened/closed. - -Don't forget to cleanup the media entity before the sub-device is destroyed: - - media_entity_cleanup(&sd->entity); - -If the subdev driver intends to process video and integrate with the media -framework, it must implement format related functionality using -v4l2_subdev_pad_ops instead of v4l2_subdev_video_ops. - -In that case, the subdev driver may set the link_validate field to provide -its own link validation function. The link validation function is called for -every link in the pipeline where both of the ends of the links are V4L2 -sub-devices. The driver is still responsible for validating the correctness -of the format configuration between sub-devices and video nodes. - -If link_validate op is not set, the default function -v4l2_subdev_link_validate_default() is used instead. This function ensures -that width, height and the media bus pixel code are equal on both source and -sink of the link. Subdev drivers are also free to use this function to -perform the checks mentioned above in addition to their own checks. - -There are currently two ways to register subdevices with the V4L2 core. The -first (traditional) possibility is to have subdevices registered by bridge -drivers. This can be done when the bridge driver has the complete information -about subdevices connected to it and knows exactly when to register them. This -is typically the case for internal subdevices, like video data processing units -within SoCs or complex PCI(e) boards, camera sensors in USB cameras or connected -to SoCs, which pass information about them to bridge drivers, usually in their -platform data. - -There are however also situations where subdevices have to be registered -asynchronously to bridge devices. An example of such a configuration is a Device -Tree based system where information about subdevices is made available to the -system independently from the bridge devices, e.g. when subdevices are defined -in DT as I2C device nodes. The API used in this second case is described further -below. - -Using one or the other registration method only affects the probing process, the -run-time bridge-subdevice interaction is in both cases the same. - -In the synchronous case a device (bridge) driver needs to register the -v4l2_subdev with the v4l2_device: - - int err = v4l2_device_register_subdev(v4l2_dev, sd); - -This can fail if the subdev module disappeared before it could be registered. -After this function was called successfully the subdev->dev field points to -the v4l2_device. - -If the v4l2_device parent device has a non-NULL mdev field, the sub-device -entity will be automatically registered with the media device. - -You can unregister a sub-device using: - - v4l2_device_unregister_subdev(sd); - -Afterwards the subdev module can be unloaded and sd->dev == NULL. - -You can call an ops function either directly: - - err = sd->ops->core->g_std(sd, &norm); - -but it is better and easier to use this macro: - - err = v4l2_subdev_call(sd, core, g_std, &norm); - -The macro will to the right NULL pointer checks and returns -ENODEV if subdev -is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_std is -NULL, or the actual result of the subdev->ops->core->g_std ops. - -It is also possible to call all or a subset of the sub-devices: - - v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm); - -Any subdev that does not support this ops is skipped and error results are -ignored. If you want to check for errors use this: - - err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm); - -Any error except -ENOIOCTLCMD will exit the loop with that error. If no -errors (except -ENOIOCTLCMD) occurred, then 0 is returned. - -The second argument to both calls is a group ID. If 0, then all subdevs are -called. If non-zero, then only those whose group ID match that value will -be called. Before a bridge driver registers a subdev it can set sd->grp_id -to whatever value it wants (it's 0 by default). This value is owned by the -bridge driver and the sub-device driver will never modify or use it. - -The group ID gives the bridge driver more control how callbacks are called. -For example, there may be multiple audio chips on a board, each capable of -changing the volume. But usually only one will actually be used when the -user want to change the volume. You can set the group ID for that subdev to -e.g. AUDIO_CONTROLLER and specify that as the group ID value when calling -v4l2_device_call_all(). That ensures that it will only go to the subdev -that needs it. - -If the sub-device needs to notify its v4l2_device parent of an event, then -it can call v4l2_subdev_notify(sd, notification, arg). This macro checks -whether there is a notify() callback defined and returns -ENODEV if not. -Otherwise the result of the notify() call is returned. - -The advantage of using v4l2_subdev is that it is a generic struct and does -not contain any knowledge about the underlying hardware. So a driver might -contain several subdevs that use an I2C bus, but also a subdev that is -controlled through GPIO pins. This distinction is only relevant when setting -up the device, but once the subdev is registered it is completely transparent. - - -In the asynchronous case subdevice probing can be invoked independently of the -bridge driver availability. The subdevice driver then has to verify whether all -the requirements for a successful probing are satisfied. This can include a -check for a master clock availability. If any of the conditions aren't satisfied -the driver might decide to return -EPROBE_DEFER to request further reprobing -attempts. Once all conditions are met the subdevice shall be registered using -the v4l2_async_register_subdev() function. Unregistration is performed using -the v4l2_async_unregister_subdev() call. Subdevices registered this way are -stored in a global list of subdevices, ready to be picked up by bridge drivers. - -Bridge drivers in turn have to register a notifier object with an array of -subdevice descriptors that the bridge device needs for its operation. This is -performed using the v4l2_async_notifier_register() call. To unregister the -notifier the driver has to call v4l2_async_notifier_unregister(). The former of -the two functions takes two arguments: a pointer to struct v4l2_device and a -pointer to struct v4l2_async_notifier. The latter contains a pointer to an array -of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The -V4L2 core will then use these descriptors to match asynchronously registered -subdevices to them. If a match is detected the .bound() notifier callback is -called. After all subdevices have been located the .complete() callback is -called. When a subdevice is removed from the system the .unbind() method is -called. All three callbacks are optional. - - -V4L2 sub-device userspace API ------------------------------ - -Beside exposing a kernel API through the v4l2_subdev_ops structure, V4L2 -sub-devices can also be controlled directly by userspace applications. - -Device nodes named v4l-subdevX can be created in /dev to access sub-devices -directly. If a sub-device supports direct userspace configuration it must set -the V4L2_SUBDEV_FL_HAS_DEVNODE flag before being registered. - -After registering sub-devices, the v4l2_device driver can create device nodes -for all registered sub-devices marked with V4L2_SUBDEV_FL_HAS_DEVNODE by calling -v4l2_device_register_subdev_nodes(). Those device nodes will be automatically -removed when sub-devices are unregistered. - -The device node handles a subset of the V4L2 API. - -VIDIOC_QUERYCTRL -VIDIOC_QUERYMENU -VIDIOC_G_CTRL -VIDIOC_S_CTRL -VIDIOC_G_EXT_CTRLS -VIDIOC_S_EXT_CTRLS -VIDIOC_TRY_EXT_CTRLS - - The controls ioctls are identical to the ones defined in V4L2. They - behave identically, with the only exception that they deal only with - controls implemented in the sub-device. Depending on the driver, those - controls can be also be accessed through one (or several) V4L2 device - nodes. - -VIDIOC_DQEVENT -VIDIOC_SUBSCRIBE_EVENT -VIDIOC_UNSUBSCRIBE_EVENT - - The events ioctls are identical to the ones defined in V4L2. They - behave identically, with the only exception that they deal only with - events generated by the sub-device. Depending on the driver, those - events can also be reported by one (or several) V4L2 device nodes. - - Sub-device drivers that want to use events need to set the - V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize - v4l2_subdev::nevents to events queue depth before registering the - sub-device. After registration events can be queued as usual on the - v4l2_subdev::devnode device node. - - To properly support events, the poll() file operation is also - implemented. - -Private ioctls - - All ioctls not in the above list are passed directly to the sub-device - driver through the core::ioctl operation. - - -I2C sub-device drivers ----------------------- - -Since these drivers are so common, special helper functions are available to -ease the use of these drivers (v4l2-common.h). - -The recommended method of adding v4l2_subdev support to an I2C driver is to -embed the v4l2_subdev struct into the state struct that is created for each -I2C device instance. Very simple devices have no state struct and in that case -you can just create a v4l2_subdev directly. - -A typical state struct would look like this (where 'chipname' is replaced by -the name of the chip): - -struct chipname_state { - struct v4l2_subdev sd; - ... /* additional state fields */ -}; - -Initialize the v4l2_subdev struct as follows: - - v4l2_i2c_subdev_init(&state->sd, client, subdev_ops); - -This function will fill in all the fields of v4l2_subdev and ensure that the -v4l2_subdev and i2c_client both point to one another. - -You should also add a helper inline function to go from a v4l2_subdev pointer -to a chipname_state struct: - -static inline struct chipname_state *to_state(struct v4l2_subdev *sd) -{ - return container_of(sd, struct chipname_state, sd); -} - -Use this to go from the v4l2_subdev struct to the i2c_client struct: - - struct i2c_client *client = v4l2_get_subdevdata(sd); - -And this to go from an i2c_client to a v4l2_subdev struct: - - struct v4l2_subdev *sd = i2c_get_clientdata(client); - -Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback -is called. This will unregister the sub-device from the bridge driver. It is -safe to call this even if the sub-device was never registered. - -You need to do this because when the bridge driver destroys the i2c adapter -the remove() callbacks are called of the i2c devices on that adapter. -After that the corresponding v4l2_subdev structures are invalid, so they -have to be unregistered first. Calling v4l2_device_unregister_subdev(sd) -from the remove() callback ensures that this is always done correctly. - - -The bridge driver also has some helper functions it can use: - -struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, - "module_foo", "chipid", 0x36, NULL); - -This loads the given module (can be NULL if no module needs to be loaded) and -calls i2c_new_device() with the given i2c_adapter and chip/address arguments. -If all goes well, then it registers the subdev with the v4l2_device. - -You can also use the last argument of v4l2_i2c_new_subdev() to pass an array -of possible I2C addresses that it should probe. These probe addresses are -only used if the previous argument is 0. A non-zero argument means that you -know the exact i2c address so in that case no probing will take place. - -Both functions return NULL if something went wrong. - -Note that the chipid you pass to v4l2_i2c_new_subdev() is usually -the same as the module name. It allows you to specify a chip variant, e.g. -"saa7114" or "saa7115". In general though the i2c driver autodetects this. -The use of chipid is something that needs to be looked at more closely at a -later date. It differs between i2c drivers and as such can be confusing. -To see which chip variants are supported you can look in the i2c driver code -for the i2c_device_id table. This lists all the possibilities. - -There are two more helper functions: - -v4l2_i2c_new_subdev_cfg: this function adds new irq and platform_data -arguments and has both 'addr' and 'probed_addrs' arguments: if addr is not -0 then that will be used (non-probing variant), otherwise the probed_addrs -are probed. - -For example: this will probe for address 0x10: - -struct v4l2_subdev *sd = v4l2_i2c_new_subdev_cfg(v4l2_dev, adapter, - "module_foo", "chipid", 0, NULL, 0, I2C_ADDRS(0x10)); - -v4l2_i2c_new_subdev_board uses an i2c_board_info struct which is passed -to the i2c driver and replaces the irq, platform_data and addr arguments. - -If the subdev supports the s_config core ops, then that op is called with -the irq and platform_data arguments after the subdev was setup. The older -v4l2_i2c_new_(probed_)subdev functions will call s_config as well, but with -irq set to 0 and platform_data set to NULL. - -struct video_device -------------------- - -The actual device nodes in the /dev directory are created using the -video_device struct (v4l2-dev.h). This struct can either be allocated -dynamically or embedded in a larger struct. - -To allocate it dynamically use: - - struct video_device *vdev = video_device_alloc(); - - if (vdev == NULL) - return -ENOMEM; - - vdev->release = video_device_release; - -If you embed it in a larger struct, then you must set the release() -callback to your own function: - - struct video_device *vdev = &my_vdev->vdev; - - vdev->release = my_vdev_release; - -The release callback must be set and it is called when the last user -of the video device exits. - -The default video_device_release() callback just calls kfree to free the -allocated memory. - -There is also a video_device_release_empty() function that does nothing -(is empty) and can be used if the struct is embedded and there is nothing -to do when it is released. - -You should also set these fields: - -- v4l2_dev: must be set to the v4l2_device parent device. - -- name: set to something descriptive and unique. - -- vfl_dir: set this to VFL_DIR_RX for capture devices (VFL_DIR_RX has value 0, - so this is normally already the default), set to VFL_DIR_TX for output - devices and VFL_DIR_M2M for mem2mem (codec) devices. - -- fops: set to the v4l2_file_operations struct. - -- ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance - (highly recommended to use this and it might become compulsory in the - future!), then set this to your v4l2_ioctl_ops struct. The vfl_type and - vfl_dir fields are used to disable ops that do not match the type/dir - combination. E.g. VBI ops are disabled for non-VBI nodes, and output ops - are disabled for a capture device. This makes it possible to provide - just one v4l2_ioctl_ops struct for both vbi and video nodes. - -- lock: leave to NULL if you want to do all the locking in the driver. - Otherwise you give it a pointer to a struct mutex_lock and before the - unlocked_ioctl file operation is called this lock will be taken by the - core and released afterwards. See the next section for more details. - -- queue: a pointer to the struct vb2_queue associated with this device node. - If queue is non-NULL, and queue->lock is non-NULL, then queue->lock is - used for the queuing ioctls (VIDIOC_REQBUFS, CREATE_BUFS, QBUF, DQBUF, - QUERYBUF, PREPARE_BUF, STREAMON and STREAMOFF) instead of the lock above. - That way the vb2 queuing framework does not have to wait for other ioctls. - This queue pointer is also used by the vb2 helper functions to check for - queuing ownership (i.e. is the filehandle calling it allowed to do the - operation). - -- prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY. - If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device. - If you want to have a separate priority state per (group of) device node(s), - then you can point it to your own struct v4l2_prio_state. - -- dev_parent: you only set this if v4l2_device was registered with NULL as - the parent device struct. This only happens in cases where one hardware - device has multiple PCI devices that all share the same v4l2_device core. - - The cx88 driver is an example of this: one core v4l2_device struct, but - it is used by both a raw video PCI device (cx8800) and a MPEG PCI device - (cx8802). Since the v4l2_device cannot be associated with two PCI devices - at the same time it is setup without a parent device. But when the struct - video_device is initialized you *do* know which parent PCI device to use and - so you set dev_device to the correct PCI device. - -If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2 -in your v4l2_file_operations struct. - -Do not use .ioctl! This is deprecated and will go away in the future. - -In some cases you want to tell the core that a function you had specified in -your v4l2_ioctl_ops should be ignored. You can mark such ioctls by calling this -function before video_device_register is called: - -void v4l2_disable_ioctl(struct video_device *vdev, unsigned int cmd); - -This tends to be needed if based on external factors (e.g. which card is -being used) you want to turns off certain features in v4l2_ioctl_ops without -having to make a new struct. - -The v4l2_file_operations struct is a subset of file_operations. The main -difference is that the inode argument is omitted since it is never used. - -If integration with the media framework is needed, you must initialize the -media_entity struct embedded in the video_device struct (entity field) by -calling media_entity_pads_init(): - - struct media_pad *pad = &my_vdev->pad; - int err; - - err = media_entity_pads_init(&vdev->entity, 1, pad); - -The pads array must have been previously initialized. There is no need to -manually set the struct media_entity type and name fields. - -A reference to the entity will be automatically acquired/released when the -video device is opened/closed. - -ioctls and locking ------------------- - -The V4L core provides optional locking services. The main service is the -lock field in struct video_device, which is a pointer to a mutex. If you set -this pointer, then that will be used by unlocked_ioctl to serialize all ioctls. - -If you are using the videobuf2 framework, then there is a second lock that you -can set: video_device->queue->lock. If set, then this lock will be used instead -of video_device->lock to serialize all queuing ioctls (see the previous section -for the full list of those ioctls). - -The advantage of using a different lock for the queuing ioctls is that for some -drivers (particularly USB drivers) certain commands such as setting controls -can take a long time, so you want to use a separate lock for the buffer queuing -ioctls. That way your VIDIOC_DQBUF doesn't stall because the driver is busy -changing the e.g. exposure of the webcam. - -Of course, you can always do all the locking yourself by leaving both lock -pointers at NULL. - -If you use the old videobuf then you must pass the video_device lock to the -videobuf queue initialize function: if videobuf has to wait for a frame to -arrive, then it will temporarily unlock the lock and relock it afterwards. If -your driver also waits in the code, then you should do the same to allow other -processes to access the device node while the first process is waiting for -something. - -In the case of videobuf2 you will need to implement the wait_prepare and -wait_finish callbacks to unlock/lock if applicable. If you use the queue->lock -pointer, then you can use the helper functions vb2_ops_wait_prepare/finish. - -The implementation of a hotplug disconnect should also take the lock from -video_device before calling v4l2_device_disconnect. If you are also using -video_device->queue->lock, then you have to first lock video_device->queue->lock -followed by video_device->lock. That way you can be sure no ioctl is running -when you call v4l2_device_disconnect. - -video_device registration -------------------------- - -Next you register the video device: this will create the character device -for you. - - err = video_register_device(vdev, VFL_TYPE_GRABBER, -1); - if (err) { - video_device_release(vdev); /* or kfree(my_vdev); */ - return err; - } - -If the v4l2_device parent device has a non-NULL mdev field, the video device -entity will be automatically registered with the media device. - -Which device is registered depends on the type argument. The following -types exist: - -VFL_TYPE_GRABBER: videoX for video input/output devices -VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext) -VFL_TYPE_RADIO: radioX for radio tuners -VFL_TYPE_SDR: swradioX for Software Defined Radio tuners - -The last argument gives you a certain amount of control over the device -device node number used (i.e. the X in videoX). Normally you will pass -1 -to let the v4l2 framework pick the first free number. But sometimes users -want to select a specific node number. It is common that drivers allow -the user to select a specific device node number through a driver module -option. That number is then passed to this function and video_register_device -will attempt to select that device node number. If that number was already -in use, then the next free device node number will be selected and it -will send a warning to the kernel log. - -Another use-case is if a driver creates many devices. In that case it can -be useful to place different video devices in separate ranges. For example, -video capture devices start at 0, video output devices start at 16. -So you can use the last argument to specify a minimum device node number -and the v4l2 framework will try to pick the first free number that is equal -or higher to what you passed. If that fails, then it will just pick the -first free number. - -Since in this case you do not care about a warning about not being able -to select the specified device node number, you can call the function -video_register_device_no_warn() instead. - -Whenever a device node is created some attributes are also created for you. -If you look in /sys/class/video4linux you see the devices. Go into e.g. -video0 and you will see 'name', 'dev_debug' and 'index' attributes. The 'name' -attribute is the 'name' field of the video_device struct. The 'dev_debug' attribute -can be used to enable core debugging. See the next section for more detailed -information on this. - -The 'index' attribute is the index of the device node: for each call to -video_register_device() the index is just increased by 1. The first video -device node you register always starts with index 0. - -Users can setup udev rules that utilize the index attribute to make fancy -device names (e.g. 'mpegX' for MPEG video capture device nodes). - -After the device was successfully registered, then you can use these fields: - -- vfl_type: the device type passed to video_register_device. -- minor: the assigned device minor number. -- num: the device node number (i.e. the X in videoX). -- index: the device index number. - -If the registration failed, then you need to call video_device_release() -to free the allocated video_device struct, or free your own struct if the -video_device was embedded in it. The vdev->release() callback will never -be called if the registration failed, nor should you ever attempt to -unregister the device if the registration failed. - -video device debugging ----------------------- - -The 'dev_debug' attribute that is created for each video, vbi, radio or swradio -device in /sys/class/video4linux/<devX>/ allows you to enable logging of -file operations. - -It is a bitmask and the following bits can be set: - -0x01: Log the ioctl name and error code. VIDIOC_(D)QBUF ioctls are only logged - if bit 0x08 is also set. -0x02: Log the ioctl name arguments and error code. VIDIOC_(D)QBUF ioctls are - only logged if bit 0x08 is also set. -0x04: Log the file operations open, release, read, write, mmap and - get_unmapped_area. The read and write operations are only logged if - bit 0x08 is also set. -0x08: Log the read and write file operations and the VIDIOC_QBUF and - VIDIOC_DQBUF ioctls. -0x10: Log the poll file operation. - -video_device cleanup --------------------- - -When the video device nodes have to be removed, either during the unload -of the driver or because the USB device was disconnected, then you should -unregister them: - - video_unregister_device(vdev); - -This will remove the device nodes from sysfs (causing udev to remove them -from /dev). - -After video_unregister_device() returns no new opens can be done. However, -in the case of USB devices some application might still have one of these -device nodes open. So after the unregister all file operations (except -release, of course) will return an error as well. - -When the last user of the video device node exits, then the vdev->release() -callback is called and you can do the final cleanup there. - -Don't forget to cleanup the media entity associated with the video device if -it has been initialized: - - media_entity_cleanup(&vdev->entity); - -This can be done from the release callback. - - -video_device helper functions ------------------------------ - -There are a few useful helper functions: - -- file/video_device private data - -You can set/get driver private data in the video_device struct using: - -void *video_get_drvdata(struct video_device *vdev); -void video_set_drvdata(struct video_device *vdev, void *data); - -Note that you can safely call video_set_drvdata() before calling -video_register_device(). - -And this function: - -struct video_device *video_devdata(struct file *file); - -returns the video_device belonging to the file struct. - -The video_drvdata function combines video_get_drvdata with video_devdata: - -void *video_drvdata(struct file *file); - -You can go from a video_device struct to the v4l2_device struct using: - -struct v4l2_device *v4l2_dev = vdev->v4l2_dev; - -- Device node name - -The video_device node kernel name can be retrieved using - -const char *video_device_node_name(struct video_device *vdev); - -The name is used as a hint by userspace tools such as udev. The function -should be used where possible instead of accessing the video_device::num and -video_device::minor fields. - - -video buffer helper functions ------------------------------ - -The v4l2 core API provides a set of standard methods (called "videobuf") -for dealing with video buffers. Those methods allow a driver to implement -read(), mmap() and overlay() in a consistent way. There are currently -methods for using video buffers on devices that supports DMA with -scatter/gather method (videobuf-dma-sg), DMA with linear access -(videobuf-dma-contig), and vmalloced buffers, mostly used on USB drivers -(videobuf-vmalloc). - -Please see Documentation/video4linux/videobuf for more information on how -to use the videobuf layer. - -struct v4l2_fh --------------- - -struct v4l2_fh provides a way to easily keep file handle specific data -that is used by the V4L2 framework. New drivers must use struct v4l2_fh -since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). - -The users of v4l2_fh (in the V4L2 framework, not the driver) know -whether a driver uses v4l2_fh as its file->private_data pointer by -testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. This bit is -set whenever v4l2_fh_init() is called. - -struct v4l2_fh is allocated as a part of the driver's own file handle -structure and file->private_data is set to it in the driver's open -function by the driver. - -In many cases the struct v4l2_fh will be embedded in a larger structure. -In that case you should call v4l2_fh_init+v4l2_fh_add in open() and -v4l2_fh_del+v4l2_fh_exit in release(). - -Drivers can extract their own file handle structure by using the container_of -macro. Example: - -struct my_fh { - int blah; - struct v4l2_fh fh; -}; - -... - -int my_open(struct file *file) -{ - struct my_fh *my_fh; - struct video_device *vfd; - int ret; - - ... - - my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL); - - ... - - v4l2_fh_init(&my_fh->fh, vfd); - - ... - - file->private_data = &my_fh->fh; - v4l2_fh_add(&my_fh->fh); - return 0; -} - -int my_release(struct file *file) -{ - struct v4l2_fh *fh = file->private_data; - struct my_fh *my_fh = container_of(fh, struct my_fh, fh); - - ... - v4l2_fh_del(&my_fh->fh); - v4l2_fh_exit(&my_fh->fh); - kfree(my_fh); - return 0; -} - -Below is a short description of the v4l2_fh functions used: - -void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev) - - Initialise the file handle. This *MUST* be performed in the driver's - v4l2_file_operations->open() handler. - -void v4l2_fh_add(struct v4l2_fh *fh) - - Add a v4l2_fh to video_device file handle list. Must be called once the - file handle is completely initialized. - -void v4l2_fh_del(struct v4l2_fh *fh) - - Unassociate the file handle from video_device(). The file handle - exit function may now be called. - -void v4l2_fh_exit(struct v4l2_fh *fh) - - Uninitialise the file handle. After uninitialisation the v4l2_fh - memory can be freed. - - -If struct v4l2_fh is not embedded, then you can use these helper functions: - -int v4l2_fh_open(struct file *filp) - - This allocates a struct v4l2_fh, initializes it and adds it to the struct - video_device associated with the file struct. - -int v4l2_fh_release(struct file *filp) - - This deletes it from the struct video_device associated with the file - struct, uninitialised the v4l2_fh and frees it. - -These two functions can be plugged into the v4l2_file_operation's open() and -release() ops. - - -Several drivers need to do something when the first file handle is opened and -when the last file handle closes. Two helper functions were added to check -whether the v4l2_fh struct is the only open filehandle of the associated -device node: - -int v4l2_fh_is_singular(struct v4l2_fh *fh) - - Returns 1 if the file handle is the only open file handle, else 0. - -int v4l2_fh_is_singular_file(struct file *filp) - - Same, but it calls v4l2_fh_is_singular with filp->private_data. - - -V4L2 events ------------ - -The V4L2 events provide a generic way to pass events to user space. -The driver must use v4l2_fh to be able to support V4L2 events. - -Events are defined by a type and an optional ID. The ID may refer to a V4L2 -object such as a control ID. If unused, then the ID is 0. - -When the user subscribes to an event the driver will allocate a number of -kevent structs for that event. So every (type, ID) event tuple will have -its own set of kevent structs. This guarantees that if a driver is generating -lots of events of one type in a short time, then that will not overwrite -events of another type. - -But if you get more events of one type than the number of kevents that were -reserved, then the oldest event will be dropped and the new one added. - -Furthermore, the internal struct v4l2_subscribed_event has merge() and -replace() callbacks which drivers can set. These callbacks are called when -a new event is raised and there is no more room. The replace() callback -allows you to replace the payload of the old event with that of the new event, -merging any relevant data from the old payload into the new payload that -replaces it. It is called when this event type has only one kevent struct -allocated. The merge() callback allows you to merge the oldest event payload -into that of the second-oldest event payload. It is called when there are two -or more kevent structs allocated. - -This way no status information is lost, just the intermediate steps leading -up to that state. - -A good example of these replace/merge callbacks is in v4l2-event.c: -ctrls_replace() and ctrls_merge() callbacks for the control event. - -Note: these callbacks can be called from interrupt context, so they must be -fast. - -Useful functions: - -void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev) - - Queue events to video device. The driver's only responsibility is to fill - in the type and the data fields. The other fields will be filled in by - V4L2. - -int v4l2_event_subscribe(struct v4l2_fh *fh, - struct v4l2_event_subscription *sub, unsigned elems, - const struct v4l2_subscribed_event_ops *ops) - - The video_device->ioctl_ops->vidioc_subscribe_event must check the driver - is able to produce events with specified event id. Then it calls - v4l2_event_subscribe() to subscribe the event. - - The elems argument is the size of the event queue for this event. If it is 0, - then the framework will fill in a default value (this depends on the event - type). - - The ops argument allows the driver to specify a number of callbacks: - * add: called when a new listener gets added (subscribing to the same - event twice will only cause this callback to get called once) - * del: called when a listener stops listening - * replace: replace event 'old' with event 'new'. - * merge: merge event 'old' into event 'new'. - All 4 callbacks are optional, if you don't want to specify any callbacks - the ops argument itself maybe NULL. - -int v4l2_event_unsubscribe(struct v4l2_fh *fh, - struct v4l2_event_subscription *sub) - - vidioc_unsubscribe_event in struct v4l2_ioctl_ops. A driver may use - v4l2_event_unsubscribe() directly unless it wants to be involved in - unsubscription process. - - The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The - drivers may want to handle this in a special way. - -int v4l2_event_pending(struct v4l2_fh *fh) - - Returns the number of pending events. Useful when implementing poll. - -Events are delivered to user space through the poll system call. The driver -can use v4l2_fh->wait (a wait_queue_head_t) as the argument for poll_wait(). - -There are standard and private events. New standard events must use the -smallest available event type. The drivers must allocate their events from -their own class starting from class base. Class base is -V4L2_EVENT_PRIVATE_START + n * 1000 where n is the lowest available number. -The first event type in the class is reserved for future use, so the first -available event type is 'class base + 1'. - -An example on how the V4L2 events may be used can be found in the OMAP -3 ISP driver (drivers/media/platform/omap3isp). - -A subdev can directly send an event to the v4l2_device notify function with -V4L2_DEVICE_NOTIFY_EVENT. This allows the bridge to map the subdev that sends -the event to the video node(s) associated with the subdev that need to be -informed about such an event. - -V4L2 clocks ------------ - -Many subdevices, like camera sensors, TV decoders and encoders, need a clock -signal to be supplied by the system. Often this clock is supplied by the -respective bridge device. The Linux kernel provides a Common Clock Framework for -this purpose. However, it is not (yet) available on all architectures. Besides, -the nature of the multi-functional (clock, data + synchronisation, I2C control) -connection of subdevices to the system might impose special requirements on the -clock API usage. E.g. V4L2 has to support clock provider driver unregistration -while a subdevice driver is holding a reference to the clock. For these reasons -a V4L2 clock helper API has been developed and is provided to bridge and -subdevice drivers. - -The API consists of two parts: two functions to register and unregister a V4L2 -clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control -a clock object, similar to the respective generic clock API calls: -v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(), -v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide -clock operations that will be called when clock users invoke respective API -methods. - -It is expected that once the CCF becomes available on all relevant -architectures this API will be removed. diff --git a/Documentation/video4linux/videobuf b/Documentation/video4linux/videobuf deleted file mode 100644 index 3ffe9e960..000000000 --- a/Documentation/video4linux/videobuf +++ /dev/null @@ -1,355 +0,0 @@ -An introduction to the videobuf layer -Jonathan Corbet <corbet@lwn.net> -Current as of 2.6.33 - -The videobuf layer functions as a sort of glue layer between a V4L2 driver -and user space. It handles the allocation and management of buffers for -the storage of video frames. There is a set of functions which can be used -to implement many of the standard POSIX I/O system calls, including read(), -poll(), and, happily, mmap(). Another set of functions can be used to -implement the bulk of the V4L2 ioctl() calls related to streaming I/O, -including buffer allocation, queueing and dequeueing, and streaming -control. Using videobuf imposes a few design decisions on the driver -author, but the payback comes in the form of reduced code in the driver and -a consistent implementation of the V4L2 user-space API. - -Buffer types - -Not all video devices use the same kind of buffers. In fact, there are (at -least) three common variations: - - - Buffers which are scattered in both the physical and (kernel) virtual - address spaces. (Almost) all user-space buffers are like this, but it - makes great sense to allocate kernel-space buffers this way as well when - it is possible. Unfortunately, it is not always possible; working with - this kind of buffer normally requires hardware which can do - scatter/gather DMA operations. - - - Buffers which are physically scattered, but which are virtually - contiguous; buffers allocated with vmalloc(), in other words. These - buffers are just as hard to use for DMA operations, but they can be - useful in situations where DMA is not available but virtually-contiguous - buffers are convenient. - - - Buffers which are physically contiguous. Allocation of this kind of - buffer can be unreliable on fragmented systems, but simpler DMA - controllers cannot deal with anything else. - -Videobuf can work with all three types of buffers, but the driver author -must pick one at the outset and design the driver around that decision. - -[It's worth noting that there's a fourth kind of buffer: "overlay" buffers -which are located within the system's video memory. The overlay -functionality is considered to be deprecated for most use, but it still -shows up occasionally in system-on-chip drivers where the performance -benefits merit the use of this technique. Overlay buffers can be handled -as a form of scattered buffer, but there are very few implementations in -the kernel and a description of this technique is currently beyond the -scope of this document.] - -Data structures, callbacks, and initialization - -Depending on which type of buffers are being used, the driver should -include one of the following files: - - <media/videobuf-dma-sg.h> /* Physically scattered */ - <media/videobuf-vmalloc.h> /* vmalloc() buffers */ - <media/videobuf-dma-contig.h> /* Physically contiguous */ - -The driver's data structure describing a V4L2 device should include a -struct videobuf_queue instance for the management of the buffer queue, -along with a list_head for the queue of available buffers. There will also -need to be an interrupt-safe spinlock which is used to protect (at least) -the queue. - -The next step is to write four simple callbacks to help videobuf deal with -the management of buffers: - - struct videobuf_queue_ops { - int (*buf_setup)(struct videobuf_queue *q, - unsigned int *count, unsigned int *size); - int (*buf_prepare)(struct videobuf_queue *q, - struct videobuf_buffer *vb, - enum v4l2_field field); - void (*buf_queue)(struct videobuf_queue *q, - struct videobuf_buffer *vb); - void (*buf_release)(struct videobuf_queue *q, - struct videobuf_buffer *vb); - }; - -buf_setup() is called early in the I/O process, when streaming is being -initiated; its purpose is to tell videobuf about the I/O stream. The count -parameter will be a suggested number of buffers to use; the driver should -check it for rationality and adjust it if need be. As a practical rule, a -minimum of two buffers are needed for proper streaming, and there is -usually a maximum (which cannot exceed 32) which makes sense for each -device. The size parameter should be set to the expected (maximum) size -for each frame of data. - -Each buffer (in the form of a struct videobuf_buffer pointer) will be -passed to buf_prepare(), which should set the buffer's size, width, height, -and field fields properly. If the buffer's state field is -VIDEOBUF_NEEDS_INIT, the driver should pass it to: - - int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb, - struct v4l2_framebuffer *fbuf); - -Among other things, this call will usually allocate memory for the buffer. -Finally, the buf_prepare() function should set the buffer's state to -VIDEOBUF_PREPARED. - -When a buffer is queued for I/O, it is passed to buf_queue(), which should -put it onto the driver's list of available buffers and set its state to -VIDEOBUF_QUEUED. Note that this function is called with the queue spinlock -held; if it tries to acquire it as well things will come to a screeching -halt. Yes, this is the voice of experience. Note also that videobuf may -wait on the first buffer in the queue; placing other buffers in front of it -could again gum up the works. So use list_add_tail() to enqueue buffers. - -Finally, buf_release() is called when a buffer is no longer intended to be -used. The driver should ensure that there is no I/O active on the buffer, -then pass it to the appropriate free routine(s): - - /* Scatter/gather drivers */ - int videobuf_dma_unmap(struct videobuf_queue *q, - struct videobuf_dmabuf *dma); - int videobuf_dma_free(struct videobuf_dmabuf *dma); - - /* vmalloc drivers */ - void videobuf_vmalloc_free (struct videobuf_buffer *buf); - - /* Contiguous drivers */ - void videobuf_dma_contig_free(struct videobuf_queue *q, - struct videobuf_buffer *buf); - -One way to ensure that a buffer is no longer under I/O is to pass it to: - - int videobuf_waiton(struct videobuf_buffer *vb, int non_blocking, int intr); - -Here, vb is the buffer, non_blocking indicates whether non-blocking I/O -should be used (it should be zero in the buf_release() case), and intr -controls whether an interruptible wait is used. - -File operations - -At this point, much of the work is done; much of the rest is slipping -videobuf calls into the implementation of the other driver callbacks. The -first step is in the open() function, which must initialize the -videobuf queue. The function to use depends on the type of buffer used: - - void videobuf_queue_sg_init(struct videobuf_queue *q, - struct videobuf_queue_ops *ops, - struct device *dev, - spinlock_t *irqlock, - enum v4l2_buf_type type, - enum v4l2_field field, - unsigned int msize, - void *priv); - - void videobuf_queue_vmalloc_init(struct videobuf_queue *q, - struct videobuf_queue_ops *ops, - struct device *dev, - spinlock_t *irqlock, - enum v4l2_buf_type type, - enum v4l2_field field, - unsigned int msize, - void *priv); - - void videobuf_queue_dma_contig_init(struct videobuf_queue *q, - struct videobuf_queue_ops *ops, - struct device *dev, - spinlock_t *irqlock, - enum v4l2_buf_type type, - enum v4l2_field field, - unsigned int msize, - void *priv); - -In each case, the parameters are the same: q is the queue structure for the -device, ops is the set of callbacks as described above, dev is the device -structure for this video device, irqlock is an interrupt-safe spinlock to -protect access to the data structures, type is the buffer type used by the -device (cameras will use V4L2_BUF_TYPE_VIDEO_CAPTURE, for example), field -describes which field is being captured (often V4L2_FIELD_NONE for -progressive devices), msize is the size of any containing structure used -around struct videobuf_buffer, and priv is a private data pointer which -shows up in the priv_data field of struct videobuf_queue. Note that these -are void functions which, evidently, are immune to failure. - -V4L2 capture drivers can be written to support either of two APIs: the -read() system call and the rather more complicated streaming mechanism. As -a general rule, it is necessary to support both to ensure that all -applications have a chance of working with the device. Videobuf makes it -easy to do that with the same code. To implement read(), the driver need -only make a call to one of: - - ssize_t videobuf_read_one(struct videobuf_queue *q, - char __user *data, size_t count, - loff_t *ppos, int nonblocking); - - ssize_t videobuf_read_stream(struct videobuf_queue *q, - char __user *data, size_t count, - loff_t *ppos, int vbihack, int nonblocking); - -Either one of these functions will read frame data into data, returning the -amount actually read; the difference is that videobuf_read_one() will only -read a single frame, while videobuf_read_stream() will read multiple frames -if they are needed to satisfy the count requested by the application. A -typical driver read() implementation will start the capture engine, call -one of the above functions, then stop the engine before returning (though a -smarter implementation might leave the engine running for a little while in -anticipation of another read() call happening in the near future). - -The poll() function can usually be implemented with a direct call to: - - unsigned int videobuf_poll_stream(struct file *file, - struct videobuf_queue *q, - poll_table *wait); - -Note that the actual wait queue eventually used will be the one associated -with the first available buffer. - -When streaming I/O is done to kernel-space buffers, the driver must support -the mmap() system call to enable user space to access the data. In many -V4L2 drivers, the often-complex mmap() implementation simplifies to a -single call to: - - int videobuf_mmap_mapper(struct videobuf_queue *q, - struct vm_area_struct *vma); - -Everything else is handled by the videobuf code. - -The release() function requires two separate videobuf calls: - - void videobuf_stop(struct videobuf_queue *q); - int videobuf_mmap_free(struct videobuf_queue *q); - -The call to videobuf_stop() terminates any I/O in progress - though it is -still up to the driver to stop the capture engine. The call to -videobuf_mmap_free() will ensure that all buffers have been unmapped; if -so, they will all be passed to the buf_release() callback. If buffers -remain mapped, videobuf_mmap_free() returns an error code instead. The -purpose is clearly to cause the closing of the file descriptor to fail if -buffers are still mapped, but every driver in the 2.6.32 kernel cheerfully -ignores its return value. - -ioctl() operations - -The V4L2 API includes a very long list of driver callbacks to respond to -the many ioctl() commands made available to user space. A number of these -- those associated with streaming I/O - turn almost directly into videobuf -calls. The relevant helper functions are: - - int videobuf_reqbufs(struct videobuf_queue *q, - struct v4l2_requestbuffers *req); - int videobuf_querybuf(struct videobuf_queue *q, struct v4l2_buffer *b); - int videobuf_qbuf(struct videobuf_queue *q, struct v4l2_buffer *b); - int videobuf_dqbuf(struct videobuf_queue *q, struct v4l2_buffer *b, - int nonblocking); - int videobuf_streamon(struct videobuf_queue *q); - int videobuf_streamoff(struct videobuf_queue *q); - -So, for example, a VIDIOC_REQBUFS call turns into a call to the driver's -vidioc_reqbufs() callback which, in turn, usually only needs to locate the -proper struct videobuf_queue pointer and pass it to videobuf_reqbufs(). -These support functions can replace a great deal of buffer management -boilerplate in a lot of V4L2 drivers. - -The vidioc_streamon() and vidioc_streamoff() functions will be a bit more -complex, of course, since they will also need to deal with starting and -stopping the capture engine. - -Buffer allocation - -Thus far, we have talked about buffers, but have not looked at how they are -allocated. The scatter/gather case is the most complex on this front. For -allocation, the driver can leave buffer allocation entirely up to the -videobuf layer; in this case, buffers will be allocated as anonymous -user-space pages and will be very scattered indeed. If the application is -using user-space buffers, no allocation is needed; the videobuf layer will -take care of calling get_user_pages() and filling in the scatterlist array. - -If the driver needs to do its own memory allocation, it should be done in -the vidioc_reqbufs() function, *after* calling videobuf_reqbufs(). The -first step is a call to: - - struct videobuf_dmabuf *videobuf_to_dma(struct videobuf_buffer *buf); - -The returned videobuf_dmabuf structure (defined in -<media/videobuf-dma-sg.h>) includes a couple of relevant fields: - - struct scatterlist *sglist; - int sglen; - -The driver must allocate an appropriately-sized scatterlist array and -populate it with pointers to the pieces of the allocated buffer; sglen -should be set to the length of the array. - -Drivers using the vmalloc() method need not (and cannot) concern themselves -with buffer allocation at all; videobuf will handle those details. The -same is normally true of contiguous-DMA drivers as well; videobuf will -allocate the buffers (with dma_alloc_coherent()) when it sees fit. That -means that these drivers may be trying to do high-order allocations at any -time, an operation which is not always guaranteed to work. Some drivers -play tricks by allocating DMA space at system boot time; videobuf does not -currently play well with those drivers. - -As of 2.6.31, contiguous-DMA drivers can work with a user-supplied buffer, -as long as that buffer is physically contiguous. Normal user-space -allocations will not meet that criterion, but buffers obtained from other -kernel drivers, or those contained within huge pages, will work with these -drivers. - -Filling the buffers - -The final part of a videobuf implementation has no direct callback - it's -the portion of the code which actually puts frame data into the buffers, -usually in response to interrupts from the device. For all types of -drivers, this process works approximately as follows: - - - Obtain the next available buffer and make sure that somebody is actually - waiting for it. - - - Get a pointer to the memory and put video data there. - - - Mark the buffer as done and wake up the process waiting for it. - -Step (1) above is done by looking at the driver-managed list_head structure -- the one which is filled in the buf_queue() callback. Because starting -the engine and enqueueing buffers are done in separate steps, it's possible -for the engine to be running without any buffers available - in the -vmalloc() case especially. So the driver should be prepared for the list -to be empty. It is equally possible that nobody is yet interested in the -buffer; the driver should not remove it from the list or fill it until a -process is waiting on it. That test can be done by examining the buffer's -done field (a wait_queue_head_t structure) with waitqueue_active(). - -A buffer's state should be set to VIDEOBUF_ACTIVE before being mapped for -DMA; that ensures that the videobuf layer will not try to do anything with -it while the device is transferring data. - -For scatter/gather drivers, the needed memory pointers will be found in the -scatterlist structure described above. Drivers using the vmalloc() method -can get a memory pointer with: - - void *videobuf_to_vmalloc(struct videobuf_buffer *buf); - -For contiguous DMA drivers, the function to use is: - - dma_addr_t videobuf_to_dma_contig(struct videobuf_buffer *buf); - -The contiguous DMA API goes out of its way to hide the kernel-space address -of the DMA buffer from drivers. - -The final step is to set the size field of the relevant videobuf_buffer -structure to the actual size of the captured image, set state to -VIDEOBUF_DONE, then call wake_up() on the done queue. At this point, the -buffer is owned by the videobuf layer and the driver should not touch it -again. - -Developers who are interested in more information can go into the relevant -header files; there are a few low-level functions declared there which have -not been talked about here. Also worthwhile is the vivi driver -(drivers/media/platform/vivi.c), which is maintained as an example of how V4L2 -drivers should be written. Vivi only uses the vmalloc() API, but it's good -enough to get started with. Note also that all of these calls are exported -GPL-only, so they will not be available to non-GPL kernel modules. diff --git a/Documentation/video4linux/vivid.txt b/Documentation/video4linux/vivid.txt deleted file mode 100644 index 8da5d2a57..000000000 --- a/Documentation/video4linux/vivid.txt +++ /dev/null @@ -1,1135 +0,0 @@ -vivid: Virtual Video Test Driver -================================ - -This driver emulates video4linux hardware of various types: video capture, video -output, vbi capture and output, radio receivers and transmitters and a software -defined radio receiver. In addition a simple framebuffer device is available for -testing capture and output overlays. - -Up to 64 vivid instances can be created, each with up to 16 inputs and 16 outputs. - -Each input can be a webcam, TV capture device, S-Video capture device or an HDMI -capture device. Each output can be an S-Video output device or an HDMI output -device. - -These inputs and outputs act exactly as a real hardware device would behave. This -allows you to use this driver as a test input for application development, since -you can test the various features without requiring special hardware. - -This document describes the features implemented by this driver: - -- Support for read()/write(), MMAP, USERPTR and DMABUF streaming I/O. -- A large list of test patterns and variations thereof -- Working brightness, contrast, saturation and hue controls -- Support for the alpha color component -- Full colorspace support, including limited/full RGB range -- All possible control types are present -- Support for various pixel aspect ratios and video aspect ratios -- Error injection to test what happens if errors occur -- Supports crop/compose/scale in any combination for both input and output -- Can emulate up to 4K resolutions -- All Field settings are supported for testing interlaced capturing -- Supports all standard YUV and RGB formats, including two multiplanar YUV formats -- Raw and Sliced VBI capture and output support -- Radio receiver and transmitter support, including RDS support -- Software defined radio (SDR) support -- Capture and output overlay support - -These features will be described in more detail below. - - -Table of Contents ------------------ - -Section 1: Configuring the driver -Section 2: Video Capture -Section 2.1: Webcam Input -Section 2.2: TV and S-Video Inputs -Section 2.3: HDMI Input -Section 3: Video Output -Section 3.1: S-Video Output -Section 3.2: HDMI Output -Section 4: VBI Capture -Section 5: VBI Output -Section 6: Radio Receiver -Section 7: Radio Transmitter -Section 8: Software Defined Radio Receiver -Section 9: Controls -Section 9.1: User Controls - Test Controls -Section 9.2: User Controls - Video Capture -Section 9.3: User Controls - Audio -Section 9.4: Vivid Controls -Section 9.4.1: Test Pattern Controls -Section 9.4.2: Capture Feature Selection Controls -Section 9.4.3: Output Feature Selection Controls -Section 9.4.4: Error Injection Controls -Section 9.4.5: VBI Raw Capture Controls -Section 9.5: Digital Video Controls -Section 9.6: FM Radio Receiver Controls -Section 9.7: FM Radio Modulator -Section 10: Video, VBI and RDS Looping -Section 10.1: Video and Sliced VBI looping -Section 10.2: Radio & RDS Looping -Section 11: Cropping, Composing, Scaling -Section 12: Formats -Section 13: Capture Overlay -Section 14: Output Overlay -Section 15: Some Future Improvements - - -Section 1: Configuring the driver ---------------------------------- - -By default the driver will create a single instance that has a video capture -device with webcam, TV, S-Video and HDMI inputs, a video output device with -S-Video and HDMI outputs, one vbi capture device, one vbi output device, one -radio receiver device, one radio transmitter device and one SDR device. - -The number of instances, devices, video inputs and outputs and their types are -all configurable using the following module options: - -n_devs: number of driver instances to create. By default set to 1. Up to 64 - instances can be created. - -node_types: which devices should each driver instance create. An array of - hexadecimal values, one for each instance. The default is 0x1d3d. - Each value is a bitmask with the following meaning: - bit 0: Video Capture node - bit 2-3: VBI Capture node: 0 = none, 1 = raw vbi, 2 = sliced vbi, 3 = both - bit 4: Radio Receiver node - bit 5: Software Defined Radio Receiver node - bit 8: Video Output node - bit 10-11: VBI Output node: 0 = none, 1 = raw vbi, 2 = sliced vbi, 3 = both - bit 12: Radio Transmitter node - bit 16: Framebuffer for testing overlays - - So to create four instances, the first two with just one video capture - device, the second two with just one video output device you would pass - these module options to vivid: - - n_devs=4 node_types=0x1,0x1,0x100,0x100 - -num_inputs: the number of inputs, one for each instance. By default 4 inputs - are created for each video capture device. At most 16 inputs can be created, - and there must be at least one. - -input_types: the input types for each instance, the default is 0xe4. This defines - what the type of each input is when the inputs are created for each driver - instance. This is a hexadecimal value with up to 16 pairs of bits, each - pair gives the type and bits 0-1 map to input 0, bits 2-3 map to input 1, - 30-31 map to input 15. Each pair of bits has the following meaning: - - 00: this is a webcam input - 01: this is a TV tuner input - 10: this is an S-Video input - 11: this is an HDMI input - - So to create a video capture device with 8 inputs where input 0 is a TV - tuner, inputs 1-3 are S-Video inputs and inputs 4-7 are HDMI inputs you - would use the following module options: - - num_inputs=8 input_types=0xffa9 - -num_outputs: the number of outputs, one for each instance. By default 2 outputs - are created for each video output device. At most 16 outputs can be - created, and there must be at least one. - -output_types: the output types for each instance, the default is 0x02. This defines - what the type of each output is when the outputs are created for each - driver instance. This is a hexadecimal value with up to 16 bits, each bit - gives the type and bit 0 maps to output 0, bit 1 maps to output 1, bit - 15 maps to output 15. The meaning of each bit is as follows: - - 0: this is an S-Video output - 1: this is an HDMI output - - So to create a video output device with 8 outputs where outputs 0-3 are - S-Video outputs and outputs 4-7 are HDMI outputs you would use the - following module options: - - num_outputs=8 output_types=0xf0 - -vid_cap_nr: give the desired videoX start number for each video capture device. - The default is -1 which will just take the first free number. This allows - you to map capture video nodes to specific videoX device nodes. Example: - - n_devs=4 vid_cap_nr=2,4,6,8 - - This will attempt to assign /dev/video2 for the video capture device of - the first vivid instance, video4 for the next up to video8 for the last - instance. If it can't succeed, then it will just take the next free - number. - -vid_out_nr: give the desired videoX start number for each video output device. - The default is -1 which will just take the first free number. - -vbi_cap_nr: give the desired vbiX start number for each vbi capture device. - The default is -1 which will just take the first free number. - -vbi_out_nr: give the desired vbiX start number for each vbi output device. - The default is -1 which will just take the first free number. - -radio_rx_nr: give the desired radioX start number for each radio receiver device. - The default is -1 which will just take the first free number. - -radio_tx_nr: give the desired radioX start number for each radio transmitter - device. The default is -1 which will just take the first free number. - -sdr_cap_nr: give the desired swradioX start number for each SDR capture device. - The default is -1 which will just take the first free number. - -ccs_cap_mode: specify the allowed video capture crop/compose/scaling combination - for each driver instance. Video capture devices can have any combination - of cropping, composing and scaling capabilities and this will tell the - vivid driver which of those is should emulate. By default the user can - select this through controls. - - The value is either -1 (controlled by the user) or a set of three bits, - each enabling (1) or disabling (0) one of the features: - - bit 0: Enable crop support. Cropping will take only part of the - incoming picture. - bit 1: Enable compose support. Composing will copy the incoming - picture into a larger buffer. - bit 2: Enable scaling support. Scaling can scale the incoming - picture. The scaler of the vivid driver can enlarge up - or down to four times the original size. The scaler is - very simple and low-quality. Simplicity and speed were - key, not quality. - - Note that this value is ignored by webcam inputs: those enumerate - discrete framesizes and that is incompatible with cropping, composing - or scaling. - -ccs_out_mode: specify the allowed video output crop/compose/scaling combination - for each driver instance. Video output devices can have any combination - of cropping, composing and scaling capabilities and this will tell the - vivid driver which of those is should emulate. By default the user can - select this through controls. - - The value is either -1 (controlled by the user) or a set of three bits, - each enabling (1) or disabling (0) one of the features: - - bit 0: Enable crop support. Cropping will take only part of the - outgoing buffer. - bit 1: Enable compose support. Composing will copy the incoming - buffer into a larger picture frame. - bit 2: Enable scaling support. Scaling can scale the incoming - buffer. The scaler of the vivid driver can enlarge up - or down to four times the original size. The scaler is - very simple and low-quality. Simplicity and speed were - key, not quality. - -multiplanar: select whether each device instance supports multi-planar formats, - and thus the V4L2 multi-planar API. By default device instances are - single-planar. - - This module option can override that for each instance. Values are: - - 1: this is a single-planar instance. - 2: this is a multi-planar instance. - -vivid_debug: enable driver debugging info - -no_error_inj: if set disable the error injecting controls. This option is - needed in order to run a tool like v4l2-compliance. Tools like that - exercise all controls including a control like 'Disconnect' which - emulates a USB disconnect, making the device inaccessible and so - all tests that v4l2-compliance is doing will fail afterwards. - - There may be other situations as well where you want to disable the - error injection support of vivid. When this option is set, then the - controls that select crop, compose and scale behavior are also - removed. Unless overridden by ccs_cap_mode and/or ccs_out_mode the - will default to enabling crop, compose and scaling. - -Taken together, all these module options allow you to precisely customize -the driver behavior and test your application with all sorts of permutations. -It is also very suitable to emulate hardware that is not yet available, e.g. -when developing software for a new upcoming device. - - -Section 2: Video Capture ------------------------- - -This is probably the most frequently used feature. The video capture device -can be configured by using the module options num_inputs, input_types and -ccs_cap_mode (see section 1 for more detailed information), but by default -four inputs are configured: a webcam, a TV tuner, an S-Video and an HDMI -input, one input for each input type. Those are described in more detail -below. - -Special attention has been given to the rate at which new frames become -available. The jitter will be around 1 jiffie (that depends on the HZ -configuration of your kernel, so usually 1/100, 1/250 or 1/1000 of a second), -but the long-term behavior is exactly following the framerate. So a -framerate of 59.94 Hz is really different from 60 Hz. If the framerate -exceeds your kernel's HZ value, then you will get dropped frames, but the -frame/field sequence counting will keep track of that so the sequence -count will skip whenever frames are dropped. - - -Section 2.1: Webcam Input -------------------------- - -The webcam input supports three framesizes: 320x180, 640x360 and 1280x720. It -supports frames per second settings of 10, 15, 25, 30, 50 and 60 fps. Which ones -are available depends on the chosen framesize: the larger the framesize, the -lower the maximum frames per second. - -The initially selected colorspace when you switch to the webcam input will be -sRGB. - - -Section 2.2: TV and S-Video Inputs ----------------------------------- - -The only difference between the TV and S-Video input is that the TV has a -tuner. Otherwise they behave identically. - -These inputs support audio inputs as well: one TV and one Line-In. They -both support all TV standards. If the standard is queried, then the Vivid -controls 'Standard Signal Mode' and 'Standard' determine what -the result will be. - -These inputs support all combinations of the field setting. Special care has -been taken to faithfully reproduce how fields are handled for the different -TV standards. This is particularly noticeable when generating a horizontally -moving image so the temporal effect of using interlaced formats becomes clearly -visible. For 50 Hz standards the top field is the oldest and the bottom field -is the newest in time. For 60 Hz standards that is reversed: the bottom field -is the oldest and the top field is the newest in time. - -When you start capturing in V4L2_FIELD_ALTERNATE mode the first buffer will -contain the top field for 50 Hz standards and the bottom field for 60 Hz -standards. This is what capture hardware does as well. - -Finally, for PAL/SECAM standards the first half of the top line contains noise. -This simulates the Wide Screen Signal that is commonly placed there. - -The initially selected colorspace when you switch to the TV or S-Video input -will be SMPTE-170M. - -The pixel aspect ratio will depend on the TV standard. The video aspect ratio -can be selected through the 'Standard Aspect Ratio' Vivid control. -Choices are '4x3', '16x9' which will give letterboxed widescreen video and -'16x9 Anamorphic' which will give full screen squashed anamorphic widescreen -video that will need to be scaled accordingly. - -The TV 'tuner' supports a frequency range of 44-958 MHz. Channels are available -every 6 MHz, starting from 49.25 MHz. For each channel the generated image -will be in color for the +/- 0.25 MHz around it, and in grayscale for -+/- 1 MHz around the channel. Beyond that it is just noise. The VIDIOC_G_TUNER -ioctl will return 100% signal strength for +/- 0.25 MHz and 50% for +/- 1 MHz. -It will also return correct afc values to show whether the frequency is too -low or too high. - -The audio subchannels that are returned are MONO for the +/- 1 MHz range around -a valid channel frequency. When the frequency is within +/- 0.25 MHz of the -channel it will return either MONO, STEREO, either MONO | SAP (for NTSC) or -LANG1 | LANG2 (for others), or STEREO | SAP. - -Which one is returned depends on the chosen channel, each next valid channel -will cycle through the possible audio subchannel combinations. This allows -you to test the various combinations by just switching channels.. - -Finally, for these inputs the v4l2_timecode struct is filled in in the -dequeued v4l2_buffer struct. - - -Section 2.3: HDMI Input ------------------------ - -The HDMI inputs supports all CEA-861 and DMT timings, both progressive and -interlaced, for pixelclock frequencies between 25 and 600 MHz. The field -mode for interlaced formats is always V4L2_FIELD_ALTERNATE. For HDMI the -field order is always top field first, and when you start capturing an -interlaced format you will receive the top field first. - -The initially selected colorspace when you switch to the HDMI input or -select an HDMI timing is based on the format resolution: for resolutions -less than or equal to 720x576 the colorspace is set to SMPTE-170M, for -others it is set to REC-709 (CEA-861 timings) or sRGB (VESA DMT timings). - -The pixel aspect ratio will depend on the HDMI timing: for 720x480 is it -set as for the NTSC TV standard, for 720x576 it is set as for the PAL TV -standard, and for all others a 1:1 pixel aspect ratio is returned. - -The video aspect ratio can be selected through the 'DV Timings Aspect Ratio' -Vivid control. Choices are 'Source Width x Height' (just use the -same ratio as the chosen format), '4x3' or '16x9', either of which can -result in pillarboxed or letterboxed video. - -For HDMI inputs it is possible to set the EDID. By default a simple EDID -is provided. You can only set the EDID for HDMI inputs. Internally, however, -the EDID is shared between all HDMI inputs. - -No interpretation is done of the EDID data. - - -Section 3: Video Output ------------------------ - -The video output device can be configured by using the module options -num_outputs, output_types and ccs_out_mode (see section 1 for more detailed -information), but by default two outputs are configured: an S-Video and an -HDMI input, one output for each output type. Those are described in more detail -below. - -Like with video capture the framerate is also exact in the long term. - - -Section 3.1: S-Video Output ---------------------------- - -This output supports audio outputs as well: "Line-Out 1" and "Line-Out 2". -The S-Video output supports all TV standards. - -This output supports all combinations of the field setting. - -The initially selected colorspace when you switch to the TV or S-Video input -will be SMPTE-170M. - - -Section 3.2: HDMI Output ------------------------- - -The HDMI output supports all CEA-861 and DMT timings, both progressive and -interlaced, for pixelclock frequencies between 25 and 600 MHz. The field -mode for interlaced formats is always V4L2_FIELD_ALTERNATE. - -The initially selected colorspace when you switch to the HDMI output or -select an HDMI timing is based on the format resolution: for resolutions -less than or equal to 720x576 the colorspace is set to SMPTE-170M, for -others it is set to REC-709 (CEA-861 timings) or sRGB (VESA DMT timings). - -The pixel aspect ratio will depend on the HDMI timing: for 720x480 is it -set as for the NTSC TV standard, for 720x576 it is set as for the PAL TV -standard, and for all others a 1:1 pixel aspect ratio is returned. - -An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID. - - -Section 4: VBI Capture ----------------------- - -There are three types of VBI capture devices: those that only support raw -(undecoded) VBI, those that only support sliced (decoded) VBI and those that -support both. This is determined by the node_types module option. In all -cases the driver will generate valid VBI data: for 60 Hz standards it will -generate Closed Caption and XDS data. The closed caption stream will -alternate between "Hello world!" and "Closed captions test" every second. -The XDS stream will give the current time once a minute. For 50 Hz standards -it will generate the Wide Screen Signal which is based on the actual Video -Aspect Ratio control setting and teletext pages 100-159, one page per frame. - -The VBI device will only work for the S-Video and TV inputs, it will give -back an error if the current input is a webcam or HDMI. - - -Section 5: VBI Output ---------------------- - -There are three types of VBI output devices: those that only support raw -(undecoded) VBI, those that only support sliced (decoded) VBI and those that -support both. This is determined by the node_types module option. - -The sliced VBI output supports the Wide Screen Signal and the teletext signal -for 50 Hz standards and Closed Captioning + XDS for 60 Hz standards. - -The VBI device will only work for the S-Video output, it will give -back an error if the current output is HDMI. - - -Section 6: Radio Receiver -------------------------- - -The radio receiver emulates an FM/AM/SW receiver. The FM band also supports RDS. -The frequency ranges are: - - FM: 64 MHz - 108 MHz - AM: 520 kHz - 1710 kHz - SW: 2300 kHz - 26.1 MHz - -Valid channels are emulated every 1 MHz for FM and every 100 kHz for AM and SW. -The signal strength decreases the further the frequency is from the valid -frequency until it becomes 0% at +/- 50 kHz (FM) or 5 kHz (AM/SW) from the -ideal frequency. The initial frequency when the driver is loaded is set to -95 MHz. - -The FM receiver supports RDS as well, both using 'Block I/O' and 'Controls' -modes. In the 'Controls' mode the RDS information is stored in read-only -controls. These controls are updated every time the frequency is changed, -or when the tuner status is requested. The Block I/O method uses the read() -interface to pass the RDS blocks on to the application for decoding. - -The RDS signal is 'detected' for +/- 12.5 kHz around the channel frequency, -and the further the frequency is away from the valid frequency the more RDS -errors are randomly introduced into the block I/O stream, up to 50% of all -blocks if you are +/- 12.5 kHz from the channel frequency. All four errors -can occur in equal proportions: blocks marked 'CORRECTED', blocks marked -'ERROR', blocks marked 'INVALID' and dropped blocks. - -The generated RDS stream contains all the standard fields contained in a -0B group, and also radio text and the current time. - -The receiver supports HW frequency seek, either in Bounded mode, Wrap Around -mode or both, which is configurable with the "Radio HW Seek Mode" control. - - -Section 7: Radio Transmitter ----------------------------- - -The radio transmitter emulates an FM/AM/SW transmitter. The FM band also supports RDS. -The frequency ranges are: - - FM: 64 MHz - 108 MHz - AM: 520 kHz - 1710 kHz - SW: 2300 kHz - 26.1 MHz - -The initial frequency when the driver is loaded is 95.5 MHz. - -The FM transmitter supports RDS as well, both using 'Block I/O' and 'Controls' -modes. In the 'Controls' mode the transmitted RDS information is configured -using controls, and in 'Block I/O' mode the blocks are passed to the driver -using write(). - - -Section 8: Software Defined Radio Receiver ------------------------------------------- - -The SDR receiver has three frequency bands for the ADC tuner: - - - 300 kHz - - 900 kHz - 2800 kHz - - 3200 kHz - -The RF tuner supports 50 MHz - 2000 MHz. - -The generated data contains the In-phase and Quadrature components of a -1 kHz tone that has an amplitude of sqrt(2). - - -Section 9: Controls -------------------- - -Different devices support different controls. The sections below will describe -each control and which devices support them. - - -Section 9.1: User Controls - Test Controls ------------------------------------------- - -The Button, Boolean, Integer 32 Bits, Integer 64 Bits, Menu, String, Bitmask and -Integer Menu are controls that represent all possible control types. The Menu -control and the Integer Menu control both have 'holes' in their menu list, -meaning that one or more menu items return EINVAL when VIDIOC_QUERYMENU is called. -Both menu controls also have a non-zero minimum control value. These features -allow you to check if your application can handle such things correctly. -These controls are supported for every device type. - - -Section 9.2: User Controls - Video Capture ------------------------------------------- - -The following controls are specific to video capture. - -The Brightness, Contrast, Saturation and Hue controls actually work and are -standard. There is one special feature with the Brightness control: each -video input has its own brightness value, so changing input will restore -the brightness for that input. In addition, each video input uses a different -brightness range (minimum and maximum control values). Switching inputs will -cause a control event to be sent with the V4L2_EVENT_CTRL_CH_RANGE flag set. -This allows you to test controls that can change their range. - -The 'Gain, Automatic' and Gain controls can be used to test volatile controls: -if 'Gain, Automatic' is set, then the Gain control is volatile and changes -constantly. If 'Gain, Automatic' is cleared, then the Gain control is a normal -control. - -The 'Horizontal Flip' and 'Vertical Flip' controls can be used to flip the -image. These combine with the 'Sensor Flipped Horizontally/Vertically' Vivid -controls. - -The 'Alpha Component' control can be used to set the alpha component for -formats containing an alpha channel. - - -Section 9.3: User Controls - Audio ----------------------------------- - -The following controls are specific to video capture and output and radio -receivers and transmitters. - -The 'Volume' and 'Mute' audio controls are typical for such devices to -control the volume and mute the audio. They don't actually do anything in -the vivid driver. - - -Section 9.4: Vivid Controls ---------------------------- - -These vivid custom controls control the image generation, error injection, etc. - - -Section 9.4.1: Test Pattern Controls ------------------------------------- - -The Test Pattern Controls are all specific to video capture. - -Test Pattern: selects which test pattern to use. Use the CSC Colorbar for - testing colorspace conversions: the colors used in that test pattern - map to valid colors in all colorspaces. The colorspace conversion - is disabled for the other test patterns. - -OSD Text Mode: selects whether the text superimposed on the - test pattern should be shown, and if so, whether only counters should - be displayed or the full text. - -Horizontal Movement: selects whether the test pattern should - move to the left or right and at what speed. - -Vertical Movement: does the same for the vertical direction. - -Show Border: show a two-pixel wide border at the edge of the actual image, - excluding letter or pillarboxing. - -Show Square: show a square in the middle of the image. If the image is - displayed with the correct pixel and image aspect ratio corrections, - then the width and height of the square on the monitor should be - the same. - -Insert SAV Code in Image: adds a SAV (Start of Active Video) code to the image. - This can be used to check if such codes in the image are inadvertently - interpreted instead of being ignored. - -Insert EAV Code in Image: does the same for the EAV (End of Active Video) code. - - -Section 9.4.2: Capture Feature Selection Controls -------------------------------------------------- - -These controls are all specific to video capture. - -Sensor Flipped Horizontally: the image is flipped horizontally and the - V4L2_IN_ST_HFLIP input status flag is set. This emulates the case where - a sensor is for example mounted upside down. - -Sensor Flipped Vertically: the image is flipped vertically and the - V4L2_IN_ST_VFLIP input status flag is set. This emulates the case where - a sensor is for example mounted upside down. - -Standard Aspect Ratio: selects if the image aspect ratio as used for the TV or - S-Video input should be 4x3, 16x9 or anamorphic widescreen. This may - introduce letterboxing. - -DV Timings Aspect Ratio: selects if the image aspect ratio as used for the HDMI - input should be the same as the source width and height ratio, or if - it should be 4x3 or 16x9. This may introduce letter or pillarboxing. - -Timestamp Source: selects when the timestamp for each buffer is taken. - -Colorspace: selects which colorspace should be used when generating the image. - This only applies if the CSC Colorbar test pattern is selected, - otherwise the test pattern will go through unconverted. - This behavior is also what you want, since a 75% Colorbar - should really have 75% signal intensity and should not be affected - by colorspace conversions. - - Changing the colorspace will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a detected colorspace change. - -Transfer Function: selects which colorspace transfer function should be used when - generating an image. This only applies if the CSC Colorbar test pattern is - selected, otherwise the test pattern will go through unconverted. - This behavior is also what you want, since a 75% Colorbar - should really have 75% signal intensity and should not be affected - by colorspace conversions. - - Changing the transfer function will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a detected colorspace change. - -Y'CbCr Encoding: selects which Y'CbCr encoding should be used when generating - a Y'CbCr image. This only applies if the format is set to a Y'CbCr format - as opposed to an RGB format. - - Changing the Y'CbCr encoding will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a detected colorspace change. - -Quantization: selects which quantization should be used for the RGB or Y'CbCr - encoding when generating the test pattern. - - Changing the quantization will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a detected colorspace change. - -Limited RGB Range (16-235): selects if the RGB range of the HDMI source should - be limited or full range. This combines with the Digital Video 'Rx RGB - Quantization Range' control and can be used to test what happens if - a source provides you with the wrong quantization range information. - See the description of that control for more details. - -Apply Alpha To Red Only: apply the alpha channel as set by the 'Alpha Component' - user control to the red color of the test pattern only. - -Enable Capture Cropping: enables crop support. This control is only present if - the ccs_cap_mode module option is set to the default value of -1 and if - the no_error_inj module option is set to 0 (the default). - -Enable Capture Composing: enables composing support. This control is only - present if the ccs_cap_mode module option is set to the default value of - -1 and if the no_error_inj module option is set to 0 (the default). - -Enable Capture Scaler: enables support for a scaler (maximum 4 times upscaling - and downscaling). This control is only present if the ccs_cap_mode - module option is set to the default value of -1 and if the no_error_inj - module option is set to 0 (the default). - -Maximum EDID Blocks: determines how many EDID blocks the driver supports. - Note that the vivid driver does not actually interpret new EDID - data, it just stores it. It allows for up to 256 EDID blocks - which is the maximum supported by the standard. - -Fill Percentage of Frame: can be used to draw only the top X percent - of the image. Since each frame has to be drawn by the driver, this - demands a lot of the CPU. For large resolutions this becomes - problematic. By drawing only part of the image this CPU load can - be reduced. - - -Section 9.4.3: Output Feature Selection Controls ------------------------------------------------- - -These controls are all specific to video output. - -Enable Output Cropping: enables crop support. This control is only present if - the ccs_out_mode module option is set to the default value of -1 and if - the no_error_inj module option is set to 0 (the default). - -Enable Output Composing: enables composing support. This control is only - present if the ccs_out_mode module option is set to the default value of - -1 and if the no_error_inj module option is set to 0 (the default). - -Enable Output Scaler: enables support for a scaler (maximum 4 times upscaling - and downscaling). This control is only present if the ccs_out_mode - module option is set to the default value of -1 and if the no_error_inj - module option is set to 0 (the default). - - -Section 9.4.4: Error Injection Controls ---------------------------------------- - -The following two controls are only valid for video and vbi capture. - -Standard Signal Mode: selects the behavior of VIDIOC_QUERYSTD: what should - it return? - - Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a changed input condition (e.g. a cable - was plugged in or out). - -Standard: selects the standard that VIDIOC_QUERYSTD should return if the - previous control is set to "Selected Standard". - - Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a changed input standard. - - -The following two controls are only valid for video capture. - -DV Timings Signal Mode: selects the behavior of VIDIOC_QUERY_DV_TIMINGS: what - should it return? - - Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates a changed input condition (e.g. a cable - was plugged in or out). - -DV Timings: selects the timings the VIDIOC_QUERY_DV_TIMINGS should return - if the previous control is set to "Selected DV Timings". - - Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE - to be sent since it emulates changed input timings. - - -The following controls are only present if the no_error_inj module option -is set to 0 (the default). These controls are valid for video and vbi -capture and output streams and for the SDR capture device except for the -Disconnect control which is valid for all devices. - -Wrap Sequence Number: test what happens when you wrap the sequence number in - struct v4l2_buffer around. - -Wrap Timestamp: test what happens when you wrap the timestamp in struct - v4l2_buffer around. - -Percentage of Dropped Buffers: sets the percentage of buffers that - are never returned by the driver (i.e., they are dropped). - -Disconnect: emulates a USB disconnect. The device will act as if it has - been disconnected. Only after all open filehandles to the device - node have been closed will the device become 'connected' again. - -Inject V4L2_BUF_FLAG_ERROR: when pressed, the next frame returned by - the driver will have the error flag set (i.e. the frame is marked - corrupt). - -Inject VIDIOC_REQBUFS Error: when pressed, the next REQBUFS or CREATE_BUFS - ioctl call will fail with an error. To be precise: the videobuf2 - queue_setup() op will return -EINVAL. - -Inject VIDIOC_QBUF Error: when pressed, the next VIDIOC_QBUF or - VIDIOC_PREPARE_BUFFER ioctl call will fail with an error. To be - precise: the videobuf2 buf_prepare() op will return -EINVAL. - -Inject VIDIOC_STREAMON Error: when pressed, the next VIDIOC_STREAMON ioctl - call will fail with an error. To be precise: the videobuf2 - start_streaming() op will return -EINVAL. - -Inject Fatal Streaming Error: when pressed, the streaming core will be - marked as having suffered a fatal error, the only way to recover - from that is to stop streaming. To be precise: the videobuf2 - vb2_queue_error() function is called. - - -Section 9.4.5: VBI Raw Capture Controls ---------------------------------------- - -Interlaced VBI Format: if set, then the raw VBI data will be interlaced instead - of providing it grouped by field. - - -Section 9.5: Digital Video Controls ------------------------------------ - -Rx RGB Quantization Range: sets the RGB quantization detection of the HDMI - input. This combines with the Vivid 'Limited RGB Range (16-235)' - control and can be used to test what happens if a source provides - you with the wrong quantization range information. This can be tested - by selecting an HDMI input, setting this control to Full or Limited - range and selecting the opposite in the 'Limited RGB Range (16-235)' - control. The effect is easy to see if the 'Gray Ramp' test pattern - is selected. - -Tx RGB Quantization Range: sets the RGB quantization detection of the HDMI - output. It is currently not used for anything in vivid, but most HDMI - transmitters would typically have this control. - -Transmit Mode: sets the transmit mode of the HDMI output to HDMI or DVI-D. This - affects the reported colorspace since DVI_D outputs will always use - sRGB. - - -Section 9.6: FM Radio Receiver Controls ---------------------------------------- - -RDS Reception: set if the RDS receiver should be enabled. - -RDS Program Type: -RDS PS Name: -RDS Radio Text: -RDS Traffic Announcement: -RDS Traffic Program: -RDS Music: these are all read-only controls. If RDS Rx I/O Mode is set to - "Block I/O", then they are inactive as well. If RDS Rx I/O Mode is set - to "Controls", then these controls report the received RDS data. Note - that the vivid implementation of this is pretty basic: they are only - updated when you set a new frequency or when you get the tuner status - (VIDIOC_G_TUNER). - -Radio HW Seek Mode: can be one of "Bounded", "Wrap Around" or "Both". This - determines if VIDIOC_S_HW_FREQ_SEEK will be bounded by the frequency - range or wrap-around or if it is selectable by the user. - -Radio Programmable HW Seek: if set, then the user can provide the lower and - upper bound of the HW Seek. Otherwise the frequency range boundaries - will be used. - -Generate RBDS Instead of RDS: if set, then generate RBDS (the US variant of - RDS) data instead of RDS (European-style RDS). This affects only the - PICODE and PTY codes. - -RDS Rx I/O Mode: this can be "Block I/O" where the RDS blocks have to be read() - by the application, or "Controls" where the RDS data is provided by - the RDS controls mentioned above. - - -Section 9.7: FM Radio Modulator Controls ----------------------------------------- - -RDS Program ID: -RDS Program Type: -RDS PS Name: -RDS Radio Text: -RDS Stereo: -RDS Artificial Head: -RDS Compressed: -RDS Dynamic PTY: -RDS Traffic Announcement: -RDS Traffic Program: -RDS Music: these are all controls that set the RDS data that is transmitted by - the FM modulator. - -RDS Tx I/O Mode: this can be "Block I/O" where the application has to use write() - to pass the RDS blocks to the driver, or "Controls" where the RDS data is - provided by the RDS controls mentioned above. - - -Section 10: Video, VBI and RDS Looping --------------------------------------- - -The vivid driver supports looping of video output to video input, VBI output -to VBI input and RDS output to RDS input. For video/VBI looping this emulates -as if a cable was hooked up between the output and input connector. So video -and VBI looping is only supported between S-Video and HDMI inputs and outputs. -VBI is only valid for S-Video as it makes no sense for HDMI. - -Since radio is wireless this looping always happens if the radio receiver -frequency is close to the radio transmitter frequency. In that case the radio -transmitter will 'override' the emulated radio stations. - -Looping is currently supported only between devices created by the same -vivid driver instance. - - -Section 10.1: Video and Sliced VBI looping ------------------------------------------- - -The way to enable video/VBI looping is currently fairly crude. A 'Loop Video' -control is available in the "Vivid" control class of the video -capture and VBI capture devices. When checked the video looping will be enabled. -Once enabled any video S-Video or HDMI input will show a static test pattern -until the video output has started. At that time the video output will be -looped to the video input provided that: - -- the input type matches the output type. So the HDMI input cannot receive - video from the S-Video output. - -- the video resolution of the video input must match that of the video output. - So it is not possible to loop a 50 Hz (720x576) S-Video output to a 60 Hz - (720x480) S-Video input, or a 720p60 HDMI output to a 1080p30 input. - -- the pixel formats must be identical on both sides. Otherwise the driver would - have to do pixel format conversion as well, and that's taking things too far. - -- the field settings must be identical on both sides. Same reason as above: - requiring the driver to convert from one field format to another complicated - matters too much. This also prohibits capturing with 'Field Top' or 'Field - Bottom' when the output video is set to 'Field Alternate'. This combination, - while legal, became too complicated to support. Both sides have to be 'Field - Alternate' for this to work. Also note that for this specific case the - sequence and field counting in struct v4l2_buffer on the capture side may not - be 100% accurate. - -- field settings V4L2_FIELD_SEQ_TB/BT are not supported. While it is possible to - implement this, it would mean a lot of work to get this right. Since these - field values are rarely used the decision was made not to implement this for - now. - -- on the input side the "Standard Signal Mode" for the S-Video input or the - "DV Timings Signal Mode" for the HDMI input should be configured so that a - valid signal is passed to the video input. - -The framerates do not have to match, although this might change in the future. - -By default you will see the OSD text superimposed on top of the looped video. -This can be turned off by changing the "OSD Text Mode" control of the video -capture device. - -For VBI looping to work all of the above must be valid and in addition the vbi -output must be configured for sliced VBI. The VBI capture side can be configured -for either raw or sliced VBI. Note that at the moment only CC/XDS (60 Hz formats) -and WSS (50 Hz formats) VBI data is looped. Teletext VBI data is not looped. - - -Section 10.2: Radio & RDS Looping ---------------------------------- - -As mentioned in section 6 the radio receiver emulates stations are regular -frequency intervals. Depending on the frequency of the radio receiver a -signal strength value is calculated (this is returned by VIDIOC_G_TUNER). -However, it will also look at the frequency set by the radio transmitter and -if that results in a higher signal strength than the settings of the radio -transmitter will be used as if it was a valid station. This also includes -the RDS data (if any) that the transmitter 'transmits'. This is received -faithfully on the receiver side. Note that when the driver is loaded the -frequencies of the radio receiver and transmitter are not identical, so -initially no looping takes place. - - -Section 11: Cropping, Composing, Scaling ----------------------------------------- - -This driver supports cropping, composing and scaling in any combination. Normally -which features are supported can be selected through the Vivid controls, -but it is also possible to hardcode it when the module is loaded through the -ccs_cap_mode and ccs_out_mode module options. See section 1 on the details of -these module options. - -This allows you to test your application for all these variations. - -Note that the webcam input never supports cropping, composing or scaling. That -only applies to the TV/S-Video/HDMI inputs and outputs. The reason is that -webcams, including this virtual implementation, normally use -VIDIOC_ENUM_FRAMESIZES to list a set of discrete framesizes that it supports. -And that does not combine with cropping, composing or scaling. This is -primarily a limitation of the V4L2 API which is carefully reproduced here. - -The minimum and maximum resolutions that the scaler can achieve are 16x16 and -(4096 * 4) x (2160 x 4), but it can only scale up or down by a factor of 4 or -less. So for a source resolution of 1280x720 the minimum the scaler can do is -320x180 and the maximum is 5120x2880. You can play around with this using the -qv4l2 test tool and you will see these dependencies. - -This driver also supports larger 'bytesperline' settings, something that -VIDIOC_S_FMT allows but that few drivers implement. - -The scaler is a simple scaler that uses the Coarse Bresenham algorithm. It's -designed for speed and simplicity, not quality. - -If the combination of crop, compose and scaling allows it, then it is possible -to change crop and compose rectangles on the fly. - - -Section 12: Formats -------------------- - -The driver supports all the regular packed and planar 4:4:4, 4:2:2 and 4:2:0 -YUYV formats, 8, 16, 24 and 32 RGB packed formats and various multiplanar -formats. - -The alpha component can be set through the 'Alpha Component' User control -for those formats that support it. If the 'Apply Alpha To Red Only' control -is set, then the alpha component is only used for the color red and set to -0 otherwise. - -The driver has to be configured to support the multiplanar formats. By default -the driver instances are single-planar. This can be changed by setting the -multiplanar module option, see section 1 for more details on that option. - -If the driver instance is using the multiplanar formats/API, then the first -single planar format (YUYV) and the multiplanar NV16M and NV61M formats the -will have a plane that has a non-zero data_offset of 128 bytes. It is rare for -data_offset to be non-zero, so this is a useful feature for testing applications. - -Video output will also honor any data_offset that the application set. - - -Section 13: Capture Overlay ---------------------------- - -Note: capture overlay support is implemented primarily to test the existing -V4L2 capture overlay API. In practice few if any GPUs support such overlays -anymore, and neither are they generally needed anymore since modern hardware -is so much more capable. By setting flag 0x10000 in the node_types module -option the vivid driver will create a simple framebuffer device that can be -used for testing this API. Whether this API should be used for new drivers is -questionable. - -This driver has support for a destructive capture overlay with bitmap clipping -and list clipping (up to 16 rectangles) capabilities. Overlays are not -supported for multiplanar formats. It also honors the struct v4l2_window field -setting: if it is set to FIELD_TOP or FIELD_BOTTOM and the capture setting is -FIELD_ALTERNATE, then only the top or bottom fields will be copied to the overlay. - -The overlay only works if you are also capturing at that same time. This is a -vivid limitation since it copies from a buffer to the overlay instead of -filling the overlay directly. And if you are not capturing, then no buffers -are available to fill. - -In addition, the pixelformat of the capture format and that of the framebuffer -must be the same for the overlay to work. Otherwise VIDIOC_OVERLAY will return -an error. - -In order to really see what it going on you will need to create two vivid -instances: the first with a framebuffer enabled. You configure the capture -overlay of the second instance to use the framebuffer of the first, then -you start capturing in the second instance. For the first instance you setup -the output overlay for the video output, turn on video looping and capture -to see the blended framebuffer overlay that's being written to by the second -instance. This setup would require the following commands: - - $ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1 - $ v4l2-ctl -d1 --find-fb - /dev/fb1 is the framebuffer associated with base address 0x12800000 - $ sudo v4l2-ctl -d2 --set-fbuf fb=1 - $ v4l2-ctl -d1 --set-fbuf fb=1 - $ v4l2-ctl -d0 --set-fmt-video=pixelformat='AR15' - $ v4l2-ctl -d1 --set-fmt-video-out=pixelformat='AR15' - $ v4l2-ctl -d2 --set-fmt-video=pixelformat='AR15' - $ v4l2-ctl -d0 -i2 - $ v4l2-ctl -d2 -i2 - $ v4l2-ctl -d2 -c horizontal_movement=4 - $ v4l2-ctl -d1 --overlay=1 - $ v4l2-ctl -d1 -c loop_video=1 - $ v4l2-ctl -d2 --stream-mmap --overlay=1 - -And from another console: - - $ v4l2-ctl -d1 --stream-out-mmap - -And yet another console: - - $ qv4l2 - -and start streaming. - -As you can see, this is not for the faint of heart... - - -Section 14: Output Overlay --------------------------- - -Note: output overlays are primarily implemented in order to test the existing -V4L2 output overlay API. Whether this API should be used for new drivers is -questionable. - -This driver has support for an output overlay and is capable of: - - - bitmap clipping, - - list clipping (up to 16 rectangles) - - chromakey - - source chromakey - - global alpha - - local alpha - - local inverse alpha - -Output overlays are not supported for multiplanar formats. In addition, the -pixelformat of the capture format and that of the framebuffer must be the -same for the overlay to work. Otherwise VIDIOC_OVERLAY will return an error. - -Output overlays only work if the driver has been configured to create a -framebuffer by setting flag 0x10000 in the node_types module option. The -created framebuffer has a size of 720x576 and supports ARGB 1:5:5:5 and -RGB 5:6:5. - -In order to see the effects of the various clipping, chromakeying or alpha -processing capabilities you need to turn on video looping and see the results -on the capture side. The use of the clipping, chromakeying or alpha processing -capabilities will slow down the video loop considerably as a lot of checks have -to be done per pixel. - - -Section 15: Some Future Improvements ------------------------------------- - -Just as a reminder and in no particular order: - -- Add a virtual alsa driver to test audio -- Add virtual sub-devices and media controller support -- Some support for testing compressed video -- Add support to loop raw VBI output to raw VBI input -- Add support to loop teletext sliced VBI output to VBI input -- Fix sequence/field numbering when looping of video with alternate fields -- Add support for V4L2_CID_BG_COLOR for video outputs -- Add ARGB888 overlay support: better testing of the alpha channel -- Add custom DV timings support -- Add support for V4L2_DV_FL_REDUCED_FPS -- Improve pixel aspect support in the tpg code by passing a real v4l2_fract -- Use per-queue locks and/or per-device locks to improve throughput -- Add support to loop from a specific output to a specific input across - vivid instances -- The SDR radio should use the same 'frequencies' for stations as the normal - radio receiver, and give back noise if the frequency doesn't match up with - a station frequency -- Make a thread for the RDS generation, that would help in particular for the - "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated - in real-time. diff --git a/Documentation/video4linux/zr364xx.txt b/Documentation/video4linux/zr364xx.txt deleted file mode 100644 index d98e4d302..000000000 --- a/Documentation/video4linux/zr364xx.txt +++ /dev/null @@ -1,69 +0,0 @@ -Zoran 364xx based USB webcam module version 0.72 -site: http://royale.zerezo.com/zr364xx/ -mail: royale@zerezo.com - -introduction: -This brings support under Linux for the Aiptek PocketDV 3300 in webcam mode. -If you just want to get on your PC the pictures and movies on the camera, you should use the usb-storage module instead. -The driver works with several other cameras in webcam mode (see the list below). -Maybe this code can work for other JPEG/USB cams based on the Coach chips from Zoran? -Possible chipsets are : ZR36430 (ZR36430BGC) and maybe ZR36431, ZR36440, ZR36442... -You can try the experience changing the vendor/product ID values (look at the source code). -You can get these values by looking at /var/log/messages when you plug your camera, or by typing : cat /proc/bus/usb/devices. -If you manage to use your cam with this code, you can send me a mail (royale@zerezo.com) with the name of your cam and a patch if needed. -This is a beta release of the driver. -Since version 0.70, this driver is only compatible with V4L2 API and 2.6.x kernels. -If you need V4L1 or 2.4x kernels support, please use an older version, but the code is not maintained anymore. -Good luck! - -install: -In order to use this driver, you must compile it with your kernel. -Location: Device Drivers -> Multimedia devices -> Video For Linux -> Video Capture Adapters -> V4L USB devices - -usage: -modprobe zr364xx debug=X mode=Y - - debug : set to 1 to enable verbose debug messages - - mode : 0 = 320x240, 1 = 160x120, 2 = 640x480 -You can then use the camera with V4L2 compatible applications, for example Ekiga. -To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M count=1 - -links : -http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV) -http://www.harmwal.nl/pccam880/ (this project also supports cameras based on this chipset) - -supported devices: ------- ------- ----------- ----- -Vendor Product Distributor Model ------- ------- ----------- ----- -0x08ca 0x0109 Aiptek PocketDV 3300 -0x08ca 0x0109 Maxell Maxcam PRO DV3 -0x041e 0x4024 Creative PC-CAM 880 -0x0d64 0x0108 Aiptek Fidelity 3200 -0x0d64 0x0108 Praktica DCZ 1.3 S -0x0d64 0x0108 Genius Digital Camera (?) -0x0d64 0x0108 DXG Technology Fashion Cam -0x0546 0x3187 Polaroid iON 230 -0x0d64 0x3108 Praktica Exakta DC 2200 -0x0d64 0x3108 Genius G-Shot D211 -0x0595 0x4343 Concord Eye-Q Duo 1300 -0x0595 0x4343 Concord Eye-Q Duo 2000 -0x0595 0x4343 Fujifilm EX-10 -0x0595 0x4343 Ricoh RDC-6000 -0x0595 0x4343 Digitrex DSC 1300 -0x0595 0x4343 Firstline FDC 2000 -0x0bb0 0x500d Concord EyeQ Go Wireless -0x0feb 0x2004 CRS Electronic 3.3 Digital Camera -0x0feb 0x2004 Packard Bell DSC-300 -0x055f 0xb500 Mustek MDC 3000 -0x08ca 0x2062 Aiptek PocketDV 5700 -0x052b 0x1a18 Chiphead Megapix V12 -0x04c8 0x0729 Konica Revio 2 -0x04f2 0xa208 Creative PC-CAM 850 -0x0784 0x0040 Traveler Slimline X5 -0x06d6 0x0034 Trust Powerc@m 750 -0x0a17 0x0062 Pentax Optio 50L -0x06d6 0x003b Trust Powerc@m 970Z -0x0a17 0x004e Pentax Optio 50 -0x041e 0x405d Creative DiVi CAM 516 -0x08ca 0x2102 Aiptek DV T300 -0x06d6 0x003d Trust Powerc@m 910Z |