bkgpl/cyb4_linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Creation of Cybook 2416 (actually Gen4) repository

Browse Source
This commit is contained in:
mlt
2009-12-18 17:10:00 +00:00
committed by godzil
commit 76f20f4d40
13791 changed files with 6812321 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
Documentation/video4linux/API.html Normal file
View File

@@ -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>

145
Documentation/video4linux/CARDLIST.bttv Normal file
View File

@@ -0,0 +1,145 @@
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), VoodooTV 200 (USA) [121a:3000,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

57
Documentation/video4linux/CARDLIST.cx88 Normal file
View File

@@ -0,0 +1,57 @@
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]
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]

11
Documentation/video4linux/CARDLIST.em28xx Normal file
View File

@@ -0,0 +1,11 @@
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
1 -> Unknown EM2820/2840 video grabber (em2820/em2840)
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]
5 -> MSI VOX USB 2.0 (em2820/em2840) [eb1a:2820]
6 -> Terratec Cinergy 200 USB (em2800)
7 -> Leadtek Winfast USB II (em2800)
8 -> Kworld USB2800 (em2800)
9 -> Pinnacle Dazzle DVC 90 (em2820/em2840) [2304:0207]
12 -> Kworld PVR TV 2800 RF (em2820/em2840)

109
Documentation/video4linux/CARDLIST.saa7134 Normal file
View File

@@ -0,0 +1,109 @@
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/Behold TV 403 FM
28 -> Manli MuchTV M-TV001/Behold TV 401
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]
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,1489:0214,5168:0304]
55 -> LifeView FlyDVB-T DUO [5168: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,1043:4876]
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]
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 [17de:7350]
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 [5168:3306,5168:3502]
95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138]
96 -> Medion Md8800 Quadro [16be:0007,16be:0008]
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:6701]
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]

74
Documentation/video4linux/CARDLIST.tuner Normal file
View File

@@ -0,0 +1,74 @@
tuner=0 - Temic PAL (4002 FH5)
tuner=1 - Philips PAL_I (FI1246 and compatibles)
tuner=2 - Philips NTSC (FI1236,FM1236 and compatibles)
tuner=3 - Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF)
tuner=4 - NoTuner
tuner=5 - Philips PAL_BG (FI1216 and compatibles)
tuner=6 - Temic NTSC (4032 FY5)
tuner=7 - Temic PAL_I (4062 FY5)
tuner=8 - Temic NTSC (4036 FY5)
tuner=9 - Alps HSBH1
tuner=10 - Alps TSBE1
tuner=11 - Alps TSBB5
tuner=12 - Alps TSBE5
tuner=13 - Alps TSBC5
tuner=14 - Temic PAL_BG (4006FH5)
tuner=15 - Alps TSCH6
tuner=16 - Temic PAL_DK (4016 FY5)
tuner=17 - Philips NTSC_M (MK2)
tuner=18 - Temic PAL_I (4066 FY5)
tuner=19 - Temic PAL* auto (4006 FN5)
tuner=20 - Temic PAL_BG (4009 FR5) or PAL_I (4069 FR5)
tuner=21 - Temic NTSC (4039 FR5)
tuner=22 - Temic PAL/SECAM multi (4046 FM5)
tuner=23 - Philips PAL_DK (FI1256 and compatibles)
tuner=24 - Philips PAL/SECAM multi (FQ1216ME)
tuner=25 - LG PAL_I+FM (TAPC-I001D)
tuner=26 - LG PAL_I (TAPC-I701D)
tuner=27 - LG NTSC+FM (TPI8NSR01F)
tuner=28 - LG PAL_BG+FM (TPI8PSB01D)
tuner=29 - LG PAL_BG (TPI8PSB11D)
tuner=30 - Temic PAL* auto + FM (4009 FN5)
tuner=31 - SHARP NTSC_JP (2U5JF5540)
tuner=32 - Samsung PAL TCPM9091PD27
tuner=33 - MT20xx universal
tuner=34 - Temic PAL_BG (4106 FH5)
tuner=35 - Temic PAL_DK/SECAM_L (4012 FY5)
tuner=36 - Temic NTSC (4136 FY5)
tuner=37 - LG PAL (newer TAPC series)
tuner=38 - Philips PAL/SECAM multi (FM1216ME MK3)
tuner=39 - LG NTSC (newer TAPC series)
tuner=40 - HITACHI V7-J180AT
tuner=41 - Philips PAL_MK (FI1216 MK)
tuner=42 - Philips 1236D ATSC/NTSC 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 - tda8290+75
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 xc3028
tuner=72 - Thomson FE6600
tuner=73 - Samsung TCPG 6121P30A

