diff options
| author | Timothy Pearson <tpearson@raptorengineering.com> | 2017-08-23 14:45:25 -0500 |
|---|---|---|
| committer | Timothy Pearson <tpearson@raptorengineering.com> | 2017-08-23 14:45:25 -0500 |
| commit | fcbb27b0ec6dcbc5a5108cb8fb19eae64593d204 (patch) | |
| tree | 22962a4387943edc841c72a4e636a068c66d58fd /Documentation/video4linux | |
| download | ast2050-linux-kernel-fcbb27b0ec6dcbc5a5108cb8fb19eae64593d204.zip ast2050-linux-kernel-fcbb27b0ec6dcbc5a5108cb8fb19eae64593d204.tar.gz | |
Initial import of modified Linux 2.6.28 tree
Original upstream URL:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git | branch linux-2.6.28.y
Diffstat (limited to 'Documentation/video4linux')
72 files changed, 11655 insertions, 0 deletions
diff --git a/Documentation/video4linux/.gitignore b/Documentation/video4linux/.gitignore new file mode 100644 index 0000000..9527039 --- /dev/null +++ b/Documentation/video4linux/.gitignore @@ -0,0 +1 @@ +v4lgrab diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html new file mode 100644 index 0000000..afbe9ae --- /dev/null +++ b/Documentation/video4linux/API.html @@ -0,0 +1,16 @@ +<TITLE>V4L API</TITLE> +<H1>Video For Linux APIs</H1> +<table border=0> +<tr> +<td> +<A HREF=http://www.linuxtv.org/downloads/video4linux/API/V4L1_API.html> +V4L original API</a> +</td><td> +Obsoleted by V4L2 API +</td></tr><tr><td> +<A HREF=http://www.linuxtv.org/downloads/video4linux/API/V4L2_API> +V4L2 API</a> +</td><td> +Should be used for new projects +</td></tr> +</table> diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 new file mode 100644 index 0000000..d5cb4ea --- /dev/null +++ b/Documentation/video4linux/CARDLIST.au0828 @@ -0,0 +1,6 @@ + 0 -> Unknown board (au0828) + 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008] + 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) [2040:8200] diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv new file mode 100644 index 0000000..60ba668 --- /dev/null +++ b/Documentation/video4linux/CARDLIST.bttv @@ -0,0 +1,153 @@ + 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 [6000:0311] + 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] +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 MiniDIN (bt878) +107 -> PHYTEC VD-009-X1 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 +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] diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 new file mode 100644 index 0000000..64823cc --- /dev/null +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -0,0 +1,13 @@ + 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] diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 new file mode 100644 index 0000000..a5227e3 --- /dev/null +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -0,0 +1,76 @@ + 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] + 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] + 9 -> Leadtek PVR 2000 [107d:663b,107d:663c,107d:6632] + 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 -> Winfast TV2000 XP Global [107d:6f18] + 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] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx new file mode 100644 index 0000000..187cc48 --- /dev/null +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -0,0 +1,59 @@ + 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] + 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2820,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] + 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/DVC 100 (em2820/em2840) [2304:0207,2304:021a] + 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] + 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] + 12 -> Kworld PVR TV 2800 RF (em2820/em2840) + 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] + 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) [eb1a:2821] + 15 -> V-Gear PocketTV (em2800) + 16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b,2040:651f] + 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] + 18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502] + 19 -> PointNix Intra-Oral Camera (em2860) + 20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002] + 21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801] + 22 -> Unknown 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 -> Pinnacle Dazzle DVC 100 (em2820/em2840) + 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) + 31 -> Usbgear VD204v9 (em2821) + 32 -> Supercomp USB 2.0 TV (em2821) + 33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821) + 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] + 35 -> Typhoon DVD Maker (em2860) + 36 -> NetGMBH Cam (em2860) + 37 -> Gadmei UTV330 (em2860) + 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] + 43 -> Terratec Cinergy T XS (em2870) [0ccd:0043] + 44 -> Terratec Cinergy T XS (MT2060) (em2870) + 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) [eb1a:e310] + 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 Hybrid XS (em2882) (em2882) [0ccd:005e] + 56 -> Pinnacle Hybrid Pro (2) (em2882) [2304:0226] + 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] + 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] diff --git a/Documentation/video4linux/CARDLIST.ivtv b/Documentation/video4linux/CARDLIST.ivtv new file mode 100644 index 0000000..a019e27 --- /dev/null +++ b/Documentation/video4linux/CARDLIST.ivtv @@ -0,0 +1,24 @@ + 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 new file mode 100644 index 0000000..dc67eef --- /dev/null +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -0,0 +1,153 @@ + 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] + 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/RDS [0000:5051,0000:505B,5ace:5050] +127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090] +128 -> Beholder BeholdTV Columbus TVFM [0000:5201] +129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093] +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] +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] diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner new file mode 100644 index 0000000..691d2f3 --- /dev/null +++ b/Documentation/video4linux/CARDLIST.tuner @@ -0,0 +1,78 @@ +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 diff --git a/Documentation/video4linux/CARDLIST.usbvision b/Documentation/video4linux/CARDLIST.usbvision new file mode 100644 index 0000000..0b72d3f --- /dev/null +++ b/Documentation/video4linux/CARDLIST.usbvision @@ -0,0 +1,65 @@ + 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] diff --git a/Documentation/video4linux/CQcam.txt b/Documentation/video4linux/CQcam.txt new file mode 100644 index 0000000..04986ef --- /dev/null +++ b/Documentation/video4linux/CQcam.txt @@ -0,0 +1,215 @@ +c-qcam - Connectix Color QuickCam video4linux kernel driver + +Copyright (C) 1999 Dave Forrest <drf5n@virginia.edu> + released under GNU GPL. + +1999-12-08 Dave Forrest, written with kernel version 2.2.12 in mind + + +Table of Contents + +1.0 Introduction +2.0 Compilation, Installation, and Configuration +3.0 Troubleshooting +4.0 Future Work / current work arounds +9.0 Sample Program, v4lgrab +10.0 Other Information + + +1.0 Introduction + + The file ../drivers/char/c-qcam.c is a device driver for the +Logitech (nee Connectix) parallel port interface color CCD camera. +This is a fairly inexpensive device for capturing images. Logitech +does not currently provide information for developers, but many people +have engineered several solutions for non-Microsoft use of the Color +Quickcam. + +1.1 Motivation + + I spent a number of hours trying to get my camera to work, and I +hope this document saves you some time. My camera will not work with +the 2.2.13 kernel as distributed, but with a few patches to the +module, I was able to grab some frames. See 4.0, Future Work. + + + +2.0 Compilation, Installation, and Configuration + + The c-qcam depends on parallel port support, video4linux, and the +Color Quickcam. It is also nice to have the parallel port readback +support enabled. I enabled these as modules during the kernel +configuration. The appropriate flags are: + + CONFIG_PRINTER M for lp.o, parport.o parport_pc.o modules + CONFIG_PNP_PARPORT M for autoprobe.o IEEE1284 readback module + CONFIG_PRINTER_READBACK M for parport_probe.o IEEE1284 readback module + CONFIG_VIDEO_DEV M for videodev.o video4linux module + CONFIG_VIDEO_CQCAM M for c-qcam.o Color Quickcam module + + With these flags, the kernel should compile and install the modules. +To record and monitor the compilation, I use: + + (make zlilo ; \ + make modules; \ + make modules_install ; + depmod -a ) &>log & + less log # then a capital 'F' to watch the progress + +But that is my personal preference. + +2.2 Configuration + + The configuration requires module configuration and device +configuration. I like kmod or kerneld process with the +/etc/modprobe.conf file so the modules can automatically load/unload as +they are used. The video devices could already exist, be generated +using MAKEDEV, or need to be created. The following sections detail +these procedures. + + +2.1 Module Configuration + + Using modules requires a bit of work to install and pass the +parameters. Understand that entries in /etc/modprobe.conf of: + + alias parport_lowlevel parport_pc + options parport_pc io=0x378 irq=none + alias char-major-81 videodev + alias char-major-81-0 c-qcam + +will cause the kmod/modprobe to do certain things. If you are +using kmod, then a request for a 'char-major-81-0' will cause +the 'c-qcam' module to load. If you have other video sources with +modules, you might want to assign the different minor numbers to +different modules. + +2.2 Device Configuration + + At this point, we need to ensure that the device files exist. +Video4linux used the /dev/video* files, and we want to attach the +Quickcam to one of these. + + ls -lad /dev/video* # should produce a list of the video devices + +If the video devices do not exist, you can create them with: + + su + cd /dev + for ii in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do + mknod video$ii c 81 $ii # char-major-81-[0-16] + chown root.root video$ii # owned by root + chmod 600 video$ii # read/writable by root only + done + + Lots of people connect video0 to video and bttv, but you might want +your c-qcam to mean something more: + + ln -s video0 c-qcam # make /dev/c-qcam a working file + ln -s c-qcam video # make /dev/c-qcam your default video source + + But these are conveniences. The important part is to make the proper +special character files with the right major and minor numbers. All +of the special device files are listed in ../devices.txt. If you +would like the c-qcam readable by non-root users, you will need to +change the permissions. + +3.0 Troubleshooting + + If the sample program below, v4lgrab, gives you output then +everything is working. + + v4lgrab | wc # should give you a count of characters + + Otherwise, you have some problem. + + The c-qcam is IEEE1284 compatible, so if you are using the proc file +system (CONFIG_PROC_FS), the parallel printer support +(CONFIG_PRINTER), the IEEE 1284 system,(CONFIG_PRINTER_READBACK), you +should be able to read some identification from your quickcam with + + modprobe -v parport + modprobe -v parport_probe + cat /proc/parport/PORTNUMBER/autoprobe +Returns: + CLASS:MEDIA; + MODEL:Color QuickCam 2.0; + MANUFACTURER:Connectix; + + A good response to this indicates that your color quickcam is alive +and well. A common problem is that the current driver does not +reliably detect a c-qcam, even though one is attached. In this case, + + modprobe -v c-qcam +or + insmod -v c-qcam + + Returns a message saying "Device or resource busy" Development is +currently underway, but a workaround is to patch the module to skip +the detection code and attach to a defined port. Check the +video4linux mailing list and archive for more current information. + +3.1 Checklist: + + Can you get an image? + v4lgrab >qcam.ppm ; wc qcam.ppm ; xv qcam.ppm + + Is a working c-qcam connected to the port? + grep ^ /proc/parport/?/autoprobe + + Do the /dev/video* files exist? + ls -lad /dev/video + + Is the c-qcam module loaded? + modprobe -v c-qcam ; lsmod + + Does the camera work with alternate programs? cqcam, etc? + + + + +4.0 Future Work / current workarounds + + It is hoped that this section will soon become obsolete, but if it +isn't, you might try patching the c-qcam module to add a parport=xxx +option as in the bw-qcam module so you can specify the parallel port: + + insmod -v c-qcam parport=0 + +And bypass the detection code, see ../../drivers/char/c-qcam.c and +look for the 'qc_detect' code and call. + + Note that there is work in progress to change the video4linux API, +this work is documented at the video4linux2 site listed below. + + +9.0 --- A sample program using v4lgrabber, + +v4lgrab is a simple image grabber that will copy a frame from the +first video device, /dev/video0 to standard output in portable pixmap +format (.ppm) To produce .jpg output, you can use it like this: +'v4lgrab | convert - c-qcam.jpg' + + +10.0 --- Other Information + +Use the ../../Maintainers file, particularly the VIDEO FOR LINUX and PARALLEL +PORT SUPPORT sections + +The video4linux page: + http://linuxtv.org + +The V4L2 API spec: + http://v4l2spec.bytesex.org/ + +Some web pages about the quickcams: + http://www.dkfz-heidelberg.de/Macromol/wedemann/mini-HOWTO-cqcam.html + + http://www.crynwr.com/qcpc/ QuickCam Third-Party Drivers + http://www.crynwr.com/qcpc/re.html Some Reverse Engineering + http://cse.unl.edu/~cluening/gqcam/ v4l client + http://phobos.illtel.denver.co.us/pub/qcread/ doesn't use v4l + ftp://ftp.cs.unm.edu/pub/chris/quickcam/ Has lots of drivers + http://www.cs.duke.edu/~reynolds/quickcam/ Has lots of information + + diff --git a/Documentation/video4linux/Makefile b/Documentation/video4linux/Makefile new file mode 100644 index 0000000..1ed0e98 --- /dev/null +++ b/Documentation/video4linux/Makefile @@ -0,0 +1,8 @@ +# kbuild trick to avoid linker error. Can be omitted if a module is built. +obj- := dummy.o + +# List of programs to build +hostprogs-y := v4lgrab + +# Tell kbuild to always build the programs +always := $(hostprogs-y) diff --git a/Documentation/video4linux/README.cpia b/Documentation/video4linux/README.cpia new file mode 100644 index 0000000..19cd3bf --- /dev/null +++ b/Documentation/video4linux/README.cpia @@ -0,0 +1,191 @@ +This is a driver for the CPiA PPC2 driven parallel connected +Camera. For example the Creative WebcamII is CPiA driven. + + ) [1]Peter Pregler, Linz 2000, published under the [2]GNU GPL + +--------------------------------------------------------------------------- + +USAGE: + +General: +======== + +1) Make sure you have created the video devices (/dev/video*): + +- if you have a recent MAKEDEV do a 'cd /dev;./MAKEDEV video' +- otherwise do a: + +cd /dev +mknod video0 c 81 0 +ln -s video0 video + +2) Compile the kernel (see below for the list of options to use), + configure your parport and reboot. + +3) If all worked well you should get messages similar + to the following (your versions may be different) on the console: + +V4L-Driver for Vision CPiA based cameras v0.7.4 +parport0: read2 timeout. +parport0: Multimedia device, VLSI Vision Ltd PPC2 +Parallel port driver for Vision CPiA based camera + CPIA Version: 1.20 (2.0) + CPIA PnP-ID: 0553:0002:0100 + VP-Version: 1.0 0100 + 1 camera(s) found + + +As modules: +=========== + +Make sure you have selected the following kernel options (you can +select all stuff as modules): + +The cpia-stuff is in the section 'Character devices -> Video For Linux'. + +CONFIG_PARPORT=m +CONFIG_PARPORT_PC=m +CONFIG_PARPORT_PC_FIFO=y +CONFIG_PARPORT_1284=y +CONFIG_VIDEO_DEV=m +CONFIG_VIDEO_CPIA=m +CONFIG_VIDEO_CPIA_PP=m + +For autoloading of all those modules you need to tell module-init-tools +some stuff. Add the following line to your module-init-tools config-file +(e.g. /etc/modprobe.conf or wherever your distribution does store that +stuff): + +options parport_pc io=0x378 irq=7 dma=3 +alias char-major-81 cpia_pp + +The first line tells the dma/irq channels to use. Those _must_ match +the settings of your BIOS. Do NOT simply use the values above. See +Documentation/parport.txt for more information about this. The second +line associates the video-device file with the driver. Of cause you +can also load the modules once upon boot (usually done in /etc/modules). + +Linked into the kernel: +======================= + +Make sure you have selected the following kernel options. Note that +you cannot compile the parport-stuff as modules and the cpia-driver +statically (the other way round is okay though). + +The cpia-stuff is in the section 'Character devices -> Video For Linux'. + +CONFIG_PARPORT=y +CONFIG_PARPORT_PC=y +CONFIG_PARPORT_PC_FIFO=y +CONFIG_PARPORT_1284=y +CONFIG_VIDEO_DEV=y +CONFIG_VIDEO_CPIA=y +CONFIG_VIDEO_CPIA_PP=y + +To use DMA/irq you will need to tell the kernel upon boot time the +hardware configuration of the parport. You can give the boot-parameter +at the LILO-prompt or specify it in lilo.conf. I use the following +append-line in lilo.conf: + + append="parport=0x378,7,3" + +See Documentation/parport.txt for more information about the +configuration of the parport and the values given above. Do not simply +use the values given above. + +--------------------------------------------------------------------------- +FEATURES: + +- mmap/read v4l-interface (but no overlay) +- image formats: CIF/QCIF, SIF/QSIF, various others used by isabel; + note: all sizes except CIF/QCIF are implemented by clipping, i.e. + pixels are not uploaded from the camera +- palettes: VIDEO_PALETTE_GRAY, VIDEO_PALETTE_RGB565, VIDEO_PALETTE_RGB555, + VIDEO_PALETTE_RGB24, VIDEO_PALETTE_RGB32, VIDEO_PALETTE_YUYV, + VIDEO_PALETTE_UYVY, VIDEO_PALETTE_YUV422 +- state information (color balance, exposure, ...) is preserved between + device opens +- complete control over camera via proc-interface (_all_ camera settings are + supported), there is also a python-gtk application available for this [3] +- works under SMP (but the driver is completely serialized and synchronous) + so you get no benefit from SMP, but at least it does not crash your box +- might work for non-Intel architecture, let us know about this + +--------------------------------------------------------------------------- +TESTED APPLICATIONS: + +- a simple test application based on Xt is available at [3] +- another test-application based on gqcam-0.4 (uses GTK) +- gqcam-0.6 should work +- xawtv-3.x (also the webcam software) +- xawtv-2.46 +- w3cam (cgi-interface and vidcat, e.g. you may try out 'vidcat |xv + -maxpect -root -quit +noresetroot -rmode 5 -') +- vic, the MBONE video conferencing tool (version 2.8ucl4-1) +- isabel 3R4beta (barely working, but AFAICT all the problems are on + their side) +- camserv-0.40 + +See [3] for pointers to v4l-applications. + +--------------------------------------------------------------------------- +KNOWN PROBLEMS: + +- some applications do not handle the image format correctly, you will + see strange horizontal stripes instead of a nice picture -> make sure + your application does use a supported image size or queries the driver + for the actually used size (reason behind this: the camera cannot + provide any image format, so if size NxM is requested the driver will + use a format to the closest fitting N1xM1, the application should now + query for this granted size, most applications do not). +- all the todo ;) +- if there is not enough light and the picture is too dark try to + adjust the SetSensorFPS setting, automatic frame rate adjustment + has its price +- do not try out isabel 3R4beta (built 135), you will be disappointed + +--------------------------------------------------------------------------- +TODO: + +- multiple camera support (struct camera or something) - This should work, + but hasn't been tested yet. +- architecture independence? +- SMP-safe asynchronous mmap interface +- nibble mode for old parport interfaces +- streaming capture, this should give a performance gain + +--------------------------------------------------------------------------- +IMPLEMENTATION NOTES: + +The camera can act in two modes, streaming or grabbing. Right now a +polling grab-scheme is used. Maybe interrupt driven streaming will be +used for a asynchronous mmap interface in the next major release of the +driver. This might give a better frame rate. + +--------------------------------------------------------------------------- +THANKS (in no particular order): + +- Scott J. Bertin <sbertin@mindspring.com> for cleanups, the proc-filesystem + and much more +- Henry Bruce <whb@vvl.co.uk> for providing developers information about + the CPiA chip, I wish all companies would treat Linux as seriously +- Karoly Erdei <Karoly.Erdei@risc.uni-linz.ac.at> and RISC-Linz for being + my boss ;) resp. my employer and for providing me the hardware and + allow me to devote some working time to this project +- Manuel J. Petit de Gabriel <mpetit@dit.upm.es> for providing help + with Isabel (http://isabel.dit.upm.es/) +- Bas Huisman <bhuism@cs.utwente.nl> for writing the initial parport code +- Jarl Totland <Jarl.Totland@bdc.no> for setting up the mailing list + and maintaining the web-server[3] +- Chris Whiteford <Chris@informinteractive.com> for fixes related to the + 1.02 firmware +- special kudos to all the tester whose machines crashed and/or + will crash. :) + +--------------------------------------------------------------------------- +REFERENCES + + 1. http://www.risc.uni-linz.ac.at/people/ppregler + mailto:Peter_Pregler@email.com + 2. see the file COPYING in the top directory of the kernel tree + 3. http://webcam.sourceforge.net/ diff --git a/Documentation/video4linux/README.cpia2 b/Documentation/video4linux/README.cpia2 new file mode 100644 index 0000000..ce8213d --- /dev/null +++ b/Documentation/video4linux/README.cpia2 @@ -0,0 +1,130 @@ +$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 separted 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 new file mode 100644 index 0000000..166d596 --- /dev/null +++ b/Documentation/video4linux/README.cx88 @@ -0,0 +1,69 @@ + +cx8800 release notes +==================== + +This is a v4l2 device driver for the cx2388x chip. + + +current status +============== + +video + - Basically works. + - Some minor image quality glitches. + - For now only capture, overlay support isn't completed yet. + +audio + - The chip specs for the on-chip TV sound decoder are next + to useless :-/ + - Neverless the builtin TV sound decoder starts working now, + at least for PAL-BG. Other TV norms need other code ... + FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE + USING. + - Most tuner chips do provide mono sound, which may or may not + be useable depending on the board design. With the Hauppauge + cards it works, so there is mono sound available as fallback. + - audio data dma (i.e. recording without loopback cable to the + sound card) should be possible, but there is no code yet ... + +vbi + - 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 informations to add the card: + + * the PCI Subsystem ID ("0070:3400" from the line above, + "lspci -v" output is fine too). + * the tuner type used by the card. You can try to find one by + trial-and-error using the tuner=<n> insmod option. If you + know which one the card has you can also have a look at the + list in CARDLIST.tuner + +Have fun, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> [SuSE Labs] diff --git a/Documentation/video4linux/README.ir b/Documentation/video4linux/README.ir new file mode 100644 index 0000000..0da47a8 --- /dev/null +++ b/Documentation/video4linux/README.ir @@ -0,0 +1,72 @@ + +infrared remote control support in video4linux drivers +====================================================== + + +basics +------ + +Current versions use the linux input layer to support infrared +remote controls. I suggest to download my input layer tools +from http://bytesex.org/snapshot/input-<date>.tar.gz + +Modules you have to load: + + saa7134 statically built in, i.e. just the driver :) + bttv ir-kbd-gpio or ir-kbd-i2c depending on your + card. + +ir-kbd-gpio and ir-kbd-i2c don't support all cards lirc supports +(yet), mainly for the reason that the code of lirc_i2c and lirc_gpio +was very confusing and I decided to basically start over from scratch. +Feel free to contact me in case of trouble. Note that the ir-kbd-* +modules work on 2.6.x kernels only through ... + + +how it works +------------ + +The modules register the remote as keyboard within the linux input +layer, i.e. you'll see the keys of the remote as normal key strokes +(if CONFIG_INPUT_KEYBOARD is enabled). + +Using the event devices (CONFIG_INPUT_EVDEV) it is possible for +applications to access the remote via /dev/input/event<n> devices. +You might have to create the special files using "/sbin/MAKEDEV +input". The input layer tools mentioned above use the event device. + +The input layer tools are nice for trouble shooting, i.e. to check +whenever the input device is really present, which of the devices it +is, check whenever pressing keys on the remote actually generates +events and the like. You can also use the kbd utility to change the +keymaps (2.6.x kernels only through). + + +using with lircd +================ + +The cvs version of the lircd daemon supports reading events from the +linux input layer (via event device). The input layer tools tarball +comes with a lircd config file. + + +using without lircd +=================== + +XFree86 likely can be configured to recognise the remote keys. Once I +simply tried to configure one of the multimedia keyboards as input +device, which had the effect that XFree86 recognised some of the keys +of my remote control and passed volume up/down key presses as +XF86AudioRaiseVolume and XF86AudioLowerVolume key events to the X11 +clients. + +It likely is possible to make that fly with a nice xkb config file, +I know next to nothing about that through. + + +Have fun, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> diff --git a/Documentation/video4linux/README.ivtv b/Documentation/video4linux/README.ivtv new file mode 100644 index 0000000..73df22c --- /dev/null +++ b/Documentation/video4linux/README.ivtv @@ -0,0 +1,187 @@ + +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/firmware.tar.gz + +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) (this framebuffer is not yet part of the kernel. In the meantime it + is available from www.ivtvdriver.org). + * 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 new file mode 100644 index 0000000..a747200 --- /dev/null +++ b/Documentation/video4linux/README.pvrusb2 @@ -0,0 +1,212 @@ + +$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 additonal 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 new file mode 100644 index 0000000..b911f08 --- /dev/null +++ b/Documentation/video4linux/README.saa7134 @@ -0,0 +1,82 @@ + + +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 new file mode 100644 index 0000000..295462b --- /dev/null +++ b/Documentation/video4linux/Zoran @@ -0,0 +1,580 @@ +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 +Note: use encoder=X or decoder=X for non-default i2c chips (see i2c-id.h) + +=========================== + +1.1 What the TV decoder can do an what not + +The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that +information is not enough. There are several formats of the TV standards. +And not every TV decoder is able to handle every format. Also the every +combination is supported by the driver. There are currently 11 different +tv broadcast formats all aver the world. + +The CCIR defines parameters needed for broadcasting the signal. +The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,... +The CCIR says not much about the colorsystem used !!! +And talking about a colorsystem says not to much about how it is broadcast. + +The CCIR standards A,E,F are not used any more. + +When you speak about NTSC, you usually mean the standard: CCIR - M using +the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada +and a few others. + +When you talk about PAL, you usually mean: CCIR - B/G using the PAL +colorsystem which is used in many Countries. + +When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem +which is used in France, and a few others. + +There the other version of SECAM, CCIR - D/K is used in Bulgaria, China, +Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others. + +The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in +Egypt, Libya, Sri Lanka, Syrain Arab. Rep. + +The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong, +Ireland, Nigeria, South Africa. + +The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate, +and is used in Argentinia, Uruguay, an a few others + +We do not talk about how the audio is broadcast ! + +A rather good sites about the TV standards are: +http://www.sony.jp/ServiceArea/Voltage_map/ +http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/ +and http://www.cabl.com/restaurant/channel.html + +Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly +used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same +as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would +be the same as NTSC 4.43. +NTSC Combs seems to be a decoder mode where the decoder uses a comb filter +to split coma and luma instead of a Delay line. + +But I did not defiantly find out what NTSC Comb is. + +Philips saa7111 TV decoder +was introduced in 1997, is used in the BUZ and +can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM + +Philips saa7110a TV decoder +was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and +can handle: PAL B/G, NTSC M and SECAM + +Philips saa7114 TV decoder +was introduced in 2000, is used in the LML33R10 and +can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM + +Brooktree bt819 TV decoder +was introduced in 1996, and is used in the LML33 and +can handle: PAL B/D/G/H/I, NTSC M + +Micronas vpx3220a TV decoder +was introduced in 1996, is used in the DC30 and DC30+ and +can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb + +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.conf: + +options zr36067 card=X1[,X2[,X3[,X4[..]]]] +alias char-major-81-0 zr36067 + +One thing to keep in mind is that this doesn't load zr36067.o itself yet. It +just automates loading. If you start using xawtv, the device won't load on +some systems, since you're trying to load modules as a user, which is not +allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to +XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in +one of your startup scripts (normally rc.local) if you don't use X. Both +make sure that the modules are loaded on startup, under the root account. + +=========================== + +3. What mainboard should I use (or why doesn't my card work) + +<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA. + +Experience tells us that people with a Buz, on average, have more problems +than users with a DC10+/LML33. Also, it tells us that people owning a VIA- +based mainboard (ktXXX, MVP3) have more problems than users with a mainboard +based on a different chipset. Here's some notes from Andrew Stevens: +-- +Here's my experience of using LML33 and Buz on various motherboards: + +VIA MVP3 + Forget it. Pointless. Doesn't work. +Intel 430FX (Pentium 200) + LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie) +Intel 440BX (early stepping) + LML33 tolerable. Buz starting to get annoying (6-10 frames/hour) +Intel 440BX (late stepping) + Buz tolerable, LML3 almost perfect (occasional single frame drops) +SiS735 + LML33 perfect, Buz tolerable. +VIA KT133(*) + LML33 starting to get annoying, Buz poor enough that I have up. + +Both 440BX boards were dual CPU versions. +-- +Bernhard Praschinger later added: +-- +AMD 751 + Buz perfect-tolerable +AMD 760 + Buz perfect-tolerable +-- +In general, people on the user mailinglist won't give you much of a chance +if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd +rather want to spend some more money on better boards. In general, VIA +mainboard's IDE/PCI performance will also suck badly compared to others. +You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview. +Basically, you can assume that if the Buz works, the LML33 will work too. If +the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to +different mainboard chipsets from all of the supported cards. + +If you experience timeouts during capture, buy a better mainboard or lower +the quality/buffersize during capture (see 'Concerning buffer sizes, quality, +output size etc.'). If it hangs, there's little we can do as of now. Check +your IRQs and make sure the card has its own interrupts. + +=========================== + +4. Programming interface + +This driver conforms to video4linux and video4linux2, both can be used to +use the driver. Since video4linux didn't provide adequate calls to fully +use the cards' features, we've introduced several programming extensions, +which are currently officially accepted in the 2.4.x branch of the kernel. +These extensions are known as the v4l/mjpeg extensions. See zoran.h for +details (structs/ioctls). + +Information - video4linux: +http://roadrunner.swansea.linux.org.uk/v4lapi.shtml +Documentation/video4linux/API.html +/usr/include/linux/videodev.h + +Information - video4linux/mjpeg extensions: +./zoran.h +(also see below) + +Information - video4linux2: +http://linuxtv.org +http://v4l2spec.bytesex.org/ +/usr/include/linux/videodev2.h + +More information on the video4linux/mjpeg extensions, by Serguei +Miridonovi and Rainer Johanni: +-- +The ioctls for that interface are as follows: + +BUZIOC_G_PARAMS +BUZIOC_S_PARAMS + +Get and set the parameters of the buz. The user should always do a +BUZIOC_G_PARAMS (with a struct buz_params) to obtain the default +settings, change what he likes and then make a BUZIOC_S_PARAMS call. + +BUZIOC_REQBUFS + +Before being able to capture/playback, the user has to request +the buffers he is wanting to use. Fill the structure +zoran_requestbuffers with the size (recommended: 256*1024) and +the number (recommended 32 up to 256). There are no such restrictions +as for the Video for Linux buffers, you should LEAVE SUFFICIENT +MEMORY for your system however, else strange things will happen .... +On return, the zoran_requestbuffers structure contains number and +size of the actually allocated buffers. +You should use these numbers for doing a mmap of the buffers +into the user space. +The BUZIOC_REQBUFS ioctl also makes it happen, that the next mmap +maps the MJPEG buffer instead of the V4L buffers. + +BUZIOC_QBUF_CAPT +BUZIOC_QBUF_PLAY + +Queue a buffer for capture or playback. The first call also starts +streaming capture. When streaming capture is going on, you may +only queue further buffers or issue syncs until streaming +capture is switched off again with a argument of -1 to +a BUZIOC_QBUF_CAPT/BUZIOC_QBUF_PLAY ioctl. + +BUZIOC_SYNC + +Issue this ioctl when all buffers are queued. This ioctl will +block until the first buffer becomes free for saving its +data to disk (after BUZIOC_QBUF_CAPT) or for reuse (after BUZIOC_QBUF_PLAY). + +BUZIOC_G_STATUS + +Get the status of the input lines (video source connected/norm). + +For programming example, please, look at lavrec.c and lavplay.c code in +lavtools-1.2p2 package (URL: http://www.cicese.mx/~mirsev/DC10plus/) +and the 'examples' directory in the original Buz driver distribution. + +Additional notes for software developers: + + The driver returns maxwidth and maxheight parameters according to + the current TV standard (norm). Therefore, the software which + communicates with the driver and "asks" for these parameters should + first set the correct norm. Well, it seems logically correct: TV + standard is "more constant" for current country than geometry + settings of a variety of TV capture cards which may work in ITU or + square pixel format. Remember that users now can lock the norm to + avoid any ambiguity. +-- +Please note that lavplay/lavrec are also included in the MJPEG-tools +(http://mjpeg.sf.net/). + +=========================== + +5. Applications + +Applications known to work with this driver: + +TV viewing: +* xawtv +* kwintv +* probably any TV application that supports video4linux or video4linux2. + +MJPEG capture/playback: +* mjpegtools/lavtools (or Linux Video Studio) +* gstreamer +* mplayer + +General raw capture: +* xawtv +* gstreamer +* probably any application that supports video4linux or video4linux2 + +Video editing: +* Cinelerra +* MainActor +* mjpegtools (or Linux Video Studio) + +=========================== + +6. Concerning buffer sizes, quality, output size etc. + +The zr36060 can do 1:2 JPEG compression. This is really the theoretical +maximum that the chipset can reach. The driver can, however, limit compression +to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz) +can't handle 1:2 compression without stopping capture after only a few minutes. +With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into +1:4 max. compression mode. + +100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame +(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the +fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 = +414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT +(quantization) tables, and you'll get to something like 512kB per frame for +1:2 compression. For 1:4 compression, you'd have frames of half this size. + +Some additional explanation by Martin Samuelsson, which also explains the +importance of buffer sizes: +-- +> Hmm, I do not think it is really that way. With the current (downloaded +> at 18:00 Monday) driver I get that output sizes for 10 sec: +> -q 50 -b 128 : 24.283.332 Bytes +> -q 50 -b 256 : 48.442.368 +> -q 25 -b 128 : 24.655.992 +> -q 25 -b 256 : 25.859.820 + +I woke up, and can't go to sleep again. I'll kill some time explaining why +this doesn't look strange to me. + +Let's do some math using a width of 704 pixels. I'm not sure whether the Buz +actually use that number or not, but that's not too important right now. + +704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block; +3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block; +1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum +output becomes 512 bits per block. Actually 510, but 512 is simpler to use +for calculations. + +Let's say that we specify d1q50. We thus want 256 bits per block; times 3168 +becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes +here, so we don't need to do any fancy corrections for bits-per-pixel or such +things. 101376 bytes per field. + +d1 video contains two fields per frame. Those sum up to 202752 bytes per +frame, and one of those frames goes into each buffer. + +But wait a second! -b128 gives 128kB buffers! It's not possible to cram +202752 bytes of JPEG data into 128kB! + +This is what the driver notice and automatically compensate for in your +examples. Let's do some math using this information: + +128kB is 131072 bytes. In this buffer, we want to store two fields, which +leaves 65536 bytes for each field. Using 3168 blocks per field, we get +20.68686868... available bytes per block; 165 bits. We can't allow the +request for 256 bits per block when there's only 165 bits available! The -q50 +option is silently overridden, and the -b128 option takes precedence, leaving +us with the equivalence of -q32. + +This gives us a data rate of 165 bits per block, which, times 3168, sums up +to 65340 bytes per field, out of the allowed 65536. The current driver has +another level of rate limiting; it won't accept -q values that fill more than +6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be +a safe bet. Personally, I think I would have lowered requested-bits-per-block +by one, or something like that.) We can't use 165 bits per block, but have to +lower it again, to 6/8 of the available buffer space: We end up with 124 bits +per block, the equivalence of -q24. With 128kB buffers, you can't use greater +than -q24 at -d1. (And PAL, and 704 pixels width...) + +The third example is limited to -q24 through the same process. The second +example, using very similar calculations, is limited to -q48. The only +example that actually grab at the specified -q value is the last one, which +is clearly visible, looking at the file size. +-- + +Conclusion: the quality of the resulting movie depends on buffer size, quality, +whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c +module to do 1:4 instead of 1:2 compression, etc. + +If you experience timeouts, lowering the quality/buffersize or using +'low_bitrate=1 as insmod option for zr36060.o might actually help, as is +proven by the Buz. + +=========================== + +7. It hangs/crashes/fails/whatevers! Help! + +Make sure that the card has its own interrupts (see /proc/interrupts), check +the output of dmesg at high verbosity (load zr36067.o with debug=2, +load all other modules with debug=1). Check that your mainboard is favorable +(see question 2) and if not, test the card in another computer. Also see the +notes given in question 3 and try lowering quality/buffersize/capturesize +if recording fails after a period of time. + +If all this doesn't help, give a clear description of the problem including +detailed hardware information (memory+brand, mainboard+chipset+brand, which +MJPEG card, processor, other PCI cards that might be of interest), give the +system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give +the kernel version, driver version, glibc version, gcc version and any other +information that might possibly be of interest. Also provide the dmesg output +at high verbosity. See 'Contacting' on how to contact the developers. + +=========================== + +8. Maintainers/Contacting + +The driver is currently maintained by Laurent Pinchart and Ronald Bultje +(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug +reports or questions, please contact the mailinglist instead of the developers +individually. For user questions (i.e. bug reports or how-to questions), send +an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to +help programming), send an email to <mjpeg-developer@lists.sf.net>. See +http://www.sf.net/projects/mjpeg/ for subscription information. + +For bug reports, be sure to include all the information as described in +the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure +you're using the latest version (http://mjpeg.sf.net/driver-zoran/). + +Previous maintainers/developers of this driver include Serguei Miridonov +<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks +<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>. + +=========================== + +9. License + +This driver is distributed under the terms of the General Public License. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +See http://www.gnu.org/ for more information. diff --git a/Documentation/video4linux/bttv/CONTRIBUTORS b/Documentation/video4linux/bttv/CONTRIBUTORS new file mode 100644 index 0000000..eb41b26 --- /dev/null +++ b/Documentation/video4linux/bttv/CONTRIBUTORS @@ -0,0 +1,25 @@ +Contributors to bttv: + +Michael Chu <mmchu@pobox.com> + AverMedia fix and more flexible card recognition + +Alan Cox <alan@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 new file mode 100644 index 0000000..d338965 --- /dev/null +++ b/Documentation/video4linux/bttv/Cards @@ -0,0 +1,964 @@ + +Gunther Mayer's bttv card gallery (graphical version of this text file :-) +is available at: http://www.bttv-gallery.de/ + + +Supported cards: +Bt848/Bt848a/Bt849/Bt878/Bt879 cards +------------------------------------ + +All cards with Bt848/Bt848a/Bt849/Bt878/Bt879 and normal +Composite/S-VHS inputs are supported. Teletext and Intercast support +(PAL only) for ALL cards via VBI sample decoding in software. + +Some cards with additional multiplexing of inputs or other additional +fancy chips are only partially supported (unless specifications by the +card manufacturer are given). When a card is listed here it isn't +necessarily fully supported. + +All other cards only differ by additional components as tuners, sound +decoders, EEPROMs, teletext decoders ... + + +Unsupported Cards: +------------------ + +Cards with Zoran (ZR) or Philips (SAA) or ISA are not supported by +this driver. + + +MATRIX Vision +------------- + +MV-Delta +- Bt848A +- 4 Composite inputs, 1 S-VHS input (shared with 4th composite) +- EEPROM + +http://www.matrix-vision.de/ + +This card has no tuner but supports all 4 composite (1 shared with an +S-VHS input) of the Bt848A. +Very nice card if you only have satellite TV but several tuners connected +to the card via composite. + +Many thanks to Matrix-Vision for giving us 2 cards for free which made +Bt848a/Bt849 single crytal operation support possible!!! + + + +Miro/Pinnacle PCTV +------------------ + +- Bt848 + some (all??) come with 2 crystals for PAL/SECAM and NTSC +- PAL, SECAM or NTSC TV tuner (Philips or TEMIC) +- MSP34xx sound decoder on add on board + decoder is supported but AFAIK does not yet work + (other sound MUX setting in GPIO port needed??? somebody who fixed this???) +- 1 tuner, 1 composite and 1 S-VHS input +- tuner type is autodetected + +http://www.miro.de/ +http://www.miro.com/ + + +Many thanks for the free card which made first NTSC support possible back +in 1997! + + +Hauppauge Win/TV pci +-------------------- + +There are many different versions of the Hauppauge cards with different +tuners (TV+Radio ...), teletext decoders. +Note that even cards with same model numbers have (depending on the revision) +different chips on it. + +- Bt848 (and others but always in 2 crystal operation???) + newer cards have a Bt878 +- PAL, SECAM, NTSC or tuner with or without Radio support + +e.g.: + PAL: + TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners + TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3 + + NTSC: + TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners + TSA5518: no datasheet available on Philips site +- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip + with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM) + SAA5246 (I2C 0x22) is supported +- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y + with configuration information + I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf) +- 1 tuner, 1 composite and (depending on model) 1 S-VHS input +- 14052B: mux for selection of sound source +- sound decoder: TDA9800, MSP34xx (stereo cards) + + +Askey CPH-Series +---------------- +Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink) + + Card series: + CPH01x: BT848 capture only + CPH03x: BT848 + CPH05x: BT878 with FM + CPH06x: BT878 (w/o FM) + CPH07x: BT878 capture only + + TV standards: + CPH0x0: NTSC-M/M + CPH0x1: PAL-B/G + CPH0x2: PAL-I/I + CPH0x3: PAL-D/K + CPH0x4: SECAM-L/L + CPH0x5: SECAM-B/G + CPH0x6: SECAM-D/K + CPH0x7: PAL-N/N + CPH0x8: PAL-B/H + CPH0x9: PAL-M/M + + CPH03x was often sold as "TV capturer". + + Identifying: + 1) 878 cards can be identified by PCI Subsystem-ID: + 144f:3000 = CPH06x + 144F:3002 = CPH05x w/ FM + 144F:3005 = CPH06x_LC (w/o remote control) + 1) The cards have a sticker with "CPH"-model on the back. + 2) These cards have a number printed on the PCB just above the tuner metal box: + "80-CP2000300-x" = CPH03X + "80-CP2000500-x" = CPH05X + "80-CP2000600-x" = CPH06X / CPH06x_LC + + Askey sells these cards as "Magic TView series", Brand "MagicXpress". + Other OEM often call these "Tview", "TView99" or else. + +Lifeview Flyvideo Series: +------------------------- + The naming of these series differs in time and space. + + Identifying: + 1) Some models can be identified by PCI subsystem ID: + 1852:1852 = Flyvideo 98 FM + 1851:1850 = Flyvideo 98 + 1851:1851 = Flyvideo 98 EZ (capture only) + 2) There is a print on the PCB: + LR25 = Flyvideo (Zoran ZR36120, SAA7110A) + LR26 Rev.N = Flyvideo II (Bt848) + Rev.O = Flyvideo II (Bt878) + LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110) + LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only) + LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID) + Rev.W = Flyvideo 98 (no eeprom) + LR51 Rev.E = Flyvideo 98 EZ (capture only) + LR90 = Flyvideo 2000 (Bt878) + Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard) + LR91 = Stereo daughter card for LR90 + LR97 = Flyvideo DVBS + LR99 Rev.E = Low profile card for OEM integration (only internal audio!) bt878 + LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134) + LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394) + LR138 Rev.C= Flyvideo 2000 (SAA7130) + or Flyvideo 3000 (SAA7134) w/Stereo TV + These exist in variations w/FM and w/Remote sometimes denoted + by suffixes "FM" and "R". + 3) You have a laptop (miniPCI card): + Product = FlyTV Platinum Mini + Model/Chip = LR212/saa7135 + + Lifeview.com.tw states (Feb. 2002): + "The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98." + Their Bt8x8 cards are listed as discontinued. + Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?). + The new Flyvideo 2000/3000 are SAA7130/SAA7134 based. + + "Flyvideo II" had been the name for the 848 cards, nowadays (in Germany) + this name is re-used for LR50 Rev.W. + The Lifeview website mentioned Flyvideo III at some time, but such a card + has not yet been seen (perhaps it was the german name for LR90 [stereo]). + These cards are sold by many OEMs too. + + FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Germany} + Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134 + + +Typhoon TV card series: +----------------------- + These can be CPH, Flyvideo, Pixelview or KNC1 series. + Typhoon is the brand of Anubis. + Model 50680 got re-used, some model no. had different contents over time. + + Models: + 50680 "TV Tuner PCI Pal BG"(old,red package)=can be CPH03x(bt848) or CPH06x(bt878) + 50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B) + 50681 "TV Tuner PCI Pal I" (variant of 50680) + 50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q) + Note: The package has a picture of CPH05x (which would be a real TView) + 50683 "TV Tuner PCI SECAM" (variant of 50680) + 50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D) + 50686 "TV Tuner" = KNC1 TV Station + 50687 "TV Tuner stereo" = KNC1 TV Station pro + 50688 "TV Tuner RDS" (black package) = KNC1 TV Station RDS + 50689 TV SAT DVB-S CARD CI PCI (SAA7146AH, SU1278?) = "KNC1 TV Station DVB-S" + 50692 "TV/FM Tuner" (small PCB) + 50694 TV TUNER CARD RDS (PHILIPS CHIPSET SAA7134HL) + 50696 TV TUNER STEREO (PHILIPS CHIPSET SAA7134HL, MK3ME Tuner) + 50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps) + 50866 TVIEW SAT RECEIVER+ADR + 50868 "TV/FM Tuner Pal I" (variant of 50682) + 50999 "TV/FM Tuner Secam" (variant of 50682) + + +Guillemot +--------- + Maxi-TV PCI (ZR36120) + Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM) + Maxi TV Video 3 = CPH064 (PAL BG + SECAM) + +Mentor +------ + Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote) + +Prolink +------- + TV cards: + PixelView Play TV pro - (Model: PV-BT878P+ REV 8E) + PixelView Play TV pro - (Model: PV-BT878P+ REV 9D) + PixelView Play TV pro - (Model: PV-BT878P+ REV 4C / 8D / 10A ) + PixelView Play TV - (Model: PV-BT848P+) + 878TV - (Model: PV-BT878TV) + + Multimedia TV packages (card + software pack): + PixelView Play TV Theater - (Model: PV-M4200) = PixelView Play TV pro + Software + PixelView Play TV PAK - (Model: PV-BT878P+ REV 4E) + PixelView Play TV/VCR - (Model: PV-M3200 REV 4C / 8D / 10A ) + PixelView Studio PAK - (Model: M2200 REV 4C / 8D / 10A ) + PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E) + PixelView DigitalVCR PAK - (Model: PV-M2400 REV 4C / 8D / 10A ) + + PixelView PlayTV PAK II (TV/FM card + usb camera) PV-M3800 + PixelView PlayTV XP PV-M4700,PV-M4700(w/FM) + PixelView PlayTV DVR PV-M4600 package contents:PixelView PlayTV pro, windvr & videoMail s/w + + Further Cards: + PV-BT878P+rev.9B (Play TV Pro, opt. w/FM w/NICAM) + PV-BT878P+rev.2F + PV-BT878P Rev.1D (bt878, capture only) + + XCapture PV-CX881P (cx23881) + PlayTV HD PV-CX881PL+, PV-CX881PL+(w/FM) (cx23881) + + DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030 + DTV2000 DVB-S = Twinhan VP-1020 + + Video Conferencing: + PixelView Meeting PAK - (Model: PV-BT878P) + PixelView Meeting PAK Lite - (Model: PV-BT878P) + PixelView Meeting PAK plus - (Model: PV-BT878P+rev 4C/8D/10A) + PixelView Capture - (Model: PV-BT848P) + + PixelView PlayTV USB pro + Model No. PV-NT1004+, PV-NT1004+ (w/FM) = NT1004 USB decoder chip + SAA7113 video decoder chip + +Dynalink +-------- + These are CPH series. + +Phoebemicro +----------- + TV Master = CPH030 or CPH060 + TV Master FM = CPH050 + +Genius/Kye +---------- + Video Wonder/Genius Internet Video Kit = LR37 Rev.C + Video Wonder Pro II (848 or 878) = LR26 + +Tekram +------ + VideoCap C205 (Bt848) + VideoCap C210 (zr36120 +Philips) + CaptureTV M200 (ISA) + CaptureTV M205 (Bt848) + +Lucky Star +---------- + Image World Conference TV = LR50 Rev. Q + +Leadtek +------- + WinView 601 (Bt848) + WinView 610 (Zoran) + WinFast2000 + WinFast2000 XP + +KNC One +------- + TV-Station + TV-Station SE (+Software Bundle) + TV-Station pro (+TV stereo) + TV-Station FM (+Radio) + TV-Station RDS (+RDS) + TV Station SAT (analog satellite) + TV-Station DVB-S + + newer Cards have saa7134, but model name stayed the same? + +Provideo +-------- + PV951 or PV-951 (also are sold as: + Boeder TV-FM Video Capture Card + Titanmedia Supervision TV-2400 + Provideo PV951 TF + 3DeMon PV951 + MediaForte TV-Vision PV951 + Yoko PV951 + Vivanco Tuner Card PCI Art.-Nr.: 68404 + ) now named PV-951T + + Surveillance Series + PV-141 + PV-143 + PV-147 + PV-148 (capture only) + PV-150 + PV-151 + + TV-FM Tuner Series + PV-951TDV (tv tuner + 1394) + PV-951T/TF + PV-951PT/TF + PV-956T/TF Low Profile + PV-911 + +Highscreen +---------- + TV Karte = LR50 Rev.S + TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb" + +Zoltrix +------- + Face to Face Capture (Bt848 capture only) (PCB "VP-2848") + Face To Face TV MAX (Bt848) (PCB "VP-8482 Rev1.3") + Genie TV (Bt878) (PCB "VP-8790 Rev 2.1") + Genie Wonder Pro + +AVerMedia +--------- + AVer FunTV Lite (ISA, AV3001 chipset) "M101.C" + AVerTV + AVerTV Stereo + AVerTV Studio (w/FM) + AVerMedia TV98 with Remote + AVerMedia TV/FM98 Stereo + AVerMedia TVCAM98 + TVCapture (Bt848) + TVPhone (Bt848) + TVCapture98 (="AVerMedia TV98" in USA) (Bt878) + TVPhone98 (Bt878, w/FM) + + PCB PCI-ID Model-Name Eeprom Tuner Sound Country + -------------------------------------------------------------------- + M101.C ISA ! + M108-B Bt848 -- FR1236 US (2),(3) + M1A8-A Bt848 AVer TV-Phone FM1216 -- + M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D (1) w/FM w/Remote + M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote + M168II-B 1461:0003 Medion MD9592 48:16 FM1216 TDA9873H D w/FM + + (1) Daughterboard MB68-A with TDA9820T and TDA9840T + (2) Sony NE41S soldered (stereo sound?) + (3) Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz + + US site has different drivers for (as of 09/2002): + EZ Capture/InterCam PCI (BT-848 chip) + EZ Capture/InterCam PCI (BT-878 chip) + TV-Phone (BT-848 chip) + TV98 (BT-848 chip) + TV98 With Remote (BT-848 chip) + TV98 (BT-878 chip) + TV98 With Remote (BT-878) + TV/FM98 (BT-878 chip) + AVerTV + AverTV Stereo + AVerTV Studio + + DE hat diverse Treiber fuer diese Modelle (Stand 09/2002): + TVPhone (848) mit Philips tuner FR12X6 (w/ FM radio) + TVPhone (848) mit Philips tuner FM12X6 (w/ FM radio) + TVCapture (848) w/Philips tuner FI12X6 + TVCapture (848) non-Philips tuner + TVCapture98 (Bt878) + TVPhone98 (Bt878) + AVerTV und TVCapture98 w/VCR (Bt 878) + AVerTVStudio und TVPhone98 w/VCR (Bt878) + AVerTV GO Serie (Kein SVideo Input) + AVerTV98 (BT-878 chip) + AVerTV98 mit Fernbedienung (BT-878 chip) + AVerTV/FM98 (BT-878 chip) + + VDOmate (www.averm.com.cn) = M168U ? + +Aimslab +------- + Video Highway or "Video Highway TR200" (ISA) + Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757) + +IXMicro (former: IMS=Integrated Micro Solutions) +------- + IXTV BT848 (=TurboTV) + IXTV BT878 + IMS TurboTV (Bt848) + +Lifetec/Medion/Tevion/Aldi +-------------------------- + LT9306/MD9306 = CPH061 + LT9415/MD9415 = LR90 Rev.F or Rev.G + MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H) + MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner) + MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner) + +Modular Technologies (www.modulartech.com) UK +--------------------------------------------- + MM100 PCTV (Bt848) + MM201 PCTV (Bt878, Bt832) w/ Quartzsight camera + MM202 PCTV (Bt878, Bt832, tda9874) + MM205 PCTV (Bt878) + MM210 PCTV (Bt878) (Galaxy TV, Galaxymedia ?) + +Terratec +-------- + Terra TV+ Version 1.0 (Bt848), "ceb105.PCB" printed on the PCB, TDA9821 + Terra TV+ Version 1.1 (Bt878), "LR74 Rev.E" printed on the PCB, TDA9821 + Terra TValueRadio, "LR102 Rev.C" printed on the PCB + Terra TV/Radio+ Version 1.0, "80-CP2830100-0" TTTV3 printed on the PCB, + "CPH010-E83" on the back, SAA6588T, TDA9873H + Terra TValue Version BT878, "80-CP2830110-0 TTTV4" printed on the PCB, + "CPH011-D83" on back + Terra TValue Version 1.0 "ceb105.PCB" (really identical to Terra TV+ Version 1.0) + Terra TValue New Revision "LR102 Rec.C" + Terra Active Radio Upgrade (tea5757h, saa6588t) + + LR74 is a newer PCB revision of ceb105 (both incl. connector for Active Radio Upgrade) + + Cinergy 400 (saa7134), "E877 11(S)", "PM820092D" printed on PCB + Cinergy 600 (saa7134) + +Technisat +--------- + Discos ADR PC-Karte ISA (no TV!) + Discos ADR PC-Karte PCI (probably no TV?) + Techni-PC-Sat (Sat. analog) + Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A) + Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio) + Mediafocus II (saa7146, Sat. analog) + SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A) + SkyStar 1 DVB (AV7110) = Technotrend Premium + SkyStar 2 DVB (B2C2) (=Sky2PC) + +Siemens +------- + Multimedia eXtension Board (MXB) (SAA7146, SAA7111) + +Stradis +------- + SDM275,SDM250,SDM026,SDM025 (SAA7146, IBMMPEG2): MPEG2 decoder only + +Powercolor +---------- + MTV878 + Package comes with different contents: + a) pcb "MTV878" (CARD=75) + b) Pixelview Rev. 4_ + MTV878R w/Remote Control + MTV878F w/Remote Control w/FM radio + +Pinnacle +-------- + Mirovideo PCTV (Bt848) + Mirovideo PCTV SE (Bt848) + Mirovideo PCTV Pro (Bt848 + Daughterboard for TV Stereo and FM) + Studio PCTV Rave (Bt848 Version = Mirovideo PCTV) + Studio PCTV Rave (Bt878 package w/o infrared) + Studio PCTV (Bt878) + Studio PCTV Pro (Bt878 stereo w/ FM) + Pinnacle PCTV (Bt878, MT2032) + Pinnacle PCTV Pro (Bt878, MT2032) + Pinncale PCTV Sat (bt878a, HM1821/1221) ["Conexant CX24110 with CX24108 tuner, aka HM1221/HM1811"] + Pinnacle PCTV Sat XE + + M(J)PEG capture and playback: + DC1+ (ISA) + DC10 (zr36057, zr36060, saa7110, adv7176) + DC10+ (zr36067, zr36060, saa7110, adv7176) + DC20 (ql16x24b,zr36050, zr36016, saa7110, saa7187 ...) + DC30 (zr36057, zr36050, zr36016, vpx3220, adv7176, ad1843, tea6415, miro FST97A1) + DC30+ (zr36067, zr36050, zr36016, vpx3220, adv7176) + DC50 (zr36067, zr36050, zr36016, saa7112, adv7176 (2 pcs.?), ad1843, miro FST97A1, Lattice ???) + +Lenco +----- + MXR-9565 (=Technisat Mediafocus?) + MXR-9571 (Bt848) (=CPH031?) + MXR-9575 + MXR-9577 (Bt878) (=Prolink 878TV Rev.3x) + MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E) + +Iomega +------ + Buz (zr36067, zr36060, saa7111, saa7185) + +LML +--- + LML33 (zr36067, zr36060, bt819, bt856) + +Grandtec +-------- + Grand Video Capture (Bt848) + Multi Capture Card (Bt878) + +Koutech +------- + KW-606 (Bt848) + KW-607 (Bt848 capture only) + KW-606RSF + KW-607A (capture only) + KW-608 (Zoran capture only) + +IODATA (jp) +------ + GV-BCTV/PCI + GV-BCTV2/PCI + GV-BCTV3/PCI + GV-BCTV4/PCI + GV-VCP/PCI (capture only) + GV-VCP2/PCI (capture only) + +Canopus (jp) +------- + WinDVR = Kworld "KW-TVL878RF" + +www.sigmacom.co.kr +------------------ + Sigma Cyber TV II + +www.sasem.co.kr +--------------- + Litte OnAir TV + +hama +---- + TV/Radio-Tuner Card, PCI (Model 44677) = CPH051 + +Sigma Designs +------------- + Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder + +Formac +------ + iProTV (Card for iMac Mezzanine slot, Bt848+SCSI) + ProTV (Bt848) + ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono] + +ATI +--- + TV-Wonder + TV-Wonder VE + +Diamond Multimedia +------------------ + DTV2000 (Bt848, tda9875) + +Aopen +----- + VA1000 Plus (w/ Stereo) + VA1000 Lite + VA1000 (=LR90) + +Intel +----- + Smart Video Recorder (ISA full-length) + Smart Video Recorder pro (ISA half-length) + Smart Video Recorder III (Bt848) + +STB +--- + STB Gateway 6000704 (bt878) + STB Gateway 6000699 (bt848) + STB Gateway 6000402 (bt848) + STB TV130 PCI + +Videologic +---------- + Captivator Pro/TV (ISA?) + Captivator PCI/VC (Bt848 bundled with camera) (capture only) + +Technotrend +------------ + TT-SAT PCI (PCB "Sat-PCI Rev.:1.3.1"; zr36125, vpx3225d, stc0056a, Tuner:BSKE6-155A + TT-DVB-Sat + revisions 1.1, 1.3, 1.5, 1.6 and 2.1 + This card is sold as OEM from: + Siemens DVB-s Card + Hauppauge WinTV DVB-S + Technisat SkyStar 1 DVB + Galaxis DVB Sat + Now this card is called TT-PCline Premium Family + TT-Budget (saa7146, bsru6-701a) + This card is sold as OEM from: + Hauppauge WinTV Nova + Satelco Standard PCI (DVB-S) + TT-DVB-C PCI + +Teles +----- + DVB-s (Rev. 2.2, BSRV2-301A, data only?) + +Remote Vision +------------- + MX RV605 (Bt848 capture only) + +Boeder +------ + PC ChatCam (Model 68252) (Bt848 capture only) + Tv/Fm Capture Card (Model 68404) = PV951 + +Media-Surfer (esc-kathrein.de) +------------------------------- + Sat-Surfer (ISA) + Sat-Surfer PCI = Techni-PC-Sat + Cable-Surfer 1 + Cable-Surfer 2 + Cable-Surfer PCI (zr36120) + Audio-Surfer (ISA Radio card) + +Jetway (www.jetway.com.tw) +-------------------------- + JW-TV 878M + JW-TV 878 = KWorld KW-TV878RF + +Galaxis +------- + Galaxis DVB Card S CI + Galaxis DVB Card C CI + Galaxis DVB Card S + Galaxis DVB Card C + Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI + +Hauppauge +--------- + many many WinTV models ... + WinTV DVBs = Technotrend Premium 1.3 + WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA" + WinTV NOVA-CI "SDVBACI" + WinTV Nova USB (=Technotrend USB 1.0) + WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2) + WinTV PVR + WinTV PVR 250 + WinTV PVR 450 + + US models + 990 WinTV-PVR-350 (249USD) (iTVC15 chipset + radio) + 980 WinTV-PVR-250 (149USD) (iTVC15 chipset) + 880 WinTV-PVR-PCI (199USD) (KFIR chipset + bt878) + 881 WinTV-PVR-USB + 190 WinTV-GO + 191 WinTV-GO-FM + 404 WinTV + 401 WinTV-radio + 495 WinTV-Theater + 602 WinTV-USB + 621 WinTV-USB-FM + 600 USB-Live + 698 WinTV-HD + 697 WinTV-D + 564 WinTV-Nexus-S + + Deutsche Modelle + 603 WinTV GO + 719 WinTV Primio-FM + 718 WinTV PCI-FM + 497 WinTV Theater + 569 WinTV USB + 568 WinTV USB-FM + 882 WinTV PVR + 981 WinTV PVR 250 + 891 WinTV-PVR-USB + 541 WinTV Nova + 488 WinTV Nova-Ci + 564 WinTV-Nexus-s + 727 WinTV-DVB-c + 545 Common Interface + 898 WinTV-Nova-USB + + UK models + 607 WinTV Go + 693,793 WinTV Primio FM + 647,747 WinTV PCI FM + 498 WinTV Theater + 883 WinTV PVR + 893 WinTV PVR USB (Duplicate entry) + 566 WinTV USB (UK) + 573 WinTV USB FM + 429 Impact VCB (bt848) + 600 USB Live (Video-In 1x Comp, 1xSVHS) + 542 WinTV Nova + 717 WinTV DVB-S + 909 Nova-t PCI + 893 Nova-t USB (Duplicate entry) + 802 MyTV + 804 MyView + 809 MyVideo + 872 MyTV2Go FM + + + 546 WinTV Nova-S CI + 543 WinTV Nova + 907 Nova-S USB + 908 Nova-T USB + 717 WinTV Nexus-S + 157 DEC3000-s Standalone + USB + + Spain + 685 WinTV-Go + 690 WinTV-PrimioFM + 416 WinTV-PCI Nicam Estereo + 677 WinTV-PCI-FM + 699 WinTV-Theater + 683 WinTV-USB + 678 WinTV-USB-FM + 983 WinTV-PVR-250 + 883 WinTV-PVR-PCI + 993 WinTV-PVR-350 + 893 WinTV-PVR-USB + 728 WinTV-DVB-C PCI + 832 MyTV2Go + 869 MyTV2Go-FM + 805 MyVideo (USB) + + +Matrix-Vision +------------- + MATRIX-Vision MV-Delta + MATRIX-Vision MV-Delta 2 + MVsigma-SLC (Bt848) + +Conceptronic (.net) +------------ + TVCON FM, TV card w/ FM = CPH05x + TVCON = CPH06x + +BestData +-------- + HCC100 = VCC100rev1 + camera + VCC100 rev1 (bt848) + VCC100 rev2 (bt878) + +Gallant (www.gallantcom.com) www.minton.com.tw +----------------------------------------------- + Intervision IV-510 (capture only bt8x8) + Intervision IV-550 (bt8x8) + Intervision IV-100 (zoran) + Intervision IV-1000 (bt8x8) + +Asonic (www.asonic.com.cn) (website down) +----------------------------------------- + SkyEye tv 878 + +Hoontech +-------- + 878TV/FM + +Teppro (www.itcteppro.com.tw) +----------------------------- + ITC PCITV (Card Ver 1.0) "Teppro TV1/TVFM1 Card" + ITC PCITV (Card Ver 2.0) + ITC PCITV (Card Ver 3.0) = "PV-BT878P+ (REV.9D)" + ITC PCITV (Card Ver 4.0) + TEPPRO IV-550 (For BT848 Main Chip) + ITC DSTTV (bt878, satellite) + ITC VideoMaker (saa7146, StreamMachine sm2110, tvtuner) "PV-SM2210P+ (REV:1C)" + +Kworld (www.kworld.com.tw) +-------------------------- + PC TV Station + KWORLD KW-TV878R TV (no radio) + KWORLD KW-TV878RF TV (w/ radio) + + KWORLD KW-TVL878RF (low profile) + + KWORLD KW-TV713XRF (saa7134) + + + MPEG TV Station (same cards as above plus WinDVR Software MPEG en/decoder) + KWORLD KW-TV878R -Pro TV (no Radio) + KWORLD KW-TV878RF-Pro TV (w/ Radio) + KWORLD KW-TV878R -Ultra TV (no Radio) + KWORLD KW-TV878RF-Ultra TV (w/ Radio) + + + +JTT/ Justy Corp.http://www.justy.co.jp/ (www.jtt.com.jp website down) +--------------------------------------------------------------------- + JTT-02 (JTT TV) "TV watchmate pro" (bt848) + +ADS www.adstech.com +------------------- + Channel Surfer TV ( CHX-950 ) + Channel Surfer TV+FM ( CHX-960FM ) + +AVEC www.prochips.com +--------------------- + AVEC Intercapture (bt848, tea6320) + +NoBrand +------- + TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_" + +Mach www.machspeed.com +---- + Mach TV 878 + +Eline www.eline-net.com/ +----- + Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878) + Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x) + +Spirit http://www.spiritmodems.com.au/ +------ + Spirit TV Tuner/Video Capture Card (bt848) + +Boser www.boser.com.tw +----- + HS-878 Mini PCI Capture Add-on Card + HS-879 Mini PCI 3D Audio and Capture Add-on Card (w/ ES1938 Solo-1) + +Satelco www.citycom-gmbh.de, www.satelco.de +------- + TV-FM =KNC1 saa7134 + Standard PCI (DVB-S) = Technotrend Budget + Standard PCI (DVB-S) w/ CI + Satelco Highend PCI (DVB-S) = Technotrend Premium + + +Sensoray www.sensoray.com +-------- + Sensoray 311 (PC/104 bus) + Sensoray 611 (PCI) + +CEI (Chartered Electronics Industries Pte Ltd [CEI] [FCC ID HBY]) +--- + TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips + TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV + Primetime TV (ISA) + acquired by Singapore Technologies + now operating as Chartered Semiconductor Manufacturing + Manufacturer of video cards is listed as: + Cogent Electronics Industries [CEI] + +AITech +------ + Wavewatcher TV (ISA) + AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878) + WaveWatcher TVR-202 TV/FM Radio Card (ISA) + +MAXRON +------ + Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK + +www.ids-imaging.de +------------------ + Falcon Series (capture only) + In USA: http://www.theimagingsource.com/ + DFG/LC1 + +www.sknet-web.co.jp +------------------- + SKnet Monster TV (saa7134) + +A-Max www.amaxhk.com (Colormax, Amax, Napa) +------------------- + APAC Viewcomp 878 + +Cybertainment +------------- + CyberMail AV Video Email Kit w/ PCI Capture Card (capture only) + CyberMail Xtreme + These are Flyvideo + +VCR (http://www.vcrinc.com/) +--- + Video Catcher 16 + +Twinhan +------- + DST Card/DST-IP (bt878, twinhan asic) VP-1020 + Sold as: + KWorld DVBS Satellite TV-Card + Powercolor DSTV Satellite Tuner Card + Prolink Pixelview DTV2000 + Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ? + DST-CI Card (DVB Satellite) VP-1030 + DCT Card (DVB cable) + +MSI +--- + MSI TV@nywhere Tuner Card (MS-8876) (CX23881/883) Not Bt878 compatible. + MS-8401 DVB-S + +Focus www.focusinfo.com +----- + InVideo PCI (bt878) + +Sdisilk www.sdisilk.com/ +------- + SDI Silk 100 + SDI Silk 200 SDI Input Card + +www.euresys.com + PICOLO series + +PMC/Pace +www.pacecom.co.uk website closed + +Mercury www.kobian.com (UK and FR) + LR50 + LR138RBG-Rx == LR138 + +TEC sound (package and manuals don't have any other manufacturer info) TecSound + Though educated googling found: www.techmakers.com + TV-Mate = Zoltrix VP-8482 + +Lorenzen www.lorenzen.de +-------- + SL DVB-S PCI = Technotrend Budget PCI (su1278 or bsru version) + +Origo (.uk) www.origo2000.com + PC TV Card = LR50 + +I/O Magic www.iomagic.com +--------- + PC PVR - Desktop TV Personal Video Recorder DR-PCTV100 = Pinnacle ROB2D-51009464 4.0 + Cyberlink PowerVCR II + +Arowana +------- + TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?) + +iTVC15 boards: +------------- +kuroutoshikou.com ITVC15 +yuan.com MPG160 PCI TV (Internal PCI MPEG2 encoder card plus TV-tuner) + +Asus www.asuscom.com + Asus TV Tuner Card 880 NTSC (low profile, cx23880) + Asus TV (saa7134) + +Hoontech +-------- +http://www.hoontech.com/korean/download/down_driver_list03.html + HART Vision 848 (H-ART Vision 848) + HART Vision 878 (H-Art Vision 878) diff --git a/Documentation/video4linux/bttv/ICs b/Documentation/video4linux/bttv/ICs new file mode 100644 index 0000000..611315f --- /dev/null +++ b/Documentation/video4linux/bttv/ICs @@ -0,0 +1,37 @@ +all boards: + +Brooktree Bt848/848A/849/878/879: video capture chip + + + +Miro PCTV: + +Philips or Temic Tuner + + + +Hauppauge Win/TV pci (version 405): + +Microchip 24LC02B or +Philips 8582E2Y: 256 Byte EEPROM with configuration information + I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf) +Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23 +TDA9800: sound decoder +Winbond W24257AS-35: 32Kx8 CMOS static RAM (Videotext buffer mem) +14052B: analog switch for selection of sound source + +PAL: +TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners +TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3 + +NTSC: +TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners +TSA5518: no datasheet available on Philips site + + + +STB TV pci: + +??? +if you want better support for STB cards send me info! +Look at the board! What chips are on it? diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options new file mode 100644 index 0000000..5ef7578 --- /dev/null +++ b/Documentation/video4linux/bttv/Insmod-options @@ -0,0 +1,182 @@ + +Note: "modinfo <module>" prints various informations about a kernel +module, among them a complete and up-to-date list of insmod options. +This list tends to be outdated because it is updated manually ... + +========================================================================== + +bttv.o + the bt848/878 (grabber chip) driver + + insmod args: + card=n card type, see CARDLIST for a list. + tuner=n tuner type, see CARDLIST for a list. + radio=0/1 card supports radio + pll=0/1/2 pll settings + 0: don't use PLL + 1: 28 MHz crystal installed + 2: 35 MHz crystal installed + + triton1=0/1 for Triton1 (+others) compatibility + vsfx=0/1 yet another chipset bug compatibility bit + see README.quirks for details on these two. + + bigendian=n Set the endianness of the gfx framebuffer. + Default is native endian. + fieldnr=0/1 Count fields. Some TV descrambling software + needs this, for others it only generates + 50 useless IRQs/sec. default is 0 (off). + autoload=0/1 autoload helper modules (tuner, audio). + default is 1 (on). + bttv_verbose=0/1/2 verbose level (at insmod time, while + looking at the hardware). default is 1. + bttv_debug=0/1 debug messages (for capture). + default is 0 (off). + irq_debug=0/1 irq handler debug messages. + default is 0 (off). + gbuffers=2-32 number of capture buffers for mmap'ed capture. + default is 4. + gbufsize= size of capture buffers. default and + maximum value is 0x208000 (~2MB) + no_overlay=0 Enable overlay on broken hardware. There + are some chipsets (SIS for example) which + are known to have problems with the PCI DMA + push used by bttv. bttv will disable overlay + by default on this hardware to avoid crashes. + With this insmod option you can override this. + 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). + +tvmixer.o + registers a mixer device for the TV card's volume/bass/treble + controls (requires a i2c audio control chip like the msp3400). + + insmod args: + debug=1 print some debug info to the syslog. + devnr=n allocate device #n (0 == /dev/mixer, + 1 = /dev/mixer1, ...), default is to + use the first free one. + +tvaudio.o + new, experimental module which is supported to provide a single + driver for all simple i2c audio control chips (tda/tea*). + + insmod args: + tda8425 = 1 enable/disable the support for the + tda9840 = 1 various chips. + tda9850 = 1 The tea6300 can't be autodetected and is + tda9855 = 1 therefore off by default, if you have + tda9873 = 1 this one on your card (STB uses these) + tda9874a = 1 you have to enable it explicitly. + tea6300 = 0 The two tda985x chips use the same i2c + tea6420 = 1 address and can't be disturgished from + pic16c54 = 1 each other, you might have to disable + the wrong one. + debug = 1 print debug messages + + insmod args for tda9874a: + tda9874a_SIF=1/2 select sound IF input pin (1 or 2) + (default is pin 1) + tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0) + Please read note 3 below! + tda9874a_STD=n select TV sound standard (0..8): + 0 - A2, B/G + 1 - A2, M (Korea) + 2 - A2, D/K (1) + 3 - A2, D/K (2) + 4 - A2, D/K (3) + 5 - NICAM, I + 6 - NICAM, B/G + 7 - NICAM, D/K (default) + 8 - NICAM, L + + Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips. + Note 2: tda9874h/a and tda9875 (which is supported separately by + tda9875.o) use the same i2c address so both modules should not be + used at the same time. + Note 3: Using tda9874a_AMSEL option depends on your TV card design! + AMSEL=0: auto-mute will switch between NICAM sound + and the sound on 1st carrier (i.e. FM mono or AM). + AMSEL=1: auto-mute will switch between NICAM sound + and the analog mono input (MONOIN pin). + If tda9874a decoder on your card has MONOIN pin not connected, then + use only tda9874_AMSEL=0 or don't specify this option at all. + For example: + card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0 + card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only + +msp3400.o + The driver for the msp34xx sound processor chips. If you have a + stereo card, you probably want to insmod this one. + + insmod args: + debug=1/2 print some debug info to the syslog, + 2 is more verbose. + simple=1 Use the "short programming" method. Newer + msp34xx versions support this. You need this + for dbx stereo. Default is on if supported by + the chip. + once=1 Don't check the TV-stations Audio mode + every few seconds, but only once after + channel switches. + amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This + should improve things for french people, the + carrier autoscan seems to work with FM only... + +tea6300.o - OBSOLETE (use tvaudio instead) + The driver for the tea6300 fader chip. If you have a stereo + card and the msp3400.o doesn't work, you might want to try this + one. This chip is seen on most STB TV/FM cards (usually from + Gateway OEM sold surplus on auction sites). + + insmod args: + debug=1 print some debug info to the syslog. + +tda8425.o - OBSOLETE (use tvaudio instead) + The driver for the tda8425 fader chip. This driver used to be + part of bttv.c, so if your sound used to work but does not + anymore, try loading this module. + + insmod args: + debug=1 print some debug info to the syslog. + +tda985x.o - OBSOLETE (use tvaudio instead) + The driver for the tda9850/55 audio chips. + + insmod args: + debug=1 print some debug info to the syslog. + chip=9850/9855 set the chip type. diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV new file mode 100644 index 0000000..6c29ba4 --- /dev/null +++ b/Documentation/video4linux/bttv/MAKEDEV @@ -0,0 +1,28 @@ +#!/bin/bash + +function makedev () { + + for dev in 0 1 2 3; do + echo "/dev/$1$dev: char 81 $[ $2 + $dev ]" + rm -f /dev/$1$dev + mknod /dev/$1$dev c 81 $[ $2 + $dev ] + chmod 666 /dev/$1$dev + done + + # symlink for default device + rm -f /dev/$1 + ln -s /dev/${1}0 /dev/$1 +} + +# see http://roadrunner.swansea.uk.linux.org/v4lapi.shtml + +echo "*** new device names ***" +makedev video 0 +makedev radio 64 +makedev vtx 192 +makedev vbi 224 + +#echo "*** old device names (for compatibility only) ***" +#makedev bttv 0 +#makedev bttv-fm 64 +#makedev bttv-vbi 224 diff --git a/Documentation/video4linux/bttv/Modprobe.conf b/Documentation/video4linux/bttv/Modprobe.conf new file mode 100644 index 0000000..55f1465 --- /dev/null +++ b/Documentation/video4linux/bttv/Modprobe.conf @@ -0,0 +1,11 @@ +# i2c +alias char-major-89 i2c-dev +options i2c-core i2c_debug=1 +options i2c-algo-bit bit_test=1 + +# bttv +alias char-major-81 videodev +alias char-major-81-0 bttv +options bttv card=2 radio=1 +options tuner debug=1 + diff --git a/Documentation/video4linux/bttv/Modules.conf b/Documentation/video4linux/bttv/Modules.conf new file mode 100644 index 0000000..753f159 --- /dev/null +++ b/Documentation/video4linux/bttv/Modules.conf @@ -0,0 +1,14 @@ +# For modern kernels (2.6 or above), this belongs in /etc/modprobe.conf +# For for 2.4 kernels or earlier, this belongs in /etc/modules.conf. + +# i2c +alias char-major-89 i2c-dev +options i2c-core i2c_debug=1 +options i2c-algo-bit bit_test=1 + +# bttv +alias char-major-81 videodev +alias char-major-81-0 bttv +options bttv card=2 radio=1 +options tuner debug=1 + diff --git a/Documentation/video4linux/bttv/PROBLEMS b/Documentation/video4linux/bttv/PROBLEMS new file mode 100644 index 0000000..2b8b007 --- /dev/null +++ b/Documentation/video4linux/bttv/PROBLEMS @@ -0,0 +1,62 @@ +- Start capturing by pressing "c" or by selecting it via a menu! + +- Start capturing by pressing "c" or by selecting it via a menu!!! + +- The memory of some S3 cards is not recognized right: + + First of all, if you are not using XFree-3.2 or newer, upgrade AT LEAST to + XFree-3.2A! This solved the problem for most people. + + Start up X11 like this: "XF86_S3 -probeonly" and write down where the + linear frame buffer is. + If it is different to the address found by bttv install bttv like this: + "insmod bttv vidmem=0xfb0" + if the linear frame buffer is at 0xfb000000 (i.e. omit the last 5 zeros!) + + Some S3 cards even take up 64MB of memory but only report 32MB to the BIOS. + If this 64MB area overlaps the IO memory of the Bt848 you also have to + remap this. E.g.: insmod bttv vidmem=0xfb0 remap=0xfa0 + + If the video memory is found at the right place and there are no address + conflicts but still no picture (or the computer even crashes), + try disabling features of your PCI chipset in the BIOS setup. + + Frank Kapahnke <frank@kapahnke.prima.ruhr.de> also reported that problems + with his S3 868 went away when he upgraded to XFree 3.2. + + +- I still only get a black picture with my S3 card! + + Even with XFree-3.2A some people have problems with their S3 cards + (mostly with Trio 64 but also with some others) + Get the free demo version of Accelerated X from www.xinside.com and try + bttv with it. bttv seems to work with most S3 cards with Accelerated X. + + Since I do not know much (better make that almost nothing) about VGA card + programming I do not know the reason for this. + Looks like XFree does something different when setting up the video memory? + Maybe somebody can enlighten me? + Would be nice if somebody could get this to work with XFree since + Accelerated X costs more than some of the grabber cards ... + + Better linear frame buffer support for S3 cards will probably be in + XFree 4.0. + +- Grabbing is not switched off when changing consoles with XFree. + That's because XFree and some AcceleratedX versions do not send unmap + events. + +- Some popup windows (e.g. of the window manager) are not refreshed. + + Disable backing store by starting X with the option "-bs" + +- When using 32 bpp in XFree or 24+8bpp mode in AccelX 3.1 the system + can sometimes lock up if you use more than 1 bt848 card at the same time. + You will always get pixel errors when e.g. using more than 1 card in full + screen mode. Maybe we need something faster than the PCI bus ... + + +- Some S3 cards and the Matrox Mystique will produce pixel errors with + full resolution in 32-bit mode. + +- Some video cards have problems with Accelerated X 4.1 diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README new file mode 100644 index 0000000..7ca2154 --- /dev/null +++ b/Documentation/video4linux/bttv/README @@ -0,0 +1,90 @@ + +Release notes for bttv +====================== + +You'll need at least these config options for bttv: + CONFIG_I2C=m + CONFIG_I2C_ALGOBIT=m + CONFIG_VIDEO_DEV=m + +The latest bttv version is available from http://bytesex.org/bttv/ + + +Make bttv work with your card +----------------------------- + +Just try "modprobe bttv" and see if that works. + +If it doesn't bttv likely could not autodetect your card and needs some +insmod options. The most important insmod option for bttv is "card=n" +to select the correct card type. If you get video but no sound you've +very likely specified the wrong (or no) card type. A list of supported +cards is in CARDLIST.bttv + +If bttv takes very long to load (happens sometimes with the cheap +cards which have no tuner), try adding this to your modules.conf: + options i2c-algo-bit bit_test=1 + +For the WinTV/PVR you need one firmware file from the driver CD: +hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting +zip file, unzip can unpack it). Put it into the /etc/pvr directory or +use the firm_altera=<path> insmod option to point the driver to the +location of the file. + +If your card isn't listed in CARDLIST.bttv or if you have trouble making +audio work, you should read the Sound-FAQ. + + +Autodetecting cards +------------------- + +bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists +the Subsystem ID in the second line, looks like this: + +00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) + Subsystem: Hauppauge computer works Inc. WinTV/GO + Flags: bus master, medium devsel, latency 32, IRQ 5 + Memory at e2000000 (32-bit, prefetchable) [size=4K] + +only bt878-based cards can have a subsystem ID (which does not mean +that every card really has one). bt848 cards can't have a Subsystem +ID and therefore can't be autodetected. There is a list with the ID's +in bttv-cards.c (in case you are intrested or want to mail patches +with updates). + + +Still doesn't work? +------------------- + +I do NOT have a lab with 30+ different grabber boards and a +PAL/NTSC/SECAM test signal generator at home, so I often can't +reproduce your problems. This makes debugging very difficult for me. +If you have some knowledge and spare time, please try to fix this +yourself (patches very welcome of course...) You know: The linux +slogan is "Do it yourself". + +There is a mailing list: video4linux-list@redhat.com. +https://listman.redhat.com/mailman/listinfo/video4linux-list + +If you have trouble with some specific TV card, try to ask there +instead of mailing me directly. The chance that someone with the +same card listens there is much higher... + +For problems with sound: There are alot of different systems used +for TV sound all over the world. And there are also different chips +which decode the audio signal. Reports about sound problems ("stereo +does'nt work") are pretty useless unless you include some details +about your hardware and the TV sound scheme used in your country (or +at least the country you are living in). + + +Finally: If you mail some patches for bttv around the world (to +linux-kernel/Alan/Linus/...), please Cc: me. + + +Have fun with bttv, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> diff --git a/Documentation/video4linux/bttv/README.WINVIEW b/Documentation/video4linux/bttv/README.WINVIEW new file mode 100644 index 0000000..c61cf28 --- /dev/null +++ b/Documentation/video4linux/bttv/README.WINVIEW @@ -0,0 +1,33 @@ + +Support for the Leadtek WinView 601 TV/FM by Jon Tombs <jon@gte.esi.us.es> + +This card is basically the same as all the rest (Bt484A, Philips tuner), +the main difference is that they have attached a programmable attenuator to 3 +GPIO lines in order to give some volume control. They have also stuck an +infra-red remote control decoded on the board, I will add support for this +when I get time (it simple generates an interrupt for each key press, with +the key code is placed in the GPIO port). + +I don't yet have any application to test the radio support. The tuner +frequency setting should work but it is possible that the audio multiplexer +is wrong. If it doesn't work, send me email. + + +- No Thanks to Leadtek they refused to answer any questions about their +hardware. The driver was written by visual inspection of the card. If you +use this driver, send an email insult to them, and tell them you won't +continue buying their hardware unless they support Linux. + +- Little thanks to Princeton Technology Corp (http://www.princeton.com.tw) +who make the audio attenuator. Their publicly available data-sheet available +on their web site doesn't include the chip programming information! Hidden +on their server are the full data-sheets, but don't ask how I found it. + +To use the driver I use the following options, the tuner and pll settings might +be different in your country + +insmod videodev +insmod i2c scan=1 i2c_debug=0 verbose=0 +insmod tuner type=1 debug=0 +insmod bttv pll=1 radio=1 card=17 + diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze new file mode 100644 index 0000000..4259dcc --- /dev/null +++ b/Documentation/video4linux/bttv/README.freeze @@ -0,0 +1,74 @@ + +If the box freezes hard with bttv ... +===================================== + +It might be a bttv driver bug. It also might be bad hardware. It also +might be something else ... + +Just mailing me "bttv freezes" isn't going to help much. This README +has a few hints how you can help to pin down the problem. + + +bttv bugs +--------- + +If some version works and another doesn't it is likely to be a driver +bug. It is very helpful if you can tell where exactly it broke +(i.e. the last working and the first broken version). + +With a hard freeze you probably doesn't find anything in the logfiles. +The only way to capture any kernel messages is to hook up a serial +console and let some terminal application log the messages. /me uses +screen. See Documentation/serial-console.txt for details on setting +up a serial console. + +Read Documentation/oops-tracing.txt to learn how to get any useful +information out of a register+stack dump printed by the kernel on +protection faults (so-called "kernel oops"). + +If you run into some kind of deadlock, you can try to dump a call trace +for each process using sysrq-t (see Documentation/sysrq.txt). +This way it is possible to figure where *exactly* some process in "D" +state is stuck. + +I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid +for some people. Thus probably a small buglet left somewhere in bttv +0.7.x. I have no idea where exactly, it works stable for me and alot of +other people. But in case you have problems with the 0.7.x versions you +can give 0.8.x a try ... + + +hardware bugs +------------- + +Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga). +Sometimes problems show up with bttv just because of the high load on +the PCI bus. The bt848/878 chips have a few workarounds for known +incompatibilities, see README.quirks. + +Some folks report that increasing the pci latency helps too, +althrought I'm not sure whenever this really fixes the problems or +only makes it less likely to happen. Both bttv and btaudio have a +insmod option to set the PCI latency of the device. + +Some mainboard have problems to deal correctly with multiple devices +doing DMA at the same time. bttv + ide seems to cause this sometimes, +if this is the case you likely see freezes only with video and hard disk +access at the same time. Updating the IDE driver to get the latest and +greatest workarounds for hardware bugs might fix these problems. + + +other +----- + +If you use some binary-only yunk (like nvidia module) try to reproduce +the problem without. + +IRQ sharing is known to cause problems in some cases. It works just +fine in theory and many configurations. Neverless it might be worth a +try to shuffle around the PCI cards to give bttv another IRQ or make +it share the IRQ with some other piece of hardware. IRQ sharing with +VGA cards seems to cause trouble sometimes. I've also seen funny +effects with bttv sharing the IRQ with the ACPI bridge (and +apci-enabled kernel). + diff --git a/Documentation/video4linux/bttv/README.quirks b/Documentation/video4linux/bttv/README.quirks new file mode 100644 index 0000000..92e0392 --- /dev/null +++ b/Documentation/video4linux/bttv/README.quirks @@ -0,0 +1,83 @@ + +Below is what the bt878 data book says about the PCI bug compatibility +modes of the bt878 chip. + +The triton1 insmod option sets the EN_TBFX bit in the control register. +The vsfx insmod option does the same for EN_VSFX bit. If you have +stability problems you can try if one of these options makes your box +work solid. + +drivers/pci/quirks.c knows about these issues, this way these bits are +enabled automagically for known-buggy chipsets (look at the kernel +messages, bttv tells you). + +HTH, + + Gerd + +---------------------------- cut here -------------------------- + +Normal PCI Mode +--------------- + +The PCI REQ signal is the logical-or of the incoming function requests. +The inter-nal GNT[0:1] signals are gated asynchronously with GNT and +demultiplexed by the audio request signal. Thus the arbiter defaults to +the video function at power-up and parks there during no requests for +bus access. This is desirable since the video will request the bus more +often. However, the audio will have highest bus access priority. Thus +the audio will have first access to the bus even when issuing a request +after the video request but before the PCI external arbiter has granted +access to the Bt879. Neither function can preempt the other once on the +bus. The duration to empty the entire video PCI FIFO onto the PCI bus is +very short compared to the bus access latency the audio PCI FIFO can +tolerate. + + +430FX Compatibility Mode +------------------------ + +When using the 430FX PCI, the following rules will ensure +compatibility: + + (1) Deassert REQ at the same time as asserting FRAME. + (2) Do not reassert REQ to request another bus transaction until after + finish-ing the previous transaction. + +Since the individual bus masters do not have direct control of REQ, a +simple logical-or of video and audio requests would violate the rules. +Thus, both the arbiter and the initiator contain 430FX compatibility +mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in +Device Control Register on page 104. + +When EN_TBFX is enabled, the arbiter ensures that the two compatibility +rules are satisfied. Before GNT is asserted by the PCI arbiter, this +internal arbiter may still logical-or the two requests. However, once +the GNT is issued, this arbiter must lock in its decision and now route +only the granted request to the REQ pin. The arbiter decision lock +happens regardless of the state of FRAME because it does not know when +FRAME will be asserted (typically - each initiator will assert FRAME on +the cycle following GNT). When FRAME is asserted, it is the initiator s +responsibility to remove its request at the same time. It is the +arbiters responsibility to allow this request to flow through to REQ and +not allow the other request to hold REQ asserted. The decision lock may +be removed at the end of the transaction: for example, when the bus is +idle (FRAME and IRDY). The arbiter decision may then continue +asynchronously until GNT is again asserted. + + +Interfacing with Non-PCI 2.1 Compliant Core Logic +------------------------------------------------- + +A small percentage of core logic devices may start a bus transaction +during the same cycle that GNT is de-asserted. This is non PCI 2.1 +compliant. To ensure compatibility when using PCs with these PCI +controllers, the EN_VSFX bit must be enabled (refer to Device Control +Register on page 104). When in this mode, the arbiter does not pass GNT +to the internal functions unless REQ is asserted. This prevents a bus +transaction from starting the same cycle as GNT is de-asserted. This +also has the side effect of not being able to take advantage of bus +parking, thus lowering arbitration performance. The Bt879 drivers must +query for these non-compliant devices, and set the EN_VSFX bit only if +required. + diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ new file mode 100644 index 0000000..1e6328f --- /dev/null +++ b/Documentation/video4linux/bttv/Sound-FAQ @@ -0,0 +1,148 @@ + +bttv and sound mini howto +========================= + +There are alot of different bt848/849/878/879 based boards available. +Making video work often is not a big deal, because this is handled +completely by the bt8xx chip, which is common on all boards. But +sound is handled in slightly different ways on each board. + +To handle the grabber boards correctly, there is a array tvcards[] in +bttv-cards.c, which holds the informations required for each board. +Sound will work only, if the correct entry is used (for video it often +makes no difference). The bttv driver prints a line to the kernel +log, telling which card type is used. Like this one: + + bttv0: model: BT848(Hauppauge old) [autodetected] + +You should verify this is correct. If it isn't, you have to pass the +correct board type as insmod argument, "insmod bttv card=2" for +example. The file CARDLIST has a list of valid arguments for card. +If your card isn't listed there, you might check the source code for +new entries which are not listed yet. If there isn't one for your +card, you can check if one of the existing entries does work for you +(just trial and error...). + +Some boards have an extra processor for sound to do stereo decoding +and other nice features. The msp34xx chips are used by Hauppauge for +example. If your board has one, you might have to load a helper +module like msp3400.o to make sound work. If there isn't one for the +chip used on your board: Bad luck. Start writing a new one. Well, +you might want to check the video4linux mailing list archive first... + +Of course you need a correctly installed soundcard unless you have the +speakers connected directly to the grabber board. Hint: check the +mixer settings too. ALSA for example has everything muted by default. + + +How sound works in detail +========================= + +Still doesn't work? Looks like some driver hacking is required. +Below is a do-it-yourself description for you. + +The bt8xx chips have 32 general purpose pins, and registers to control +these pins. One register is the output enable register +(BT848_GPIO_OUT_EN), it says which pins are actively driven by the +bt848 chip. Another one is the data register (BT848_GPIO_DATA), where +you can get/set the status if these pins. They can be used for input +and output. + +Most grabber board vendors use these pins to control an external chip +which does the sound routing. But every board is a little different. +These pins are also used by some companies to drive remote control +receiver chips. Some boards use the i2c bus instead of the gpio pins +to connect the mux chip. + +As mentioned above, there is a array which holds the required +informations for each known board. You basically have to create a new +line for your board. The important fields are these two: + +struct tvcard +{ + [ ... ] + u32 gpiomask; + u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */ +}; + +gpiomask specifies which pins are used to control the audio mux chip. +The corresponding bits in the output enable register +(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the +bt848 chip. + +The audiomux[] array holds the data values for the different inputs +(i.e. which pins must be high/low for tuner/mute/...). This will be +written to the data register (BT848_GPIO_DATA) to switch the audio +mux. + + +What you have to do is figure out the correct values for gpiomask and +the audiomux array. If you have Windows and the drivers four your +card installed, you might to check out if you can read these registers +values used by the windows driver. A tool to do this is available +from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it +does'nt work with bt878 boards according to some reports I received. +Another one with bt878 suport is available from +http://btwincap.sourceforge.net/Files/btspy2.00.zip + +You might also dig around in the *.ini files of the Windows applications. +You can have a look at the board to see which of the gpio pins are +connected at all and then start trial-and-error ... + + +Starting with release 0.7.41 bttv has a number of insmod options to +make the gpio debugging easier: + +bttv_gpio=0/1 enable/disable gpio debug messages +gpiomask=n set the gpiomask value +audiomux=i,j,... set the values of the audiomux array +audioall=a set the values of the audiomux array (one + value for all array elements, useful to check + out which effect the particular value has). + +The messages printed with bttv_gpio=1 look like this: + + bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off] + +en = output _en_able register (BT848_GPIO_OUT_EN) +out = _out_put bits of the data register (BT848_GPIO_DATA), + i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN +in = _in_put bits of the data register, + i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN + + + +Other elements of the tvcards array +=================================== + +If you are trying to make a new card work you might find it useful to +know what the other elements in the tvcards array are good for: + +video_inputs - # of video inputs the card has +audio_inputs - historical cruft, not used any more. +tuner - which input is the tuner +svhs - which input is svhs (all others are labeled composite) +muxsel - video mux, input->registervalue mapping +pll - same as pll= insmod option +tuner_type - same as tuner= insmod option +*_modulename - hint whenever some card needs this or that audio + module loaded to work properly. +has_radio - whenever this TV card has a radio tuner. +no_msp34xx - "1" disables loading of msp3400.o module +no_tda9875 - "1" disables loading of tda9875.o module +needs_tvaudio - set to "1" to load tvaudio.o module + +If some config item is specified both from the tvcards array and as +insmod option, the insmod option takes precedence. + + + +Good luck, + + Gerd + + +PS: If you have a new working entry, mail it to me. + +-- +Gerd Knorr <kraxel@bytesex.org> diff --git a/Documentation/video4linux/bttv/Specs b/Documentation/video4linux/bttv/Specs new file mode 100644 index 0000000..79b9e57 --- /dev/null +++ b/Documentation/video4linux/bttv/Specs @@ -0,0 +1,3 @@ +Philips http://www.Semiconductors.COM/pip/ +Conexant http://www.conexant.com/techinfo/default.asp +Micronas http://www.micronas.de/pages/product_documentation/index.html diff --git a/Documentation/video4linux/bttv/THANKS b/Documentation/video4linux/bttv/THANKS new file mode 100644 index 0000000..950aa78 --- /dev/null +++ b/Documentation/video4linux/bttv/THANKS @@ -0,0 +1,24 @@ +Many thanks to: + +- Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848 + and tuner programming and his control program xtvc. + +- Martin Buck <martin-2.buck@student.uni-ulm.de> for his great Videotext + package. + +- Gerd Knorr <kraxel@cs.tu-berlin.de> for the MSP3400 support and the modular + I2C, tuner, ... support. + + +- MATRIX Vision for giving us 2 cards for free, which made support of + single crystal operation possible. + +- MIRO for providing a free PCTV card and detailed information about the + components on their cards. (E.g. how the tuner type is detected) + Without their card I could not have debugged the NTSC mode. + +- Hauppauge for telling how the sound input is selected and what components + they do and will use on their radio cards. + Also many thanks for faxing me the FM1216 data sheet. + + diff --git a/Documentation/video4linux/bttv/Tuners b/Documentation/video4linux/bttv/Tuners new file mode 100644 index 0000000..0a371d3 --- /dev/null +++ b/Documentation/video4linux/bttv/Tuners @@ -0,0 +1,115 @@ +1) Tuner Programming +==================== +There are some flavors of Tuner programming APIs. +These differ mainly by the bandswitch byte. + + L= LG_API (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04) + P= PHILIPS_API (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04) + T= TEMIC_API (VHF_LO=0x02, VHF_HI=0x04, UHF=0x01) + A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11) + M= PHILIPS_MK3 (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19) + +2) Tuner Manufacturers +====================== + +SAMSUNG Tuner identification: (e.g. TCPM9091PD27) + TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD] + [ABCJLMNQ]: + A= BG+DK + B= BG + C= I+DK + J= NTSC-Japan + L= Secam LL + M= BG+I+DK + N= NTSC + Q= BG+I+DK+LL + [89]: ? + [125]: + 2: No FM + 5: With FM + [DP]: + D= NTSC + P= PAL + [ACD]: + A= F-connector + C= Phono connector + D= Din Jack + [ABCD]: + 3-wire/I2C tuning, 2-band/3-band + + These Tuners are PHILIPS_API compatible. + +Philips Tuner identification: (e.g. FM1216MF) + F[IRMQ]12[1345]6{MF|ME|MP} + F[IRMQ]: + FI12x6: Tuner Series + FR12x6: Tuner + Radio IF + FM12x6: Tuner + FM + FQ12x6: special + FMR12x6: special + TD15xx: Digital Tuner ATSC + 12[1345]6: + 1216: PAL BG + 1236: NTSC + 1246: PAL I + 1256: Pal DK + {MF|ME|MP} + MF: BG LL w/ Secam (Multi France) + ME: BG DK I LL (Multi Europe) + MP: BG DK I (Multi PAL) + MR: BG DK M (?) + MG: BG DKI M (?) + MK2 series PHILIPS_API, most tuners are compatible to this one ! + MK3 series introduced in 2002 w/ PHILIPS_MK3_API + +Temic Tuner identification: (.e.g 4006FH5) + 4[01][0136][269]F[HYNR]5 + 40x2: Tuner (5V/33V), TEMIC_API. + 40x6: Tuner 5V + 41xx: Tuner compact + 40x9: Tuner+FM compact + [0136] + xx0x: PAL BG + xx1x: Pal DK, Secam LL + xx3x: NTSC + xx6x: PAL I + F[HYNR]5 + FH5: Pal BG + FY5: others + FN5: multistandard + FR5: w/ FM radio + 3X xxxx: order number with specific connector + Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API. + +LG Innotek Tuner: + TPI8NSR11 : NTSC J/M (TPI8NSR01 w/FM) (P,210/497) + TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM) (P,170/450) + TAPC-I701 : PAL I (TAPC-I001 w/FM) (P,170/450) + TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM) (P,170/450) + TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450) + TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450) + TAPC-W701P: PAL I (TAPC-W001P w/FM) (L,170/450) + TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450) + TAPC-Q704P: PAL D/K+I (L,170/450) + TAPC-G702P: PAL D/K+B/G (L,170/450) + + TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69) + TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8) + TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69) + Suffix: + P= Standard phono female socket + D= IEC female socket + F= F-connector + +Other Tuners: +TCL2002MB-1 : PAL BG + DK =TUNER_LG_PAL_NEW_TAPC +TCL2002MB-1F: PAL BG + DK w/FM =PHILIPS_PAL +TCL2002MI-2 : PAL I = ?? + +ALPS Tuners: + Most are LG_API compatible + TSCH6 has ALPS_API (TSCH5 ?) + TSBE1 has extra API 05,02,08 Control_byte=0xCB Source:(1) + +Lit. +(1) conexant100029b-PCI-Decoder-ApplicationNote.pdf diff --git a/Documentation/video4linux/cafe_ccic b/Documentation/video4linux/cafe_ccic new file mode 100644 index 0000000..8882102 --- /dev/null +++ b/Documentation/video4linux/cafe_ccic @@ -0,0 +1,54 @@ +"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 new file mode 100644 index 0000000..a6e5366 --- /dev/null +++ b/Documentation/video4linux/cpia2_overview.txt @@ -0,0 +1,38 @@ + 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.
\ No newline at end of file diff --git a/Documentation/video4linux/cx18.txt b/Documentation/video4linux/cx18.txt new file mode 100644 index 0000000..914cb7e --- /dev/null +++ b/Documentation/video4linux/cx18.txt @@ -0,0 +1,30 @@ +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 mailinglist. + +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 new file mode 100644 index 0000000..0e213ed --- /dev/null +++ b/Documentation/video4linux/cx2341x/README.hm12 @@ -0,0 +1,116 @@ +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. + +-------------------------------------------------------------------------- + +#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 new file mode 100644 index 0000000..5807cf1 --- /dev/null +++ b/Documentation/video4linux/cx2341x/README.vbi @@ -0,0 +1,45 @@ + +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 new file mode 100644 index 0000000..8d21181 --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-calling.txt @@ -0,0 +1,69 @@ +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 new file mode 100644 index 0000000..8c317b7 --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-decoder-api.txt @@ -0,0 +1,297 @@ +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 new file mode 100644 index 0000000..cf52c8f --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-decoder-regs.txt @@ -0,0 +1,817 @@ +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 new file mode 100644 index 0000000..be52b6f --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-dma.txt @@ -0,0 +1,96 @@ +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 new file mode 100644 index 0000000..5a27af2 --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-encoder-api.txt @@ -0,0 +1,709 @@ +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 new file mode 100644 index 0000000..9d736fe --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-memory.txt @@ -0,0 +1,139 @@ +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 new file mode 100644 index 0000000..89c4601 --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-osd-api.txt @@ -0,0 +1,350 @@ +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 new file mode 100644 index 0000000..60c502c --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-upload.txt @@ -0,0 +1,49 @@ +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 new file mode 100644 index 0000000..faccee6 --- /dev/null +++ b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt @@ -0,0 +1,54 @@ +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://users.pandora.be/nenya/electronics/rc5/ 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/et61x251.txt b/Documentation/video4linux/et61x251.txt new file mode 100644 index 0000000..1247566 --- /dev/null +++ b/Documentation/video4linux/et61x251.txt @@ -0,0 +1,315 @@ + + ET61X[12]51 PC Camera Controllers + Driver for Linux + ================================= + + - Documentation - + + +Index +===== +1. Copyright +2. Disclaimer +3. License +4. Overview and features +5. Module dependencies +6. Module loading +7. Module parameters +8. Optional device control through "sysfs" +9. Supported devices +10. Notes for V4L2 application developers +11. Contact information + + +1. Copyright +============ +Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> + + +2. Disclaimer +============= +Etoms is a trademark of Etoms Electronics Corp. +This software is not developed or sponsored by Etoms Electronics. + + +3. 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. + + +4. Overview and features +======================== +This driver supports the video interface of the devices mounting the ET61X151 +or ET61X251 PC Camera Controllers. + +It's worth to note that Etoms Electronics has never collaborated with the +author during the development of this project; despite several requests, +Etoms Electronics also refused to release enough detailed specifications of +the video compression engine. + +The driver relies on the Video4Linux2 and USB core modules. It has been +designed to run properly on SMP systems as well. + +The latest version of the ET61X[12]51 driver can be found at the following URL: +http://www.linux-projects.org/ + +Some of the features of the driver are: + +- full compliance with the Video4Linux2 API (see also "Notes for V4L2 + application developers" paragraph); +- available mmap or read/poll methods for video streaming through isochronous + data transfers; +- automatic detection of image sensor; +- support for any window resolutions and optional panning within the maximum + pixel area of image sensor; +- image downscaling with arbitrary scaling factors from 1 and 2 in both + directions (see "Notes for V4L2 application developers" paragraph); +- two different video formats for uncompressed or compressed data in low or + high compression quality (see also "Notes for V4L2 application developers" + paragraph); +- full support for the capabilities of every possible image sensors that can + be connected to the ET61X[12]51 bridges, including, for instance, red, green, + blue and global gain adjustments and exposure control (see "Supported + devices" paragraph for details); +- use of default color settings for sunlight conditions; +- dynamic I/O interface for both ET61X[12]51 and image sensor control (see + "Optional device control through 'sysfs'" paragraph); +- dynamic driver control thanks to various module parameters (see "Module + parameters" paragraph); +- up to 64 cameras can be handled at the same time; they can be connected and + disconnected from the host many times without turning off the computer, if + the system supports hotplugging; +- no known bugs. + + +5. Module dependencies +====================== +For it to work properly, the driver needs kernel support for Video4Linux and +USB. + +The following options of the kernel configuration file must be enabled and +corresponding modules must be compiled: + + # Multimedia devices + # + CONFIG_VIDEO_DEV=m + +To enable advanced debugging functionality on the device through /sysfs: + + # Multimedia devices + # + CONFIG_VIDEO_ADV_DEBUG=y + + # USB support + # + CONFIG_USB=m + +In addition, depending on the hardware being used, the modules below are +necessary: + + # USB Host Controller Drivers + # + CONFIG_USB_EHCI_HCD=m + CONFIG_USB_UHCI_HCD=m + CONFIG_USB_OHCI_HCD=m + +And finally: + + # USB Multimedia devices + # + CONFIG_USB_ET61X251=m + + +6. Module loading +================= +To use the driver, it is necessary to load the "et61x251" module into memory +after every other module required: "videodev", "v4l2_common", "compat_ioctl32", +"usbcore" and, depending on the USB host controller you have, "ehci-hcd", +"uhci-hcd" or "ohci-hcd". + +Loading can be done as shown below: + + [root@localhost home]# modprobe et61x251 + +At this point the devices should be recognized. You can invoke "dmesg" to +analyze kernel messages and verify that the loading process has gone well: + + [user@localhost home]$ dmesg + + +7. Module parameters +==================== +Module parameters are listed below: +------------------------------------------------------------------------------- +Name: video_nr +Type: short array (min = 0, max = 64) +Syntax: <-1|n[,...]> +Description: Specify V4L2 minor mode number: + -1 = use next available + n = use minor number n + You can specify up to 64 cameras this way. + For example: + video_nr=-1,2,-1 would assign minor number 2 to the second + registered camera and use auto for the first one and for every + other camera. +Default: -1 +------------------------------------------------------------------------------- +Name: force_munmap +Type: bool array (min = 0, max = 64) +Syntax: <0|1[,...]> +Description: Force the application to unmap previously mapped buffer memory + before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not + all the applications support this feature. This parameter is + specific for each detected camera. + 0 = do not force memory unmapping + 1 = force memory unmapping (save memory) +Default: 0 +------------------------------------------------------------------------------- +Name: frame_timeout +Type: uint array (min = 0, max = 64) +Syntax: <n[,...]> +Description: Timeout for a video frame in seconds. This parameter is + specific for each detected camera. This parameter can be + changed at runtime thanks to the /sys filesystem interface. +Default: 2 +------------------------------------------------------------------------------- +Name: debug +Type: ushort +Syntax: <n> +Description: Debugging information level, from 0 to 3: + 0 = none (use carefully) + 1 = critical errors + 2 = significant informations + 3 = more verbose messages + Level 3 is useful for testing only, when only one device + is used at the same time. It also shows some more informations + about the hardware being detected. This module parameter can be + changed at runtime thanks to the /sys filesystem interface. +Default: 2 +------------------------------------------------------------------------------- + + +8. Optional device control through "sysfs" +========================================== +If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, +it is possible to read and write both the ET61X[12]51 and the image sensor +registers by using the "sysfs" filesystem interface. + +There are four files in the /sys/class/video4linux/videoX directory for each +registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files +control the ET61X[12]51 bridge, while the other two control the sensor chip. +"reg" and "i2c_reg" hold the values of the current register index where the +following reading/writing operations are addressed at through "val" and +"i2c_val". Their use is not intended for end-users, unless you know what you +are doing. Remember that you must be logged in as root before writing to them. + +As an example, suppose we were to want to read the value contained in the +register number 1 of the sensor register table - which is usually the product +identifier - of the camera registered as "/dev/video0": + + [root@localhost #] cd /sys/class/video4linux/video0 + [root@localhost #] echo 1 > i2c_reg + [root@localhost #] cat i2c_val + +Note that if the sensor registers cannot be read, "cat" will fail. +To avoid race conditions, all the I/O accesses to the files are serialized. + + +9. Supported devices +==================== +None of the names of the companies as well as their products will be mentioned +here. They have never collaborated with the author, so no advertising. + +From the point of view of a driver, what unambiguously identify a device are +its vendor and product USB identifiers. Below is a list of known identifiers of +devices mounting the ET61X[12]51 PC camera controllers: + +Vendor ID Product ID +--------- ---------- +0x102c 0x6151 +0x102c 0x6251 +0x102c 0x6253 +0x102c 0x6254 +0x102c 0x6255 +0x102c 0x6256 +0x102c 0x6257 +0x102c 0x6258 +0x102c 0x6259 +0x102c 0x625a +0x102c 0x625b +0x102c 0x625c +0x102c 0x625d +0x102c 0x625e +0x102c 0x625f +0x102c 0x6260 +0x102c 0x6261 +0x102c 0x6262 +0x102c 0x6263 +0x102c 0x6264 +0x102c 0x6265 +0x102c 0x6266 +0x102c 0x6267 +0x102c 0x6268 +0x102c 0x6269 + +The following image sensors are supported: + +Model Manufacturer +----- ------------ +TAS5130D1B Taiwan Advanced Sensor Corporation + +All the available control settings of each image sensor are supported through +the V4L2 interface. + + +10. Notes for V4L2 application developers +========================================= +This driver follows the V4L2 API specifications. In particular, it enforces two +rules: + +- exactly one I/O method, either "mmap" or "read", is associated with each +file descriptor. Once it is selected, the application must close and reopen the +device to switch to the other I/O method; + +- although it is not mandatory, previously mapped buffer memory should always +be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. +The same number of buffers as before will be allocated again to match the size +of the new video frames, so you have to map the buffers again before any I/O +attempts on them. + +Consistently with the hardware limits, this driver also supports image +downscaling with arbitrary scaling factors from 1 and 2 in both directions. +However, the V4L2 API specifications don't correctly define how the scaling +factor can be chosen arbitrarily by the "negotiation" of the "source" and +"target" rectangles. To work around this flaw, we have added the convention +that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the +scaling factor is restored to 1. + +This driver supports two different video formats: the first one is the "8-bit +Sequential Bayer" format and can be used to obtain uncompressed video data +from the device through the current I/O method, while the second one provides +"raw" compressed video data (without frame headers not related to the +compressed data). The current compression quality may vary from 0 to 1 and can +be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP +V4L2 ioctl's. + + +11. Contact information +======================= +The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. + +GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is +'FCE635A4'; the public 1024-bit key should be available at any keyserver; +the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl new file mode 100644 index 0000000..2cb8160 --- /dev/null +++ b/Documentation/video4linux/extract_xc3028.pl @@ -0,0 +1,926 @@ +#!/usr/bin/perl + +# Copyright (c) Mauro Carvalho Chehab <mchehab@infradead.org> +# Released under GPLv2 +# +# In order to use, you need to: +# 1) Download the windows driver with something like: +# wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip +# 2) Extract the file hcw85bda.sys from the zip into the current dir: +# unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys +# 3) run the script: +# ./extract_xc3028.pl +# 4) copy the generated file: +# cp xc3028-v27.fw /lib/firmware + +#use strict; +use IO::Handle; + +my $debug=0; + +sub verify ($$) +{ + my ($filename, $hash) = @_; + my ($testhash); + + if (system("which md5sum > /dev/null 2>&1")) { + die "This firmware requires the md5sum command - see http://www.gnu.org/software/coreutils/\n"; + } + + open(CMD, "md5sum ".$filename."|"); + $testhash = <CMD>; + $testhash =~ /([a-zA-Z0-9]*)/; + $testhash = $1; + close CMD; + die "Hash of extracted file does not match (found $testhash, expected $hash!\n" if ($testhash ne $hash); +} + +sub get_hunk ($$) +{ + my ($offset, $length) = @_; + my ($chunklength, $buf, $rcount, $out); + + sysseek(INFILE, $offset, SEEK_SET); + while ($length > 0) { + # Calc chunk size + $chunklength = 2048; + $chunklength = $length if ($chunklength > $length); + + $rcount = sysread(INFILE, $buf, $chunklength); + die "Ran out of data\n" if ($rcount != $chunklength); + $out .= $buf; + $length -= $rcount; + } + return $out; +} + +sub write_le16($) +{ + my $val = shift; + my $msb = ($val >> 8) &0xff; + my $lsb = $val & 0xff; + + syswrite(OUTFILE, chr($lsb).chr($msb)); +} + +sub write_le32($) +{ + my $val = shift; + my $l3 = ($val >> 24) & 0xff; + my $l2 = ($val >> 16) & 0xff; + my $l1 = ($val >> 8) & 0xff; + my $l0 = $val & 0xff; + + syswrite(OUTFILE, chr($l0).chr($l1).chr($l2).chr($l3)); +} + +sub write_le64($$) +{ + my $msb_val = shift; + my $lsb_val = shift; + my $l7 = ($msb_val >> 24) & 0xff; + my $l6 = ($msb_val >> 16) & 0xff; + my $l5 = ($msb_val >> 8) & 0xff; + my $l4 = $msb_val & 0xff; + + my $l3 = ($lsb_val >> 24) & 0xff; + my $l2 = ($lsb_val >> 16) & 0xff; + my $l1 = ($lsb_val >> 8) & 0xff; + my $l0 = $lsb_val & 0xff; + + syswrite(OUTFILE, + chr($l0).chr($l1).chr($l2).chr($l3). + chr($l4).chr($l5).chr($l6).chr($l7)); +} + +sub write_hunk($$) +{ + my ($offset, $length) = @_; + my $out = get_hunk($offset, $length); + + printf "(len %d) ",$length if ($debug); + + for (my $i=0;$i<$length;$i++) { + printf "%02x ",ord(substr($out,$i,1)) if ($debug); + } + printf "\n" if ($debug); + + syswrite(OUTFILE, $out); +} + +sub write_hunk_fix_endian($$) +{ + my ($offset, $length) = @_; + my $out = get_hunk($offset, $length); + + printf "(len_fix %d) ",$length if ($debug); + + for (my $i=0;$i<$length;$i++) { + printf "%02x ",ord(substr($out,$i,1)) if ($debug); + } + printf "\n" if ($debug); + + my $i=0; + while ($i<$length) { + my $size = ord(substr($out,$i,1))*256+ord(substr($out,$i+1,1)); + syswrite(OUTFILE, substr($out,$i+1,1)); + syswrite(OUTFILE, substr($out,$i,1)); + $i+=2; + if ($size>0 && $size <0x8000) { + for (my $j=0;$j<$size;$j++) { + syswrite(OUTFILE, substr($out,$j+$i,1)); + } + $i+=$size; + } + } +} + +sub main_firmware($$$$) +{ + my $out; + my $j=0; + my $outfile = shift; + my $name = shift; + my $version = shift; + my $nr_desc = shift; + + for ($j = length($name); $j <32; $j++) { + $name = $name.chr(0); +} + + open OUTFILE, ">$outfile"; + syswrite(OUTFILE, $name); + write_le16($version); + write_le16($nr_desc); + + # + # Firmware 0, type: BASE FW F8MHZ (0x00000003), id: (0000000000000000), size: 8718 + # + + write_le32(0x00000003); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(8718); # Size + write_hunk_fix_endian(813432, 8718); + + # + # Firmware 1, type: BASE FW F8MHZ MTS (0x00000007), id: (0000000000000000), size: 8712 + # + + write_le32(0x00000007); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(8712); # Size + write_hunk_fix_endian(822152, 8712); + + # + # Firmware 2, type: BASE FW FM (0x00000401), id: (0000000000000000), size: 8562 + # + + write_le32(0x00000401); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(8562); # Size + write_hunk_fix_endian(830872, 8562); + + # + # Firmware 3, type: BASE FW FM INPUT1 (0x00000c01), id: (0000000000000000), size: 8576 + # + + write_le32(0x00000c01); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(8576); # Size + write_hunk_fix_endian(839440, 8576); + + # + # Firmware 4, type: BASE FW (0x00000001), id: (0000000000000000), size: 8706 + # + + write_le32(0x00000001); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(8706); # Size + write_hunk_fix_endian(848024, 8706); + + # + # Firmware 5, type: BASE FW MTS (0x00000005), id: (0000000000000000), size: 8682 + # + + write_le32(0x00000005); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(8682); # Size + write_hunk_fix_endian(856736, 8682); + + # + # Firmware 6, type: STD FW (0x00000000), id: PAL/BG A2/A (0000000100000007), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000001, 0x00000007); # ID + write_le32(161); # Size + write_hunk_fix_endian(865424, 161); + + # + # Firmware 7, type: STD FW MTS (0x00000004), id: PAL/BG A2/A (0000000100000007), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000001, 0x00000007); # ID + write_le32(169); # Size + write_hunk_fix_endian(865592, 169); + + # + # Firmware 8, type: STD FW (0x00000000), id: PAL/BG A2/B (0000000200000007), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000002, 0x00000007); # ID + write_le32(161); # Size + write_hunk_fix_endian(865424, 161); + + # + # Firmware 9, type: STD FW MTS (0x00000004), id: PAL/BG A2/B (0000000200000007), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000002, 0x00000007); # ID + write_le32(169); # Size + write_hunk_fix_endian(865592, 169); + + # + # Firmware 10, type: STD FW (0x00000000), id: PAL/BG NICAM/A (0000000400000007), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000004, 0x00000007); # ID + write_le32(161); # Size + write_hunk_fix_endian(866112, 161); + + # + # Firmware 11, type: STD FW MTS (0x00000004), id: PAL/BG NICAM/A (0000000400000007), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000004, 0x00000007); # ID + write_le32(169); # Size + write_hunk_fix_endian(866280, 169); + + # + # Firmware 12, type: STD FW (0x00000000), id: PAL/BG NICAM/B (0000000800000007), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000008, 0x00000007); # ID + write_le32(161); # Size + write_hunk_fix_endian(866112, 161); + + # + # Firmware 13, type: STD FW MTS (0x00000004), id: PAL/BG NICAM/B (0000000800000007), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000008, 0x00000007); # ID + write_le32(169); # Size + write_hunk_fix_endian(866280, 169); + + # + # Firmware 14, type: STD FW (0x00000000), id: PAL/DK A2 (00000003000000e0), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000003, 0x000000e0); # ID + write_le32(161); # Size + write_hunk_fix_endian(866800, 161); + + # + # Firmware 15, type: STD FW MTS (0x00000004), id: PAL/DK A2 (00000003000000e0), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000003, 0x000000e0); # ID + write_le32(169); # Size + write_hunk_fix_endian(866968, 169); + + # + # Firmware 16, type: STD FW (0x00000000), id: PAL/DK NICAM (0000000c000000e0), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x0000000c, 0x000000e0); # ID + write_le32(161); # Size + write_hunk_fix_endian(867144, 161); + + # + # Firmware 17, type: STD FW MTS (0x00000004), id: PAL/DK NICAM (0000000c000000e0), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x0000000c, 0x000000e0); # ID + write_le32(169); # Size + write_hunk_fix_endian(867312, 169); + + # + # Firmware 18, type: STD FW (0x00000000), id: SECAM/K1 (0000000000200000), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x00200000); # ID + write_le32(161); # Size + write_hunk_fix_endian(867488, 161); + + # + # Firmware 19, type: STD FW MTS (0x00000004), id: SECAM/K1 (0000000000200000), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000000, 0x00200000); # ID + write_le32(169); # Size + write_hunk_fix_endian(867656, 169); + + # + # Firmware 20, type: STD FW (0x00000000), id: SECAM/K3 (0000000004000000), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x04000000); # ID + write_le32(161); # Size + write_hunk_fix_endian(867832, 161); + + # + # Firmware 21, type: STD FW MTS (0x00000004), id: SECAM/K3 (0000000004000000), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000000, 0x04000000); # ID + write_le32(169); # Size + write_hunk_fix_endian(868000, 169); + + # + # Firmware 22, type: STD FW D2633 DTV6 ATSC (0x00010030), id: (0000000000000000), size: 149 + # + + write_le32(0x00010030); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868176, 149); + + # + # Firmware 23, type: STD FW D2620 DTV6 QAM (0x00000068), id: (0000000000000000), size: 149 + # + + write_le32(0x00000068); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868336, 149); + + # + # Firmware 24, type: STD FW D2633 DTV6 QAM (0x00000070), id: (0000000000000000), size: 149 + # + + write_le32(0x00000070); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868488, 149); + + # + # Firmware 25, type: STD FW D2620 DTV7 (0x00000088), id: (0000000000000000), size: 149 + # + + write_le32(0x00000088); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868648, 149); + + # + # Firmware 26, type: STD FW D2633 DTV7 (0x00000090), id: (0000000000000000), size: 149 + # + + write_le32(0x00000090); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868800, 149); + + # + # Firmware 27, type: STD FW D2620 DTV78 (0x00000108), id: (0000000000000000), size: 149 + # + + write_le32(0x00000108); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868960, 149); + + # + # Firmware 28, type: STD FW D2633 DTV78 (0x00000110), id: (0000000000000000), size: 149 + # + + write_le32(0x00000110); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(869112, 149); + + # + # Firmware 29, type: STD FW D2620 DTV8 (0x00000208), id: (0000000000000000), size: 149 + # + + write_le32(0x00000208); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868648, 149); + + # + # Firmware 30, type: STD FW D2633 DTV8 (0x00000210), id: (0000000000000000), size: 149 + # + + write_le32(0x00000210); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(149); # Size + write_hunk_fix_endian(868800, 149); + + # + # Firmware 31, type: STD FW FM (0x00000400), id: (0000000000000000), size: 135 + # + + write_le32(0x00000400); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le32(135); # Size + write_hunk_fix_endian(869584, 135); + + # + # Firmware 32, type: STD FW (0x00000000), id: PAL/I (0000000000000010), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x00000010); # ID + write_le32(161); # Size + write_hunk_fix_endian(869728, 161); + + # + # Firmware 33, type: STD FW MTS (0x00000004), id: PAL/I (0000000000000010), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000000, 0x00000010); # ID + write_le32(169); # Size + write_hunk_fix_endian(869896, 169); + + # + # Firmware 34, type: STD FW (0x00000000), id: SECAM/L AM (0000001000400000), size: 169 + # + + write_le32(0x00000000); # Type + write_le64(0x00000010, 0x00400000); # ID + write_le32(169); # Size + write_hunk_fix_endian(870072, 169); + + # + # Firmware 35, type: STD FW (0x00000000), id: SECAM/L NICAM (0000000c00400000), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x0000000c, 0x00400000); # ID + write_le32(161); # Size + write_hunk_fix_endian(870248, 161); + + # + # Firmware 36, type: STD FW (0x00000000), id: SECAM/Lc (0000000000800000), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x00800000); # ID + write_le32(161); # Size + write_hunk_fix_endian(870416, 161); + + # + # Firmware 37, type: STD FW (0x00000000), id: NTSC/M Kr (0000000000008000), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x00008000); # ID + write_le32(161); # Size + write_hunk_fix_endian(870584, 161); + + # + # Firmware 38, type: STD FW LCD (0x00001000), id: NTSC/M Kr (0000000000008000), size: 161 + # + + write_le32(0x00001000); # Type + write_le64(0x00000000, 0x00008000); # ID + write_le32(161); # Size + write_hunk_fix_endian(870752, 161); + + # + # Firmware 39, type: STD FW LCD NOGD (0x00003000), id: NTSC/M Kr (0000000000008000), size: 161 + # + + write_le32(0x00003000); # Type + write_le64(0x00000000, 0x00008000); # ID + write_le32(161); # Size + write_hunk_fix_endian(870920, 161); + + # + # Firmware 40, type: STD FW MTS (0x00000004), id: NTSC/M Kr (0000000000008000), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000000, 0x00008000); # ID + write_le32(169); # Size + write_hunk_fix_endian(871088, 169); + + # + # Firmware 41, type: STD FW (0x00000000), id: NTSC PAL/M PAL/N (000000000000b700), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le32(161); # Size + write_hunk_fix_endian(871264, 161); + + # + # Firmware 42, type: STD FW LCD (0x00001000), id: NTSC PAL/M PAL/N (000000000000b700), size: 161 + # + + write_le32(0x00001000); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le32(161); # Size + write_hunk_fix_endian(871432, 161); + + # + # Firmware 43, type: STD FW LCD NOGD (0x00003000), id: NTSC PAL/M PAL/N (000000000000b700), size: 161 + # + + write_le32(0x00003000); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le32(161); # Size + write_hunk_fix_endian(871600, 161); + + # + # Firmware 44, type: STD FW (0x00000000), id: NTSC/M Jp (0000000000002000), size: 161 + # + + write_le32(0x00000000); # Type + write_le64(0x00000000, 0x00002000); # ID + write_le32(161); # Size + write_hunk_fix_endian(871264, 161); + + # + # Firmware 45, type: STD FW MTS (0x00000004), id: NTSC PAL/M PAL/N (000000000000b700), size: 169 + # + + write_le32(0x00000004); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le32(169); # Size + write_hunk_fix_endian(871936, 169); + + # + # Firmware 46, type: STD FW MTS LCD (0x00001004), id: NTSC PAL/M PAL/N (000000000000b700), size: 169 + # + + write_le32(0x00001004); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le32(169); # Size + write_hunk_fix_endian(872112, 169); + + # + # Firmware 47, type: STD FW MTS LCD NOGD (0x00003004), id: NTSC PAL/M PAL/N (000000000000b700), size: 169 + # + + write_le32(0x00003004); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le32(169); # Size + write_hunk_fix_endian(872288, 169); + + # + # Firmware 48, type: SCODE FW HAS IF (0x60000000), IF = 3.28 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(3280); # IF + write_le32(192); # Size + write_hunk(811896, 192); + + # + # Firmware 49, type: SCODE FW HAS IF (0x60000000), IF = 3.30 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(3300); # IF + write_le32(192); # Size + write_hunk(813048, 192); + + # + # Firmware 50, type: SCODE FW HAS IF (0x60000000), IF = 3.44 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(3440); # IF + write_le32(192); # Size + write_hunk(812280, 192); + + # + # Firmware 51, type: SCODE FW HAS IF (0x60000000), IF = 3.46 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(3460); # IF + write_le32(192); # Size + write_hunk(812472, 192); + + # + # Firmware 52, type: SCODE FW DTV6 ATSC OREN36 HAS IF (0x60210020), IF = 3.80 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60210020); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(3800); # IF + write_le32(192); # Size + write_hunk(809784, 192); + + # + # Firmware 53, type: SCODE FW HAS IF (0x60000000), IF = 4.00 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(4000); # IF + write_le32(192); # Size + write_hunk(812088, 192); + + # + # Firmware 54, type: SCODE FW DTV6 ATSC TOYOTA388 HAS IF (0x60410020), IF = 4.08 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60410020); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(4080); # IF + write_le32(192); # Size + write_hunk(809976, 192); + + # + # Firmware 55, type: SCODE FW HAS IF (0x60000000), IF = 4.20 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(4200); # IF + write_le32(192); # Size + write_hunk(811704, 192); + + # + # Firmware 56, type: SCODE FW MONO HAS IF (0x60008000), IF = 4.32 MHz id: NTSC/M Kr (0000000000008000), size: 192 + # + + write_le32(0x60008000); # Type + write_le64(0x00000000, 0x00008000); # ID + write_le16(4320); # IF + write_le32(192); # Size + write_hunk(808056, 192); + + # + # Firmware 57, type: SCODE FW HAS IF (0x60000000), IF = 4.45 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(4450); # IF + write_le32(192); # Size + write_hunk(812664, 192); + + # + # Firmware 58, type: SCODE FW MTS LCD NOGD MONO IF HAS IF (0x6002b004), IF = 4.50 MHz id: NTSC PAL/M PAL/N (000000000000b700), size: 192 + # + + write_le32(0x6002b004); # Type + write_le64(0x00000000, 0x0000b700); # ID + write_le16(4500); # IF + write_le32(192); # Size + write_hunk(807672, 192); + + # + # Firmware 59, type: SCODE FW LCD NOGD IF HAS IF (0x60023000), IF = 4.60 MHz id: NTSC/M Kr (0000000000008000), size: 192 + # + + write_le32(0x60023000); # Type + write_le64(0x00000000, 0x00008000); # ID + write_le16(4600); # IF + write_le32(192); # Size + write_hunk(807864, 192); + + # + # Firmware 60, type: SCODE FW DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 HAS IF (0x620003e0), IF = 4.76 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x620003e0); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(4760); # IF + write_le32(192); # Size + write_hunk(807288, 192); + + # + # Firmware 61, type: SCODE FW HAS IF (0x60000000), IF = 4.94 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(4940); # IF + write_le32(192); # Size + write_hunk(811512, 192); + + # + # Firmware 62, type: SCODE FW HAS IF (0x60000000), IF = 5.26 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(5260); # IF + write_le32(192); # Size + write_hunk(810552, 192); + + # + # Firmware 63, type: SCODE FW MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG A2 NICAM (0000000f00000007), size: 192 + # + + write_le32(0x60008000); # Type + write_le64(0x0000000f, 0x00000007); # ID + write_le16(5320); # IF + write_le32(192); # Size + write_hunk(810744, 192); + + # + # Firmware 64, type: SCODE FW DTV7 DTV78 DTV8 DIBCOM52 CHINA HAS IF (0x65000380), IF = 5.40 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x65000380); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(5400); # IF + write_le32(192); # Size + write_hunk(807096, 192); + + # + # Firmware 65, type: SCODE FW DTV6 ATSC OREN538 HAS IF (0x60110020), IF = 5.58 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60110020); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(5580); # IF + write_le32(192); # Size + write_hunk(809592, 192); + + # + # Firmware 66, type: SCODE FW HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2 (0000000300000007), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000003, 0x00000007); # ID + write_le16(5640); # IF + write_le32(192); # Size + write_hunk(808440, 192); + + # + # Firmware 67, type: SCODE FW HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM (0000000c00000007), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x0000000c, 0x00000007); # ID + write_le16(5740); # IF + write_le32(192); # Size + write_hunk(808632, 192); + + # + # Firmware 68, type: SCODE FW HAS IF (0x60000000), IF = 5.90 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(5900); # IF + write_le32(192); # Size + write_hunk(810360, 192); + + # + # Firmware 69, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/DK PAL/I SECAM/K3 SECAM/L SECAM/Lc NICAM (0000000c04c000f0), size: 192 + # + + write_le32(0x60008000); # Type + write_le64(0x0000000c, 0x04c000f0); # ID + write_le16(6000); # IF + write_le32(192); # Size + write_hunk(808824, 192); + + # + # Firmware 70, type: SCODE FW DTV6 QAM ATSC LG60 F6MHZ HAS IF (0x68050060), IF = 6.20 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x68050060); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(6200); # IF + write_le32(192); # Size + write_hunk(809400, 192); + + # + # Firmware 71, type: SCODE FW HAS IF (0x60000000), IF = 6.24 MHz id: PAL/I (0000000000000010), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000010); # ID + write_le16(6240); # IF + write_le32(192); # Size + write_hunk(808248, 192); + + # + # Firmware 72, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.32 MHz id: SECAM/K1 (0000000000200000), size: 192 + # + + write_le32(0x60008000); # Type + write_le64(0x00000000, 0x00200000); # ID + write_le16(6320); # IF + write_le32(192); # Size + write_hunk(811320, 192); + + # + # Firmware 73, type: SCODE FW HAS IF (0x60000000), IF = 6.34 MHz id: SECAM/K1 (0000000000200000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00200000); # ID + write_le16(6340); # IF + write_le32(192); # Size + write_hunk(809208, 192); + + # + # Firmware 74, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.50 MHz id: PAL/DK SECAM/K3 SECAM/L NICAM (0000000c044000e0), size: 192 + # + + write_le32(0x60008000); # Type + write_le64(0x0000000c, 0x044000e0); # ID + write_le16(6500); # IF + write_le32(192); # Size + write_hunk(811128, 192); + + # + # Firmware 75, type: SCODE FW DTV6 ATSC ATI638 HAS IF (0x60090020), IF = 6.58 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60090020); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(6580); # IF + write_le32(192); # Size + write_hunk(807480, 192); + + # + # Firmware 76, type: SCODE FW HAS IF (0x60000000), IF = 6.60 MHz id: PAL/DK A2 (00000003000000e0), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000003, 0x000000e0); # ID + write_le16(6600); # IF + write_le32(192); # Size + write_hunk(809016, 192); + + # + # Firmware 77, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.68 MHz id: PAL/DK A2 (00000003000000e0), size: 192 + # + + write_le32(0x60008000); # Type + write_le64(0x00000003, 0x000000e0); # ID + write_le16(6680); # IF + write_le32(192); # Size + write_hunk(810936, 192); + + # + # Firmware 78, type: SCODE FW DTV6 ATSC TOYOTA794 HAS IF (0x60810020), IF = 8.14 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60810020); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(8140); # IF + write_le32(192); # Size + write_hunk(810168, 192); + + # + # Firmware 79, type: SCODE FW HAS IF (0x60000000), IF = 8.20 MHz id: (0000000000000000), size: 192 + # + + write_le32(0x60000000); # Type + write_le64(0x00000000, 0x00000000); # ID + write_le16(8200); # IF + write_le32(192); # Size + write_hunk(812856, 192); +} + +sub extract_firmware { + my $sourcefile = "hcw85bda.sys"; + my $hash = "0e44dbf63bb0169d57446aec21881ff2"; + my $outfile = "xc3028-v27.fw"; + my $name = "xc2028 firmware"; + my $version = 519; + my $nr_desc = 80; + my $out; + + verify($sourcefile, $hash); + + open INFILE, "<$sourcefile"; + main_firmware($outfile, $name, $version, $nr_desc); + close INFILE; +} + +extract_firmware; +printf "Firmwares generated.\n"; diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt new file mode 100644 index 0000000..004818f --- /dev/null +++ b/Documentation/video4linux/gspca.txt @@ -0,0 +1,274 @@ +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 Unknow Camera +m5602 0402:5602 ALi Video Camera Controller +spca501 040a:0002 Kodak DVC-325 +spca500 040a:0300 Kodak EZ200 +zc3xx 041e:041e Creative WebCam Live! +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 ! +zc3xx 041e:403a Creative Nx Pro 2 +spca561 041e:403b Creative Webcam Vista (VF0010) +zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) +ov519 041e:4052 Creative Live! VISTA IM +zc3xx 041e:4053 Creative Live!Cam Video IM +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:4068 Creative Live! VISTA VF0470 +spca561 0458:7004 Genius VideoCAM Express V2 +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 +sonixj 0458:702e Genius Slim 310 NB +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 +spca500 046d:0890 Logitech QuickCam traveler +vc032x 046d:0892 Logitech Orbicam +vc032x 046d:0896 Logitech Orbicam +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 QC IM ??? +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 QC 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 +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 +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 +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 +spca501 0506:00df 3Com HomeConnect Lite +sunplus 052b:1513 Megapix V4 +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 +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 +zc3xx 055f:d003 Mustek WCam300A +zc3xx 055f:d004 Mustek WCam300 AN +conex 0572:0041 Creative Notebook cx11646 +ov519 05a9:0519 OmniVision +ov519 05a9:0530 OmniVision +ov519 05a9:4519 OmniVision +ov519 05a9:8519 OmniVision +sunplus 05da:1018 Digital Dream Enigma 1.3 +stk014 05e1:0893 Syntek DV4000 +spca561 060b:a001 Maxell Compact Pc PM3 +zc3xx 0698:2003 CTX M730V built in +spca500 06bd:0404 Agfa CL20 +spca500 06be:0800 Optimedia +sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom +spca506 06e1:a190 ADS Instant VCD +spca508 0733:0110 ViewQuest VQ110 +spca508 0130:0130 Clone Digital Webcam 11043 +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 +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+ +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 +pac207 093a:2460 PAC207 Qtec Webcam 100 +pac207 093a:2463 Philips SPC 220 NC +pac207 093a:2464 Labtec Webcam 1200 +pac207 093a:2468 PAC207 +pac207 093a:2470 Genius GF112 +pac207 093a:2471 Genius VideoCam ge111 +pac207 093a:2472 Genius VideoCam ge110 +pac207 093a:2476 Genius e-Messenger 112 +pac7311 093a:2600 PAC7311 Typhoon +pac7311 093a:2601 Philips SPC 610 NC +pac7311 093a:2603 PAC7312 +pac7311 093a:2608 Trust WB-3300p +pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 +pac7311 093a:260f SnakeCam +pac7311 093a:2621 PAC731x +pac7311 093a:2624 PAC7302 +pac7311 093a:2626 Labtec 2200 +pac7311 093a:262a Webcam 300k +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 Ldlc VC302+Ov7620 +vc032x 0ac8:c001 Sony embedded vimicro +vc032x 0ac8:c002 Sony embedded vimicro +spca508 0af9:0010 Hama USB Sightcam 100 +spca508 0af9:0011 Hama USB Sightcam 100 +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:60ec SN9C105+MO4000 +sonixj 0c45:60fb Surfer NoName +sonixj 0c45:60fc LG-LIC300 +sonixj 0c45:6128 Microdia/Sonix SNP325 +sonixj 0c45:612a Avant Camera +sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix +sonixj 0c45:6130 Sonix Pccam +sonixj 0c45:6138 Sn9c120 Mo4000 +sonixj 0c45:613b Surfer SN-206 +sonixj 0c45:613c Sonix Pccam168 +sonixj 0c45:6143 Sonix Pccam168 +sunplus 0d64:0303 Sunplus FashionCam DXG +etoms 102c:6151 Qcam Sangha CIF +etoms 102c:6251 Qcam xxxxxx VGA +zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 +spca561 10fd:7e50 FlyCam Usb 100 +zc3xx 10fd:8050 Typhoon Webshot II USB 300k +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 +spca500 2899:012c Toptro Industrial +spca508 8086:0110 Intel Easy PC Camera +spca500 8086:0630 Intel Pocket PC Camera +spca506 99fa:8988 Grandtec V.cap +spca561 abcd:cdee Petcam diff --git a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt new file mode 100644 index 0000000..faccee6 --- /dev/null +++ b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt @@ -0,0 +1,54 @@ +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://users.pandora.be/nenya/electronics/rc5/ 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/ibmcam.txt b/Documentation/video4linux/ibmcam.txt new file mode 100644 index 0000000..397a94e --- /dev/null +++ b/Documentation/video4linux/ibmcam.txt @@ -0,0 +1,324 @@ +README for Linux device driver for the IBM "C-It" USB video camera + +INTRODUCTION: + +This driver does not use all features known to exist in +the IBM camera. However most of needed features work well. + +This driver was developed using logs of observed USB traffic +which was produced by standard Windows driver (c-it98.sys). +I did not have data sheets from Xirlink. + +Video formats: + 128x96 [model 1] + 176x144 + 320x240 [model 2] + 352x240 [model 2] + 352x288 +Frame rate: 3 - 30 frames per second (FPS) +External interface: USB +Internal interface: Video For Linux (V4L) +Supported controls: +- by V4L: Contrast, Brightness, Color, Hue +- by driver options: frame rate, lighting conditions, video format, + default picture settings, sharpness. + +SUPPORTED CAMERAS: + +Xirlink "C-It" camera, also known as "IBM PC Camera". +The device uses proprietary ASIC (and compression method); +it is manufactured by Xirlink. See http://www.xirlink.com/ +(renamed to http://www.veo.com), http://www.ibmpccamera.com, +or http://www.c-itnow.com/ for details and pictures. + +This very chipset ("X Chip", as marked at the factory) +is used in several other cameras, and they are supported +as well: + +- IBM NetCamera +- Veo Stingray + +The Linux driver was developed with camera with following +model number (or FCC ID): KSX-XVP510. This camera has three +interfaces, each with one endpoint (control, iso, iso). This +type of cameras is referred to as "model 1". These cameras are +no longer manufactured. + +Xirlink now manufactures new cameras which are somewhat different. +In particular, following models [FCC ID] belong to that category: + +XVP300 [KSX-X9903] +XVP600 [KSX-X9902] +XVP610 [KSX-X9902] + +(see http://www.xirlink.com/ibmpccamera/ for updates, they refer +to these new cameras by Windows driver dated 12-27-99, v3005 BETA) +These cameras have two interfaces, one endpoint in each (iso, bulk). +Such type of cameras is referred to as "model 2". They are supported +(with exception of 352x288 native mode). + +Some IBM NetCameras (Model 4) are made to generate only compressed +video streams. This is great for performance, but unfortunately +nobody knows how to decompress the stream :-( Therefore, these +cameras are *unsupported* and if you try to use one of those, all +you get is random colored horizontal streaks, not the image! +If you have one of those cameras, you probably should return it +to the store and get something that is supported. + +Tell me more about all that "model" business +-------------------------------------------- + +I just invented model numbers to uniquely identify flavors of the +hardware/firmware that were sold. It was very confusing to use +brand names or some other internal numbering schemes. So I found +by experimentation that all Xirlink chipsets fall into four big +classes, and I called them "models". Each model is programmed in +its own way, and each model sends back the video in its own way. + +Quirks of Model 2 cameras: +------------------------- + +Model 2 does not have hardware contrast control. Corresponding V4L +control is implemented in software, which is not very nice to your +CPU, but at least it works. + +This driver provides 352x288 mode by switching the camera into +quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting +this mode to 10 frames per second or less, in ideal conditions on +the bus (USB is shared, after all). The frame rate +has to be programmed very conservatively. Additional concern is that +frame rate depends on brightness setting; therefore the picture can +be good at one brightness and broken at another! I did not want to fix +the frame rate at slowest setting, but I had to move it pretty much down +the scale (so that framerate option barely matters). I also noticed that +camera after first powering up produces frames slightly faster than during +consecutive uses. All this means that if you use 352x288 (which is +default), be warned - you may encounter broken picture on first connect; +try to adjust brightness - brighter image is slower, so USB will be able +to send all data. However if you regularly use Model 2 cameras you may +prefer 176x144 which makes perfectly good I420, with no scaling and +lesser demands on USB (300 Kbits per second, or 26 frames per second). + +Another strange effect of 352x288 mode is the fine vertical grid visible +on some colored surfaces. I am sure it is caused by me not understanding +what the camera is trying to say. Blame trade secrets for that. + +The camera that I had also has a hardware quirk: if disconnected, +it needs few minutes to "relax" before it can be plugged in again +(poorly designed USB processor reset circuit?) + +[Veo Stingray with Product ID 0x800C is also Model 2, but I haven't +observed this particular flaw in it.] + +Model 2 camera can be programmed for very high sensitivity (even starlight +may be enough), this makes it convenient for tinkering with. The driver +code has enough comments to help a programmer to tweak the camera +as s/he feels necessary. + +WHAT YOU NEED: + +- A supported IBM PC (C-it) camera (model 1 or 2) + +- A Linux box with USB support (2.3/2.4; 2.2 w/backport may work) + +- A Video4Linux compatible frame grabber program such as xawtv. + +HOW TO COMPILE THE DRIVER: + +You need to compile the driver only if you are a developer +or if you want to make changes to the code. Most distributions +precompile all modules, so you can go directly to the next +section "HOW TO USE THE DRIVER". + +The ibmcam driver uses usbvideo helper library (module), +so if you are studying the ibmcam code you will be led there. + +The driver itself consists of only one file in usb/ directory: +ibmcam.c. This file is included into the Linux kernel build +process if you configure the kernel for CONFIG_USB_IBMCAM. +Run "make xconfig" and in USB section you will find the IBM +camera driver. Select it, save the configuration and recompile. + +HOW TO USE THE DRIVER: + +I recommend to compile driver as a module. This gives you an +easier access to its configuration. The camera has many more +settings than V4L can operate, so some settings are done using +module options. + +To begin with, on most modern Linux distributions the driver +will be automatically loaded whenever you plug the supported +camera in. Therefore, you don't need to do anything. However +if you want to experiment with some module parameters then +you can load and unload the driver manually, with camera +plugged in or unplugged. + +Typically module is installed with command 'modprobe', like this: + +# modprobe ibmcam framerate=1 + +Alternatively you can use 'insmod' in similar fashion: + +# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1 + +Module can be inserted with camera connected or disconnected. + +The driver can have options, though some defaults are provided. + +Driver options: (* indicates that option is model-dependent) + +Name Type Range [default] Example +-------------- -------------- -------------- ------------------ +debug Integer 0-9 [0] debug=1 +flags Integer 0-0xFF [0] flags=0x0d +framerate Integer 0-6 [2] framerate=1 +hue_correction Integer 0-255 [128] hue_correction=115 +init_brightness Integer 0-255 [128] init_brightness=100 +init_contrast Integer 0-255 [192] init_contrast=200 +init_color Integer 0-255 [128] init_color=130 +init_hue Integer 0-255 [128] init_hue=115 +lighting Integer 0-2* [1] lighting=2 +sharpness Integer 0-6* [4] sharpness=3 +size Integer 0-2* [2] size=1 + +Options for Model 2 only: + +Name Type Range [default] Example +-------------- -------------- -------------- ------------------ +init_model2_rg Integer 0..255 [0x70] init_model2_rg=128 +init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50 +init_model2_sat Integer 0..255 [0x34] init_model2_sat=65 +init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200 + +debug You don't need this option unless you are a developer. + If you are a developer then you will see in the code + what values do what. 0=off. + +flags This is a bit mask, and you can combine any number of + bits to produce what you want. Usually you don't want + any of extra features this option provides: + + FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed + VIDIOCSYNC ioctls without failing. + Will work with xawtv, will not + with xrealproducer. Default is + not set. + FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode. + FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have + magic meaning to developers. + FLAGS_OVERLAY_STATS 8 Shows tiny numbers on screen, + useful only for debugging. + FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers. + FLAGS_SEPARATE_FRAMES 32 Shows each frame separately, as + it was received from the camera. + Default (not set) is to mix the + preceding frame in to compensate + for occasional loss of Isoc data + on high frame rates. + FLAGS_CLEAN_FRAMES 64 Forces "cleanup" of each frame + prior to use; relevant only if + FLAGS_SEPARATE_FRAMES is set. + Default is not to clean frames, + this is a little faster but may + produce flicker if frame rate is + too high and Isoc data gets lost. + FLAGS_NO_DECODING 128 This flag turns the video stream + decoder off, and dumps the raw + Isoc data from the camera into + the reading process. Useful to + developers, but not to users. + +framerate This setting controls frame rate of the camera. This is + an approximate setting (in terms of "worst" ... "best") + because camera changes frame rate depending on amount + of light available. Setting 0 is slowest, 6 is fastest. + Beware - fast settings are very demanding and may not + work well with all video sizes. Be conservative. + +hue_correction This highly optional setting allows to adjust the + hue of the image in a way slightly different from + what usual "hue" control does. Both controls affect + YUV colorspace: regular "hue" control adjusts only + U component, and this "hue_correction" option similarly + adjusts only V component. However usually it is enough + to tweak only U or V to compensate for colored light or + color temperature; this option simply allows more + complicated correction when and if it is necessary. + +init_brightness These settings specify _initial_ values which will be +init_contrast used to set up the camera. If your V4L application has +init_color its own controls to adjust the picture then these +init_hue controls will be used too. These options allow you to + preconfigure the camera when it gets connected, before + any V4L application connects to it. Good for webcams. + +init_model2_rg These initial settings alter color balance of the +init_model2_rg2 camera on hardware level. All four settings may be used +init_model2_sat to tune the camera to specific lighting conditions. These +init_model2_yb settings only apply to Model 2 cameras. + +lighting This option selects one of three hardware-defined + photosensitivity settings of the camera. 0=bright light, + 1=Medium (default), 2=Low light. This setting affects + frame rate: the dimmer the lighting the lower the frame + rate (because longer exposition time is needed). The + Model 2 cameras allow values more than 2 for this option, + thus enabling extremely high sensitivity at cost of frame + rate, color saturation and imaging sensor noise. + +sharpness This option controls smoothing (noise reduction) + made by camera. Setting 0 is most smooth, setting 6 + is most sharp. Be aware that CMOS sensor used in the + camera is pretty noisy, so if you choose 6 you will + be greeted with "snowy" image. Default is 4. Model 2 + cameras do not support this feature. + +size This setting chooses one of several image sizes that are + supported by this driver. Cameras may support more, but + it's difficult to reverse-engineer all formats. + Following video sizes are supported: + + size=0 128x96 (Model 1 only) + size=1 160x120 + size=2 176x144 + size=3 320x240 (Model 2 only) + size=4 352x240 (Model 2 only) + size=5 352x288 + size=6 640x480 (Model 3 only) + + The 352x288 is the native size of the Model 1 sensor + array, so it's the best resolution the camera can + yield. The best resolution of Model 2 is 176x144, and + larger images are produced by stretching the bitmap. + Model 3 has sensor with 640x480 grid, and it works too, + but the frame rate will be exceptionally low (1-2 FPS); + it may be still OK for some applications, like security. + Choose the image size you need. The smaller image can + support faster frame rate. Default is 352x288. + +For more information and the Troubleshooting FAQ visit this URL: + + http://www.linux-usb.org/ibmcam/ + +WHAT NEEDS TO BE DONE: + +- The button on the camera is not used. I don't know how to get to it. + I know now how to read button on Model 2, but what to do with it? + +- Camera reports its status back to the driver; however I don't know + what returned data means. If camera fails at some initialization + stage then something should be done, and I don't do that because + I don't even know that some command failed. This is mostly Model 1 + concern because Model 2 uses different commands which do not return + status (and seem to complete successfully every time). + +- Some flavors of Model 4 NetCameras produce only compressed video + streams, and I don't know how to decode them. + +CREDITS: + +The code is based in no small part on the CPiA driver by Johannes Erdfelt, +Randy Dunlap, and others. Big thanks to them for their pioneering work on that +and the USB stack. + +I also thank John Lightsey for his donation of the Veo Stingray camera. diff --git a/Documentation/video4linux/lifeview.txt b/Documentation/video4linux/lifeview.txt new file mode 100644 index 0000000..05f9eb5 --- /dev/null +++ b/Documentation/video4linux/lifeview.txt @@ -0,0 +1,42 @@ +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/m5602.txt b/Documentation/video4linux/m5602.txt new file mode 100644 index 0000000..4450ab1 --- /dev/null +++ b/Documentation/video4linux/m5602.txt @@ -0,0 +1,12 @@ +This document describes the ALi m5602 bridge connected +to the following supported sensors: +OmniVision OV9650, +Samsung s5k83a, +Samsung s5k4aa, +Micron mt9m111, +Pixel plus PO1030 + +This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution. +In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats + +Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net diff --git a/Documentation/video4linux/meye.txt b/Documentation/video4linux/meye.txt new file mode 100644 index 0000000..bf3af5f --- /dev/null +++ b/Documentation/video4linux/meye.txt @@ -0,0 +1,129 @@ +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: + + forcev4l1: force use of V4L1 API instead of V4L2 + + gbuffers: number of capture buffers, default is 2 (32 max) + + gbufsize: size of each capture buffer, default is 614400 + + video_nr: video device to register (0 = /dev/video0, etc) + +Module use: +----------- + +In order to automatically load the meye module on use, you can put those lines +in your /etc/modprobe.conf file: + + alias char-major-81 videodev + alias char-major-81-0 meye + options meye gbuffers=32 + +Usage: +------ + + xawtv >= 3.49 (<http://bytesex.org/xawtv/>) + for display and uncompressed video capture: + + xawtv -c /dev/video0 -geometry 640x480 + or + xawtv -c /dev/video0 -geometry 320x240 + + motioneye (<http://popies.net/meye/>) + for getting ppm or jpg snapshots, mjpeg video + +Private API: +------------ + + The driver supports frame grabbing with the video4linux API + (either v4l1 or v4l2), so all video4linux tools (like xawtv) + should work with this driver. + + Besides the video4linux interface, the driver has a private interface + for accessing the Motion Eye extended parameters (camera sharpness, + agc, video framerate), the shapshot and the MJPEG capture facilities. + + This interface consists of several ioctls (prototypes and structures + can be found in include/linux/meye.h): + + MEYEIOC_G_PARAMS + MEYEIOC_S_PARAMS + Get and set the extended parameters of the motion eye camera. + The user should always query the current parameters with + MEYEIOC_G_PARAMS, change what he likes and then issue the + MEYEIOC_S_PARAMS call (checking for -EINVAL). The extended + parameters are described by the meye_params structure. + + + MEYEIOC_QBUF_CAPT + Queue a buffer for capture (the buffers must have been + obtained with a VIDIOCGMBUF call and mmap'ed by the + application). The argument to MEYEIOC_QBUF_CAPT is the + buffer number to queue (or -1 to end capture). The first + call to MEYEIOC_QBUF_CAPT starts the streaming capture. + + MEYEIOC_SYNC + Takes as an argument the buffer number you want to sync. + This ioctl blocks until the buffer is filled and ready + for the application to use. It returns the buffer size. + + MEYEIOC_STILLCAPT + MEYEIOC_STILLJCAPT + Takes a snapshot in an uncompressed or compressed jpeg format. + This ioctl blocks until the snapshot is done and returns (for + jpeg snapshot) the size of the image. The image data is + available from the first mmap'ed buffer. + + Look at the 'motioneye' application code for an actual example. + +Bugs / Todo: +------------ + + - the driver could be much cleaned up by removing the v4l1 support. + However, this means all v4l1-only applications will stop working. + + - 'motioneye' still uses the meye private v4l1 API extensions. diff --git a/Documentation/video4linux/not-in-cx2388x-datasheet.txt b/Documentation/video4linux/not-in-cx2388x-datasheet.txt new file mode 100644 index 0000000..edbfe74 --- /dev/null +++ b/Documentation/video4linux/not-in-cx2388x-datasheet.txt @@ -0,0 +1,41 @@ +================================================================================= +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/ov511.txt b/Documentation/video4linux/ov511.txt new file mode 100644 index 0000000..b3326b1 --- /dev/null +++ b/Documentation/video4linux/ov511.txt @@ -0,0 +1,288 @@ +------------------------------------------------------------------------------- +Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC +------------------------------------------------------------------------------- + +Author: Mark McClelland +Homepage: http://alpha.dyndns.org/ov511 + +INTRODUCTION: + +This is a driver for the OV511, a USB-only chip used in many "webcam" devices. +Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work. +Video capture devices that use the Philips SAA7111A decoder also work. It +supports streaming and capture of color or monochrome video via the Video4Linux +API. Most V4L apps are compatible with it. Most resolutions with a width and +height that are a multiple of 8 are supported. + +If you need more information, please visit the OV511 homepage at the above URL. + +WHAT YOU NEED: + +- If you want to help with the development, get the chip's specification docs at + http://www.ovt.com/omniusbp.html + +- A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv) + vidcat is part of the w3cam package: http://mpx.freeshell.net/ + xawtv is available at: http://linux.bytesex.org/xawtv/ + +HOW TO USE IT: + +Note: These are simplified instructions. For complete instructions see: + http://alpha.dyndns.org/ov511/install.html + +You must have first compiled USB support, support for your specific USB host +controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend +making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled. + +Next, (as root): + + modprobe usbcore + modprobe usb-uhci <OR> modprobe usb-ohci + modprobe videodev + modprobe ov511 + +If it is not already there (it usually is), create the video device: + + mknod /dev/video0 c 81 0 + +Optionally, symlink /dev/video to /dev/video0 + +You will have to set permissions on this device to allow you to read/write +from it: + + chmod 666 /dev/video + chmod 666 /dev/video0 (if necessary) + +Now you are ready to run a video app! Both vidcat and xawtv work well for me +at 640x480. + +[Using vidcat:] + + vidcat -s 640x480 -p c > test.jpg + xview test.jpg + +[Using xawtv:] + +From the main xawtv directory: + + make clean + ./configure + make + make install + +Now you should be able to run xawtv. Right click for the options dialog. + +MODULE PARAMETERS: + + You can set these with: insmod ov511 NAME=VALUE + There is currently no way to set these on a per-camera basis. + + NAME: autobright + TYPE: integer (Boolean) + DEFAULT: 1 + DESC: Brightness is normally under automatic control and can't be set + manually by the video app. Set to 0 for manual control. + + NAME: autogain + TYPE: integer (Boolean) + DEFAULT: 1 + DESC: Auto Gain Control enable. This feature is not yet implemented. + + NAME: autoexp + TYPE: integer (Boolean) + DEFAULT: 1 + DESC: Auto Exposure Control enable. This feature is not yet implemented. + + NAME: debug + TYPE: integer (0-6) + DEFAULT: 3 + DESC: Sets the threshold for printing debug messages. The higher the value, + the more is printed. The levels are cumulative, and are as follows: + 0=no debug messages + 1=init/detection/unload and other significant messages + 2=some warning messages + 3=config/control function calls + 4=most function calls and data parsing messages + 5=highly repetitive mesgs + + NAME: snapshot + TYPE: integer (Boolean) + DEFAULT: 0 + DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until + the snapshot button is pressed. Note: enabling this mode disables + /proc/video/ov511/<minor#>/button + + NAME: cams + TYPE: integer (1-4 for OV511, 1-31 for OV511+) + DEFAULT: 1 + DESC: Number of cameras allowed to stream simultaneously on a single bus. + Values higher than 1 reduce the data rate of each camera, allowing two + or more to be used at once. If you have a complicated setup involving + both OV511 and OV511+ cameras, trial-and-error may be necessary for + finding the optimum setting. + + NAME: compress + TYPE: integer (Boolean) + DEFAULT: 0 + DESC: Set this to 1 to turn on the camera's compression engine. This can + potentially increase the frame rate at the expense of quality, if you + have a fast CPU. You must load the proper compression module for your + camera before starting your application (ov511_decomp or ov518_decomp). + + NAME: testpat + TYPE: integer (Boolean) + DEFAULT: 0 + DESC: This configures the camera's sensor to transmit a colored test-pattern + instead of an image. This does not work correctly yet. + + NAME: dumppix + TYPE: integer (0-2) + DEFAULT: 0 + DESC: Dumps raw pixel data and skips post-processing and format conversion. + It is for debugging purposes only. Options are: + 0: Disable (default) + 1: Dump raw data from camera, excluding headers and trailers + 2: Dumps data exactly as received from camera + + NAME: led + TYPE: integer (0-2) + DEFAULT: 1 (Always on) + DESC: Controls whether the LED (the little light) on the front of the camera + is always off (0), always on (1), or only on when driver is open (2). + This is not supported with the OV511, and might only work with certain + cameras (ones that actually have the LED wired to the control pin, and + not just hard-wired to be on all the time). + + NAME: dump_bridge + TYPE: integer (Boolean) + DEFAULT: 0 + DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system + log. Only useful for serious debugging/development purposes. + + NAME: dump_sensor + TYPE: integer (Boolean) + DEFAULT: 0 + DESC: Dumps the sensor register values to the system log. Only useful for + serious debugging/development purposes. + + NAME: printph + TYPE: integer (Boolean) + DEFAULT: 0 + DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This + is only useful if you are trying to debug problems with the isoc data + stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be + warned that this dumps a large number of messages to your kernel log. + + NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv + TYPE: integer (0-63 for phy and phuv, 0-255 for rest) + DEFAULT: OV511 default values + DESC: These are registers 70h - 77h of the OV511, which control the + prediction ranges and quantization thresholds of the compressor, for + the Y and UV channels in the horizontal and vertical directions. See + the OV511 or OV511+ data sheet for more detailed descriptions. These + normally do not need to be changed. + + NAME: lightfreq + TYPE: integer (0, 50, or 60) + DEFAULT: 0 (use sensor default) + DESC: Sets the sensor to match your lighting frequency. This can reduce the + appearance of "banding", i.e. horizontal lines or waves of light and + dark that are often caused by artificial lighting. Valid values are: + 0 - Use default (depends on sensor, most likely 60 Hz) + 50 - For European and Asian 50 Hz power + 60 - For American 60 Hz power + + NAME: bandingfilter + TYPE: integer (Boolean) + DEFAULT: 0 (off) + DESC: Enables the sensor´s banding filter exposure algorithm. This reduces + or stabilizes the "banding" caused by some artificial light sources + (especially fluorescent). You might have to set lightfreq correctly for + this to work right. As an added bonus, this sometimes makes it + possible to capture your monitor´s output. + + NAME: fastset + TYPE: integer (Boolean) + DEFAULT: 0 (off) + DESC: Allows picture settings (brightness, contrast, color, and hue) to take + effect immediately, even in the middle of a frame. This reduces the + time to change settings, but can ruin frames during the change. Only + affects OmniVision sensors. + + NAME: force_palette + TYPE: integer (Boolean) + DEFAULT: 0 (off) + DESC: Forces the palette (color format) to a specific value. If an + application requests a different palette, it will be rejected, thereby + forcing it to try others until it succeeds. This is useful for forcing + greyscale mode with a color camera, for example. Supported modes are: + 0 (Allows all the following formats) + 1 VIDEO_PALETTE_GREY (Linear greyscale) + 10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar) + 15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10) + + NAME: backlight + TYPE: integer (Boolean) + DEFAULT: 0 (off) + DESC: Setting this flag changes the exposure algorithm for OmniVision sensors + such that objects in the camera's view (i.e. your head) can be clearly + seen when they are illuminated from behind. It reduces or eliminates + the sensor's auto-exposure function, so it should only be used when + needed. Additionally, it is only supported with the OV6620 and OV7620. + + NAME: unit_video + TYPE: Up to 16 comma-separated integers + DEFAULT: 0,0,0... (automatically assign the next available minor(s)) + DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices. + For example, "unit_video=1,3" will make the driver use /dev/video1 and + /dev/video3 for the first two devices it detects. Additional devices + will be assigned automatically starting at the first available device + node (/dev/video0 in this case). Note that you cannot specify 0 as a + minor number. This feature requires kernel version 2.4.5 or higher. + + NAME: remove_zeros + TYPE: integer (Boolean) + DEFAULT: 0 (do not skip any incoming data) + DESC: Setting this to 1 will remove zero-padding from incoming data. This + will compensate for the blocks of corruption that can appear when the + camera cannot keep up with the speed of the USB bus (eg. at low frame + resolutions). This feature is always enabled when compression is on. + + NAME: mirror + TYPE: integer (Boolean) + DEFAULT: 0 (off) + DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This + might be necessary if your camera has a custom lens assembly. This has + no effect with video capture devices. + + NAME: ov518_color + TYPE: integer (Boolean) + DEFAULT: 0 (off) + DESC: Enable OV518 color support. This is off by default since it doesn't + work most of the time. If you want to try it, you must also load + ov518_decomp with the "nouv=0" parameter. If you get improper colors or + diagonal lines through the image, restart your video app and try again. + Repeat as necessary. + +WORKING FEATURES: + o Color streaming/capture at most widths and heights that are multiples of 8. + o Monochrome (use force_palette=1 to enable) + o Setting/getting of saturation, contrast, brightness, and hue (only some of + them work the OV7620 and OV7620AE) + o /proc status reporting + o SAA7111A video capture support at 320x240 and 640x480 + o Compression support + o SMP compatibility + +HOW TO CONTACT ME: + +You can email me at mark@alpha.dyndns.org . Please prefix the subject line +with "OV511: " so that I am certain to notice your message. + +CREDITS: + +The code is based in no small part on the CPiA driver by Johannes Erdfelt, +Randy Dunlap, and others. Big thanks to them for their pioneering work on that +and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and +image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio +Matsuoka for their work as well. diff --git a/Documentation/video4linux/radiotrack.txt b/Documentation/video4linux/radiotrack.txt new file mode 100644 index 0000000..d1f3ed1 --- /dev/null +++ b/Documentation/video4linux/radiotrack.txt @@ -0,0 +1,147 @@ +NOTES ON RADIOTRACK CARD CONTROL +by Stephen M. Benoit (benoits@servicepro.com) Dec 14, 1996 +---------------------------------------------------------------------------- + +Document version 1.0 + +ACKNOWLEDGMENTS +---------------- +This document was made based on 'C' code for Linux from Gideon le Grange +(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from +Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from +experiments that the author performed on his own setup, so your mileage may +vary... I make no guarantees, claims or warranties to the suitability or +validity of this information. No other documentation on the AIMS +Lab (http://www.aimslab.com/) RadioTrack card was made available to the +author. This document is offered in the hopes that it might help users who +want to use the RadioTrack card in an environment other than MS Windows. + +WHY THIS DOCUMENT? +------------------ +I have a RadioTrack card from back when I ran an MS-Windows platform. After +converting to Linux, I found Gideon le Grange's command-line software for +running the card, and found that it was good! Frans Brinkman made a +comfortable X-windows interface, and added a scanning feature. For hack +value, I wanted to see if the tuner could be tuned beyond the usual FM radio +broadcast band, so I could pick up the audio carriers from North American +broadcast TV channels, situated just below and above the 87.0-109.0 MHz range. +I did not get much success, but I learned about programming ioports under +Linux and gained some insights about the hardware design used for the card. + +So, without further delay, here are the details. + + +PHYSICAL DESCRIPTION +-------------------- +The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF) +input is simply an antenna lead, and the output is a power audio signal +available through a miniature phone plug. Its RF frequencies of operation are +more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast +band). Although the registers can be programmed to request frequencies beyond +these limits, experiments did not give promising results. The variable +frequency oscillator (VFO) that demodulates the intermediate frequency (IF) +signal probably has a small range of useful frequencies, and wraps around or +gets clipped beyond the limits mentioned above. + + +CONTROLLING THE CARD WITH IOPORT +-------------------------------- +The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one +ioport seems to be involved. The ioport decoding circuitry must be pretty +simple, as individual ioport bits are directly matched to specific functions +(or blocks) of the radio card. This way, many functions can be changed in +parallel with one write to the ioport. The only feedback available through +the ioports appears to be the "Stereo Detect" bit. + +The bits of the ioport are arranged as follows: + + MSb LSb ++------+------+------+--------+--------+-------+---------+--------+ +| VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune | +| (+) | (-) | | Detect | Audio | (bit) | (latch) | Update | +| | | | Enable | Enable | | | Enable | ++------+------+------+--------+--------+-------+---------+--------+ + + +VolA . VolB [AB......] +----------- +0 0 : audio mute +0 1 : volume + (some delay required) +1 0 : volume - (some delay required) +1 1 : stay at present volume + +Stereo Detect Enable [...S....] +-------------------- +0 : No Detect +1 : Detect + + Results available by reading ioport >60 msec after last port write. + 0xff ==> no stereo detected, 0xfd ==> stereo detected. + +Radio to Audio (path) Enable [....R...] +---------------------------- +0 : Disable path (silence) +1 : Enable path (audio produced) + +TuneA . TuneB [.....AB.] +------------- +0 0 : "zero" bit phase 1 +0 1 : "zero" bit phase 2 + +1 0 : "one" bit phase 1 +1 1 : "one" bit phase 2 + + 24-bit code, where bits = (freq*40) + 10486188. + The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid. + The bits are shifted in LSb first. + +Tune Update Enable [.......T] +------------------ +0 : Tuner held constant +1 : Tuner updating in progress + + +PROGRAMMING EXAMPLES +-------------------- +Default: BASE <-- 0xc8 (current volume, no stereo detect, + radio enable, tuner adjust disable) + +Card Off: BASE <-- 0x00 (audio mute, no stereo detect, + radio disable, tuner adjust disable) + +Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business) + BASE <-- 0xc8 (see "Default") + +Volume Down: BASE <-- 0x48 (volume down, no stereo detect, + radio enable, tuner adjust disable) + * wait 10 msec * + BASE <-- 0xc8 (see "Default") + +Volume Up: BASE <-- 0x88 (volume up, no stereo detect, + radio enable, tuner adjust disable) + * wait 10 msec * + BASE <-- 0xc8 (see "Default") + +Check Stereo: BASE <-- 0xd8 (current volume, stereo detect, + radio enable, tuner adjust disable) + * wait 100 msec * + x <-- BASE (read ioport) + BASE <-- 0xc8 (see "Default") + + x=0xff ==> "not stereo", x=0xfd ==> "stereo detected" + +Set Frequency: code = (freq*40) + 10486188 + foreach of the 24 bits in code, + (from Least to Most Significant): + to write a "zero" bit, + BASE <-- 0x01 (audio mute, no stereo detect, radio + disable, "zero" bit phase 1, tuner adjust) + BASE <-- 0x03 (audio mute, no stereo detect, radio + disable, "zero" bit phase 2, tuner adjust) + to write a "one" bit, + BASE <-- 0x05 (audio mute, no stereo detect, radio + disable, "one" bit phase 1, tuner adjust) + BASE <-- 0x07 (audio mute, no stereo detect, radio + disable, "one" bit phase 2, tuner adjust) + +---------------------------------------------------------------------------- diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt new file mode 100644 index 0000000..7b9d1c9 --- /dev/null +++ b/Documentation/video4linux/se401.txt @@ -0,0 +1,54 @@ +Linux driver for SE401 based USB cameras + +Copyright, 2001, Jeroen Vreeken + + +INTRODUCTION: + +The SE401 chip is the used in low-cost usb webcams. +It is produced by Endpoints Inc. (www.endpoints.com). +It interfaces directly to a cmos image sensor and USB. The only other major +part in a se401 based camera is a dram chip. + +The following cameras are known to work with this driver: + +Aox se401 (non-branded) cameras +Philips PVCV665 USB VGA webcam 'Vesta Fun' +Kensington VideoCAM PC Camera Model 67014 +Kensington VideoCAM PC Camera Model 67015 +Kensington VideoCAM PC Camera Model 67016 +Kensington VideoCAM PC Camera Model 67017 + + +WHAT YOU NEED: + +- USB support +- VIDEO4LINUX support + +More information about USB support for linux can be found at: +http://www.linux-usb.org + + +MODULE OPTIONS: + +When the driver is compiled as a module you can also use the 'flickerless' +option. With it exposure is limited to values that do not interfere with the +net frequency. Valid options for this option are 0, 50 and 60. (0=disable, +50=50hz, 60=60hz) + + +KNOWN PROBLEMS: + +The driver works fine with the usb-ohci and uhci host controller drivers, +the default settings also work with usb-uhci. But sending more than one bulk +transfer at a time with usb-uhci doesn't work yet. +Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in +order to increase the throughput (and thus framerate). + + +HELP: + +The latest info on this driver can be found at: +http://www.chello.nl/~j.vreeken/se401/ +And questions to me can be send to: +pe1rxq@amsat.org diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt new file mode 100644 index 0000000..11c5fd2 --- /dev/null +++ b/Documentation/video4linux/si470x.txt @@ -0,0 +1,118 @@ +Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers + +Copyright (c) 2008 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) + + +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 + +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. + +If you just want to test audio (very poor quality): +cat /dev/dsp1 > /dev/dsp + +If you use OSS try: +sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp + +If you use arts try: +arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - + + +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/sn9c102.txt b/Documentation/video4linux/sn9c102.txt new file mode 100644 index 0000000..73de405 --- /dev/null +++ b/Documentation/video4linux/sn9c102.txt @@ -0,0 +1,592 @@ + + SN9C1xx PC Camera Controllers + Driver for Linux + ============================= + + - Documentation - + + +Index +===== +1. Copyright +2. Disclaimer +3. License +4. Overview and features +5. Module dependencies +6. Module loading +7. Module parameters +8. Optional device control through "sysfs" +9. Supported devices +10. Notes for V4L2 application developers +11. Video frame formats +12. Contact information +13. Credits + + +1. Copyright +============ +Copyright (C) 2004-2007 by Luca Risolia <luca.risolia@studio.unibo.it> + + +2. Disclaimer +============= +SONiX is a trademark of SONiX Technology Company Limited, inc. +This software is not sponsored or developed by SONiX. + + +3. 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. + + +4. Overview and features +======================== +This driver attempts to support the video interface of the devices assembling +the SONiX SN9C101, SN9C102, SN9C103, SN9C105 and SN9C120 PC Camera Controllers +("SN9C1xx" from now on). + +The driver relies on the Video4Linux2 and USB core modules. It has been +designed to run properly on SMP systems as well. + +The latest version of the SN9C1xx driver can be found at the following URL: +http://www.linux-projects.org/ + +Some of the features of the driver are: + +- full compliance with the Video4Linux2 API (see also "Notes for V4L2 + application developers" paragraph); +- available mmap or read/poll methods for video streaming through isochronous + data transfers; +- automatic detection of image sensor; +- support for built-in microphone interface; +- support for any window resolutions and optional panning within the maximum + pixel area of image sensor; +- image downscaling with arbitrary scaling factors from 1, 2 and 4 in both + directions (see "Notes for V4L2 application developers" paragraph); +- two different video formats for uncompressed or compressed data in low or + high compression quality (see also "Notes for V4L2 application developers" + and "Video frame formats" paragraphs); +- full support for the capabilities of many of the possible image sensors that + can be connected to the SN9C1xx bridges, including, for instance, red, green, + blue and global gain adjustments and exposure (see "Supported devices" + paragraph for details); +- use of default color settings for sunlight conditions; +- dynamic I/O interface for both SN9C1xx and image sensor control and + monitoring (see "Optional device control through 'sysfs'" paragraph); +- dynamic driver control thanks to various module parameters (see "Module + parameters" paragraph); +- up to 64 cameras can be handled at the same time; they can be connected and + disconnected from the host many times without turning off the computer, if + the system supports hotplugging; +- no known bugs. + + +5. Module dependencies +====================== +For it to work properly, the driver needs kernel support for Video4Linux and +USB. + +The following options of the kernel configuration file must be enabled and +corresponding modules must be compiled: + + # Multimedia devices + # + CONFIG_VIDEO_DEV=m + +To enable advanced debugging functionality on the device through /sysfs: + + # Multimedia devices + # + CONFIG_VIDEO_ADV_DEBUG=y + + # USB support + # + CONFIG_USB=m + +In addition, depending on the hardware being used, the modules below are +necessary: + + # USB Host Controller Drivers + # + CONFIG_USB_EHCI_HCD=m + CONFIG_USB_UHCI_HCD=m + CONFIG_USB_OHCI_HCD=m + +The SN9C103, SN9c105 and SN9C120 controllers also provide a built-in microphone +interface. It is supported by the USB Audio driver thanks to the ALSA API: + + # Sound + # + CONFIG_SOUND=y + + # Advanced Linux Sound Architecture + # + CONFIG_SND=m + + # USB devices + # + CONFIG_SND_USB_AUDIO=m + +And finally: + + # USB Multimedia devices + # + CONFIG_USB_SN9C102=m + + +6. Module loading +================= +To use the driver, it is necessary to load the "sn9c102" module into memory +after every other module required: "videodev", "v4l2_common", "compat_ioctl32", +"usbcore" and, depending on the USB host controller you have, "ehci-hcd", +"uhci-hcd" or "ohci-hcd". + +Loading can be done as shown below: + + [root@localhost home]# modprobe sn9c102 + +Note that the module is called "sn9c102" for historic reasons, although it +does not just support the SN9C102. + +At this point all the devices supported by the driver and connected to the USB +ports should be recognized. You can invoke "dmesg" to analyze kernel messages +and verify that the loading process has gone well: + + [user@localhost home]$ dmesg + +or, to isolate all the kernel messages generated by the driver: + + [user@localhost home]$ dmesg | grep sn9c102 + + +7. Module parameters +==================== +Module parameters are listed below: +------------------------------------------------------------------------------- +Name: video_nr +Type: short array (min = 0, max = 64) +Syntax: <-1|n[,...]> +Description: Specify V4L2 minor mode number: + -1 = use next available + n = use minor number n + You can specify up to 64 cameras this way. + For example: + video_nr=-1,2,-1 would assign minor number 2 to the second + recognized camera and use auto for the first one and for every + other camera. +Default: -1 +------------------------------------------------------------------------------- +Name: force_munmap +Type: bool array (min = 0, max = 64) +Syntax: <0|1[,...]> +Description: Force the application to unmap previously mapped buffer memory + before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not + all the applications support this feature. This parameter is + specific for each detected camera. + 0 = do not force memory unmapping + 1 = force memory unmapping (save memory) +Default: 0 +------------------------------------------------------------------------------- +Name: frame_timeout +Type: uint array (min = 0, max = 64) +Syntax: <0|n[,...]> +Description: Timeout for a video frame in seconds before returning an I/O + error; 0 for infinity. This parameter is specific for each + detected camera and can be changed at runtime thanks to the + /sys filesystem interface. +Default: 2 +------------------------------------------------------------------------------- +Name: debug +Type: ushort +Syntax: <n> +Description: Debugging information level, from 0 to 3: + 0 = none (use carefully) + 1 = critical errors + 2 = significant informations + 3 = more verbose messages + Level 3 is useful for testing only. It also shows some more + informations about the hardware being detected. + This parameter can be changed at runtime thanks to the /sys + filesystem interface. +Default: 2 +------------------------------------------------------------------------------- + + +8. Optional device control through "sysfs" [1] +========================================== +If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, +it is possible to read and write both the SN9C1xx and the image sensor +registers by using the "sysfs" filesystem interface. + +Every time a supported device is recognized, a write-only file named "green" is +created in the /sys/class/video4linux/videoX directory. You can set the green +channel's gain by writing the desired value to it. The value may range from 0 +to 15 for the SN9C101 or SN9C102 bridges, from 0 to 127 for the SN9C103, +SN9C105 and SN9C120 bridges. +Similarly, only for the SN9C103, SN9C105 and SN9C120 controllers, blue and red +gain control files are available in the same directory, for which accepted +values may range from 0 to 127. + +There are other four entries in the directory above for each registered camera: +"reg", "val", "i2c_reg" and "i2c_val". The first two files control the +SN9C1xx bridge, while the other two control the sensor chip. "reg" and +"i2c_reg" hold the values of the current register index where the following +reading/writing operations are addressed at through "val" and "i2c_val". Their +use is not intended for end-users. Note that "i2c_reg" and "i2c_val" will not +be created if the sensor does not actually support the standard I2C protocol or +its registers are not 8-bit long. Also, remember that you must be logged in as +root before writing to them. + +As an example, suppose we were to want to read the value contained in the +register number 1 of the sensor register table - which is usually the product +identifier - of the camera registered as "/dev/video0": + + [root@localhost #] cd /sys/class/video4linux/video0 + [root@localhost #] echo 1 > i2c_reg + [root@localhost #] cat i2c_val + +Note that "cat" will fail if sensor registers cannot be read. + +Now let's set the green gain's register of the SN9C101 or SN9C102 chips to 2: + + [root@localhost #] echo 0x11 > reg + [root@localhost #] echo 2 > val + +Note that the SN9C1xx always returns 0 when some of its registers are read. +To avoid race conditions, all the I/O accesses to the above files are +serialized. +The sysfs interface also provides the "frame_header" entry, which exports the +frame header of the most recent requested and captured video frame. The header +is always 18-bytes long and is appended to every video frame by the SN9C1xx +controllers. As an example, this additional information can be used by the user +application for implementing auto-exposure features via software. + +The following table describes the frame header exported by the SN9C101 and +SN9C102: + +Byte # Value or bits Description +------ ------------- ----------- +0x00 0xFF Frame synchronisation pattern +0x01 0xFF Frame synchronisation pattern +0x02 0x00 Frame synchronisation pattern +0x03 0xC4 Frame synchronisation pattern +0x04 0xC4 Frame synchronisation pattern +0x05 0x96 Frame synchronisation pattern +0x06 [3:0] Read channel gain control = (1+R_GAIN/8) + [7:4] Blue channel gain control = (1+B_GAIN/8) +0x07 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled + [2:1] Maximum scale factor for compression + [ 3 ] 1 = USB fifo(2K bytes) is full + [ 4 ] 1 = Digital gain is finish + [ 5 ] 1 = Exposure is finish + [7:6] Frame index +0x08 [7:0] Y sum inside Auto-Exposure area (low-byte) +0x09 [7:0] Y sum inside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 32 +0x0A [7:0] Y sum outside Auto-Exposure area (low-byte) +0x0B [7:0] Y sum outside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 128 +0x0C 0xXX Not used +0x0D 0xXX Not used +0x0E 0xXX Not used +0x0F 0xXX Not used +0x10 0xXX Not used +0x11 0xXX Not used + +The following table describes the frame header exported by the SN9C103: + +Byte # Value or bits Description +------ ------------- ----------- +0x00 0xFF Frame synchronisation pattern +0x01 0xFF Frame synchronisation pattern +0x02 0x00 Frame synchronisation pattern +0x03 0xC4 Frame synchronisation pattern +0x04 0xC4 Frame synchronisation pattern +0x05 0x96 Frame synchronisation pattern +0x06 [6:0] Read channel gain control = (1/2+R_GAIN/64) +0x07 [6:0] Blue channel gain control = (1/2+B_GAIN/64) + [7:4] +0x08 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled + [2:1] Maximum scale factor for compression + [ 3 ] 1 = USB fifo(2K bytes) is full + [ 4 ] 1 = Digital gain is finish + [ 5 ] 1 = Exposure is finish + [7:6] Frame index +0x09 [7:0] Y sum inside Auto-Exposure area (low-byte) +0x0A [7:0] Y sum inside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 32 +0x0B [7:0] Y sum outside Auto-Exposure area (low-byte) +0x0C [7:0] Y sum outside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 128 +0x0D [1:0] Audio frame number + [ 2 ] 1 = Audio is recording +0x0E [7:0] Audio summation (low-byte) +0x0F [7:0] Audio summation (high-byte) +0x10 [7:0] Audio sample count +0x11 [7:0] Audio peak data in audio frame + +The AE area (sx, sy, ex, ey) in the active window can be set by programming the +registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C1xx controllers, where one unit +corresponds to 32 pixels. + +[1] The frame headers exported by the SN9C105 and SN9C120 are not described. + + +9. Supported devices +==================== +None of the names of the companies as well as their products will be mentioned +here. They have never collaborated with the author, so no advertising. + +From the point of view of a driver, what unambiguously identify a device are +its vendor and product USB identifiers. Below is a list of known identifiers of +devices assembling the SN9C1xx PC camera controllers: + +Vendor ID Product ID +--------- ---------- +0x0458 0x7025 +0x045e 0x00f5 +0x045e 0x00f7 +0x0471 0x0327 +0x0471 0x0328 +0x0c45 0x6001 +0x0c45 0x6005 +0x0c45 0x6007 +0x0c45 0x6009 +0x0c45 0x600d +0x0c45 0x6011 +0x0c45 0x6019 +0x0c45 0x6024 +0x0c45 0x6025 +0x0c45 0x6028 +0x0c45 0x6029 +0x0c45 0x602a +0x0c45 0x602b +0x0c45 0x602c +0x0c45 0x602d +0x0c45 0x602e +0x0c45 0x6030 +0x0c45 0x603f +0x0c45 0x6080 +0x0c45 0x6082 +0x0c45 0x6083 +0x0c45 0x6088 +0x0c45 0x608a +0x0c45 0x608b +0x0c45 0x608c +0x0c45 0x608e +0x0c45 0x608f +0x0c45 0x60a0 +0x0c45 0x60a2 +0x0c45 0x60a3 +0x0c45 0x60a8 +0x0c45 0x60aa +0x0c45 0x60ab +0x0c45 0x60ac +0x0c45 0x60ae +0x0c45 0x60af +0x0c45 0x60b0 +0x0c45 0x60b2 +0x0c45 0x60b3 +0x0c45 0x60b8 +0x0c45 0x60ba +0x0c45 0x60bb +0x0c45 0x60bc +0x0c45 0x60be +0x0c45 0x60c0 +0x0c45 0x60c2 +0x0c45 0x60c8 +0x0c45 0x60cc +0x0c45 0x60ea +0x0c45 0x60ec +0x0c45 0x60ef +0x0c45 0x60fa +0x0c45 0x60fb +0x0c45 0x60fc +0x0c45 0x60fe +0x0c45 0x6102 +0x0c45 0x6108 +0x0c45 0x610f +0x0c45 0x6130 +0x0c45 0x6138 +0x0c45 0x613a +0x0c45 0x613b +0x0c45 0x613c +0x0c45 0x613e + +The list above does not imply that all those devices work with this driver: up +until now only the ones that assemble the following pairs of SN9C1xx bridges +and image sensors are supported; kernel messages will always tell you whether +this is the case (see "Module loading" paragraph): + +Image sensor / SN9C1xx bridge | SN9C10[12] SN9C103 SN9C105 SN9C120 +------------------------------------------------------------------------------- +HV7131D Hynix Semiconductor | Yes No No No +HV7131R Hynix Semiconductor | No Yes Yes Yes +MI-0343 Micron Technology | Yes No No No +MI-0360 Micron Technology | No Yes Yes Yes +OV7630 OmniVision Technologies | Yes Yes Yes Yes +OV7660 OmniVision Technologies | No No Yes Yes +PAS106B PixArt Imaging | Yes No No No +PAS202B PixArt Imaging | Yes Yes No No +TAS5110C1B Taiwan Advanced Sensor | Yes No No No +TAS5110D Taiwan Advanced Sensor | Yes No No No +TAS5130D1B Taiwan Advanced Sensor | Yes No No No + +"Yes" means that the pair is supported by the driver, while "No" means that the +pair does not exist or is not supported by the driver. + +Only some of the available control settings of each image sensor are supported +through the V4L2 interface. + +Donations of new models for further testing and support would be much +appreciated. Non-available hardware will not be supported by the author of this +driver. + + +10. Notes for V4L2 application developers +========================================= +This driver follows the V4L2 API specifications. In particular, it enforces two +rules: + +- exactly one I/O method, either "mmap" or "read", is associated with each +file descriptor. Once it is selected, the application must close and reopen the +device to switch to the other I/O method; + +- although it is not mandatory, previously mapped buffer memory should always +be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. +The same number of buffers as before will be allocated again to match the size +of the new video frames, so you have to map the buffers again before any I/O +attempts on them. + +Consistently with the hardware limits, this driver also supports image +downscaling with arbitrary scaling factors from 1, 2 and 4 in both directions. +However, the V4L2 API specifications don't correctly define how the scaling +factor can be chosen arbitrarily by the "negotiation" of the "source" and +"target" rectangles. To work around this flaw, we have added the convention +that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the +scaling factor is restored to 1. + +This driver supports two different video formats: the first one is the "8-bit +Sequential Bayer" format and can be used to obtain uncompressed video data +from the device through the current I/O method, while the second one provides +either "raw" compressed video data (without frame headers not related to the +compressed data) or standard JPEG (with frame headers). The compression quality +may vary from 0 to 1 and can be selected or queried thanks to the +VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum flexibility, +both the default active video format and the default compression quality +depend on how the image sensor being used is initialized. + + +11. Video frame formats [1] +======================= +The SN9C1xx PC Camera Controllers can send images in two possible video +formats over the USB: either native "Sequential RGB Bayer" or compressed. +The compression is used to achieve high frame rates. With regard to the +SN9C101, SN9C102 and SN9C103, the compression is based on the Huffman encoding +algorithm described below, while with regard to the SN9C105 and SN9C120 the +compression is based on the JPEG standard. +The current video format may be selected or queried from the user application +by calling the VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2 +API specifications. + +The name "Sequential Bayer" indicates the organization of the red, green and +blue pixels in one video frame. Each pixel is associated with a 8-bit long +value and is disposed in memory according to the pattern shown below: + +B[0] G[1] B[2] G[3] ... B[m-2] G[m-1] +G[m] R[m+1] G[m+2] R[m+2] ... G[2m-2] R[2m-1] +... +... B[(n-1)(m-2)] G[(n-1)(m-1)] +... G[n(m-2)] R[n(m-1)] + +The above matrix also represents the sequential or progressive read-out mode of +the (n, m) Bayer color filter array used in many CCD or CMOS image sensors. + +The Huffman compressed video frame consists of a bitstream that encodes for +every R, G, or B pixel the difference between the value of the pixel itself and +some reference pixel value. Pixels are organised in the Bayer pattern and the +Bayer sub-pixels are tracked individually and alternatingly. For example, in +the first line values for the B and G1 pixels are alternatingly encoded, while +in the second line values for the G2 and R pixels are alternatingly encoded. + +The pixel reference value is calculated as follows: +- the 4 top left pixels are encoded in raw uncompressed 8-bit format; +- the value in the top two rows is the value of the pixel left of the current + pixel; +- the value in the left column is the value of the pixel above the current + pixel; +- for all other pixels, the reference value is the average of the value of the + pixel on the left and the value of the pixel above the current pixel; +- there is one code in the bitstream that specifies the value of a pixel + directly (in 4-bit resolution); +- pixel values need to be clamped inside the range [0..255] for proper + decoding. + +The algorithm purely describes the conversion from compressed Bayer code used +in the SN9C101, SN9C102 and SN9C103 chips to uncompressed Bayer. Additional +steps are required to convert this to a color image (i.e. a color interpolation +algorithm). + +The following Huffman codes have been found: +0: +0 (relative to reference pixel value) +100: +4 +101: -4? +1110xxxx: set absolute value to xxxx.0000 +1101: +11 +1111: -11 +11001: +20 +110000: -20 +110001: ??? - these codes are apparently not used + +[1] The Huffman compression algorithm has been reverse-engineered and + documented by Bertrik Sikken. + + +12. Contact information +======================= +The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. + +GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is +'FCE635A4'; the public 1024-bit key should be available at any keyserver; +the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. + + +13. Credits +=========== +Many thanks to following persons for their contribute (listed in alphabetical +order): + +- David Anderson for the donation of a webcam; +- Luca Capello for the donation of a webcam; +- Philippe Coval for having helped testing the PAS202BCA image sensor; +- Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the + donation of a webcam; +- Dennis Heitmann for the donation of a webcam; +- Jon Hollstrom for the donation of a webcam; +- Nick McGill for the donation of a webcam; +- Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB + image sensor; +- Stefano Mozzi, who donated 45 EU; +- Andrew Pearce for the donation of a webcam; +- John Pullan for the donation of a webcam; +- Bertrik Sikken, who reverse-engineered and documented the Huffman compression + algorithm used in the SN9C101, SN9C102 and SN9C103 controllers and + implemented the first decoder; +- Ronny Standke for the donation of a webcam; +- Mizuno Takafumi for the donation of a webcam; +- an "anonymous" donator (who didn't want his name to be revealed) for the + donation of a webcam. +- an anonymous donator for the donation of four webcams and two boards with ten + image sensors. diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt new file mode 100644 index 0000000..178ef3c --- /dev/null +++ b/Documentation/video4linux/soc-camera.txt @@ -0,0 +1,120 @@ + 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 provides a unified API between camera host drivers and +camera sensor drivers. It implements a V4L2 interface to the user, currently +only the mmap method is supported. + +This subsystem has been written to connect drivers for System-on-Chip (SoC) +video capture interfaces with drivers for CMOS camera sensor chips to enable +the reuse of sensor drivers with various hosts. 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 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for +PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers: +mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This +list is not supposed to be updated, look for more examples in your tree. + +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: + +static struct soc_camera_host pxa_soc_camera_host = { + .drv_name = PXA_CAM_DRV_NAME, + .ops = &pxa_soc_camera_host_ops, +}; + +All camera host methods are passed in a struct soc_camera_host_ops: + +static struct soc_camera_host_ops pxa_soc_camera_host_ops = { + .owner = THIS_MODULE, + .add = pxa_camera_add_device, + .remove = pxa_camera_remove_device, + .suspend = pxa_camera_suspend, + .resume = pxa_camera_resume, + .set_fmt_cap = pxa_camera_set_fmt_cap, + .try_fmt_cap = pxa_camera_try_fmt_cap, + .init_videobuf = pxa_camera_init_videobuf, + .reqbufs = pxa_camera_reqbufs, + .poll = pxa_camera_poll, + .querycap = pxa_camera_querycap, + .try_bus_param = pxa_camera_try_bus_param, + .set_bus_param = pxa_camera_set_bus_param, +}; + +.add and .remove methods are called when a sensor is attached to or detached +from the host, apart from performing host-internal tasks they shall also call +sensor driver's .init and .release methods respectively. .suspend and .resume +methods implement host's power-management functionality and its their +responsibility to call respective sensor's methods. .try_bus_param and +.set_bus_param are used to negotiate physical connection parameters between the +host and the sensor. .init_videobuf is called by soc-camera core when a +video-device is opened, further video-buffer management is implemented completely +by the specific camera host driver. 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 arbitrarily provide platform .power and .reset methods for the camera. +soc_camera_device_register() and soc_camera_device_unregister() functions are +used to add a sensor driver to or remove one from the system. The registration +function takes a pointer to struct soc_camera_device as the only parameter. +This struct can be initialized as follows: + + /* link to driver operations */ + icd->ops = &mt9m001_ops; + /* link to the underlying physical (e.g., i2c) device */ + icd->control = &client->dev; + /* window geometry */ + icd->x_min = 20; + icd->y_min = 12; + icd->x_current = 20; + icd->y_current = 12; + icd->width_min = 48; + icd->width_max = 1280; + icd->height_min = 32; + icd->height_max = 1024; + icd->y_skip_top = 1; + /* camera bus ID, typically obtained from platform data */ + icd->iface = icl->bus_id; + +struct soc_camera_ops provides .probe and .remove methods, which are called by +the soc-camera core, when a camera is matched against or removed from a camera +host bus, .init, .release, .suspend, and .resume are called from the camera host +driver as discussed above. Other members of this struct provide respective V4L2 +functionality. + +struct soc_camera_device also links to an array of struct soc_camera_data_format, +listing pixel formats, supported by the camera. + +-- +Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt new file mode 100644 index 0000000..4f8946f --- /dev/null +++ b/Documentation/video4linux/stv680.txt @@ -0,0 +1,53 @@ +Linux driver for STV0680 based USB cameras + +Copyright, 2001, Kevin Sisson + + +INTRODUCTION: + +STMicroelectronics produces the STV0680B chip, which comes in two +types, -001 and -003. The -003 version allows the recording and downloading +of sound clips from the camera, and allows a flash attachment. Otherwise, +it uses the same commands as the -001 version. Both versions support a +variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20 +CIF pictures. The STV0680 supports either a serial or a usb interface, and +video is possible through the usb interface. + +The following cameras are known to work with this driver, although any +camera with Vendor/Product codes of 0553/0202 should work: + +Aiptek Pencam (various models) +Nisis QuickPix 2 +Radio Shack 'Kid's digital camera' (#60-1207) +At least one Trust Spycam model +Several other European brand models + +WHAT YOU NEED: + +- USB support +- VIDEO4LINUX support + +More information about USB support for linux can be found at: +http://www.linux-usb.org + + +MODULE OPTIONS: + +When the driver is compiled as a module, you can set a "swapRGB=1" +option, if necessary, for those applications that require it +(such as xawtv). However, the driver should detect and set this +automatically, so this option should not normally be used. + + +KNOWN PROBLEMS: + +The driver seems to work better with the usb-ohci than the usb-uhci host +controller driver. + +HELP: + +The latest info on this driver can be found at: +http://personal.clt.bellsouth.net/~kjsisson or at +http://stv0680-usb.sourceforge.net + +Any questions to me can be send to: kjsisson@bellsouth.net
\ No newline at end of file diff --git a/Documentation/video4linux/v4lgrab.c b/Documentation/video4linux/v4lgrab.c new file mode 100644 index 0000000..079b628 --- /dev/null +++ b/Documentation/video4linux/v4lgrab.c @@ -0,0 +1,192 @@ +/* Simple Video4Linux image grabber. */ +/* + * Video4Linux Driver Test/Example Framegrabbing Program + * + * Compile with: + * gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab + * Use as: + * v4lgrab >image.ppm + * + * Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org> + * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c + * with minor modifications (Dave Forrest, drf5n@virginia.edu). + * + */ + +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <stdio.h> +#include <sys/ioctl.h> +#include <stdlib.h> + +#include <linux/types.h> +#include <linux/videodev.h> + +#define FILE "/dev/video0" + +/* Stole this from tvset.c */ + +#define READ_VIDEO_PIXEL(buf, format, depth, r, g, b) \ +{ \ + switch (format) \ + { \ + case VIDEO_PALETTE_GREY: \ + switch (depth) \ + { \ + case 4: \ + case 6: \ + case 8: \ + (r) = (g) = (b) = (*buf++ << 8);\ + break; \ + \ + case 16: \ + (r) = (g) = (b) = \ + *((unsigned short *) buf); \ + buf += 2; \ + break; \ + } \ + break; \ + \ + \ + case VIDEO_PALETTE_RGB565: \ + { \ + unsigned short tmp = *(unsigned short *)buf; \ + (r) = tmp&0xF800; \ + (g) = (tmp<<5)&0xFC00; \ + (b) = (tmp<<11)&0xF800; \ + buf += 2; \ + } \ + break; \ + \ + case VIDEO_PALETTE_RGB555: \ + (r) = (buf[0]&0xF8)<<8; \ + (g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8; \ + (b) = ((buf[1] << 2 ) & 0xF8)<<8; \ + buf += 2; \ + break; \ + \ + case VIDEO_PALETTE_RGB24: \ + (r) = buf[0] << 8; (g) = buf[1] << 8; \ + (b) = buf[2] << 8; \ + buf += 3; \ + break; \ + \ + default: \ + fprintf(stderr, \ + "Format %d not yet supported\n", \ + format); \ + } \ +} + +int get_brightness_adj(unsigned char *image, long size, int *brightness) { + long i, tot = 0; + for (i=0;i<size*3;i++) + tot += image[i]; + *brightness = (128 - tot/(size*3))/3; + return !((tot/(size*3)) >= 126 && (tot/(size*3)) <= 130); +} + +int main(int argc, char ** argv) +{ + int fd = open(FILE, O_RDONLY), f; + struct video_capability cap; + struct video_window win; + struct video_picture vpic; + + unsigned char *buffer, *src; + int bpp = 24, r, g, b; + unsigned int i, src_depth; + + if (fd < 0) { + perror(FILE); + exit(1); + } + + if (ioctl(fd, VIDIOCGCAP, &cap) < 0) { + perror("VIDIOGCAP"); + fprintf(stderr, "(" FILE " not a video4linux device?)\n"); + close(fd); + exit(1); + } + + if (ioctl(fd, VIDIOCGWIN, &win) < 0) { + perror("VIDIOCGWIN"); + close(fd); + exit(1); + } + + if (ioctl(fd, VIDIOCGPICT, &vpic) < 0) { + perror("VIDIOCGPICT"); + close(fd); + exit(1); + } + + if (cap.type & VID_TYPE_MONOCHROME) { + vpic.depth=8; + vpic.palette=VIDEO_PALETTE_GREY; /* 8bit grey */ + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + vpic.depth=6; + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + vpic.depth=4; + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + fprintf(stderr, "Unable to find a supported capture format.\n"); + close(fd); + exit(1); + } + } + } + } else { + vpic.depth=24; + vpic.palette=VIDEO_PALETTE_RGB24; + + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { + vpic.palette=VIDEO_PALETTE_RGB565; + vpic.depth=16; + + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { + vpic.palette=VIDEO_PALETTE_RGB555; + vpic.depth=15; + + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { + fprintf(stderr, "Unable to find a supported capture format.\n"); + return -1; + } + } + } + } + + buffer = malloc(win.width * win.height * bpp); + if (!buffer) { + fprintf(stderr, "Out of memory.\n"); + exit(1); + } + + do { + int newbright; + read(fd, buffer, win.width * win.height * bpp); + f = get_brightness_adj(buffer, win.width * win.height, &newbright); + if (f) { + vpic.brightness += (newbright << 8); + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { + perror("VIDIOSPICT"); + break; + } + } + } while (f); + + fprintf(stdout, "P6\n%d %d 255\n", win.width, win.height); + + src = buffer; + + for (i = 0; i < win.width * win.height; i++) { + READ_VIDEO_PIXEL(src, vpic.palette, src_depth, r, g, b); + fputc(r>>8, stdout); + fputc(g>>8, stdout); + fputc(b>>8, stdout); + } + + close(fd); + return 0; +} diff --git a/Documentation/video4linux/w9966.txt b/Documentation/video4linux/w9966.txt new file mode 100644 index 0000000..78a6512 --- /dev/null +++ b/Documentation/video4linux/w9966.txt @@ -0,0 +1,33 @@ +W9966 Camera driver, written by Jakob Kemi (jakob.kemi@telia.com) + +After a lot of work in softice & wdasm, reading .pdf-files and tiresome +trial-and-error work I've finally got everything to work. I needed vision for a +robotics project so I borrowed this camera from a friend and started hacking. +Anyway I've converted my original code from the AVR 8bit RISC C/ASM code into +a working Linux driver. + +To get it working simply configure your kernel to support +parport, ieee1284, video4linux and w9966 + +If w9966 is statically linked it will always perform aggressive probing for +the camera. If built as a module you'll have more configuration options. + +Options: + modprobe w9966.o pardev=parport0(or whatever) parmode=0 (0=auto, 1=ecp, 2=epp) +voila! + +you can also type 'modinfo -p w9966.o' for option usage +(or checkout w9966.c) + +The only thing to keep in mind is that the image format is in Y-U-Y-V format +where every two pixels take 4 bytes. In SDL (www.libsdl.org) this format +is called VIDEO_PALETTE_YUV422 (16 bpp). + +A minimal test application (with source) is available from: + http://hem.fyristorg.com/mogul/w9966.html + +The slow framerate is due to missing DMA ECP read support in the +parport drivers. I might add working EPP support later. + +Good luck! + /Jakob Kemi diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt new file mode 100644 index 0000000..05138e8 --- /dev/null +++ b/Documentation/video4linux/w9968cf.txt @@ -0,0 +1,458 @@ + + W996[87]CF JPEG USB Dual Mode Camera Chip + Driver for Linux 2.6 (basic version) + ========================================= + + - Documentation - + + +Index +===== +1. Copyright +2. Disclaimer +3. License +4. Overview +5. Supported devices +6. Module dependencies +7. Module loading +8. Module parameters +9. Contact information +10. Credits + + +1. Copyright +============ +Copyright (C) 2002-2004 by Luca Risolia <luca.risolia@studio.unibo.it> + + +2. Disclaimer +============= +Winbond is a trademark of Winbond Electronics Corporation. +This software is not sponsored or developed by Winbond. + + +3. 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. + + +4. Overview +=========== +This driver supports the video streaming capabilities of the devices mounting +Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681 +based cameras should be supported as well. + +The driver is divided into two modules: the basic one, "w9968cf", is needed for +the supported devices to work; the second one, "w9968cf-vpp", is an optional +module, which provides some useful video post-processing functions like video +decoding, up-scaling and colour conversions. + +Note that the official kernels do neither include nor support the second +module for performance purposes. Therefore, it is always recommended to +download and install the latest and complete release of the driver, +replacing the existing one, if present. + +The latest and full-featured version of the W996[87]CF driver can be found at: +http://www.linux-projects.org. Please refer to the documentation included in +that package, if you are going to use it. + +Up to 32 cameras can be handled at the same time. They can be connected and +disconnected from the host many times without turning off the computer, if +your system supports the hotplug facility. + +To change the default settings for each camera, many parameters can be passed +through command line when the module is loaded into memory. + +The driver relies on the Video4Linux, USB and I2C core modules. It has been +designed to run properly on SMP systems as well. An additional module, +"ovcamchip", is mandatory; it provides support for some OmniVision image +sensors connected to the W996[87]CF chips; if found in the system, the module +will be automatically loaded by default (provided that the kernel has been +compiled with the automatic module loading option). + + +5. Supported devices +==================== +At the moment, known W996[87]CF and OV681 based devices are: +- Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor) +- AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip) +- Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor) +- Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor) +- Lebon LDC-035A (unknown image sensor) +- Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor) +- OmniVision OV8610-EDE (OmniVision OV8610 sensor) +- OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor) +- Pretec Digi Pen-II (OmniVision OV7620 sensor) +- Pretec DigiPen-480 (OmniVision OV8610 sensor) + +If you know any other W996[87]CF or OV681 based cameras, please contact me. + +The list above does not imply that all those devices work with this driver: up +until now only webcams that have an image sensor supported by the "ovcamchip" +module work. Kernel messages will always tell you whether this is case. + +Possible external microcontrollers of those webcams are not supported: this +means that still images cannot be downloaded from the device memory. + +Furthermore, it's worth to note that I was only able to run tests on my +"Creative Labs Video Blaster WebCam Go". Donations of other models, for +additional testing and full support, would be much appreciated. + + +6. Module dependencies +====================== +For it to work properly, the driver needs kernel support for Video4Linux, USB +and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not +actually using any external "ovcamchip" module, given that the W996[87]CF +driver depends on the version of the module present in the official kernels. + +The following options of the kernel configuration file must be enabled and +corresponding modules must be compiled: + + # Multimedia devices + # + CONFIG_VIDEO_DEV=m + + # I2C support + # + CONFIG_I2C=m + +The I2C core module can be compiled statically in the kernel as well. + + # OmniVision Camera Chip support + # + CONFIG_VIDEO_OVCAMCHIP=m + + # USB support + # + CONFIG_USB=m + +In addition, depending on the hardware being used, only one of the modules +below is necessary: + + # USB Host Controller Drivers + # + CONFIG_USB_EHCI_HCD=m + CONFIG_USB_UHCI_HCD=m + CONFIG_USB_OHCI_HCD=m + +And finally: + + # USB Multimedia devices + # + CONFIG_USB_W9968CF=m + + +7. Module loading +================= +To use the driver, it is necessary to load the "w9968cf" module into memory +after every other module required. + +Loading can be done this way, from root: + + [root@localhost home]# modprobe usbcore + [root@localhost home]# modprobe i2c-core + [root@localhost home]# modprobe videodev + [root@localhost home]# modprobe w9968cf + +At this point the pertinent devices should be recognized: "dmesg" can be used +to analyze kernel messages: + + [user@localhost home]$ dmesg + +There are a lot of parameters the module can use to change the default +settings for each device. To list every possible parameter with a brief +explanation about them and which syntax to use, it is recommended to run the +"modinfo" command: + + [root@locahost home]# modinfo w9968cf + + +8. Module parameters +==================== +Module parameters are listed below: +------------------------------------------------------------------------------- +Name: ovmod_load +Type: bool +Syntax: <0|1> +Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled. + If enabled, 'insmod' searches for the required 'ovcamchip' + module in the system, according to its configuration, and + loads that module automatically. This action is performed as + once soon as the 'w9968cf' module is loaded into memory. +Default: 1 +------------------------------------------------------------------------------- +Name: simcams +Type: int +Syntax: <n> +Description: Number of cameras allowed to stream simultaneously. + n may vary from 0 to 32. +Default: 32 +------------------------------------------------------------------------------- +Name: video_nr +Type: int array (min = 0, max = 32) +Syntax: <-1|n[,...]> +Description: Specify V4L minor mode number. + -1 = use next available + n = use minor number n + You can specify up to 32 cameras this way. + For example: + video_nr=-1,2,-1 would assign minor number 2 to the second + recognized camera and use auto for the first one and for every + other camera. +Default: -1 +------------------------------------------------------------------------------- +Name: packet_size +Type: int array (min = 0, max = 32) +Syntax: <n[,...]> +Description: Specify the maximum data payload size in bytes for alternate + settings, for each device. n is scaled between 63 and 1023. +Default: 1023 +------------------------------------------------------------------------------- +Name: max_buffers +Type: int array (min = 0, max = 32) +Syntax: <n[,...]> +Description: For advanced users. + Specify the maximum number of video frame buffers to allocate + for each device, from 2 to 32. +Default: 2 +------------------------------------------------------------------------------- +Name: double_buffer +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Hardware double buffering: 0 disabled, 1 enabled. + It should be enabled if you want smooth video output: if you + obtain out of sync. video, disable it, or try to + decrease the 'clockdiv' module parameter value. +Default: 1 for every device. +------------------------------------------------------------------------------- +Name: clamping +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Video data clamping: 0 disabled, 1 enabled. +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: filter_type +Type: int array (min = 0, max = 32) +Syntax: <0|1|2[,...]> +Description: Video filter type. + 0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter. + The filter is used to reduce noise and aliasing artifacts + produced by the CCD or CMOS image sensor. +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: largeview +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Large view: 0 disabled, 1 enabled. +Default: 1 for every device. +------------------------------------------------------------------------------- +Name: upscaling +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Software scaling (for non-compressed video only): + 0 disabled, 1 enabled. + Disable it if you have a slow CPU or you don't have enough + memory. +Default: 0 for every device. +Note: If 'w9968cf-vpp' is not present, this parameter is set to 0. +------------------------------------------------------------------------------- +Name: decompression +Type: int array (min = 0, max = 32) +Syntax: <0|1|2[,...]> +Description: Software video decompression: + 0 = disables decompression + (doesn't allow formats needing decompression). + 1 = forces decompression + (allows formats needing decompression only). + 2 = allows any permitted formats. + Formats supporting (de)compressed video are YUV422P and + YUV420P/YUV420 in any resolutions where width and height are + multiples of 16. +Default: 2 for every device. +Note: If 'w9968cf-vpp' is not present, forcing decompression is not + allowed; in this case this parameter is set to 2. +------------------------------------------------------------------------------- +Name: force_palette +Type: int array (min = 0, max = 32) +Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]> +Description: Force picture palette. + In order: + 0 = Off - allows any of the following formats: + 9 = UYVY 16 bpp - Original video, compression disabled + 10 = YUV420 12 bpp - Original video, compression enabled + 13 = YUV422P 16 bpp - Original video, compression enabled + 15 = YUV420P 12 bpp - Original video, compression enabled + 8 = YUVY 16 bpp - Software conversion from UYVY + 7 = YUV422 16 bpp - Software conversion from UYVY + 1 = GREY 8 bpp - Software conversion from UYVY + 6 = RGB555 16 bpp - Software conversion from UYVY + 3 = RGB565 16 bpp - Software conversion from UYVY + 4 = RGB24 24 bpp - Software conversion from UYVY + 5 = RGB32 32 bpp - Software conversion from UYVY + When not 0, this parameter will override 'decompression'. +Default: 0 for every device. Initial palette is 9 (UYVY). +Note: If 'w9968cf-vpp' is not present, this parameter is set to 9. +------------------------------------------------------------------------------- +Name: force_rgb +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Read RGB video data instead of BGR: + 1 = use RGB component ordering. + 0 = use BGR component ordering. + This parameter has effect when using RGBX palettes only. +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: autobright +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Image sensor automatically changes brightness: + 0 = no, 1 = yes +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: autoexp +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Image sensor automatically changes exposure: + 0 = no, 1 = yes +Default: 1 for every device. +------------------------------------------------------------------------------- +Name: lightfreq +Type: int array (min = 0, max = 32) +Syntax: <50|60[,...]> +Description: Light frequency in Hz: + 50 for European and Asian lighting, 60 for American lighting. +Default: 50 for every device. +------------------------------------------------------------------------------- +Name: bandingfilter +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Banding filter to reduce effects of fluorescent + lighting: + 0 disabled, 1 enabled. + This filter tries to reduce the pattern of horizontal + light/dark bands caused by some (usually fluorescent) lighting. +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: clockdiv +Type: int array (min = 0, max = 32) +Syntax: <-1|n[,...]> +Description: Force pixel clock divisor to a specific value (for experts): + n may vary from 0 to 127. + -1 for automatic value. + See also the 'double_buffer' module parameter. +Default: -1 for every device. +------------------------------------------------------------------------------- +Name: backlight +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Objects are lit from behind: + 0 = no, 1 = yes +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: mirror +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: Reverse image horizontally: + 0 = no, 1 = yes +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: monochrome +Type: bool array (min = 0, max = 32) +Syntax: <0|1[,...]> +Description: The image sensor is monochrome: + 0 = no, 1 = yes +Default: 0 for every device. +------------------------------------------------------------------------------- +Name: brightness +Type: long array (min = 0, max = 32) +Syntax: <n[,...]> +Description: Set picture brightness (0-65535). + This parameter has no effect if 'autobright' is enabled. +Default: 31000 for every device. +------------------------------------------------------------------------------- +Name: hue +Type: long array (min = 0, max = 32) +Syntax: <n[,...]> +Description: Set picture hue (0-65535). +Default: 32768 for every device. +------------------------------------------------------------------------------- +Name: colour +Type: long array (min = 0, max = 32) +Syntax: <n[,...]> +Description: Set picture saturation (0-65535). +Default: 32768 for every device. +------------------------------------------------------------------------------- +Name: contrast +Type: long array (min = 0, max = 32) +Syntax: <n[,...]> +Description: Set picture contrast (0-65535). +Default: 50000 for every device. +------------------------------------------------------------------------------- +Name: whiteness +Type: long array (min = 0, max = 32) +Syntax: <n[,...]> +Description: Set picture whiteness (0-65535). +Default: 32768 for every device. +------------------------------------------------------------------------------- +Name: debug +Type: int +Syntax: <n> +Description: Debugging information level, from 0 to 6: + 0 = none (use carefully) + 1 = critical errors + 2 = significant informations + 3 = configuration or general messages + 4 = warnings + 5 = called functions + 6 = function internals + Level 5 and 6 are useful for testing only, when only one + device is used. +Default: 2 +------------------------------------------------------------------------------- +Name: specific_debug +Type: bool +Syntax: <0|1> +Description: Enable or disable specific debugging messages: + 0 = print messages concerning every level <= 'debug' level. + 1 = print messages concerning the level indicated by 'debug'. +Default: 0 +------------------------------------------------------------------------------- + + +9. Contact information +====================== +I may be contacted by e-mail at <luca.risolia@studio.unibo.it>. + +I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'. +My public 1024-bit key should be available at your keyserver; the fingerprint +is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. + + +10. Credits +========== +The development would not have proceed much further without having looked at +the source code of other drivers and without the help of several persons; in +particular: + +- the I2C interface to kernel and high-level image sensor control routines have + been taken from the OV511 driver by Mark McClelland; + +- memory management code has been copied from the bttv driver by Ralph Metzler, + Marcus Metzler and Gerd Knorr; + +- the low-level I2C read function has been written by Frederic Jouault; + +- the low-level I2C fast write function has been written by Piotr Czerczak. diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt new file mode 100644 index 0000000..befdfda --- /dev/null +++ b/Documentation/video4linux/zc0301.txt @@ -0,0 +1,270 @@ + + ZC0301 and ZC0301P Image Processor and Control Chip + Driver for Linux + =================================================== + + - Documentation - + + +Index +===== +1. Copyright +2. Disclaimer +3. License +4. Overview and features +5. Module dependencies +6. Module loading +7. Module parameters +8. Supported devices +9. Notes for V4L2 application developers +10. Contact information +11. Credits + + +1. Copyright +============ +Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> + + +2. Disclaimer +============= +This software is not developed or sponsored by Z-Star Microelectronics Corp. +Trademarks are property of their respective owner. + + +3. 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. + + +4. Overview and features +======================== +This driver supports the video interface of the devices mounting the ZC0301 or +ZC0301P Image Processors and Control Chips. + +The driver relies on the Video4Linux2 and USB core modules. It has been +designed to run properly on SMP systems as well. + +The latest version of the ZC0301[P] driver can be found at the following URL: +http://www.linux-projects.org/ + +Some of the features of the driver are: + +- full compliance with the Video4Linux2 API (see also "Notes for V4L2 + application developers" paragraph); +- available mmap or read/poll methods for video streaming through isochronous + data transfers; +- automatic detection of image sensor; +- video format is standard JPEG; +- dynamic driver control thanks to various module parameters (see "Module + parameters" paragraph); +- up to 64 cameras can be handled at the same time; they can be connected and + disconnected from the host many times without turning off the computer, if + the system supports hotplugging; + + +5. Module dependencies +====================== +For it to work properly, the driver needs kernel support for Video4Linux and +USB. + +The following options of the kernel configuration file must be enabled and +corresponding modules must be compiled: + + # Multimedia devices + # + CONFIG_VIDEO_DEV=m + + # USB support + # + CONFIG_USB=m + +In addition, depending on the hardware being used, the modules below are +necessary: + + # USB Host Controller Drivers + # + CONFIG_USB_EHCI_HCD=m + CONFIG_USB_UHCI_HCD=m + CONFIG_USB_OHCI_HCD=m + +The ZC0301 controller also provides a built-in microphone interface. It is +supported by the USB Audio driver thanks to the ALSA API: + + # Sound + # + CONFIG_SOUND=y + + # Advanced Linux Sound Architecture + # + CONFIG_SND=m + + # USB devices + # + CONFIG_SND_USB_AUDIO=m + +And finally: + + # V4L USB devices + # + CONFIG_USB_ZC0301=m + + +6. Module loading +================= +To use the driver, it is necessary to load the "zc0301" module into memory +after every other module required: "videodev", "v4l2_common", "compat_ioctl32", +"usbcore" and, depending on the USB host controller you have, "ehci-hcd", +"uhci-hcd" or "ohci-hcd". + +Loading can be done as shown below: + + [root@localhost home]# modprobe zc0301 + +At this point the devices should be recognized. You can invoke "dmesg" to +analyze kernel messages and verify that the loading process has gone well: + + [user@localhost home]$ dmesg + + +7. Module parameters +==================== +Module parameters are listed below: +------------------------------------------------------------------------------- +Name: video_nr +Type: short array (min = 0, max = 64) +Syntax: <-1|n[,...]> +Description: Specify V4L2 minor mode number: + -1 = use next available + n = use minor number n + You can specify up to 64 cameras this way. + For example: + video_nr=-1,2,-1 would assign minor number 2 to the second + registered camera and use auto for the first one and for every + other camera. +Default: -1 +------------------------------------------------------------------------------- +Name: force_munmap +Type: bool array (min = 0, max = 64) +Syntax: <0|1[,...]> +Description: Force the application to unmap previously mapped buffer memory + before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not + all the applications support this feature. This parameter is + specific for each detected camera. + 0 = do not force memory unmapping + 1 = force memory unmapping (save memory) +Default: 0 +------------------------------------------------------------------------------- +Name: frame_timeout +Type: uint array (min = 0, max = 64) +Syntax: <n[,...]> +Description: Timeout for a video frame in seconds. This parameter is + specific for each detected camera. This parameter can be + changed at runtime thanks to the /sys filesystem interface. +Default: 2 +------------------------------------------------------------------------------- +Name: debug +Type: ushort +Syntax: <n> +Description: Debugging information level, from 0 to 3: + 0 = none (use carefully) + 1 = critical errors + 2 = significant informations + 3 = more verbose messages + Level 3 is useful for testing only, when only one device + is used at the same time. It also shows some more informations + about the hardware being detected. This module parameter can be + changed at runtime thanks to the /sys filesystem interface. +Default: 2 +------------------------------------------------------------------------------- + + +8. Supported devices +==================== +None of the names of the companies as well as their products will be mentioned +here. They have never collaborated with the author, so no advertising. + +From the point of view of a driver, what unambiguously identify a device are +its vendor and product USB identifiers. Below is a list of known identifiers of +devices mounting the ZC0301 Image Processor and Control Chips: + +Vendor ID Product ID +--------- ---------- +0x041e 0x4017 +0x041e 0x401c +0x041e 0x401e +0x041e 0x401f +0x041e 0x4022 +0x041e 0x4034 +0x041e 0x4035 +0x041e 0x4036 +0x041e 0x403a +0x0458 0x7007 +0x0458 0x700c +0x0458 0x700f +0x046d 0x08ae +0x055f 0xd003 +0x055f 0xd004 +0x0ac8 0x0301 +0x0ac8 0x301b +0x0ac8 0x303b +0x10fd 0x0128 +0x10fd 0x8050 +0x10fd 0x804e + +The list above does not imply that all those devices work with this driver: up +until now only the ones that mount the following image sensors are supported; +kernel messages will always tell you whether this is the case: + +Model Manufacturer +----- ------------ +PAS202BCB PixArt Imaging, Inc. +PB-0330 Photobit Corporation + + +9. Notes for V4L2 application developers +======================================== +This driver follows the V4L2 API specifications. In particular, it enforces two +rules: + +- exactly one I/O method, either "mmap" or "read", is associated with each +file descriptor. Once it is selected, the application must close and reopen the +device to switch to the other I/O method; + +- although it is not mandatory, previously mapped buffer memory should always +be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. +The same number of buffers as before will be allocated again to match the size +of the new video frames, so you have to map the buffers again before any I/O +attempts on them. + + +10. Contact information +======================= +The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. + +GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is +'FCE635A4'; the public 1024-bit key should be available at any keyserver; +the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. + + +11. Credits +=========== +- Informations about the chip internals needed to enable the I2C protocol have + been taken from the documentation of the ZC030x Video4Linux1 driver written + by Andrew Birkett <andy@nobugs.org>; +- The initialization values of the ZC0301 controller connected to the PAS202BCB + and PB-0330 image sensors have been taken from the SPCA5XX driver maintained + by Michel Xhaard <mxhaard@magic.fr>; +- Stanislav Lechev donated one camera. diff --git a/Documentation/video4linux/zr364xx.txt b/Documentation/video4linux/zr364xx.txt new file mode 100644 index 0000000..5c81e3a --- /dev/null +++ b/Documentation/video4linux/zr364xx.txt @@ -0,0 +1,67 @@ +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 |