215
Documentation/video4linux/CQcam.txt Normal file
View File

@@ -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

191
Documentation/video4linux/README.cpia Normal file
View File

@@ -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/

130
Documentation/video4linux/README.cpia2 Normal file
View File

@@ -0,0 +1,130 @@
$Id: README.cpia2,v 1.1.1.1 2007/06/12 07:27:11 eyryu 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.

69
Documentation/video4linux/README.cx88 Normal file
View File

@@ -0,0 +1,69 @@
cx8800 release notes
====================
This is a v4l2 device driver for the cx2388x chip.
current status
==============
video
- Basically works.
- Some minor image quality glitches.
- For now only capture, overlay support isn't completed yet.
audio
- The chip specs for the on-chip TV sound decoder are next
to useless :-/
- Neverless the builtin TV sound decoder starts working now,
at least for PAL-BG. Other TV norms need other code ...
FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
USING.
- Most tuner chips do provide mono sound, which may or may not
be useable depending on the board design. With the Hauppauge
cards it works, so there is mono sound available as fallback.
- audio data dma (i.e. recording without loopback cable to the
sound card) should be possible, but there is no code yet ...
vbi
- some code present. Doesn't crash any more, but also doesn't
work yet ...
how to add support for new cards
================================
The driver needs some config info for the TV cards. This stuff is in
cx88-cards.c. If the driver doesn't work well you likely need a new
entry for your card in that file. Check the kernel log (using dmesg)
to see whenever the driver knows your card or not. There is a line
like this one:
cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \
34xxx models [card=1,autodetected]
If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to
the driver. What to do then?
(1) Try upgrading to the latest snapshot, maybe it has been added
meanwhile.
(2) You can try to create a new entry yourself, have a look at
cx88-cards.c. If that worked, mail me your changes as unified
diff ("diff -u").
(3) Or you can mail me the config information. I need at least the
following informations to add the card:
* the PCI Subsystem ID ("0070:3400" from the line above,
"lspci -v" output is fine too).
* the tuner type used by the card. You can try to find one by
trial-and-error using the tuner=<n> insmod option. If you
know which one the card has you can also have a look at the
list in CARDLIST.tuner
Have fun,
Gerd
--
Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]

72
Documentation/video4linux/README.ir Normal file
View File

@@ -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>

212
Documentation/video4linux/README.pvrusb2 Normal file
View File

@@ -0,0 +1,212 @@
$Id: README.pvrusb2,v 1.1.1.1 2007/06/12 07:27:11 eyryu Exp $
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<42>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

82
Documentation/video4linux/README.saa7134 Normal file
View File

@@ -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]

580
Documentation/video4linux/Zoran Normal file
View File

@@ -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<41>M, PAL<41>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.

25
Documentation/video4linux/bttv/CONTRIBUTORS Normal file
View File

@@ -0,0 +1,25 @@
Contributors to bttv:
Michael Chu <mmchu@pobox.com>
AverMedia fix and more flexible card recognition
Alan Cox <alan@redhat.com>
Video4Linux interface and 2.1.x kernel adaptation
Chris Kleitsch
Hardware I2C
Gerd Knorr <kraxel@cs.tu-berlin.de>
Radio card (ITT sound processor)
bigfoot <bigfoot@net-way.net>
Ragnar Hojland Espinosa <ragnar@macula.net>
ConferenceTV card
+ many more (please mail me if you are missing in this list and would
like to be mentioned)

964
Documentation/video4linux/bttv/Cards Normal file
View File

@@ -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)

37
Documentation/video4linux/bttv/ICs Normal file
View File

@@ -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?

182
Documentation/video4linux/bttv/Insmod-options Normal file
View File

@@ -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.

28
Documentation/video4linux/bttv/MAKEDEV Normal file
View File

@@ -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

11
Documentation/video4linux/bttv/Modprobe.conf Normal file
View File

@@ -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

14
Documentation/video4linux/bttv/Modules.conf Normal file
View File

@@ -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

62
Documentation/video4linux/bttv/PROBLEMS Normal file
View File

@@ -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

90
Documentation/video4linux/bttv/README Normal file
View File

@@ -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>

33
Documentation/video4linux/bttv/README.WINVIEW Normal file
View File

@@ -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

74
Documentation/video4linux/bttv/README.freeze Normal file
View File

@@ -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).

83
Documentation/video4linux/bttv/README.quirks Normal file
View File

@@ -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.

148
Documentation/video4linux/bttv/Sound-FAQ Normal file
View File

@@ -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>

3
Documentation/video4linux/bttv/Specs Normal file
View File

@@ -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

24
Documentation/video4linux/bttv/THANKS Normal file
View File

@@ -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.

115
Documentation/video4linux/bttv/Tuners Normal file
View File

@@ -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

54
Documentation/video4linux/cafe_ccic Normal file
View File

@@ -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

38
Documentation/video4linux/cpia2_overview.txt Normal file
View File

@@ -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.

116
Documentation/video4linux/cx2341x/README.hm12 Normal file
View File

@@ -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;
}
--------------------------------------------------------------------------

45
Documentation/video4linux/cx2341x/README.vbi Normal file
View File

@@ -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>

69
Documentation/video4linux/cx2341x/fw-calling.txt Normal file
View File

@@ -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.

297
Documentation/video4linux/cx2341x/fw-decoder-api.txt Normal file
View File

@@ -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

815
Documentation/video4linux/cx2341x/fw-decoder-regs.txt Normal file
View File

@@ -0,0 +1,815 @@
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
001 = 16 bit (565)
010 = 15 bit (555)
011 = 12 bit (444)
100 = 32 bit (8888)
101 = 8 bit indexed
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 is a per-pixel 256 step transparency, with 0 being transparent
and 255 being solid. This is only available in 32 bit & 8 bit indexed
colour modes.
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.3 - 2 February 2007 - Ian Armstrong (ian@iarmst.demon.co.uk)

96
Documentation/video4linux/cx2341x/fw-dma.txt Normal file
View File

@@ -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

706
Documentation/video4linux/cx2341x/fw-encoder-api.txt Normal file
View File

@@ -0,0 +1,706 @@
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-1 are the type mask:
// 1=I, 2=P, 4=B
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_UNKNOWN
Enum 219/0xDB
Description
Unknown API, it's used by Hauppauge though.
Param[0]
0 This is the value Hauppauge uses, Unknown what it means.
-------------------------------------------------------------------------------
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 (supposedly only for the cx23416
for raw YUV).
Actually it looks like this should be 0 for saa7114/5 based card and 1
for cx25840 based cards.
4=generate artificial 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
13=set audio volume delay
14=set audio delay
Param[1]
Command value.

139
Documentation/video4linux/cx2341x/fw-memory.txt Normal file
View File

@@ -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

342
Documentation/video4linux/cx2341x/fw-osd-api.txt Normal file
View File

@@ -0,0 +1,342 @@
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, 4=AlphaRGB 8:8:8:8
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_PIXEL_FORMAT
Enum 67/0x43
Description
Assign pixel format
Param[0]
0=8bit index, 4=AlphaRGB 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

49
Documentation/video4linux/cx2341x/fw-upload.txt Normal file
View File

@@ -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.

54
Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt Normal file
View File

@@ -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

315
Documentation/video4linux/et61x251.txt Normal file
View File

@@ -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'.

54
Documentation/video4linux/hauppauge-wintv-cx88-ir.txt Normal file
View File

@@ -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

324
Documentation/video4linux/ibmcam.txt Normal file
View File

@@ -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.

42
Documentation/video4linux/lifeview.txt Normal file
View File

@@ -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 */

130
Documentation/video4linux/meye.txt Normal file
View File

@@ -0,0 +1,130 @@
Vaio Picturebook Motion Eye Camera Driver Readme
------------------------------------------------
Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
Copyright (C) 2001-2002 Alc<6C>ve <www.alcove.com>
Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
This driver enable the use of video4linux compatible applications with the
Motion Eye camera. This driver requires the "Sony Vaio Programmable I/O
Control Device" driver (which can be found in the "Character drivers"
section of the kernel configuration utility) to be compiled and installed
(using its "camera=1" parameter).
It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
Grabbing is supported in packed YUV colorspace only.
MJPEG hardware grabbing is supported via a private API (see below).
Hardware supported:
-------------------
This driver supports the 'second' version of the MotionEye camera :)
The first version was connected directly on the video bus of the Neomagic
video card and is unsupported.
The second one, made by Kawasaki Steel is fully supported by this
driver (PCI vendor/device is 0x136b/0xff01)
The third one, present in recent (more or less last year) Picturebooks
(C1M* models), is not supported. The manufacturer has given the specs
to the developers under a NDA (which allows the 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.

41
Documentation/video4linux/not-in-cx2388x-datasheet.txt Normal file
View File

@@ -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.
=================================================================================

288
Documentation/video4linux/ov511.txt Normal file
View File

@@ -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<6F>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<6F>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.

147
Documentation/video4linux/radiotrack.txt Normal file
View File

@@ -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)
----------------------------------------------------------------------------

54
Documentation/video4linux/se401.txt Normal file
View File

@@ -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

576
Documentation/video4linux/sn9c102.txt Normal file
View File

@@ -0,0 +1,576 @@
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-2006 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, althought 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, when only one device
is used. 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 SN9120 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
--------- ----------
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 0x60c8
0x0c45 0x60cc
0x0c45 0x60ea
0x0c45 0x60ec
0x0c45 0x60fa
0x0c45 0x60fb
0x0c45 0x60fc
0x0c45 0x60fe
0x0c45 0x6130
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 image sensors are
supported; kernel messages will always tell you whether this is the case (see
"Module loading" paragraph):
Model Manufacturer
----- ------------
HV7131D Hynix Semiconductor, Inc.
MI-0343 Micron Technology, Inc.
OV7630 OmniVision Technologies, Inc.
OV7660 OmniVision Technologies, Inc.
PAS106B PixArt Imaging, Inc.
PAS202BCA PixArt Imaging, Inc.
PAS202BCB PixArt Imaging, Inc.
TAS5110C1B Taiwan Advanced Sensor Corporation
TAS5130D1B Taiwan Advanced Sensor Corporation
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
"raw" compressed video data (without frame headers not related to the
compressed data). 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 (as described in the documentation of the API for the image sensors
supplied by this driver).
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 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):
- 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;
- 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.

53
Documentation/video4linux/stv680.txt Normal file
View File

@@ -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

192
Documentation/video4linux/v4lgrab.c Normal file
View File

@@ -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;
}

33
Documentation/video4linux/w9966.txt Normal file
View File

@@ -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

461
Documentation/video4linux/w9968cf.txt Normal file
View File

@@ -0,0 +1,461 @@
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
Note: The kernel must be compiled with the CONFIG_KMOD option
enabled for the 'ovcamchip' module to be loaded and for
this parameter to be present.
-------------------------------------------------------------------------------
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.

270
Documentation/video4linux/zc0301.txt Normal file
View File

@@ -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.