nathan/Chromebook-Device-Nyan-NVIDIA-Tegra-K1-T124-Upstream-Linux-3.10-LTS-Kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit; kernel source import

Browse Source
This commit is contained in:
Nathan
2025-04-06 23:50:55 -05:00
commit 25c6d769f4
45093 changed files with 18199410 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Documentation/video4linux/.gitignore vendored Normal file
View File

@@ -0,0 +1 @@
v4lgrab

32
Documentation/video4linux/4CCs.txt Normal file
View File

@@ -0,0 +1,32 @@
Guidelines for Linux4Linux pixel format 4CCs
============================================
Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are
specified in this document. First of the characters defines the nature of
the pixel format, compression and colour space. The interpretation of the
other three characters depends on the first one.
Existing 4CCs may not obey these guidelines.
Formats
=======
Raw bayer
---------
The following first characters are used by raw bayer formats:
B: raw bayer, uncompressed
b: raw bayer, DPCM compressed
a: A-law compressed
u: u-law compressed
2nd character: pixel order
B: BGGR
G: GBRG
g: GRBG
R: RGGB
3rd character: uncompressed bits-per-pixel 0--9, A--
4th character: compressed bits-per-pixel 0--9, A--

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

@@ -0,0 +1,27 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type" />
<title>V4L API</title>
</head>
<body>
<h1>Video For Linux APIs</h1>
<table border="0">
<tr>
<td>
<a href="http://linuxtv.org/downloads/legacy/video4linux/API/V4L1_API.html">V4L original API</a>
</td>
<td>
Obsoleted by V4L2 API
</td>
</tr>
<tr>
<td>
<a href="http://v4l2spec.bytesex.org/spec-single/v4l2.html">V4L2 API</a>
</td>
<td>Should be used for new projects
</td>
</tr>
</table>
</body>
</html>

6
Documentation/video4linux/CARDLIST.au0828 Normal file
View File

@@ -0,0 +1,6 @@
0 -> Unknown board (au0828)
1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213,2040:7270]
2 -> Hauppauge HVR850 (au0828) [2040:7240]
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281]
5 -> Hauppauge Woodbury (au0828) [05e1:0480,2040:8200]

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

@@ -0,0 +1,162 @@
0 -> *** UNKNOWN/GENERIC ***
1 -> MIRO PCTV
2 -> Hauppauge (bt848)
3 -> STB, Gateway P/N 6000699 (bt848)
4 -> Intel Create and Share PCI/ Smart Video Recorder III
5 -> Diamond DTV2000
6 -> AVerMedia TVPhone
7 -> MATRIX-Vision MV-Delta
8 -> Lifeview FlyVideo II (Bt848) LR26 / MAXI TV Video PCI2 LR26
9 -> IMS/IXmicro TurboTV
10 -> Hauppauge (bt878) [0070:13eb,0070:3900,2636:10b4]
11 -> MIRO PCTV pro
12 -> ADS Technologies Channel Surfer TV (bt848)
13 -> AVerMedia TVCapture 98 [1461:0002,1461:0004,1461:0300]
14 -> Aimslab Video Highway Xtreme (VHX)
15 -> Zoltrix TV-Max [a1a0:a0fc]
16 -> Prolink Pixelview PlayTV (bt878)
17 -> Leadtek WinView 601
18 -> AVEC Intercapture
19 -> Lifeview FlyVideo II EZ /FlyKit LR38 Bt848 (capture only)
20 -> CEI Raffles Card
21 -> Lifeview FlyVideo 98/ Lucky Star Image World ConferenceTV LR50
22 -> Askey CPH050/ Phoebe Tv Master + FM [14ff:3002]
23 -> Modular Technology MM201/MM202/MM205/MM210/MM215 PCTV, bt878 [14c7:0101]
24 -> Askey CPH05X/06X (bt878) [many vendors] [144f:3002,144f:3005,144f:5000,14ff:3000]
25 -> Terratec TerraTV+ Version 1.0 (Bt848)/ Terra TValue Version 1.0/ Vobis TV-Boostar
26 -> Hauppauge WinCam newer (bt878)
27 -> Lifeview FlyVideo 98/ MAXI TV Video PCI2 LR50
28 -> Terratec TerraTV+ Version 1.1 (bt878) [153b:1127,1852:1852]
29 -> Imagenation PXC200 [1295:200a]
30 -> Lifeview FlyVideo 98 LR50 [1f7f:1850]
31 -> Formac iProTV, Formac ProTV I (bt848)
32 -> Intel Create and Share PCI/ Smart Video Recorder III
33 -> Terratec TerraTValue Version Bt878 [153b:1117,153b:1118,153b:1119,153b:111a,153b:1134,153b:5018]
34 -> Leadtek WinFast 2000/ WinFast 2000 XP [107d:6606,107d:6609,6606:217d,f6ff:fff6]
35 -> Lifeview FlyVideo 98 LR50 / Chronos Video Shuttle II [1851:1850,1851:a050]
36 -> Lifeview FlyVideo 98FM LR50 / Typhoon TView TV/FM Tuner [1852:1852]
37 -> Prolink PixelView PlayTV pro
38 -> Askey CPH06X TView99 [144f:3000,144f:a005,a04f:a0fc]
39 -> Pinnacle PCTV Studio/Rave [11bd:0012,bd11:1200,bd11:ff00,11bd:ff12]
40 -> STB TV PCI FM, Gateway P/N 6000704 (bt878), 3Dfx VoodooTV 100 [10b4:2636,10b4:2645,121a:3060]
41 -> AVerMedia TVPhone 98 [1461:0001,1461:0003]
42 -> ProVideo PV951 [aa0c:146c]
43 -> Little OnAir TV
44 -> Sigma TVII-FM
45 -> MATRIX-Vision MV-Delta 2
46 -> Zoltrix Genie TV/FM [15b0:4000,15b0:400a,15b0:400d,15b0:4010,15b0:4016]
47 -> Terratec TV/Radio+ [153b:1123]
48 -> Askey CPH03x/ Dynalink Magic TView
49 -> IODATA GV-BCTV3/PCI [10fc:4020]
50 -> Prolink PV-BT878P+4E / PixelView PlayTV PAK / Lenco MXTV-9578 CP
51 -> Eagle Wireless Capricorn2 (bt878A)
52 -> Pinnacle PCTV Studio Pro
53 -> Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS
54 -> Lifeview FlyVideo 2000 /FlyVideo A2/ Lifetec LT 9415 TV [LR90]
55 -> Askey CPH031/ BESTBUY Easy TV
56 -> Lifeview FlyVideo 98FM LR50 [a051:41a0]
57 -> GrandTec 'Grand Video Capture' (Bt848) [4344:4142]
58 -> Askey CPH060/ Phoebe TV Master Only (No FM)
59 -> Askey CPH03x TV Capturer
60 -> Modular Technology MM100PCTV
61 -> AG Electronics GMV1 [15cb:0101]
62 -> Askey CPH061/ BESTBUY Easy TV (bt878)
63 -> ATI TV-Wonder [1002:0001]
64 -> ATI TV-Wonder VE [1002:0003]
65 -> Lifeview FlyVideo 2000S LR90
66 -> Terratec TValueRadio [153b:1135,153b:ff3b]
67 -> IODATA GV-BCTV4/PCI [10fc:4050]
68 -> 3Dfx VoodooTV FM (Euro) [10b4:2637]
69 -> Active Imaging AIMMS
70 -> Prolink Pixelview PV-BT878P+ (Rev.4C,8E)
71 -> Lifeview FlyVideo 98EZ (capture only) LR51 [1851:1851]
72 -> Prolink Pixelview PV-BT878P+9B (PlayTV Pro rev.9B FM+NICAM) [1554:4011]
73 -> Sensoray 311/611 [6000:0311,6000:0611]
74 -> RemoteVision MX (RV605)
75 -> Powercolor MTV878/ MTV878R/ MTV878F
76 -> Canopus WinDVR PCI (COMPAQ Presario 3524JP, 5112JP) [0e11:0079]
77 -> GrandTec Multi Capture Card (Bt878)
78 -> Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF [0a01:17de]
79 -> DSP Design TCVIDEO
80 -> Hauppauge WinTV PVR [0070:4500]
81 -> IODATA GV-BCTV5/PCI [10fc:4070,10fc:d018]
82 -> Osprey 100/150 (878) [0070:ff00]
83 -> Osprey 100/150 (848)
84 -> Osprey 101 (848)
85 -> Osprey 101/151
86 -> Osprey 101/151 w/ svid
87 -> Osprey 200/201/250/251
88 -> Osprey 200/250 [0070:ff01]
89 -> Osprey 210/220/230
90 -> Osprey 500 [0070:ff02]
91 -> Osprey 540 [0070:ff04]
92 -> Osprey 2000 [0070:ff03]
93 -> IDS Eagle
94 -> Pinnacle PCTV Sat [11bd:001c]
95 -> Formac ProTV II (bt878)
96 -> MachTV
97 -> Euresys Picolo
98 -> ProVideo PV150 [aa00:1460,aa01:1461,aa02:1462,aa03:1463,aa04:1464,aa05:1465,aa06:1466,aa07:1467]
99 -> AD-TVK503
100 -> Hercules Smart TV Stereo
101 -> Pace TV & Radio Card
102 -> IVC-200 [0000:a155,0001:a155,0002:a155,0003:a155,0100:a155,0101:a155,0102:a155,0103:a155,0800:a155,0801:a155,0802:a155,0803:a155]
103 -> Grand X-Guard / Trust 814PCI [0304:0102]
104 -> Nebula Electronics DigiTV [0071:0101]
105 -> ProVideo PV143 [aa00:1430,aa00:1431,aa00:1432,aa00:1433,aa03:1433]
106 -> PHYTEC VD-009-X1 VD-011 MiniDIN (bt878)
107 -> PHYTEC VD-009-X1 VD-011 Combi (bt878)
108 -> PHYTEC VD-009 MiniDIN (bt878)
109 -> PHYTEC VD-009 Combi (bt878)
110 -> IVC-100 [ff00:a132]
111 -> IVC-120G [ff00:a182,ff01:a182,ff02:a182,ff03:a182,ff04:a182,ff05:a182,ff06:a182,ff07:a182,ff08:a182,ff09:a182,ff0a:a182,ff0b:a182,ff0c:a182,ff0d:a182,ff0e:a182,ff0f:a182]
112 -> pcHDTV HD-2000 TV [7063:2000]
113 -> Twinhan DST + clones [11bd:0026,1822:0001,270f:fc00,1822:0026]
114 -> Winfast VC100 [107d:6607]
115 -> Teppro TEV-560/InterVision IV-560
116 -> SIMUS GVC1100 [aa6a:82b2]
117 -> NGS NGSTV+
118 -> LMLBT4
119 -> Tekram M205 PRO
120 -> Conceptronic CONTVFMi
121 -> Euresys Picolo Tetra [1805:0105,1805:0106,1805:0107,1805:0108]
122 -> Spirit TV Tuner
123 -> AVerMedia AVerTV DVB-T 771 [1461:0771]
124 -> AverMedia AverTV DVB-T 761 [1461:0761]
125 -> MATRIX Vision Sigma-SQ
126 -> MATRIX Vision Sigma-SLC
127 -> APAC Viewcomp 878(AMAX)
128 -> DViCO FusionHDTV DVB-T Lite [18ac:db10,18ac:db11]
129 -> V-Gear MyVCD
130 -> Super TV Tuner
131 -> Tibet Systems 'Progress DVR' CS16
132 -> Kodicom 4400R (master)
133 -> Kodicom 4400R (slave)
134 -> Adlink RTV24
135 -> DViCO FusionHDTV 5 Lite [18ac:d500]
136 -> Acorp Y878F [9511:1540]
137 -> Conceptronic CTVFMi v2 [036e:109e]
138 -> Prolink Pixelview PV-BT878P+ (Rev.2E)
139 -> Prolink PixelView PlayTV MPEG2 PV-M4900
140 -> Osprey 440 [0070:ff07]
141 -> Asound Skyeye PCTV
142 -> Sabrent TV-FM (bttv version)
143 -> Hauppauge ImpactVCB (bt878) [0070:13eb]
144 -> MagicTV
145 -> SSAI Security Video Interface [4149:5353]
146 -> SSAI Ultrasound Video Interface [414a:5353]
147 -> VoodooTV 200 (USA) [121a:3000]
148 -> DViCO FusionHDTV 2 [dbc0:d200]
149 -> Typhoon TV-Tuner PCI (50684)
150 -> Geovision GV-600 [008a:763c]
151 -> Kozumi KTV-01C
152 -> Encore ENL TV-FM-2 [1000:1801]
153 -> PHYTEC VD-012 (bt878)
154 -> PHYTEC VD-012-X1 (bt878)
155 -> PHYTEC VD-012-X2 (bt878)
156 -> IVCE-8784 [0000:f050,0001:f050,0002:f050,0003:f050]
157 -> Geovision GV-800(S) (master) [800a:763d]
158 -> Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d]
159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
160 -> Tongwei Video Technology TD-3116 [f200:3116]
161 -> Aposonic W-DVR [0279:0228]

40
Documentation/video4linux/CARDLIST.cx23885 Normal file
View File

@@ -0,0 +1,40 @@
0 -> UNKNOWN/GENERIC [0070:3400]
1 -> Hauppauge WinTV-HVR1800lp [0070:7600]
2 -> Hauppauge WinTV-HVR1800 [0070:7800,0070:7801,0070:7809]
3 -> Hauppauge WinTV-HVR1250 [0070:7911]
4 -> DViCO FusionHDTV5 Express [18ac:d500]
5 -> Hauppauge WinTV-HVR1500Q [0070:7790,0070:7797]
6 -> Hauppauge WinTV-HVR1500 [0070:7710,0070:7717]
7 -> Hauppauge WinTV-HVR1200 [0070:71d1,0070:71d3]
8 -> Hauppauge WinTV-HVR1700 [0070:8101]
9 -> Hauppauge WinTV-HVR1400 [0070:8010]
10 -> DViCO FusionHDTV7 Dual Express [18ac:d618]
11 -> DViCO FusionHDTV DVB-T Dual Express [18ac:db78]
12 -> Leadtek Winfast PxDVR3200 H [107d:6681]
13 -> Compro VideoMate E650F [185b:e800]
14 -> TurboSight TBS 6920 [6920:8888]
15 -> TeVii S470 [d470:9022]
16 -> DVBWorld DVB-S2 2005 [0001:2005]
17 -> NetUP Dual DVB-S2 CI [1b55:2a2c]
18 -> Hauppauge WinTV-HVR1270 [0070:2211]
19 -> Hauppauge WinTV-HVR1275 [0070:2215,0070:221d,0070:22f2]
20 -> Hauppauge WinTV-HVR1255 [0070:2251,0070:22f1]
21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295,0070:2299,0070:229d,0070:22f0,0070:22f3,0070:22f4,0070:22f5]
22 -> Mygica X8506 DMB-TH [14f1:8651]
23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657]
24 -> Hauppauge WinTV-HVR1850 [0070:8541]
25 -> Compro VideoMate E800 [1858:e800]
26 -> Hauppauge WinTV-HVR1290 [0070:8551]
27 -> Mygica X8558 PRO DMB-TH [14f1:8578]
28 -> LEADTEK WinFast PxTV1200 [107d:6f22]
29 -> GoTView X5 3D Hybrid [5654:2390]
30 -> NetUP Dual DVB-T/C-CI RF [1b55:e2e4]
31 -> Leadtek Winfast PxDVR3200 H XC4000 [107d:6f39]
32 -> MPX-885
33 -> Mygica X8507 [14f1:8502]
34 -> TerraTec Cinergy T PCIe Dual [153b:117e]
35 -> TeVii S471 [d471:9022]
36 -> Hauppauge WinTV-HVR1255 [0070:2259]
37 -> Prof Revolution DVB-S2 8000 [8000:3034]
38 -> Hauppauge WinTV-HVR4400 [0070:c108,0070:c138,0070:c12a,0070:c1f8]
39 -> AVerTV Hybrid Express Slim HC81R [1461:d939]

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

@@ -0,0 +1,91 @@
0 -> UNKNOWN/GENERIC
1 -> Hauppauge WinTV 34xxx models [0070:3400,0070:3401]
2 -> GDI Black Gold [14c7:0106,14c7:0107]
3 -> PixelView [1554:4811]
4 -> ATI TV Wonder Pro [1002:00f8,1002:00f9]
5 -> Leadtek Winfast 2000XP Expert [107d:6611,107d:6613]
6 -> AverTV Studio 303 (M126) [1461:000b]
7 -> MSI TV-@nywhere Master [1462:8606]
8 -> Leadtek Winfast DV2000 [107d:6620,107d:6621]
9 -> Leadtek PVR 2000 [107d:663b,107d:663c,107d:6632,107d:6630,107d:6638,107d:6631,107d:6637,107d:663d]
10 -> IODATA GV-VCP3/PCI [10fc:d003]
11 -> Prolink PlayTV PVR
12 -> ASUS PVR-416 [1043:4823,1461:c111]
13 -> MSI TV-@nywhere
14 -> KWorld/VStream XPert DVB-T [17de:08a6]
15 -> DViCO FusionHDTV DVB-T1 [18ac:db00]
16 -> KWorld LTV883RF
17 -> DViCO FusionHDTV 3 Gold-Q [18ac:d810,18ac:d800]
18 -> Hauppauge Nova-T DVB-T [0070:9002,0070:9001,0070:9000]
19 -> Conexant DVB-T reference design [14f1:0187]
20 -> Provideo PV259 [1540:2580]
21 -> DViCO FusionHDTV DVB-T Plus [18ac:db10,18ac:db11]
22 -> pcHDTV HD3000 HDTV [7063:3000]
23 -> digitalnow DNTV Live! DVB-T [17de:a8a6]
24 -> Hauppauge WinTV 28xxx (Roslyn) models [0070:2801]
25 -> Digital-Logic MICROSPACE Entertainment Center (MEC) [14f1:0342]
26 -> IODATA GV/BCTV7E [10fc:d035]
27 -> PixelView PlayTV Ultra Pro (Stereo)
28 -> DViCO FusionHDTV 3 Gold-T [18ac:d820]
29 -> ADS Tech Instant TV DVB-T PCI [1421:0334]
30 -> TerraTec Cinergy 1400 DVB-T [153b:1166]
31 -> DViCO FusionHDTV 5 Gold [18ac:d500]
32 -> AverMedia UltraTV Media Center PCI 550 [1461:8011]
33 -> Kworld V-Stream Xpert DVD
34 -> ATI HDTV Wonder [1002:a101]
35 -> WinFast DTV1000-T [107d:665f]
36 -> AVerTV 303 (M126) [1461:000a]
37 -> Hauppauge Nova-S-Plus DVB-S [0070:9201,0070:9202]
38 -> Hauppauge Nova-SE2 DVB-S [0070:9200]
39 -> KWorld DVB-S 100 [17de:08b2,1421:0341]
40 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid [0070:9400,0070:9402]
41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile) [0070:9800,0070:9802]
42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025,1822:0019]
43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1,12ab:2300]
44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54]
45 -> KWorld HardwareMpegTV XPert [17de:0840,1421:0305]
46 -> DViCO FusionHDTV DVB-T Hybrid [18ac:db40,18ac:db44]
47 -> pcHDTV HD5500 HDTV [7063:5500]
48 -> Kworld MCE 200 Deluxe [17de:0841]
49 -> PixelView PlayTV P7000 [1554:4813]
50 -> NPG Tech Real TV FM Top 10 [14f1:0842]
51 -> WinFast DTV2000 H [107d:665e]
52 -> Geniatech DVB-S [14f1:0084]
53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404,0070:1400,0070:1401,0070:1402]
54 -> Norwood Micro TV Tuner
55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980]
56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602]
57 -> ADS Tech Instant Video PCI [1421:0390]
58 -> Pinnacle PCTV HD 800i [11bd:0051]
59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530]
60 -> Pinnacle Hybrid PCTV [12ab:1788]
61 -> Leadtek TV2000 XP Global [107d:6f18,107d:6618,107d:6619]
62 -> PowerColor RA330 [14f1:ea3d]
63 -> Geniatech X8000-MT DVBT [14f1:8852]
64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30]
65 -> DViCO FusionHDTV 7 Gold [18ac:d610]
66 -> Prolink Pixelview MPEG 8000GT [1554:4935]
67 -> Kworld PlusTV HD PCI 120 (ATSC 120) [17de:08c1]
68 -> Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [0070:6900,0070:6904,0070:6902]
69 -> Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [0070:6905,0070:6906]
70 -> TeVii S460 DVB-S/S2 [d460:9022]
71 -> Omicom SS4 DVB-S/S2 PCI [A044:2011]
72 -> TBS 8920 DVB-S/S2 [8920:8888]
73 -> TeVii S420 DVB-S [d420:9022]
74 -> Prolink Pixelview Global Extreme [1554:4976]
75 -> PROF 7300 DVB-S/S2 [B033:3033]
76 -> SATTRADE ST4200 DVB-S/S2 [b200:4200]
77 -> TBS 8910 DVB-S [8910:8888]
78 -> Prof 6200 DVB-S [b022:3022]
79 -> Terratec Cinergy HT PCI MKII [153b:1177]
80 -> Hauppauge WinTV-IR Only [0070:9290]
81 -> Leadtek WinFast DTV1800 Hybrid [107d:6654]
82 -> WinFast DTV2000 H rev. J [107d:6f2b]
83 -> Prof 7301 DVB-S/S2 [b034:3034]
84 -> Samsung SMT 7020 DVB-S [18ac:dc00,18ac:dccd]
85 -> Twinhan VP-1027 DVB-S [1822:0023]
86 -> TeVii S464 DVB-S/S2 [d464:9022]
87 -> Leadtek WinFast DTV2000 H PLUS [107d:6f42]
88 -> Leadtek WinFast DTV1800 H (XC4000) [107d:6f38]
89 -> Leadtek TV2000 XP Global (SC4100) [107d:6f36]
90 -> Leadtek TV2000 XP Global (XC4100) [107d:6f43]

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

@@ -0,0 +1,88 @@
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2863,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868,eb1a:2875]
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
5 -> MSI VOX USB 2.0 (em2820/em2840)
6 -> Terratec Cinergy 200 USB (em2800)
7 -> Leadtek Winfast USB II (em2800) [0413:6023]
8 -> Kworld USB2800 (em2800)
9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a,093b:a003]
10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
11 -> Terratec Hybrid XS (em2880)
12 -> Kworld PVR TV 2800 RF (em2820/em2840)
13 -> Terratec Prodigy XS (em2880)
14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
15 -> V-Gear PocketTV (em2800)
16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b]
17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227]
18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502]
19 -> EM2860/SAA711X Reference Design (em2860)
20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002]
21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801]
22 -> EM2710/EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751]
23 -> Huaqi DLCW-130 (em2750)
24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112]
25 -> Gadmei UTV310 (em2820/em2840)
26 -> Hercules Smart TV USB 2.0 (em2820/em2840)
27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) (em2820/em2840)
28 -> Leadtek Winfast USB II Deluxe (em2820/em2840)
29 -> EM2860/TVP5150 Reference Design (em2860)
30 -> Videology 20K14XUSB USB2.0 (em2820/em2840)
31 -> Usbgear VD204v9 (em2821)
32 -> Supercomp USB 2.0 TV (em2821)
33 -> Elgato Video Capture (em2860) [0fd9:0033]
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
35 -> Typhoon DVD Maker (em2860)
36 -> NetGMBH Cam (em2860)
37 -> Gadmei UTV330 (em2860) [eb1a:50a6]
38 -> Yakumo MovieMixer (em2861)
39 -> KWorld PVRTV 300U (em2861) [eb1a:e300]
40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005]
41 -> Kworld 350 U DVB-T (em2870) [eb1a:e350]
42 -> Kworld 355 U DVB-T (em2870) [eb1a:e355,eb1a:e357,eb1a:e359]
43 -> Terratec Cinergy T XS (em2870) [0ccd:0043]
44 -> Terratec Cinergy T XS (MT2060) (em2870)
45 -> Pinnacle PCTV DVB-T (em2870)
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
47 -> KWorld DVB-T 305U (em2880) [eb1a:e305]
48 -> KWorld DVB-T 310U (em2880)
49 -> MSI DigiVox A/D (em2880) [eb1a:e310]
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
52 -> DNT DA2 Hybrid (em2881)
53 -> Pinnacle Hybrid Pro (em2881)
54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323]
55 -> Terratec Cinnergy Hybrid T USB XS (em2882) (em2882) [0ccd:005e,0ccd:0042]
56 -> Pinnacle Hybrid Pro (330e) (em2882) [2304:0226]
57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316]
58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041]
60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f]
61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840)
62 -> Gadmei TVR200 (em2820/em2840)
63 -> Kaiomy TVnPC U2 (em2860) [eb1a:e303]
64 -> Easy Cap Capture DC-60 (em2860) [1b80:e309]
65 -> IO-DATA GV-MVP/SZ (em2820/em2840) [04bb:0515]
66 -> Empire dual TV (em2880)
67 -> Terratec Grabby (em2860) [0ccd:0096,0ccd:10AF]
68 -> Terratec AV350 (em2860) [0ccd:0084]
69 -> KWorld ATSC 315U HDTV TV Box (em2882) [eb1a:a313]
70 -> Evga inDtube (em2882)
71 -> Silvercrest Webcam 1.3mpix (em2820/em2840)
72 -> Gadmei UTV330+ (em2861)
73 -> Reddo DVB-C USB TV Box (em2870)
74 -> Actionmaster/LinXcel/Digitus VC211A (em2800)
75 -> Dikom DK300 (em2882)
76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340]
77 -> EM2874 Leadership ISDBT (em2874)
78 -> PCTV nanoStick T2 290e (em28174)
79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad,0ccd:10b6]
80 -> PCTV DVB-S2 Stick (460e) (em28174)
81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605]
82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2]
83 -> Honestech Vidbox NW03 (em2860) [eb1a:5006]
84 -> MaxMedia UB425-TC (em2874) [1b80:e425]
85 -> PCTV QuatroStick (510e) (em2884) [2304:0242]
86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251]
87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac]
88 -> C3 Tech Digital Duo HDTV/SDTV USB (em2884) [1b80:e755]

24
Documentation/video4linux/CARDLIST.ivtv Normal file
View File

@@ -0,0 +1,24 @@
1 -> Hauppauge WinTV PVR-250
2 -> Hauppauge WinTV PVR-350
3 -> Hauppauge WinTV PVR-150 or PVR-500
4 -> AVerMedia M179 [1461:a3ce,1461:a3cf]
5 -> Yuan MPG600/Kuroutoshikou iTVC16-STVLP [12ab:fff3,12ab:ffff]
6 -> Yuan MPG160/Kuroutoshikou iTVC15-STVLP [12ab:0000,10fc:40a0]
7 -> Yuan PG600/DiamondMM PVR-550 [ff92:0070,ffab:0600]
8 -> Adaptec AVC-2410 [9005:0093]
9 -> Adaptec AVC-2010 [9005:0092]
10 -> NAGASE TRANSGEAR 5000TV [1461:bfff]
11 -> AOpen VA2000MAX-STN6 [0000:ff5f]
12 -> YUAN MPG600GR/Kuroutoshikou CX23416GYC-STVLP [12ab:0600,fbab:0600,1154:0523]
13 -> I/O Data GV-MVP/RX [10fc:d01e,10fc:d038,10fc:d039]
14 -> I/O Data GV-MVP/RX2E [10fc:d025]
15 -> GOTVIEW PCI DVD (partial support only) [12ab:0600]
16 -> GOTVIEW PCI DVD2 Deluxe [ffac:0600]
17 -> Yuan MPC622 [ff01:d998]
18 -> Digital Cowboy DCT-MTVP1 [1461:bfff]
19 -> Yuan PG600V2/GotView PCI DVD Lite [ffab:0600,ffad:0600]
20 -> Club3D ZAP-TV1x01 [ffab:0600]
21 -> AverTV MCE 116 Plus [1461:c439]
22 -> ASUS Falcon2 [1043:4b66,1043:462e,1043:4b2e]
23 -> AverMedia PVR-150 Plus [1461:c035]
24 -> AverMedia EZMaker PCI Deluxe [1461:c03f]

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

@@ -0,0 +1,192 @@
0 -> UNKNOWN/GENERIC
1 -> Proteus Pro [philips reference design] [1131:2001,1131:2001]
2 -> LifeView FlyVIDEO3000 [5168:0138,4e42:0138]
3 -> LifeView/Typhoon FlyVIDEO2000 [5168:0138,4e42:0138]
4 -> EMPRESS [1131:6752]
5 -> SKNet Monster TV [1131:4e85]
6 -> Tevion MD 9717
7 -> KNC One TV-Station RDS / Typhoon TV Tuner RDS [1131:fe01,1894:fe01]
8 -> Terratec Cinergy 400 TV [153b:1142]
9 -> Medion 5044
10 -> Kworld/KuroutoShikou SAA7130-TVPCI
11 -> Terratec Cinergy 600 TV [153b:1143]
12 -> Medion 7134 [16be:0003,16be:5000]
13 -> Typhoon TV+Radio 90031
14 -> ELSA EX-VISION 300TV [1048:226b]
15 -> ELSA EX-VISION 500TV [1048:226a]
16 -> ASUS TV-FM 7134 [1043:4842,1043:4830,1043:4840]
17 -> AOPEN VA1000 POWER [1131:7133]
18 -> BMK MPEX No Tuner
19 -> Compro VideoMate TV [185b:c100]
20 -> Matrox CronosPlus [102B:48d0]
21 -> 10MOONS PCI TV CAPTURE CARD [1131:2001]
22 -> AverMedia M156 / Medion 2819 [1461:a70b]
23 -> BMK MPEX Tuner
24 -> KNC One TV-Station DVR [1894:a006]
25 -> ASUS TV-FM 7133 [1043:4843]
26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b]
27 -> Manli MuchTV M-TV002
28 -> Manli MuchTV M-TV001
29 -> Nagase Sangyo TransGear 3000TV [1461:050c]
30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4]
31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5]
32 -> AVACS SmartTV
33 -> AVerMedia DVD EZMaker [1461:10ff]
34 -> Noval Prime TV 7133
35 -> AverMedia AverTV Studio 305 [1461:2115]
36 -> UPMOST PURPLE TV [12ab:0800]
37 -> Items MuchTV Plus / IT-005
38 -> Terratec Cinergy 200 TV [153b:1152]
39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212,5169:1502]
40 -> Compro VideoMate TV PVR/FM [185b:c100]
41 -> Compro VideoMate TV Gold+ [185b:c100]
42 -> Sabrent SBT-TVFM (saa7130)
43 -> :Zolid Xpert TV7134
44 -> Empire PCI TV-Radio LE
45 -> Avermedia AVerTV Studio 307 [1461:9715]
46 -> AVerMedia Cardbus TV/Radio (E500) [1461:d6ee]
47 -> Terratec Cinergy 400 mobile [153b:1162]
48 -> Terratec Cinergy 600 TV MK3 [153b:1158]
49 -> Compro VideoMate Gold+ Pal [185b:c200]
50 -> Pinnacle PCTV 300i DVB-T + PAL [11bd:002d]
51 -> ProVideo PV952 [1540:9524]
52 -> AverMedia AverTV/305 [1461:2108]
53 -> ASUS TV-FM 7135 [1043:4845]
54 -> LifeView FlyTV Platinum FM / Gold [5168:0214,5168:5214,1489:0214,5168:0304]
55 -> LifeView FlyDVB-T DUO / MSI TV@nywhere Duo [5168:0306,4E42:0306]
56 -> Avermedia AVerTV 307 [1461:a70a]
57 -> Avermedia AVerTV GO 007 FM [1461:f31f]
58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370]
59 -> Kworld/Tevion V-Stream Xpert TV PVR7134
60 -> LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [5168:0502,4e42:0502,1489:0502]
61 -> Philips TOUGH DVB-T reference design [1131:2004]
62 -> Compro VideoMate TV Gold+II
63 -> Kworld Xpert TV PVR7134
64 -> FlyTV mini Asus Digimatrix [1043:0210]
65 -> V-Stream Studio TV Terminator
66 -> Yuan TUN-900 (saa7135)
67 -> Beholder BeholdTV 409 FM [0000:4091]
68 -> GoTView 7135 PCI [5456:7135]
69 -> Philips EUROPA V3 reference design [1131:2004]
70 -> Compro Videomate DVB-T300 [185b:c900]
71 -> Compro Videomate DVB-T200 [185b:c901]
72 -> RTD Embedded Technologies VFG7350 [1435:7350]
73 -> RTD Embedded Technologies VFG7330 [1435:7330]
74 -> LifeView FlyTV Platinum Mini2 [14c0:1212]
75 -> AVerMedia AVerTVHD MCE A180 [1461:1044]
76 -> SKNet MonsterTV Mobile [1131:4ee9]
77 -> Pinnacle PCTV 40i/50i/110i (saa7133) [11bd:002e]
78 -> ASUSTeK P7131 Dual [1043:4862]
79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B)
80 -> ASUS Digimatrix TV [1043:0210]
81 -> Philips Tiger reference design [1131:2018]
82 -> MSI TV@Anywhere plus [1462:6231,1462:8624]
83 -> Terratec Cinergy 250 PCI TV [153b:1160]
84 -> LifeView FlyDVB Trio [5168:0319]
85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05]
86 -> LifeView FlyDVB-T / Genius VideoWonder DVB-T [5168:0301,1489:0301]
87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421]
88 -> Tevion/KWorld DVB-T 220RF [17de:7201]
89 -> ELSA EX-VISION 700TV [1048:226c]
90 -> Kworld ATSC110/115 [17de:7350,17de:7352]
91 -> AVerMedia A169 B [1461:7360]
92 -> AVerMedia A169 B1 [1461:6360]
93 -> Medion 7134 Bridge #2 [16be:0005]
94 -> LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [5168:3306,5168:3502,5168:3307,4e42:3502]
95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138]
96 -> Medion Md8800 Quadro [16be:0007,16be:0008,16be:000d]
97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300]
98 -> Proteus Pro 2309 [0919:2003]
99 -> AVerMedia TV Hybrid A16AR [1461:2c00]
100 -> Asus Europa2 OEM [1043:4860]
101 -> Pinnacle PCTV 310i [11bd:002f]
102 -> Avermedia AVerTV Studio 507 [1461:9715]
103 -> Compro Videomate DVB-T200A
104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6700,0070:6701,0070:6702,0070:6703,0070:6704,0070:6705]
105 -> Terratec Cinergy HT PCMCIA [153b:1172]
106 -> Encore ENLTV [1131:2342,1131:2341,3016:2344]
107 -> Encore ENLTV-FM [1131:230f]
108 -> Terratec Cinergy HT PCI [153b:1175]
109 -> Philips Tiger - S Reference design
110 -> Avermedia M102 [1461:f31e]
111 -> ASUS P7131 4871 [1043:4871]
112 -> ASUSTeK P7131 Hybrid [1043:4876]
113 -> Elitegroup ECS TVP3XP FM1246 Tuner Card (PAL,FM) [1019:4cb6]
114 -> KWorld DVB-T 210 [17de:7250]
115 -> Sabrent PCMCIA TV-PCB05 [0919:2003]
116 -> 10MOONS TM300 TV Card [1131:2304]
117 -> Avermedia Super 007 [1461:f01d]
118 -> Beholder BeholdTV 401 [0000:4016]
119 -> Beholder BeholdTV 403 [0000:4036]
120 -> Beholder BeholdTV 403 FM [0000:4037]
121 -> Beholder BeholdTV 405 [0000:4050]
122 -> Beholder BeholdTV 405 FM [0000:4051]
123 -> Beholder BeholdTV 407 [0000:4070]
124 -> Beholder BeholdTV 407 FM [0000:4071]
125 -> Beholder BeholdTV 409 [0000:4090]
126 -> Beholder BeholdTV 505 FM [5ace:5050]
127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090]
128 -> Beholder BeholdTV Columbus TV/FM [0000:5201]
129 -> Beholder BeholdTV 607 FM [5ace:6070]
130 -> Beholder BeholdTV M6 [5ace:6190]
131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
132 -> Genius TVGO AM11MCE
133 -> NXP Snake DVB-S reference design
134 -> Medion/Creatix CTX953 Hybrid [16be:0010]
135 -> MSI TV@nywhere A/D v1.1 [1462:8625]
136 -> AVerMedia Cardbus TV/Radio (E506R) [1461:f436]
137 -> AVerMedia Hybrid TV/Radio (A16D) [1461:f936]
138 -> Avermedia M115 [1461:a836]
139 -> Compro VideoMate T750 [185b:c900]
140 -> Avermedia DVB-S Pro A700 [1461:a7a1]
141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2]
142 -> Beholder BeholdTV H6 [5ace:6290]
143 -> Beholder BeholdTV M63 [5ace:6191]
144 -> Beholder BeholdTV M6 Extra [5ace:6193]
145 -> AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636,1461:f736]
146 -> ASUSTeK P7131 Analog
147 -> Asus Tiger 3in1 [1043:4878]
148 -> Encore ENLTV-FM v5.3 [1a7f:2008]
149 -> Avermedia PCI pure analog (M135A) [1461:f11d]
150 -> Zogis Real Angel 220
151 -> ADS Tech Instant HDTV [1421:0380]
152 -> Asus Tiger Rev:1.00 [1043:4857]
153 -> Kworld Plus TV Analog Lite PCI [17de:7128]
154 -> Avermedia AVerTV GO 007 FM Plus [1461:f31d]
155 -> Hauppauge WinTV-HVR1150 ATSC/QAM-Hybrid [0070:6706,0070:6708]
156 -> Hauppauge WinTV-HVR1120 DVB-T/Hybrid [0070:6707,0070:6709,0070:670a]
157 -> Avermedia AVerTV Studio 507UA [1461:a11b]
158 -> AVerMedia Cardbus TV/Radio (E501R) [1461:b7e9]
159 -> Beholder BeholdTV 505 RDS [0000:505B]
160 -> Beholder BeholdTV 507 RDS [0000:5071]
161 -> Beholder BeholdTV 507 RDS [0000:507B]
162 -> Beholder BeholdTV 607 FM [5ace:6071]
163 -> Beholder BeholdTV 609 FM [5ace:6090]
164 -> Beholder BeholdTV 609 FM [5ace:6091]
165 -> Beholder BeholdTV 607 RDS [5ace:6072]
166 -> Beholder BeholdTV 607 RDS [5ace:6073]
167 -> Beholder BeholdTV 609 RDS [5ace:6092]
168 -> Beholder BeholdTV 609 RDS [5ace:6093]
169 -> Compro VideoMate S350/S300 [185b:c900]
170 -> AverMedia AverTV Studio 505 [1461:a115]
171 -> Beholder BeholdTV X7 [5ace:7595]
172 -> RoverMedia TV Link Pro FM [19d1:0138]
173 -> Zolid Hybrid TV Tuner PCI [1131:2004]
174 -> Asus Europa Hybrid OEM [1043:4847]
175 -> Leadtek Winfast DTV1000S [107d:6655]
176 -> Beholder BeholdTV 505 RDS [0000:5051]
177 -> Hawell HW-404M7
178 -> Beholder BeholdTV H7 [5ace:7190]
179 -> Beholder BeholdTV A7 [5ace:7090]
180 -> Avermedia PCI M733A [1461:4155,1461:4255]
181 -> TechoTrend TT-budget T-3000 [13c2:2804]
182 -> Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid [17de:b136]
183 -> Compro VideoMate Vista M1F [185b:c900]
184 -> Encore ENLTV-FM 3 [1a7f:2108]
185 -> MagicPro ProHDTV Pro2 DMB-TH/Hybrid [17de:d136]
186 -> Beholder BeholdTV 501 [5ace:5010]
187 -> Beholder BeholdTV 503 FM [5ace:5030]
188 -> Sensoray 811/911 [6000:0811,6000:0911]
189 -> Kworld PC150-U [17de:a134]
190 -> Asus My Cinema PS3-100 [1043:48cd]
191 -> Hawell HW-9004V1

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

@@ -0,0 +1,11 @@
0 -> Unknown
1 -> Generic Rev2
2 -> Generic Rev3
3 -> Hauppauge WinTV-HVR2250 [0070:8880,0070:8810]
4 -> Hauppauge WinTV-HVR2200 [0070:8980]
5 -> Hauppauge WinTV-HVR2200 [0070:8900]
6 -> Hauppauge WinTV-HVR2200 [0070:8901]
7 -> Hauppauge WinTV-HVR2250 [0070:8891,0070:8851]
8 -> Hauppauge WinTV-HVR2250 [0070:88A1]
9 -> Hauppauge WinTV-HVR2200 [0070:8940]
10 -> Hauppauge WinTV-HVR2200 [0070:8953]

16
Documentation/video4linux/CARDLIST.tm6000 Normal file
View File

@@ -0,0 +1,16 @@
1 -> Generic tm5600 board (tm5600) [6000:0001]
2 -> Generic tm6000 board (tm6000) [6000:0001]
3 -> Generic tm6010 board (tm6010) [6000:0002]
4 -> 10Moons UT821 (tm5600) [6000:0001]
5 -> 10Moons UT330 (tm5600)
6 -> ADSTech Dual TV (tm6000) [06e1:f332]
7 -> FreeCom and similar (tm6000) [14aa:0620]
8 -> ADSTech Mini Dual TV (tm6000) [06e1:b339]
9 -> Hauppauge WinTV HVR-900H/USB2 Stick (tm6010) [2040:6600,2040:6601,2040:6610,2040:6611]
10 -> Beholder Wander (tm6010) [6000:dec0]
11 -> Beholder Voyager (tm6010) [6000:dec1]
12 -> TerraTec Cinergy Hybrid XE/Cinergy Hybrid Stick (tm6010) [0ccd:0086,0ccd:00a5]
13 -> TwinHan TU501 (tm6010) [13d3:3240,13d3:3241,13d3:3243,13d3:3264]
14 -> Beholder Wander Lite (tm6010) [6000:dec2]
15 -> Beholder Voyager Lite (tm6010) [6000:dec3]

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

@@ -0,0 +1,91 @@
tuner=0 - Temic PAL (4002 FH5)
tuner=1 - Philips PAL_I (FI1246 and compatibles)
tuner=2 - Philips NTSC (FI1236,FM1236 and compatibles)
tuner=3 - Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF)
tuner=4 - NoTuner
tuner=5 - Philips PAL_BG (FI1216 and compatibles)
tuner=6 - Temic NTSC (4032 FY5)
tuner=7 - Temic PAL_I (4062 FY5)
tuner=8 - Temic NTSC (4036 FY5)
tuner=9 - Alps HSBH1
tuner=10 - Alps TSBE1
tuner=11 - Alps TSBB5
tuner=12 - Alps TSBE5
tuner=13 - Alps TSBC5
tuner=14 - Temic PAL_BG (4006FH5)
tuner=15 - Alps TSCH6
tuner=16 - Temic PAL_DK (4016 FY5)
tuner=17 - Philips NTSC_M (MK2)
tuner=18 - Temic PAL_I (4066 FY5)
tuner=19 - Temic PAL* auto (4006 FN5)
tuner=20 - Temic PAL_BG (4009 FR5) or PAL_I (4069 FR5)
tuner=21 - Temic NTSC (4039 FR5)
tuner=22 - Temic PAL/SECAM multi (4046 FM5)
tuner=23 - Philips PAL_DK (FI1256 and compatibles)
tuner=24 - Philips PAL/SECAM multi (FQ1216ME)
tuner=25 - LG PAL_I+FM (TAPC-I001D)
tuner=26 - LG PAL_I (TAPC-I701D)
tuner=27 - LG NTSC+FM (TPI8NSR01F)
tuner=28 - LG PAL_BG+FM (TPI8PSB01D)
tuner=29 - LG PAL_BG (TPI8PSB11D)
tuner=30 - Temic PAL* auto + FM (4009 FN5)
tuner=31 - SHARP NTSC_JP (2U5JF5540)
tuner=32 - Samsung PAL TCPM9091PD27
tuner=33 - MT20xx universal
tuner=34 - Temic PAL_BG (4106 FH5)
tuner=35 - Temic PAL_DK/SECAM_L (4012 FY5)
tuner=36 - Temic NTSC (4136 FY5)
tuner=37 - LG PAL (newer TAPC series)
tuner=38 - Philips PAL/SECAM multi (FM1216ME MK3)
tuner=39 - LG NTSC (newer TAPC series)
tuner=40 - HITACHI V7-J180AT
tuner=41 - Philips PAL_MK (FI1216 MK)
tuner=42 - Philips FCV1236D ATSC/NTSC dual in
tuner=43 - Philips NTSC MK3 (FM1236MK3 or FM1236/F)
tuner=44 - Philips 4 in 1 (ATI TV Wonder Pro/Conexant)
tuner=45 - Microtune 4049 FM5
tuner=46 - Panasonic VP27s/ENGE4324D
tuner=47 - LG NTSC (TAPE series)
tuner=48 - Tenna TNF 8831 BGFF)
tuner=49 - Microtune 4042 FI5 ATSC/NTSC dual in
tuner=50 - TCL 2002N
tuner=51 - Philips PAL/SECAM_D (FM 1256 I-H3)
tuner=52 - Thomson DTT 7610 (ATSC/NTSC)
tuner=53 - Philips FQ1286
tuner=54 - Philips/NXP TDA 8290/8295 + 8275/8275A/18271
tuner=55 - TCL 2002MB
tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4)
tuner=57 - Philips FQ1236A MK4
tuner=58 - Ymec TVision TVF-8531MF/8831MF/8731MF
tuner=59 - Ymec TVision TVF-5533MF
tuner=60 - Thomson DTT 761X (ATSC/NTSC)
tuner=61 - Tena TNF9533-D/IF/TNF9533-B/DF
tuner=62 - Philips TEA5767HN FM Radio
tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner
tuner=64 - LG TDVS-H06xF
tuner=65 - Ymec TVF66T5-B/DFF
tuner=66 - LG TALN series
tuner=67 - Philips TD1316 Hybrid Tuner
tuner=68 - Philips TUV1236D ATSC/NTSC dual in
tuner=69 - Tena TNF 5335 and similar models
tuner=70 - Samsung TCPN 2121P30A
tuner=71 - Xceive xc2028/xc3028 tuner
tuner=72 - Thomson FE6600
tuner=73 - Samsung TCPG 6121P30A
tuner=75 - Philips TEA5761 FM Radio
tuner=76 - Xceive 5000 tuner
tuner=77 - TCL tuner MF02GIP-5N-E
tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner
tuner=79 - Philips PAL/SECAM multi (FM1216 MK5)
tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough
tuner=81 - Partsnic (Daewoo) PTI-5NF05
tuner=82 - Philips CU1216L
tuner=83 - NXP TDA18271
tuner=84 - Sony BTF-Pxn01Z
tuner=85 - Philips FQ1236 MK5
tuner=86 - Tena TNF5337 MFD
tuner=87 - Xceive 4000 tuner
tuner=88 - Xceive 5000C tuner
tuner=89 - Sony PAL+SECAM (BTF-PG472Z)
tuner=90 - Sony NTSC-M-JP (BTF-PK467Z)
tuner=91 - Sony NTSC-M (BTF-PB463Z)

67
Documentation/video4linux/CARDLIST.usbvision Normal file
View File

@@ -0,0 +1,67 @@
0 -> Xanboo [0a6f:0400]
1 -> Belkin USB VideoBus II Adapter [050d:0106]
2 -> Belkin Components USB VideoBus [050d:0207]
3 -> Belkin USB VideoBus II [050d:0208]
4 -> echoFX InterView Lite [0571:0002]
5 -> USBGear USBG-V1 resp. HAMA USB [0573:0003]
6 -> D-Link V100 [0573:0400]
7 -> X10 USB Camera [0573:2000]
8 -> Hauppauge WinTV USB Live (PAL B/G) [0573:2d00]
9 -> Hauppauge WinTV USB Live Pro (NTSC M/N) [0573:2d01]
10 -> Zoran Co. PMD (Nogatech) AV-grabber Manhattan [0573:2101]
11 -> Nogatech USB-TV (NTSC) FM [0573:4100]
12 -> PNY USB-TV (NTSC) FM [0573:4110]
13 -> PixelView PlayTv-USB PRO (PAL) FM [0573:4450]
14 -> ZTV ZT-721 2.4GHz USB A/V Receiver [0573:4550]
15 -> Hauppauge WinTV USB (NTSC M/N) [0573:4d00]
16 -> Hauppauge WinTV USB (PAL B/G) [0573:4d01]
17 -> Hauppauge WinTV USB (PAL I) [0573:4d02]
18 -> Hauppauge WinTV USB (PAL/SECAM L) [0573:4d03]
19 -> Hauppauge WinTV USB (PAL D/K) [0573:4d04]
20 -> Hauppauge WinTV USB (NTSC FM) [0573:4d10]
21 -> Hauppauge WinTV USB (PAL B/G FM) [0573:4d11]
22 -> Hauppauge WinTV USB (PAL I FM) [0573:4d12]
23 -> Hauppauge WinTV USB (PAL D/K FM) [0573:4d14]
24 -> Hauppauge WinTV USB Pro (NTSC M/N) [0573:4d2a]
25 -> Hauppauge WinTV USB Pro (NTSC M/N) V2 [0573:4d2b]
26 -> Hauppauge WinTV USB Pro (PAL/SECAM B/G/I/D/K/L) [0573:4d2c]
27 -> Hauppauge WinTV USB Pro (NTSC M/N) V3 [0573:4d20]
28 -> Hauppauge WinTV USB Pro (PAL B/G) [0573:4d21]
29 -> Hauppauge WinTV USB Pro (PAL I) [0573:4d22]
30 -> Hauppauge WinTV USB Pro (PAL/SECAM L) [0573:4d23]
31 -> Hauppauge WinTV USB Pro (PAL D/K) [0573:4d24]
32 -> Hauppauge WinTV USB Pro (PAL/SECAM BGDK/I/L) [0573:4d25]
33 -> Hauppauge WinTV USB Pro (PAL/SECAM BGDK/I/L) V2 [0573:4d26]
34 -> Hauppauge WinTV USB Pro (PAL B/G) V2 [0573:4d27]
35 -> Hauppauge WinTV USB Pro (PAL B/G,D/K) [0573:4d28]
36 -> Hauppauge WinTV USB Pro (PAL I,D/K) [0573:4d29]
37 -> Hauppauge WinTV USB Pro (NTSC M/N FM) [0573:4d30]
38 -> Hauppauge WinTV USB Pro (PAL B/G FM) [0573:4d31]
39 -> Hauppauge WinTV USB Pro (PAL I FM) [0573:4d32]
40 -> Hauppauge WinTV USB Pro (PAL D/K FM) [0573:4d34]
41 -> Hauppauge WinTV USB Pro (Temic PAL/SECAM B/G/I/D/K/L FM) [0573:4d35]
42 -> Hauppauge WinTV USB Pro (Temic PAL B/G FM) [0573:4d36]
43 -> Hauppauge WinTV USB Pro (PAL/SECAM B/G/I/D/K/L FM) [0573:4d37]
44 -> Hauppauge WinTV USB Pro (NTSC M/N FM) V2 [0573:4d38]
45 -> Camtel Technology USB TV Genie Pro FM Model TVB330 [0768:0006]
46 -> Digital Video Creator I [07d0:0001]
47 -> Global Village GV-007 (NTSC) [07d0:0002]
48 -> Dazzle Fusion Model DVC-50 Rev 1 (NTSC) [07d0:0003]
49 -> Dazzle Fusion Model DVC-80 Rev 1 (PAL) [07d0:0004]
50 -> Dazzle Fusion Model DVC-90 Rev 1 (SECAM) [07d0:0005]
51 -> Eskape Labs MyTV2Go [07f8:9104]
52 -> Pinnacle Studio PCTV USB (PAL) [2304:010d]
53 -> Pinnacle Studio PCTV USB (SECAM) [2304:0109]
54 -> Pinnacle Studio PCTV USB (PAL) FM [2304:0110]
55 -> Miro PCTV USB [2304:0111]
56 -> Pinnacle Studio PCTV USB (NTSC) FM [2304:0112]
57 -> Pinnacle Studio PCTV USB (PAL) FM V2 [2304:0210]
58 -> Pinnacle Studio PCTV USB (NTSC) FM V2 [2304:0212]
59 -> Pinnacle Studio PCTV USB (PAL) FM V3 [2304:0214]
60 -> Pinnacle Studio Linx Video input cable (NTSC) [2304:0300]
61 -> Pinnacle Studio Linx Video input cable (PAL) [2304:0301]
62 -> Pinnacle PCTV Bungee USB (PAL) FM [2304:0419]
63 -> Hauppauge WinTv-USB [2400:4200]
64 -> Pinnacle Studio PCTV USB (NTSC) FM V3 [2304:0113]
65 -> Nogatech USB MicroCam NTSC (NV3000N) [0573:3000]
66 -> Nogatech USB MicroCam PAL (NV3001P) [0573:3001]

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

@@ -0,0 +1,205 @@
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/media/parport/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. 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.d/*.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
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.pingouin-land.com/howto/QuickCam-HOWTO.html
http://www.crynwr.com/qcpc/ QuickCam Third-Party Drivers
http://www.crynwr.com/qcpc/re.html Some Reverse Engineering
http://www.wirelesscouch.net/software/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

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

@@ -0,0 +1,130 @@
$Id: README,v 1.7 2005/08/29 23:39:57 sbertin Exp $
1. Introduction
This is a driver for STMicroelectronics's CPiA2 (second generation
Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
stream at up to vga size. It implements the Video4Linux interface as much as
possible. Since the V4L interface does not support compressed formats, only
an mjpeg enabled application can be used with the camera. We have modified the
gqcam application to view this stream.
The driver is implemented as two kernel modules. The cpia2 module
contains the camera functions and the V4L interface. The cpia2_usb module
contains usb specific functions. The main reason for this was the size of the
module was getting out of hand, so I separated them. It is not likely that
there will be a parallel port version.
FEATURES:
- Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
sensors. I only have the vga sensor, so can't test the other.
- Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
VGA and QVGA are the native image sizes for the VGA camera. CIF is done
in the coprocessor by scaling QVGA. All other sizes are done by clipping.
- Palette: YCrCb, compressed with MJPEG.
- Some compression parameters are settable.
- Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
- Adjust brightness, color, contrast while streaming.
- Flicker control settable for 50 or 60 Hz mains frequency.
2. Making and installing the stv672 driver modules:
Requirements:
-------------
This should work with 2.4 (2.4.23 and later) and 2.6 kernels, but has
only been tested on 2.6. Video4Linux must be either compiled into the kernel or
available as a module. Video4Linux2 is automatically detected and made
available at compile time.
Compiling:
----------
As root, do a make install. This will compile and install the modules
into the media/video directory in the module tree. For 2.4 kernels, use
Makefile_2.4 (aka do make -f Makefile_2.4 install).
Setup:
------
Use 'modprobe cpia2' to load and 'modprobe -r cpia2' to unload. This
may be done automatically by your distribution.
3. Driver options
Option Description
------ -----------
video_nr video device to register (0=/dev/video0, etc)
range -1 to 64. default is -1 (first available)
If you have more than 1 camera, this MUST be -1.
buffer_size Size for each frame buffer in bytes (default 68k)
num_buffers Number of frame buffers (1-32, default 3)
alternate USB Alternate (2-7, default 7)
flicker_freq Frequency for flicker reduction(50 or 60, default 60)
flicker_mode 0 to disable, or 1 to enable flicker reduction.
(default 0). This is only effective if the camera
uses a stv0672 coprocessor.
Setting the options:
--------------------
If you are using modules, edit /etc/modules.conf and add an options
line like this:
options cpia2 num_buffers=3 buffer_size=65535
If the driver is compiled into the kernel, at boot time specify them
like this:
cpia2.num_buffers=3 cpia2.buffer_size=65535
What buffer size should I use?
------------------------------
The maximum image size depends on the alternate you choose, and the
frame rate achieved by the camera. If the compression engine is able to
keep up with the frame rate, the maximum image size is given by the table
below.
The compression engine starts out at maximum compression, and will
increase image quality until it is close to the size in the table. As long
as the compression engine can keep up with the frame rate, after a short time
the images will all be about the size in the table, regardless of resolution.
At low alternate settings, the compression engine may not be able to
compress the image enough and will reduce the frame rate by producing larger
images.
The default of 68k should be good for most users. This will handle
any alternate at frame rates down to 15fps. For lower frame rates, it may
be necessary to increase the buffer size to avoid having frames dropped due
to insufficient space.
Image size(bytes)
Alternate bytes/ms 15fps 30fps
2 128 8533 4267
3 384 25600 12800
4 640 42667 21333
5 768 51200 25600
6 896 59733 29867
7 1023 68200 34100
How many buffers should I use?
------------------------------
For normal streaming, 3 should give the best results. With only 2,
it is possible for the camera to finish sending one image just after a
program has started reading the other. If this happens, the driver must drop
a frame. The exception to this is if you have a heavily loaded machine. In
this case use 2 buffers. You are probably not reading at the full frame rate.
If the camera can send multiple images before a read finishes, it could
overwrite the third buffer before the read finishes, leading to a corrupt
image. Single and double buffering have extra checks to avoid overwriting.
4. Using the camera
We are providing a modified gqcam application to view the output. In
order to avoid confusion, here it is called mview. There is also the qx5view
program which can also control the lights on the qx5 microscope. MJPEG Tools
(http://mjpeg.sourceforge.net) can also be used to record from the camera.
5. Notes to developers:
- This is a driver version stripped of the 2.4 back compatibility
and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
6. Thanks:
- Peter Pregler <Peter_Pregler@email.com>,
Scott J. Bertin <scottbertin@yahoo.com>, and
Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
this one was modelled from.

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

@@ -0,0 +1,67 @@
cx8800 release notes
====================
This is a v4l2 device driver for the cx2388x chip.
current status
==============
video
- Basically works.
- For now, only capture and read(). Overlay isn't supported.
audio
- The chip specs for the on-chip TV sound decoder are next
to useless :-/
- Neverless the builtin TV sound decoder starts working now,
at least for some standards.
FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
USING.
- Most tuner chips do provide mono sound, which may or may not
be useable depending on the board design. With the Hauppauge
cards it works, so there is mono sound available as fallback.
- audio data dma (i.e. recording without loopback cable to the
sound card) is supported via cx88-alsa.
vbi
- Code present. Works for NTSC closed caption. PAL and other
TV norms may or may not work.
how to add support for new cards
================================
The driver needs some config info for the TV cards. This stuff is in
cx88-cards.c. If the driver doesn't work well you likely need a new
entry for your card in that file. Check the kernel log (using dmesg)
to see whenever the driver knows your card or not. There is a line
like this one:
cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \
34xxx models [card=1,autodetected]
If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to
the driver. What to do then?
(1) Try upgrading to the latest snapshot, maybe it has been added
meanwhile.
(2) You can try to create a new entry yourself, have a look at
cx88-cards.c. If that worked, mail me your changes as unified
diff ("diff -u").
(3) Or you can mail me the config information. I need at least the
following 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]

93
Documentation/video4linux/README.davinci-vpbe Normal file
View File

@@ -0,0 +1,93 @@
VPBE V4L2 driver design
======================================================================
File partitioning
-----------------
V4L2 display device driver
drivers/media/platform/davinci/vpbe_display.c
drivers/media/platform/davinci/vpbe_display.h
VPBE display controller
drivers/media/platform/davinci/vpbe.c
drivers/media/platform/davinci/vpbe.h
VPBE venc sub device driver
drivers/media/platform/davinci/vpbe_venc.c
drivers/media/platform/davinci/vpbe_venc.h
drivers/media/platform/davinci/vpbe_venc_regs.h
VPBE osd driver
drivers/media/platform/davinci/vpbe_osd.c
drivers/media/platform/davinci/vpbe_osd.h
drivers/media/platform/davinci/vpbe_osd_regs.h
Functional partitioning
-----------------------
Consists of the following (in the same order as the list under file
partitioning):-
1. V4L2 display driver
Implements creation of video2 and video3 device nodes and
provides v4l2 device interface to manage VID0 and VID1 layers.
2. Display controller
Loads up VENC, OSD and external encoders such as ths8200. It provides
a set of API calls to V4L2 drivers to set the output/standards
in the VENC or external sub devices. It also provides
a device object to access the services from OSD subdevice
using sub device ops. The connection of external encoders to VENC LCD
controller port is done at init time based on default output and standard
selection or at run time when application change the output through
V4L2 IOCTLs.
When connected to an external encoder, vpbe controller is also responsible
for setting up the interface between VENC and external encoders based on
board specific settings (specified in board-xxx-evm.c). This allows
interfacing external encoders such as ths8200. The setup_if_config()
is implemented for this as well as configure_venc() (part of the next patch)
API to set timings in VENC for a specific display resolution. As of this
patch series, the interconnection and enabling and setting of the external
encoders is not present, and would be a part of the next patch series.
3. VENC subdevice module
Responsible for setting outputs provided through internal DACs and also
setting timings at LCD controller port when external encoders are connected
at the port or LCD panel timings required. When external encoder/LCD panel
is connected, the timings for a specific standard/preset is retrieved from
the board specific table and the values are used to set the timings in
venc using non-standard timing mode.
Support LCD Panel displays using the VENC. For example to support a Logic
PD display, it requires setting up the LCD controller port with a set of
timings for the resolution supported and setting the dot clock. So we could
add the available outputs as a board specific entry (i.e add the "LogicPD"
output name to board-xxx-evm.c). A table of timings for various LCDs
supported can be maintained in the board specific setup file to support
various LCD displays.As of this patch a basic driver is present, and this
support for external encoders and displays forms a part of the next
patch series.
4. OSD module
OSD module implements all OSD layer management and hardware specific
features. The VPBE module interacts with the OSD for enabling and
disabling appropriate features of the OSD.
Current status:-
A fully functional working version of the V4L2 driver is available. This
driver has been tested with NTSC and PAL standards and buffer streaming.
Following are TBDs.
vpbe display controller
- Add support for external encoders.
- add support for selecting external encoder as default at probe time.
vpbe venc sub device
- add timings for supporting ths8200
- add support for LogicPD LCD.
FB drivers
- Add support for fbdev drivers.- Ready and part of subsequent patches.

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>

186
Documentation/video4linux/README.ivtv Normal file
View File

@@ -0,0 +1,186 @@
ivtv release notes
==================
This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder.
The cx23415 can do both encoding and decoding, the cx23416 can only do MPEG
encoding. Currently the only card featuring full decoding support is the
Hauppauge PVR-350.
NOTE: this driver requires the latest encoder firmware (version 2.06.039, size
376836 bytes). Get the firmware from here:
http://dl.ivtvdriver.org/ivtv/firmware/
NOTE: 'normal' TV applications do not work with this driver, you need
an application that can handle MPEG input such as mplayer, xine, MythTV,
etc.
The primary goal of the IVTV project is to provide a "clean room" Linux
Open Source driver implementation for video capture cards based on the
iCompression iTVC15 or Conexant CX23415/CX23416 MPEG Codec.
Features:
* Hardware mpeg2 capture of broadcast video (and sound) via the tuner or
S-Video/Composite and audio line-in.
* Hardware mpeg2 capture of FM radio where hardware support exists
* Supports NTSC, PAL, SECAM with stereo sound
* Supports SAP and bilingual transmissions.
* Supports raw VBI (closed captions and teletext).
* Supports sliced VBI (closed captions and teletext) and is able to insert
this into the captured MPEG stream.
* Supports raw YUV and PCM input.
Additional features for the PVR-350 (CX23415 based):
* Provides hardware mpeg2 playback
* Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the
video signal)
* Provides a framebuffer (allowing X applications to appear on the video
device)
* Supports raw YUV output.
IMPORTANT: In case of problems first read this page:
http://www.ivtvdriver.org/index.php/Troubleshooting
See also:
Homepage + Wiki
http://www.ivtvdriver.org
IRC
irc://irc.freenode.net/ivtv-dev
----------------------------------------------------------
Devices
=======
A maximum of 12 ivtv boards are allowed at the moment.
Cards that don't have a video output capability (i.e. non PVR350 cards)
lack the vbi8, vbi16, video16 and video48 devices. They also do not
support the framebuffer device /dev/fbx for OSD.
The radio0 device may or may not be present, depending on whether the
card has a radio tuner or not.
Here is a list of the base v4l devices:
crw-rw---- 1 root video 81, 0 Jun 19 22:22 /dev/video0
crw-rw---- 1 root video 81, 16 Jun 19 22:22 /dev/video16
crw-rw---- 1 root video 81, 24 Jun 19 22:22 /dev/video24
crw-rw---- 1 root video 81, 32 Jun 19 22:22 /dev/video32
crw-rw---- 1 root video 81, 48 Jun 19 22:22 /dev/video48
crw-rw---- 1 root video 81, 64 Jun 19 22:22 /dev/radio0
crw-rw---- 1 root video 81, 224 Jun 19 22:22 /dev/vbi0
crw-rw---- 1 root video 81, 228 Jun 19 22:22 /dev/vbi8
crw-rw---- 1 root video 81, 232 Jun 19 22:22 /dev/vbi16
Base devices
============
For every extra card you have the numbers increased by one. For example,
/dev/video0 is listed as the 'base' encoding capture device so we have:
/dev/video0 is the encoding capture device for the first card (card 0)
/dev/video1 is the encoding capture device for the second card (card 1)
/dev/video2 is the encoding capture device for the third card (card 2)
Note that if the first card doesn't have a feature (eg no decoder, so no
video16, the second card will still use video17. The simple rule is 'add
the card number to the base device number'. If you have other capture
cards (e.g. WinTV PCI) that are detected first, then you have to tell
the ivtv module about it so that it will start counting at 1 (or 2, or
whatever). Otherwise the device numbers can get confusing. The ivtv
'ivtv_first_minor' module option can be used for that.
/dev/video0
The encoding capture device(s).
Read-only.
Reading from this device gets you the MPEG1/2 program stream.
Example:
cat /dev/video0 > my.mpg (you need to hit ctrl-c to exit)
/dev/video16
The decoder output device(s)
Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
An mpeg2 stream sent to this device will appear on the selected video
display, audio will appear on the line-out/audio out. It is only
available for cards that support video out. Example:
cat my.mpg >/dev/video16
/dev/video24
The raw audio capture device(s).
Read-only
The raw audio PCM stereo stream from the currently selected
tuner or audio line-in. Reading from this device results in a raw
(signed 16 bit Little Endian, 48000 Hz, stereo pcm) capture.
This device only captures audio. This should be replaced by an ALSA
device in the future.
Note that there is no corresponding raw audio output device, this is
not supported in the decoder firmware.
/dev/video32
The raw video capture device(s)
Read-only
The raw YUV video output from the current video input. The YUV format
is non-standard (V4L2_PIX_FMT_HM12).
Note that the YUV and PCM streams are not synchronized, so they are of
limited use.
/dev/video48
The raw video display device(s)
Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
Writes a YUV stream to the decoder of the card.
/dev/radio0
The radio tuner device(s)
Cannot be read or written.
Used to enable the radio tuner and tune to a frequency. You cannot
read or write audio streams with this device. Once you use this
device to tune the radio, use /dev/video24 to read the raw pcm stream
or /dev/video0 to get an mpeg2 stream with black video.
/dev/vbi0
The 'vertical blank interval' (Teletext, CC, WSS etc) capture device(s)
Read-only
Captures the raw (or sliced) video data sent during the Vertical Blank
Interval. This data is used to encode teletext, closed captions, VPS,
widescreen signalling, electronic program guide information, and other
services.
/dev/vbi8
Processed vbi feedback device(s)
Read-only. Only present if the MPEG decoder (i.e. CX23415) exists.
The sliced VBI data embedded in an MPEG stream is reproduced on this
device. So while playing back a recording on /dev/video16, you can
read the embedded VBI data from /dev/vbi8.
/dev/vbi16
The vbi 'display' device(s)
Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
Can be used to send sliced VBI data to the video-out connector.
---------------------------------
Hans Verkuil <hverkuil@xs4all.nl>

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

@@ -0,0 +1,212 @@
$Id$
Mike Isely <isely@pobox.com>
pvrusb2 driver
Background:
This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which
is a USB 2.0 hosted TV Tuner. This driver is a work in progress.
Its history started with the reverse-engineering effort by Björn
Danielsson <pvrusb2@dax.nu> whose web page can be found here:
http://pvrusb2.dax.nu/
From there Aurelien Alleaume <slts@free.fr> began an effort to
create a video4linux compatible driver. I began with Aurelien's
last known snapshot and evolved the driver to the state it is in
here.
More information on this driver can be found at:
http://www.isely.net/pvrusb2.html
This driver has a strong separation of layers. They are very
roughly:
1a. Low level wire-protocol implementation with the device.
1b. I2C adaptor implementation and corresponding I2C client drivers
implemented elsewhere in V4L.
1c. High level hardware driver implementation which coordinates all
activities that ensure correct operation of the device.
2. A "context" layer which manages instancing of driver, setup,
tear-down, arbitration, and interaction with high level
interfaces appropriately as devices are hotplugged in the
system.
3. High level interfaces which glue the driver to various published
Linux APIs (V4L, sysfs, maybe DVB in the future).
The most important shearing layer is between the top 2 layers. A
lot of work went into the driver to ensure that any kind of
conceivable API can be laid on top of the core driver. (Yes, the
driver internally leverages V4L to do its work but that really has
nothing to do with the API published by the driver to the outside
world.) The architecture allows for different APIs to
simultaneously access the driver. I have a strong sense of fairness
about APIs and also feel that it is a good design principle to keep
implementation and interface isolated from each other. Thus while
right now the V4L high level interface is the most complete, the
sysfs high level interface will work equally well for similar
functions, and there's no reason I see right now why it shouldn't be
possible to produce a DVB high level interface that can sit right
alongside V4L.
NOTE: Complete documentation on the pvrusb2 driver is contained in
the html files within the doc directory; these are exactly the same
as what is on the web site at the time. Browse those files
(especially the FAQ) before asking questions.
Building
To build these modules essentially amounts to just running "Make",
but you need the kernel source tree nearby and you will likely also
want to set a few controlling environment variables first in order
to link things up with that source tree. Please see the Makefile
here for comments that explain how to do that.
Source file list / functional overview:
(Note: The term "module" used below generally refers to loosely
defined functional units within the pvrusb2 driver and bears no
relation to the Linux kernel's concept of a loadable module.)
pvrusb2-audio.[ch] - This is glue logic that resides between this
driver and the msp3400.ko I2C client driver (which is found
elsewhere in V4L).
pvrusb2-context.[ch] - This module implements the context for an
instance of the driver. Everything else eventually ties back to
or is otherwise instanced within the data structures implemented
here. Hotplugging is ultimately coordinated here. All high level
interfaces tie into the driver through this module. This module
helps arbitrate each interface's access to the actual driver core,
and is designed to allow concurrent access through multiple
instances of multiple interfaces (thus you can for example change
the tuner's frequency through sysfs while simultaneously streaming
video through V4L out to an instance of mplayer).
pvrusb2-debug.h - This header defines a printk() wrapper and a mask
of debugging bit definitions for the various kinds of debug
messages that can be enabled within the driver.
pvrusb2-debugifc.[ch] - This module implements a crude command line
oriented debug interface into the driver. Aside from being part
of the process for implementing manual firmware extraction (see
the pvrusb2 web site mentioned earlier), probably I'm the only one
who has ever used this. It is mainly a debugging aid.
pvrusb2-eeprom.[ch] - This is glue logic that resides between this
driver the tveeprom.ko module, which is itself implemented
elsewhere in V4L.
pvrusb2-encoder.[ch] - This module implements all protocol needed to
interact with the Conexant mpeg2 encoder chip within the pvrusb2
device. It is a crude echo of corresponding logic in ivtv,
however the design goals (strict isolation) and physical layer
(proxy through USB instead of PCI) are enough different that this
implementation had to be completely different.
pvrusb2-hdw-internal.h - This header defines the core data structure
in the driver used to track ALL internal state related to control
of the hardware. Nobody outside of the core hardware-handling
modules should have any business using this header. All external
access to the driver should be through one of the high level
interfaces (e.g. V4L, sysfs, etc), and in fact even those high
level interfaces are restricted to the API defined in
pvrusb2-hdw.h and NOT this header.
pvrusb2-hdw.h - This header defines the full internal API for
controlling the hardware. High level interfaces (e.g. V4L, sysfs)
will work through here.
pvrusb2-hdw.c - This module implements all the various bits of logic
that handle overall control of a specific pvrusb2 device.
(Policy, instantiation, and arbitration of pvrusb2 devices fall
within the jurisdiction of pvrusb-context not here).
pvrusb2-i2c-chips-*.c - These modules implement the glue logic to
tie together and configure various I2C modules as they attach to
the I2C bus. There are two versions of this file. The "v4l2"
version is intended to be used in-tree alongside V4L, where we
implement just the logic that makes sense for a pure V4L
environment. The "all" version is intended for use outside of
V4L, where we might encounter other possibly "challenging" modules
from ivtv or older kernel snapshots (or even the support modules
in the standalone snapshot).
pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1
compatible commands to the I2C modules. It is here where state
changes inside the pvrusb2 driver are translated into V4L1
commands that are in turn send to the various I2C modules.
pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2
compatible commands to the I2C modules. It is here where state
changes inside the pvrusb2 driver are translated into V4L2
commands that are in turn send to the various I2C modules.
pvrusb2-i2c-core.[ch] - This module provides an implementation of a
kernel-friendly I2C adaptor driver, through which other external
I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
operate corresponding chips within the pvrusb2 device. It is
through here that other V4L modules can reach into this driver to
operate specific pieces (and those modules are in turn driven by
glue logic which is coordinated by pvrusb2-hdw, doled out by
pvrusb2-context, and then ultimately made available to users
through one of the high level interfaces).
pvrusb2-io.[ch] - This module implements a very low level ring of
transfer buffers, required in order to stream data from the
device. This module is *very* low level. It only operates the
buffers and makes no attempt to define any policy or mechanism for
how such buffers might be used.
pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch]
to provide a streaming API usable by a read() system call style of
I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
however the underlying architecture here was intended to allow for
other styles of I/O to be implemented with additional modules, like
mmap()'ed buffers or something even more exotic.
pvrusb2-main.c - This is the top level of the driver. Module level
and USB core entry points are here. This is our "main".
pvrusb2-sysfs.[ch] - This is the high level interface which ties the
pvrusb2 driver into sysfs. Through this interface you can do
everything with the driver except actually stream data.
pvrusb2-tuner.[ch] - This is glue logic that resides between this
driver and the tuner.ko I2C client driver (which is found
elsewhere in V4L).
pvrusb2-util.h - This header defines some common macros used
throughout the driver. These macros are not really specific to
the driver, but they had to go somewhere.
pvrusb2-v4l2.[ch] - This is the high level interface which ties the
pvrusb2 driver into video4linux. It is through here that V4L
applications can open and operate the driver in the usual V4L
ways. Note that **ALL** V4L functionality is published only
through here and nowhere else.
pvrusb2-video-*.[ch] - This is glue logic that resides between this
driver and the saa711x.ko I2C client driver (which is found
elsewhere in V4L). Note that saa711x.ko used to be known as
saa7115.ko in ivtv. There are two versions of this; one is
selected depending on the particular saa711[5x].ko that is found.
pvrusb2.h - This header contains compile time tunable parameters
(and at the moment the driver has very little that needs to be
tuned).
-Mike Isely
isely@pobox.com

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]

47
Documentation/video4linux/README.tlg2300 Normal file
View File

@@ -0,0 +1,47 @@
tlg2300 release notes
====================
This is a v4l2/dvb device driver for the tlg2300 chip.
current status
==============
video
- support mmap and read().(no overlay)
audio
- The driver will register a ALSA card for the audio input.
vbi
- Works for almost TV norms.
dvb-t
- works for DVB-T
FM
- Works for radio.
---------------------------------------------------------------------------
TESTED APPLICATIONS:
-VLC1.0.4 test the video and dvb. The GUI is friendly to use.
-Mplayer test the video.
-Mplayer test the FM. The mplayer should be compiled with --enable-radio and
--enable-radio-capture.
The command runs as this(The alsa audio registers to card 1):
#mplayer radio://103.7/capture/ -radio adevice=hw=1,0:arate=48000 \
-rawaudio rate=48000:channels=2
---------------------------------------------------------------------------
KNOWN PROBLEMS:
about preemphasis:
You can set the preemphasis for radio by the following command:
#v4l2-ctl -d /dev/radio0 --set-ctrl=pre_emphasis_settings=1
"pre_emphasis_settings=1" means that you select the 50us. If you want
to select the 75us, please use "pre_emphasis_settings=2"

510
Documentation/video4linux/Zoran Normal file
View File

@@ -0,0 +1,510 @@
Frequently Asked Questions:
===========================
subject: unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)
website: http://mjpeg.sourceforge.net/driver-zoran/
1. What cards are supported
1.1 What the TV decoder can do an what not
1.2 What the TV encoder can do an what not
2. How do I get this damn thing to work
3. What mainboard should I use (or why doesn't my card work)
4. Programming interface
5. Applications
6. Concerning buffer sizes, quality, output size etc.
7. It hangs/crashes/fails/whatevers! Help!
8. Maintainers/Contacting
9. License
===========================
1. What cards are supported
Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
DC10/DC10+/DC30/DC30+ and related boards (available under various names).
Iomega Buz:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7111 TV decoder
* Philips saa7185 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7111, saa7185, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 7
AverMedia 6 Eyes AVS6EYES:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Samsung ks0127 TV decoder
* Conexant bt866 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, ks0127, bt866, zr36060, zr36067
Inputs/outputs: Six physical inputs. 1-6 are composite,
1-2, 3-4, 5-6 doubles as S-video,
1-3 triples as component.
One composite output.
Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 8
Not autodetected, card=8 is necessary.
Linux Media Labs LML33:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Brooktree bt819 TV decoder
* Brooktree bt856 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, bt819, bt856, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 5
Linux Media Labs LML33R10:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7114 TV decoder
* Analog Devices adv7170 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7114, adv7170, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 6
Pinnacle/Miro DC10(new):
* Zoran zr36057 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7110, adv7175, zr36060, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 1
Pinnacle/Miro DC10+:
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, sa7110, adv7175, zr36060, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 2
Pinnacle/Miro DC10(old): *
* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
* Micronas vpx3220a TV decoder
* mse3000 TV encoder or Analog Devices adv7176 TV encoder *
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 0
Pinnacle/Miro DC30: *
* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 3
Pinnacle/Miro DC30+: *
* Zoran zr36067 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 4
Note: No module for the mse3000 is available yet
Note: No module for the vpx3224 is available yet
===========================
1.1 What the TV decoder can do an what not
The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
information is not enough. There are several formats of the TV standards.
And not every TV decoder is able to handle every format. Also the every
combination is supported by the driver. There are currently 11 different
tv broadcast formats all aver the world.
The CCIR defines parameters needed for broadcasting the signal.
The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
The CCIR says not much about the colorsystem used !!!
And talking about a colorsystem says not to much about how it is broadcast.
The CCIR standards A,E,F are not used any more.
When you speak about NTSC, you usually mean the standard: CCIR - M using
the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
and a few others.
When you talk about PAL, you usually mean: CCIR - B/G using the PAL
colorsystem which is used in many Countries.
When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
which is used in France, and a few others.
There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.
The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
Ireland, Nigeria, South Africa.
The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
and is used in Argentinia, Uruguay, an a few others
We do not talk about how the audio is broadcast !
A rather good sites about the TV standards are:
http://www.sony.jp/support/
http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
and http://www.cabl.com/restaurant/channel.html
Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
be the same as NTSC 4.43.
NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
to split coma and luma instead of a Delay line.
But I did not defiantly find out what NTSC Comb is.
Philips saa7111 TV decoder
was introduced in 1997, is used in the BUZ and
can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM
Philips saa7110a TV decoder
was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
can handle: PAL B/G, NTSC M and SECAM
Philips saa7114 TV decoder
was introduced in 2000, is used in the LML33R10 and
can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
Brooktree bt819 TV decoder
was introduced in 1996, and is used in the LML33 and
can handle: PAL B/D/G/H/I, NTSC M
Micronas vpx3220a TV decoder
was introduced in 1996, is used in the DC30 and DC30+ and
can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb
Samsung ks0127 TV decoder
is used in the AVS6EYES card and
can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM
===========================
1.2 What the TV encoder can do an what not
The TV encoder are doing the "same" as the decoder, but in the oder direction.
You feed them digital data and the generate a Composite or SVHS signal.
For information about the colorsystems and TV norm take a look in the
TV decoder section.
Philips saa7185 TV Encoder
was introduced in 1996, is used in the BUZ
can generate: PAL B/G, NTSC M
Brooktree bt856 TV Encoder
was introduced in 1994, is used in the LML33
can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
Analog Devices adv7170 TV Encoder
was introduced in 2000, is used in the LML300R10
can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60
Analog Devices adv7175 TV Encoder
was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
can generate: PAL B/D/G/H/I/N, PAL M, NTSC M
ITT mse3000 TV encoder
was introduced in 1991, is used in the DC10 old
can generate: PAL , NTSC , SECAM
Conexant bt866 TV encoder
is used in AVS6EYES, and
can generate: NTSC/PAL, PAL­M, PAL­N
The adv717x, should be able to produce PAL N. But you find nothing PAL N
specific in the registers. Seem that you have to reuse a other standard
to generate PAL N, maybe it would work if you use the PAL M settings.
==========================
2. How do I get this damn thing to work
Load zr36067.o. If it can't autodetect your card, use the card=X insmod
option with X being the card number as given in the previous section.
To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
To automate this, add the following to your /etc/modprobe.d/zoran.conf:
options zr36067 card=X1[,X2[,X3[,X4[..]]]]
alias char-major-81-0 zr36067
One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
just automates loading. If you start using xawtv, the device won't load on
some systems, since you're trying to load modules as a user, which is not
allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
one of your startup scripts (normally rc.local) if you don't use X. Both
make sure that the modules are loaded on startup, under the root account.
===========================
3. What mainboard should I use (or why doesn't my card work)
<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.
Experience tells us that people with a Buz, on average, have more problems
than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
based on a different chipset. Here's some notes from Andrew Stevens:
--
Here's my experience of using LML33 and Buz on various motherboards:
VIA MVP3
Forget it. Pointless. Doesn't work.
Intel 430FX (Pentium 200)
LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
Intel 440BX (early stepping)
LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
Intel 440BX (late stepping)
Buz tolerable, LML3 almost perfect (occasional single frame drops)
SiS735
LML33 perfect, Buz tolerable.
VIA KT133(*)
LML33 starting to get annoying, Buz poor enough that I have up.
Both 440BX boards were dual CPU versions.
--
Bernhard Praschinger later added:
--
AMD 751
Buz perfect-tolerable
AMD 760
Buz perfect-tolerable
--
In general, people on the user mailinglist won't give you much of a chance
if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
rather want to spend some more money on better boards. In general, VIA
mainboard's IDE/PCI performance will also suck badly compared to others.
You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
Basically, you can assume that if the Buz works, the LML33 will work too. If
the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
different mainboard chipsets from all of the supported cards.
If you experience timeouts during capture, buy a better mainboard or lower
the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
output size etc.'). If it hangs, there's little we can do as of now. Check
your IRQs and make sure the card has its own interrupts.
===========================
4. Programming interface
This driver conforms to video4linux2. Support for V4L1 and for the custom
zoran ioctls has been removed in kernel 2.6.38.
For programming example, please, look at lavrec.c and lavplay.c code in
the MJPEG-tools (http://mjpeg.sf.net/).
Additional notes for software developers:
The driver returns maxwidth and maxheight parameters according to
the current TV standard (norm). Therefore, the software which
communicates with the driver and "asks" for these parameters should
first set the correct norm. Well, it seems logically correct: TV
standard is "more constant" for current country than geometry
settings of a variety of TV capture cards which may work in ITU or
square pixel format.
===========================
5. Applications
Applications known to work with this driver:
TV viewing:
* xawtv
* kwintv
* probably any TV application that supports video4linux or video4linux2.
MJPEG capture/playback:
* mjpegtools/lavtools (or Linux Video Studio)
* gstreamer
* mplayer
General raw capture:
* xawtv
* gstreamer
* probably any application that supports video4linux or video4linux2
Video editing:
* Cinelerra
* MainActor
* mjpegtools (or Linux Video Studio)
===========================
6. Concerning buffer sizes, quality, output size etc.
The zr36060 can do 1:2 JPEG compression. This is really the theoretical
maximum that the chipset can reach. The driver can, however, limit compression
to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
can't handle 1:2 compression without stopping capture after only a few minutes.
With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
1:4 max. compression mode.
100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
(quantization) tables, and you'll get to something like 512kB per frame for
1:2 compression. For 1:4 compression, you'd have frames of half this size.
Some additional explanation by Martin Samuelsson, which also explains the
importance of buffer sizes:
--
> Hmm, I do not think it is really that way. With the current (downloaded
> at 18:00 Monday) driver I get that output sizes for 10 sec:
> -q 50 -b 128 : 24.283.332 Bytes
> -q 50 -b 256 : 48.442.368
> -q 25 -b 128 : 24.655.992
> -q 25 -b 256 : 25.859.820
I woke up, and can't go to sleep again. I'll kill some time explaining why
this doesn't look strange to me.
Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
actually use that number or not, but that's not too important right now.
704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
output becomes 512 bits per block. Actually 510, but 512 is simpler to use
for calculations.
Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
here, so we don't need to do any fancy corrections for bits-per-pixel or such
things. 101376 bytes per field.
d1 video contains two fields per frame. Those sum up to 202752 bytes per
frame, and one of those frames goes into each buffer.
But wait a second! -b128 gives 128kB buffers! It's not possible to cram
202752 bytes of JPEG data into 128kB!
This is what the driver notice and automatically compensate for in your
examples. Let's do some math using this information:
128kB is 131072 bytes. In this buffer, we want to store two fields, which
leaves 65536 bytes for each field. Using 3168 blocks per field, we get
20.68686868... available bytes per block; 165 bits. We can't allow the
request for 256 bits per block when there's only 165 bits available! The -q50
option is silently overridden, and the -b128 option takes precedence, leaving
us with the equivalence of -q32.
This gives us a data rate of 165 bits per block, which, times 3168, sums up
to 65340 bytes per field, out of the allowed 65536. The current driver has
another level of rate limiting; it won't accept -q values that fill more than
6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
a safe bet. Personally, I think I would have lowered requested-bits-per-block
by one, or something like that.) We can't use 165 bits per block, but have to
lower it again, to 6/8 of the available buffer space: We end up with 124 bits
per block, the equivalence of -q24. With 128kB buffers, you can't use greater
than -q24 at -d1. (And PAL, and 704 pixels width...)
The third example is limited to -q24 through the same process. The second
example, using very similar calculations, is limited to -q48. The only
example that actually grab at the specified -q value is the last one, which
is clearly visible, looking at the file size.
--
Conclusion: the quality of the resulting movie depends on buffer size, quality,
whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
module to do 1:4 instead of 1:2 compression, etc.
If you experience timeouts, lowering the quality/buffersize or using
'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
proven by the Buz.
===========================
7. It hangs/crashes/fails/whatevers! Help!
Make sure that the card has its own interrupts (see /proc/interrupts), check
the output of dmesg at high verbosity (load zr36067.o with debug=2,
load all other modules with debug=1). Check that your mainboard is favorable
(see question 2) and if not, test the card in another computer. Also see the
notes given in question 3 and try lowering quality/buffersize/capturesize
if recording fails after a period of time.
If all this doesn't help, give a clear description of the problem including
detailed hardware information (memory+brand, mainboard+chipset+brand, which
MJPEG card, processor, other PCI cards that might be of interest), give the
system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
the kernel version, driver version, glibc version, gcc version and any other
information that might possibly be of interest. Also provide the dmesg output
at high verbosity. See 'Contacting' on how to contact the developers.
===========================
8. Maintainers/Contacting
The driver is currently maintained by Laurent Pinchart and Ronald Bultje
(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug
reports or questions, please contact the mailinglist instead of the developers
individually. For user questions (i.e. bug reports or how-to questions), send
an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to
help programming), send an email to <mjpeg-developer@lists.sf.net>. See
http://www.sf.net/projects/mjpeg/ for subscription information.
For bug reports, be sure to include all the information as described in
the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure
you're using the latest version (http://mjpeg.sf.net/driver-zoran/).
Previous maintainers/developers of this driver include Serguei Miridonov
<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks
<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>.
===========================
9. License
This driver is distributed under the terms of the General Public License.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
See http://www.gnu.org/ for more information.

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@lxorguk.ukuu.org.uk>
Video4Linux interface and 2.1.x kernel adaptation
Chris Kleitsch
Hardware I2C
Gerd Knorr <kraxel@cs.tu-berlin.de>
Radio card (ITT sound processor)
bigfoot <bigfoot@net-way.net>
Ragnar Hojland Espinosa <ragnar@macula.net>
ConferenceTV card
+ many more (please mail me if you are missing in this list and would
like to be mentioned)

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

@@ -0,0 +1,960 @@
Gunther Mayer's bttv card gallery (graphical version of this text file :-)
is available at: http://www.bttv-gallery.de/
Supported cards:
Bt848/Bt848a/Bt849/Bt878/Bt879 cards
------------------------------------
All cards with Bt848/Bt848a/Bt849/Bt878/Bt879 and normal
Composite/S-VHS inputs are supported. Teletext and Intercast support
(PAL only) for ALL cards via VBI sample decoding in software.
Some cards with additional multiplexing of inputs or other additional
fancy chips are only partially supported (unless specifications by the
card manufacturer are given). When a card is listed here it isn't
necessarily fully supported.
All other cards only differ by additional components as tuners, sound
decoders, EEPROMs, teletext decoders ...
Unsupported Cards:
------------------
Cards with Zoran (ZR) or Philips (SAA) or ISA are not supported by
this driver.
MATRIX Vision
-------------
MV-Delta
- Bt848A
- 4 Composite inputs, 1 S-VHS input (shared with 4th composite)
- EEPROM
http://www.matrix-vision.de/
This card has no tuner but supports all 4 composite (1 shared with an
S-VHS input) of the Bt848A.
Very nice card if you only have satellite TV but several tuners connected
to the card via composite.
Many thanks to Matrix-Vision for giving us 2 cards for free which made
Bt848a/Bt849 single crystal operation support possible!!!
Miro/Pinnacle PCTV
------------------
- Bt848
some (all??) come with 2 crystals for PAL/SECAM and NTSC
- PAL, SECAM or NTSC TV tuner (Philips or TEMIC)
- MSP34xx sound decoder on add on board
decoder is supported but AFAIK does not yet work
(other sound MUX setting in GPIO port needed??? somebody who fixed this???)
- 1 tuner, 1 composite and 1 S-VHS input
- tuner type is autodetected
http://www.miro.de/
http://www.miro.com/
Many thanks for the free card which made first NTSC support possible back
in 1997!
Hauppauge Win/TV pci
--------------------
There are many different versions of the Hauppauge cards with different
tuners (TV+Radio ...), teletext decoders.
Note that even cards with same model numbers have (depending on the revision)
different chips on it.
- Bt848 (and others but always in 2 crystal operation???)
newer cards have a Bt878
- PAL, SECAM, NTSC or tuner with or without Radio support
e.g.:
PAL:
TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
NTSC:
TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5518: no datasheet available on Philips site
- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip
with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM)
SAA5246 (I2C 0x22) is supported
- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y
with configuration information
I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf)
- 1 tuner, 1 composite and (depending on model) 1 S-VHS input
- 14052B: mux for selection of sound source
- sound decoder: TDA9800, MSP34xx (stereo cards)
Askey CPH-Series
----------------
Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink)
Card series:
CPH01x: BT848 capture only
CPH03x: BT848
CPH05x: BT878 with FM
CPH06x: BT878 (w/o FM)
CPH07x: BT878 capture only
TV standards:
CPH0x0: NTSC-M/M
CPH0x1: PAL-B/G
CPH0x2: PAL-I/I
CPH0x3: PAL-D/K
CPH0x4: SECAM-L/L
CPH0x5: SECAM-B/G
CPH0x6: SECAM-D/K
CPH0x7: PAL-N/N
CPH0x8: PAL-B/H
CPH0x9: PAL-M/M
CPH03x was often sold as "TV capturer".
Identifying:
1) 878 cards can be identified by PCI Subsystem-ID:
144f:3000 = CPH06x
144F:3002 = CPH05x w/ FM
144F:3005 = CPH06x_LC (w/o remote control)
1) The cards have a sticker with "CPH"-model on the back.
2) These cards have a number printed on the PCB just above the tuner metal box:
"80-CP2000300-x" = CPH03X
"80-CP2000500-x" = CPH05X
"80-CP2000600-x" = CPH06X / CPH06x_LC
Askey sells these cards as "Magic TView series", Brand "MagicXpress".
Other OEM often call these "Tview", "TView99" or else.
Lifeview Flyvideo Series:
-------------------------
The naming of these series differs in time and space.
Identifying:
1) Some models can be identified by PCI subsystem ID:
1852:1852 = Flyvideo 98 FM
1851:1850 = Flyvideo 98
1851:1851 = Flyvideo 98 EZ (capture only)
2) There is a print on the PCB:
LR25 = Flyvideo (Zoran ZR36120, SAA7110A)
LR26 Rev.N = Flyvideo II (Bt848)
Rev.O = Flyvideo II (Bt878)
LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110)
LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only)
LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID)
Rev.W = Flyvideo 98 (no eeprom)
LR51 Rev.E = Flyvideo 98 EZ (capture only)
LR90 = Flyvideo 2000 (Bt878)
Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard)
LR91 = Stereo daughter card for LR90
LR97 = Flyvideo DVBS
LR99 Rev.E = Low profile card for OEM integration (only internal audio!) bt878
LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134)
LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394)
LR138 Rev.C= Flyvideo 2000 (SAA7130)
or Flyvideo 3000 (SAA7134) w/Stereo TV
These exist in variations w/FM and w/Remote sometimes denoted
by suffixes "FM" and "R".
3) You have a laptop (miniPCI card):
Product = FlyTV Platinum Mini
Model/Chip = LR212/saa7135
Lifeview.com.tw states (Feb. 2002):
"The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98."
Their Bt8x8 cards are listed as discontinued.
Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?).
The new Flyvideo 2000/3000 are SAA7130/SAA7134 based.
"Flyvideo II" had been the name for the 848 cards, nowadays (in Germany)
this name is re-used for LR50 Rev.W.
The Lifeview website mentioned Flyvideo III at some time, but such a card
has not yet been seen (perhaps it was the german name for LR90 [stereo]).
These cards are sold by many OEMs too.
FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Germany}
Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134
Typhoon TV card series:
-----------------------
These can be CPH, Flyvideo, Pixelview or KNC1 series.
Typhoon is the brand of Anubis.
Model 50680 got re-used, some model no. had different contents over time.
Models:
50680 "TV Tuner PCI Pal BG"(old,red package)=can be CPH03x(bt848) or CPH06x(bt878)
50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B)
50681 "TV Tuner PCI Pal I" (variant of 50680)
50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q)
Note: The package has a picture of CPH05x (which would be a real TView)
50683 "TV Tuner PCI SECAM" (variant of 50680)
50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D)
50686 "TV Tuner" = KNC1 TV Station
50687 "TV Tuner stereo" = KNC1 TV Station pro
50688 "TV Tuner RDS" (black package) = KNC1 TV Station RDS
50689 TV SAT DVB-S CARD CI PCI (SAA7146AH, SU1278?) = "KNC1 TV Station DVB-S"
50692 "TV/FM Tuner" (small PCB)
50694 TV TUNER CARD RDS (PHILIPS CHIPSET SAA7134HL)
50696 TV TUNER STEREO (PHILIPS CHIPSET SAA7134HL, MK3ME Tuner)
50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps)
50866 TVIEW SAT RECEIVER+ADR
50868 "TV/FM Tuner Pal I" (variant of 50682)
50999 "TV/FM Tuner Secam" (variant of 50682)
Guillemot
---------
Maxi-TV PCI (ZR36120)
Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM)
Maxi TV Video 3 = CPH064 (PAL BG + SECAM)
Mentor
------
Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote)
Prolink
-------
TV cards:
PixelView Play TV pro - (Model: PV-BT878P+ REV 8E)
PixelView Play TV pro - (Model: PV-BT878P+ REV 9D)
PixelView Play TV pro - (Model: PV-BT878P+ REV 4C / 8D / 10A )
PixelView Play TV - (Model: PV-BT848P+)
878TV - (Model: PV-BT878TV)
Multimedia TV packages (card + software pack):
PixelView Play TV Theater - (Model: PV-M4200) = PixelView Play TV pro + Software
PixelView Play TV PAK - (Model: PV-BT878P+ REV 4E)
PixelView Play TV/VCR - (Model: PV-M3200 REV 4C / 8D / 10A )
PixelView Studio PAK - (Model: M2200 REV 4C / 8D / 10A )
PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E)
PixelView DigitalVCR PAK - (Model: PV-M2400 REV 4C / 8D / 10A )
PixelView PlayTV PAK II (TV/FM card + usb camera) PV-M3800
PixelView PlayTV XP PV-M4700,PV-M4700(w/FM)
PixelView PlayTV DVR PV-M4600 package contents:PixelView PlayTV pro, windvr & videoMail s/w
Further Cards:
PV-BT878P+rev.9B (Play TV Pro, opt. w/FM w/NICAM)
PV-BT878P+rev.2F
PV-BT878P Rev.1D (bt878, capture only)
XCapture PV-CX881P (cx23881)
PlayTV HD PV-CX881PL+, PV-CX881PL+(w/FM) (cx23881)
DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030
DTV2000 DVB-S = Twinhan VP-1020
Video Conferencing:
PixelView Meeting PAK - (Model: PV-BT878P)
PixelView Meeting PAK Lite - (Model: PV-BT878P)
PixelView Meeting PAK plus - (Model: PV-BT878P+rev 4C/8D/10A)
PixelView Capture - (Model: PV-BT848P)
PixelView PlayTV USB pro
Model No. PV-NT1004+, PV-NT1004+ (w/FM) = NT1004 USB decoder chip + SAA7113 video decoder chip
Dynalink
--------
These are CPH series.
Phoebemicro
-----------
TV Master = CPH030 or CPH060
TV Master FM = CPH050
Genius/Kye
----------
Video Wonder/Genius Internet Video Kit = LR37 Rev.C
Video Wonder Pro II (848 or 878) = LR26
Tekram
------
VideoCap C205 (Bt848)
VideoCap C210 (zr36120 +Philips)
CaptureTV M200 (ISA)
CaptureTV M205 (Bt848)
Lucky Star
----------
Image World Conference TV = LR50 Rev. Q
Leadtek
-------
WinView 601 (Bt848)
WinView 610 (Zoran)
WinFast2000
WinFast2000 XP
KNC One
-------
TV-Station
TV-Station SE (+Software Bundle)
TV-Station pro (+TV stereo)
TV-Station FM (+Radio)
TV-Station RDS (+RDS)
TV Station SAT (analog satellite)
TV-Station DVB-S
newer Cards have saa7134, but model name stayed the same?
Provideo
--------
PV951 or PV-951 (also are sold as:
Boeder TV-FM Video Capture Card
Titanmedia Supervision TV-2400
Provideo PV951 TF
3DeMon PV951
MediaForte TV-Vision PV951
Yoko PV951
Vivanco Tuner Card PCI Art.-Nr.: 68404
) now named PV-951T
Surveillance Series
PV-141
PV-143
PV-147
PV-148 (capture only)
PV-150
PV-151
TV-FM Tuner Series
PV-951TDV (tv tuner + 1394)
PV-951T/TF
PV-951PT/TF
PV-956T/TF Low Profile
PV-911
Highscreen
----------
TV Karte = LR50 Rev.S
TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb"
Zoltrix
-------
Face to Face Capture (Bt848 capture only) (PCB "VP-2848")
Face To Face TV MAX (Bt848) (PCB "VP-8482 Rev1.3")
Genie TV (Bt878) (PCB "VP-8790 Rev 2.1")
Genie Wonder Pro
AVerMedia
---------
AVer FunTV Lite (ISA, AV3001 chipset) "M101.C"
AVerTV
AVerTV Stereo
AVerTV Studio (w/FM)
AVerMedia TV98 with Remote
AVerMedia TV/FM98 Stereo
AVerMedia TVCAM98
TVCapture (Bt848)
TVPhone (Bt848)
TVCapture98 (="AVerMedia TV98" in USA) (Bt878)
TVPhone98 (Bt878, w/FM)
PCB PCI-ID Model-Name Eeprom Tuner Sound Country
--------------------------------------------------------------------
M101.C ISA !
M108-B Bt848 -- FR1236 US (2),(3)
M1A8-A Bt848 AVer TV-Phone FM1216 --
M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D (1) w/FM w/Remote
M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote
M168II-B 1461:0003 Medion MD9592 48:16 FM1216 TDA9873H D w/FM
(1) Daughterboard MB68-A with TDA9820T and TDA9840T
(2) Sony NE41S soldered (stereo sound?)
(3) Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz
US site has different drivers for (as of 09/2002):
EZ Capture/InterCam PCI (BT-848 chip)
EZ Capture/InterCam PCI (BT-878 chip)
TV-Phone (BT-848 chip)
TV98 (BT-848 chip)
TV98 With Remote (BT-848 chip)
TV98 (BT-878 chip)
TV98 With Remote (BT-878)
TV/FM98 (BT-878 chip)
AVerTV
AverTV Stereo
AVerTV Studio
DE hat diverse Treiber fuer diese Modelle (Stand 09/2002):
TVPhone (848) mit Philips tuner FR12X6 (w/ FM radio)
TVPhone (848) mit Philips tuner FM12X6 (w/ FM radio)
TVCapture (848) w/Philips tuner FI12X6
TVCapture (848) non-Philips tuner
TVCapture98 (Bt878)
TVPhone98 (Bt878)
AVerTV und TVCapture98 w/VCR (Bt 878)
AVerTVStudio und TVPhone98 w/VCR (Bt878)
AVerTV GO Serie (Kein SVideo Input)
AVerTV98 (BT-878 chip)
AVerTV98 mit Fernbedienung (BT-878 chip)
AVerTV/FM98 (BT-878 chip)
VDOmate (www.averm.com.cn) = M168U ?
Aimslab
-------
Video Highway or "Video Highway TR200" (ISA)
Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757)
IXMicro (former: IMS=Integrated Micro Solutions)
-------
IXTV BT848 (=TurboTV)
IXTV BT878
IMS TurboTV (Bt848)
Lifetec/Medion/Tevion/Aldi
--------------------------
LT9306/MD9306 = CPH061
LT9415/MD9415 = LR90 Rev.F or Rev.G
MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H)
MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner)
MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner)
Modular Technologies (www.modulartech.com) UK
---------------------------------------------
MM100 PCTV (Bt848)
MM201 PCTV (Bt878, Bt832) w/ Quartzsight camera
MM202 PCTV (Bt878, Bt832, tda9874)
MM205 PCTV (Bt878)
MM210 PCTV (Bt878) (Galaxy TV, Galaxymedia ?)
Terratec
--------
Terra TV+ Version 1.0 (Bt848), "ceb105.PCB" printed on the PCB, TDA9821
Terra TV+ Version 1.1 (Bt878), "LR74 Rev.E" printed on the PCB, TDA9821
Terra TValueRadio, "LR102 Rev.C" printed on the PCB
Terra TV/Radio+ Version 1.0, "80-CP2830100-0" TTTV3 printed on the PCB,
"CPH010-E83" on the back, SAA6588T, TDA9873H
Terra TValue Version BT878, "80-CP2830110-0 TTTV4" printed on the PCB,
"CPH011-D83" on back
Terra TValue Version 1.0 "ceb105.PCB" (really identical to Terra TV+ Version 1.0)
Terra TValue New Revision "LR102 Rec.C"
Terra Active Radio Upgrade (tea5757h, saa6588t)
LR74 is a newer PCB revision of ceb105 (both incl. connector for Active Radio Upgrade)
Cinergy 400 (saa7134), "E877 11(S)", "PM820092D" printed on PCB
Cinergy 600 (saa7134)
Technisat
---------
Discos ADR PC-Karte ISA (no TV!)
Discos ADR PC-Karte PCI (probably no TV?)
Techni-PC-Sat (Sat. analog)
Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A)
Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio)
Mediafocus II (saa7146, Sat. analog)
SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A)
SkyStar 1 DVB (AV7110) = Technotrend Premium
SkyStar 2 DVB (B2C2) (=Sky2PC)
Siemens
-------
Multimedia eXtension Board (MXB) (SAA7146, SAA7111)
Powercolor
----------
MTV878
Package comes with different contents:
a) pcb "MTV878" (CARD=75)
b) Pixelview Rev. 4_
MTV878R w/Remote Control
MTV878F w/Remote Control w/FM radio
Pinnacle
--------
Mirovideo PCTV (Bt848)
Mirovideo PCTV SE (Bt848)
Mirovideo PCTV Pro (Bt848 + Daughterboard for TV Stereo and FM)
Studio PCTV Rave (Bt848 Version = Mirovideo PCTV)
Studio PCTV Rave (Bt878 package w/o infrared)
Studio PCTV (Bt878)
Studio PCTV Pro (Bt878 stereo w/ FM)
Pinnacle PCTV (Bt878, MT2032)
Pinnacle PCTV Pro (Bt878, MT2032)
Pinncale PCTV Sat (bt878a, HM1821/1221) ["Conexant CX24110 with CX24108 tuner, aka HM1221/HM1811"]
Pinnacle PCTV Sat XE
M(J)PEG capture and playback:
DC1+ (ISA)
DC10 (zr36057, zr36060, saa7110, adv7176)
DC10+ (zr36067, zr36060, saa7110, adv7176)
DC20 (ql16x24b,zr36050, zr36016, saa7110, saa7187 ...)
DC30 (zr36057, zr36050, zr36016, vpx3220, adv7176, ad1843, tea6415, miro FST97A1)
DC30+ (zr36067, zr36050, zr36016, vpx3220, adv7176)
DC50 (zr36067, zr36050, zr36016, saa7112, adv7176 (2 pcs.?), ad1843, miro FST97A1, Lattice ???)
Lenco
-----
MXR-9565 (=Technisat Mediafocus?)
MXR-9571 (Bt848) (=CPH031?)
MXR-9575
MXR-9577 (Bt878) (=Prolink 878TV Rev.3x)
MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E)
Iomega
------
Buz (zr36067, zr36060, saa7111, saa7185)
LML
---
LML33 (zr36067, zr36060, bt819, bt856)
Grandtec
--------
Grand Video Capture (Bt848)
Multi Capture Card (Bt878)
Koutech
-------
KW-606 (Bt848)
KW-607 (Bt848 capture only)
KW-606RSF
KW-607A (capture only)
KW-608 (Zoran capture only)
IODATA (jp)
------
GV-BCTV/PCI
GV-BCTV2/PCI
GV-BCTV3/PCI
GV-BCTV4/PCI
GV-VCP/PCI (capture only)
GV-VCP2/PCI (capture only)
Canopus (jp)
-------
WinDVR = Kworld "KW-TVL878RF"
www.sigmacom.co.kr
------------------
Sigma Cyber TV II
www.sasem.co.kr
---------------
Litte OnAir TV
hama
----
TV/Radio-Tuner Card, PCI (Model 44677) = CPH051
Sigma Designs
-------------
Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder
Formac
------
iProTV (Card for iMac Mezzanine slot, Bt848+SCSI)
ProTV (Bt848)
ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono]
ATI
---
TV-Wonder
TV-Wonder VE
Diamond Multimedia
------------------
DTV2000 (Bt848, tda9875)
Aopen
-----
VA1000 Plus (w/ Stereo)
VA1000 Lite
VA1000 (=LR90)
Intel
-----
Smart Video Recorder (ISA full-length)
Smart Video Recorder pro (ISA half-length)
Smart Video Recorder III (Bt848)
STB
---
STB Gateway 6000704 (bt878)
STB Gateway 6000699 (bt848)
STB Gateway 6000402 (bt848)
STB TV130 PCI
Videologic
----------
Captivator Pro/TV (ISA?)
Captivator PCI/VC (Bt848 bundled with camera) (capture only)
Technotrend
------------
TT-SAT PCI (PCB "Sat-PCI Rev.:1.3.1"; zr36125, vpx3225d, stc0056a, Tuner:BSKE6-155A
TT-DVB-Sat
revisions 1.1, 1.3, 1.5, 1.6 and 2.1
This card is sold as OEM from:
Siemens DVB-s Card
Hauppauge WinTV DVB-S
Technisat SkyStar 1 DVB
Galaxis DVB Sat
Now this card is called TT-PCline Premium Family
TT-Budget (saa7146, bsru6-701a)
This card is sold as OEM from:
Hauppauge WinTV Nova
Satelco Standard PCI (DVB-S)
TT-DVB-C PCI
Teles
-----
DVB-s (Rev. 2.2, BSRV2-301A, data only?)
Remote Vision
-------------
MX RV605 (Bt848 capture only)
Boeder
------
PC ChatCam (Model 68252) (Bt848 capture only)
Tv/Fm Capture Card (Model 68404) = PV951
Media-Surfer (esc-kathrein.de)
-------------------------------
Sat-Surfer (ISA)
Sat-Surfer PCI = Techni-PC-Sat
Cable-Surfer 1
Cable-Surfer 2
Cable-Surfer PCI (zr36120)
Audio-Surfer (ISA Radio card)
Jetway (www.jetway.com.tw)
--------------------------
JW-TV 878M
JW-TV 878 = KWorld KW-TV878RF
Galaxis
-------
Galaxis DVB Card S CI
Galaxis DVB Card C CI
Galaxis DVB Card S
Galaxis DVB Card C
Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI
Hauppauge
---------
many many WinTV models ...
WinTV DVBs = Technotrend Premium 1.3
WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA"
WinTV NOVA-CI "SDVBACI"
WinTV Nova USB (=Technotrend USB 1.0)
WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2)
WinTV PVR
WinTV PVR 250
WinTV PVR 450
US models
990 WinTV-PVR-350 (249USD) (iTVC15 chipset + radio)
980 WinTV-PVR-250 (149USD) (iTVC15 chipset)
880 WinTV-PVR-PCI (199USD) (KFIR chipset + bt878)
881 WinTV-PVR-USB
190 WinTV-GO
191 WinTV-GO-FM
404 WinTV
401 WinTV-radio
495 WinTV-Theater
602 WinTV-USB
621 WinTV-USB-FM
600 USB-Live
698 WinTV-HD
697 WinTV-D
564 WinTV-Nexus-S
Deutsche Modelle
603 WinTV GO
719 WinTV Primio-FM
718 WinTV PCI-FM
497 WinTV Theater
569 WinTV USB
568 WinTV USB-FM
882 WinTV PVR
981 WinTV PVR 250
891 WinTV-PVR-USB
541 WinTV Nova
488 WinTV Nova-Ci
564 WinTV-Nexus-s
727 WinTV-DVB-c
545 Common Interface
898 WinTV-Nova-USB
UK models
607 WinTV Go
693,793 WinTV Primio FM
647,747 WinTV PCI FM
498 WinTV Theater
883 WinTV PVR
893 WinTV PVR USB (Duplicate entry)
566 WinTV USB (UK)
573 WinTV USB FM
429 Impact VCB (bt848)
600 USB Live (Video-In 1x Comp, 1xSVHS)
542 WinTV Nova
717 WinTV DVB-S
909 Nova-t PCI
893 Nova-t USB (Duplicate entry)
802 MyTV
804 MyView
809 MyVideo
872 MyTV2Go FM
546 WinTV Nova-S CI
543 WinTV Nova
907 Nova-S USB
908 Nova-T USB
717 WinTV Nexus-S
157 DEC3000-s Standalone + USB
Spain
685 WinTV-Go
690 WinTV-PrimioFM
416 WinTV-PCI Nicam Estereo
677 WinTV-PCI-FM
699 WinTV-Theater
683 WinTV-USB
678 WinTV-USB-FM
983 WinTV-PVR-250
883 WinTV-PVR-PCI
993 WinTV-PVR-350
893 WinTV-PVR-USB
728 WinTV-DVB-C PCI
832 MyTV2Go
869 MyTV2Go-FM
805 MyVideo (USB)
Matrix-Vision
-------------
MATRIX-Vision MV-Delta
MATRIX-Vision MV-Delta 2
MVsigma-SLC (Bt848)
Conceptronic (.net)
------------
TVCON FM, TV card w/ FM = CPH05x
TVCON = CPH06x
BestData
--------
HCC100 = VCC100rev1 + camera
VCC100 rev1 (bt848)
VCC100 rev2 (bt878)
Gallant (www.gallantcom.com) www.minton.com.tw
-----------------------------------------------
Intervision IV-510 (capture only bt8x8)
Intervision IV-550 (bt8x8)
Intervision IV-100 (zoran)
Intervision IV-1000 (bt8x8)
Asonic (www.asonic.com.cn) (website down)
-----------------------------------------
SkyEye tv 878
Hoontech
--------
878TV/FM
Teppro (www.itcteppro.com.tw)
-----------------------------
ITC PCITV (Card Ver 1.0) "Teppro TV1/TVFM1 Card"
ITC PCITV (Card Ver 2.0)
ITC PCITV (Card Ver 3.0) = "PV-BT878P+ (REV.9D)"
ITC PCITV (Card Ver 4.0)
TEPPRO IV-550 (For BT848 Main Chip)
ITC DSTTV (bt878, satellite)
ITC VideoMaker (saa7146, StreamMachine sm2110, tvtuner) "PV-SM2210P+ (REV:1C)"
Kworld (www.kworld.com.tw)
--------------------------
PC TV Station
KWORLD KW-TV878R TV (no radio)
KWORLD KW-TV878RF TV (w/ radio)
KWORLD KW-TVL878RF (low profile)
KWORLD KW-TV713XRF (saa7134)
MPEG TV Station (same cards as above plus WinDVR Software MPEG en/decoder)
KWORLD KW-TV878R -Pro TV (no Radio)
KWORLD KW-TV878RF-Pro TV (w/ Radio)
KWORLD KW-TV878R -Ultra TV (no Radio)
KWORLD KW-TV878RF-Ultra TV (w/ Radio)
JTT/ Justy Corp.(http://www.jtt.ne.jp/)
---------------------------------------------------------------------
JTT-02 (JTT TV) "TV watchmate pro" (bt848)
ADS www.adstech.com
-------------------
Channel Surfer TV ( CHX-950 )
Channel Surfer TV+FM ( CHX-960FM )
AVEC www.prochips.com
---------------------
AVEC Intercapture (bt848, tea6320)
NoBrand
-------
TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_"
Mach www.machspeed.com
----
Mach TV 878
Eline www.eline-net.com/
-----
Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878)
Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x)
Spirit
------
Spirit TV Tuner/Video Capture Card (bt848)
Boser www.boser.com.tw
-----
HS-878 Mini PCI Capture Add-on Card
HS-879 Mini PCI 3D Audio and Capture Add-on Card (w/ ES1938 Solo-1)
Satelco www.citycom-gmbh.de, www.satelco.de
-------
TV-FM =KNC1 saa7134
Standard PCI (DVB-S) = Technotrend Budget
Standard PCI (DVB-S) w/ CI
Satelco Highend PCI (DVB-S) = Technotrend Premium
Sensoray www.sensoray.com
--------
Sensoray 311 (PC/104 bus)
Sensoray 611 (PCI)
CEI (Chartered Electronics Industries Pte Ltd [CEI] [FCC ID HBY])
---
TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips
TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV
Primetime TV (ISA)
acquired by Singapore Technologies
now operating as Chartered Semiconductor Manufacturing
Manufacturer of video cards is listed as:
Cogent Electronics Industries [CEI]
AITech
------
Wavewatcher TV (ISA)
AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878)
WaveWatcher TVR-202 TV/FM Radio Card (ISA)
MAXRON
------
Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK
www.ids-imaging.de
------------------
Falcon Series (capture only)
In USA: http://www.theimagingsource.com/
DFG/LC1
www.sknet-web.co.jp
-------------------
SKnet Monster TV (saa7134)
A-Max www.amaxhk.com (Colormax, Amax, Napa)
-------------------
APAC Viewcomp 878
Cybertainment
-------------
CyberMail AV Video Email Kit w/ PCI Capture Card (capture only)
CyberMail Xtreme
These are Flyvideo
VCR (http://www.vcrinc.com/)
---
Video Catcher 16
Twinhan
-------
DST Card/DST-IP (bt878, twinhan asic) VP-1020
Sold as:
KWorld DVBS Satellite TV-Card
Powercolor DSTV Satellite Tuner Card
Prolink Pixelview DTV2000
Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ?
DST-CI Card (DVB Satellite) VP-1030
DCT Card (DVB cable)
MSI
---
MSI TV@nywhere Tuner Card (MS-8876) (CX23881/883) Not Bt878 compatible.
MS-8401 DVB-S
Focus www.focusinfo.com
-----
InVideo PCI (bt878)
Sdisilk www.sdisilk.com/
-------
SDI Silk 100
SDI Silk 200 SDI Input Card
www.euresys.com
PICOLO series
PMC/Pace
www.pacecom.co.uk website closed
Mercury www.kobian.com (UK and FR)
LR50
LR138RBG-Rx == LR138
TEC sound (package and manuals don't have any other manufacturer info) TecSound
Though educated googling found: www.techmakers.com
TV-Mate = Zoltrix VP-8482
Lorenzen www.lorenzen.de
--------
SL DVB-S PCI = Technotrend Budget PCI (su1278 or bsru version)
Origo (.uk) www.origo2000.com
PC TV Card = LR50
I/O Magic www.iomagic.com
---------
PC PVR - Desktop TV Personal Video Recorder DR-PCTV100 = Pinnacle ROB2D-51009464 4.0 + Cyberlink PowerVCR II
Arowana
-------
TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?)
iTVC15 boards:
-------------
kuroutoshikou.com ITVC15
yuan.com MPG160 PCI TV (Internal PCI MPEG2 encoder card plus TV-tuner)
Asus www.asuscom.com
Asus TV Tuner Card 880 NTSC (low profile, cx23880)
Asus TV (saa7134)
Hoontech
--------
http://www.hoontech.de/
HART Vision 848 (H-ART Vision 848)
HART Vision 878 (H-Art Vision 878)

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?

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

@@ -0,0 +1,172 @@
Note: "modinfo <module>" prints various information about a kernel
module, among them a complete and up-to-date list of insmod options.
This list tends to be outdated because it is updated manually ...
==========================================================================
bttv.o
the bt848/878 (grabber chip) driver
insmod args:
card=n card type, see CARDLIST for a list.
tuner=n tuner type, see CARDLIST for a list.
radio=0/1 card supports radio
pll=0/1/2 pll settings
0: don't use PLL
1: 28 MHz crystal installed
2: 35 MHz crystal installed
triton1=0/1 for Triton1 (+others) compatibility
vsfx=0/1 yet another chipset bug compatibility bit
see README.quirks for details on these two.
bigendian=n Set the endianness of the gfx framebuffer.
Default is native endian.
fieldnr=0/1 Count fields. Some TV descrambling software
needs this, for others it only generates
50 useless IRQs/sec. default is 0 (off).
autoload=0/1 autoload helper modules (tuner, audio).
default is 1 (on).
bttv_verbose=0/1/2 verbose level (at insmod time, while
looking at the hardware). default is 1.
bttv_debug=0/1 debug messages (for capture).
default is 0 (off).
irq_debug=0/1 irq handler debug messages.
default is 0 (off).
gbuffers=2-32 number of capture buffers for mmap'ed capture.
default is 4.
gbufsize= size of capture buffers. default and
maximum value is 0x208000 (~2MB)
no_overlay=0 Enable overlay on broken hardware. There
are some chipsets (SIS for example) which
are known to have problems with the PCI DMA
push used by bttv. bttv will disable overlay
by default on this hardware to avoid crashes.
With this insmod option you can override this.
no_overlay=1 Disable overlay. It should be used by broken
hardware that doesn't support PCI2PCI direct
transfers.
automute=0/1 Automatically mutes the sound if there is
no TV signal, on by default. You might try
to disable this if you have bad input signal
quality which leading to unwanted sound
dropouts.
chroma_agc=0/1 AGC of chroma signal, off by default.
adc_crush=0/1 Luminance ADC crush, on by default.
i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
(meaning 66,67 Kbps). The default is the
maximum supported speed by kernel bitbang
algorithm. You may use lower numbers, if I2C
messages are lost (16 is known to work on
all supported cards).
bttv_gpio=0/1
gpiomask=
audioall=
audiomux=
See Sound-FAQ for a detailed description.
remap, card, radio and pll accept up to four comma-separated arguments
(for multiple boards).
tuner.o
The tuner driver. You need this unless you want to use only
with a camera or external tuner ...
insmod args:
debug=1 print some debug info to the syslog
type=n type of the tuner chip. n as follows:
see CARDLIST for a complete list.
pal=[bdgil] select PAL variant (used for some tuners
only, important for the audio carrier).
tvaudio.o
new, experimental module which is supported to provide a single
driver for all simple i2c audio control chips (tda/tea*).
insmod args:
tda8425 = 1 enable/disable the support for the
tda9840 = 1 various chips.
tda9850 = 1 The tea6300 can't be autodetected and is
tda9855 = 1 therefore off by default, if you have
tda9873 = 1 this one on your card (STB uses these)
tda9874a = 1 you have to enable it explicitly.
tea6300 = 0 The two tda985x chips use the same i2c
tea6420 = 1 address and can't be disturgished from
pic16c54 = 1 each other, you might have to disable
the wrong one.
debug = 1 print debug messages
insmod args for tda9874a:
tda9874a_SIF=1/2 select sound IF input pin (1 or 2)
(default is pin 1)
tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0)
Please read note 3 below!
tda9874a_STD=n select TV sound standard (0..8):
0 - A2, B/G
1 - A2, M (Korea)
2 - A2, D/K (1)
3 - A2, D/K (2)
4 - A2, D/K (3)
5 - NICAM, I
6 - NICAM, B/G
7 - NICAM, D/K (default)
8 - NICAM, L
Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips.
Note 2: tda9874h/a and tda9875 (which is supported separately by
tda9875.o) use the same i2c address so both modules should not be
used at the same time.
Note 3: Using tda9874a_AMSEL option depends on your TV card design!
AMSEL=0: auto-mute will switch between NICAM sound
and the sound on 1st carrier (i.e. FM mono or AM).
AMSEL=1: auto-mute will switch between NICAM sound
and the analog mono input (MONOIN pin).
If tda9874a decoder on your card has MONOIN pin not connected, then
use only tda9874_AMSEL=0 or don't specify this option at all.
For example:
card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0
card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only
msp3400.o
The driver for the msp34xx sound processor chips. If you have a
stereo card, you probably want to insmod this one.
insmod args:
debug=1/2 print some debug info to the syslog,
2 is more verbose.
simple=1 Use the "short programming" method. Newer
msp34xx versions support this. You need this
for dbx stereo. Default is on if supported by
the chip.
once=1 Don't check the TV-stations Audio mode
every few seconds, but only once after
channel switches.
amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This
should improve things for french people, the
carrier autoscan seems to work with FM only...
tea6300.o - OBSOLETE (use tvaudio instead)
The driver for the tea6300 fader chip. If you have a stereo
card and the msp3400.o doesn't work, you might want to try this
one. This chip is seen on most STB TV/FM cards (usually from
Gateway OEM sold surplus on auction sites).
insmod args:
debug=1 print some debug info to the syslog.
tda8425.o - OBSOLETE (use tvaudio instead)
The driver for the tda8425 fader chip. This driver used to be
part of bttv.c, so if your sound used to work but does not
anymore, try loading this module.
insmod args:
debug=1 print some debug info to the syslog.
tda985x.o - OBSOLETE (use tvaudio instead)
The driver for the tda9850/55 audio chips.
insmod args:
debug=1 print some debug info to the syslog.
chip=9850/9855 set the chip type.

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

@@ -0,0 +1,27 @@
#!/bin/bash
function makedev () {
for dev in 0 1 2 3; do
echo "/dev/$1$dev: char 81 $[ $2 + $dev ]"
rm -f /dev/$1$dev
mknod /dev/$1$dev c 81 $[ $2 + $dev ]
chmod 666 /dev/$1$dev
done
# symlink for default device
rm -f /dev/$1
ln -s /dev/${1}0 /dev/$1
}
# see http://linux.bytesex.org/v4l2/API.html
echo "*** new device names ***"
makedev video 0
makedev radio 64
makedev vbi 224
#echo "*** old device names (for compatibility only) ***"
#makedev bttv 0
#makedev bttv-fm 64
#makedev bttv-vbi 224

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.d/*.conf
# For for 2.4 kernels or earlier, this belongs in /etc/modules.conf.
# i2c
alias char-major-89 i2c-dev
options i2c-core i2c_debug=1
options i2c-algo-bit bit_test=1
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=2 radio=1
options tuner debug=1

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: linux-media@vger.kernel.org
http://vger.kernel.org/vger-lists.html#linux-media
If you have trouble with some specific TV card, try to ask there
instead of mailing me directly. The chance that someone with the
same card listens there is much higher...
For problems with sound: There are a lot of different systems used
for TV sound all over the world. And there are also different chips
which decode the audio signal. Reports about sound problems ("stereo
does'nt work") are pretty useless unless you include some details
about your hardware and the TV sound scheme used in your country (or
at least the country you are living in).
Finally: If you mail some patches for bttv around the world (to
linux-kernel/Alan/Linus/...), please Cc: me.
Have fun with bttv,
Gerd
--
Gerd Knorr <kraxel@bytesex.org>

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 a lot of
other people. But in case you have problems with the 0.7.x versions you
can give 0.8.x a try ...
hardware bugs
-------------
Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga).
Sometimes problems show up with bttv just because of the high load on
the PCI bus. The bt848/878 chips have a few workarounds for known
incompatibilities, see README.quirks.
Some folks report that increasing the pci latency helps too,
althrought I'm not sure whenever this really fixes the problems or
only makes it less likely to happen. Both bttv and btaudio have a
insmod option to set the PCI latency of the device.
Some mainboard have problems to deal correctly with multiple devices
doing DMA at the same time. bttv + ide seems to cause this sometimes,
if this is the case you likely see freezes only with video and hard disk
access at the same time. Updating the IDE driver to get the latest and
greatest workarounds for hardware bugs might fix these problems.
other
-----
If you use some binary-only yunk (like nvidia module) try to reproduce
the problem without.
IRQ sharing is known to cause problems in some cases. It works just
fine in theory and many configurations. Neverless it might be worth a
try to shuffle around the PCI cards to give bttv another IRQ or make
it share the IRQ with some other piece of hardware. IRQ sharing with
VGA cards seems to cause trouble sometimes. I've also seen funny
effects with bttv sharing the IRQ with the ACPI bridge (and
apci-enabled kernel).

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 a lot of different bt848/849/878/879 based boards available.
Making video work often is not a big deal, because this is handled
completely by the bt8xx chip, which is common on all boards. But
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
bttv-cards.c, which holds the information required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one:
bttv0: model: BT848(Hauppauge old) [autodetected]
You should verify this is correct. If it isn't, you have to pass the
correct board type as insmod argument, "insmod bttv card=2" for
example. The file CARDLIST has a list of valid arguments for card.
If your card isn't listed there, you might check the source code for
new entries which are not listed yet. If there isn't one for your
card, you can check if one of the existing entries does work for you
(just trial and error...).
Some boards have an extra processor for sound to do stereo decoding
and other nice features. The msp34xx chips are used by Hauppauge for
example. If your board has one, you might have to load a helper
module like msp3400.o to make sound work. If there isn't one for the
chip used on your board: Bad luck. Start writing a new one. Well,
you might want to check the video4linux mailing list archive first...
Of course you need a correctly installed soundcard unless you have the
speakers connected directly to the grabber board. Hint: check the
mixer settings too. ALSA for example has everything muted by default.
How sound works in detail
=========================
Still doesn't work? Looks like some driver hacking is required.
Below is a do-it-yourself description for you.
The bt8xx chips have 32 general purpose pins, and registers to control
these pins. One register is the output enable register
(BT848_GPIO_OUT_EN), it says which pins are actively driven by the
bt848 chip. Another one is the data register (BT848_GPIO_DATA), where
you can get/set the status if these pins. They can be used for input
and output.
Most grabber board vendors use these pins to control an external chip
which does the sound routing. But every board is a little different.
These pins are also used by some companies to drive remote control
receiver chips. Some boards use the i2c bus instead of the gpio pins
to connect the mux chip.
As mentioned above, there is a array which holds the required
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 support is available from
http://btwincap.sourceforge.net/Files/btspy2.00.zip
You might also dig around in the *.ini files of the Windows applications.
You can have a look at the board to see which of the gpio pins are
connected at all and then start trial-and-error ...
Starting with release 0.7.41 bttv has a number of insmod options to
make the gpio debugging easier:
bttv_gpio=0/1 enable/disable gpio debug messages
gpiomask=n set the gpiomask value
audiomux=i,j,... set the values of the audiomux array
audioall=a set the values of the audiomux array (one
value for all array elements, useful to check
out which effect the particular value has).
The messages printed with bttv_gpio=1 look like this:
bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
en = output _en_able register (BT848_GPIO_OUT_EN)
out = _out_put bits of the data register (BT848_GPIO_DATA),
i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
in = _in_put bits of the data register,
i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
Other elements of the tvcards array
===================================
If you are trying to make a new card work you might find it useful to
know what the other elements in the tvcards array are good for:
video_inputs - # of video inputs the card has
audio_inputs - historical cruft, not used any more.
tuner - which input is the tuner
svhs - which input is svhs (all others are labeled composite)
muxsel - video mux, input->registervalue mapping
pll - same as pll= insmod option
tuner_type - same as tuner= insmod option
*_modulename - hint whenever some card needs this or that audio
module loaded to work properly.
has_radio - whenever this TV card has a radio tuner.
no_msp34xx - "1" disables loading of msp3400.o module
no_tda9875 - "1" disables loading of tda9875.o module
needs_tvaudio - set to "1" to load tvaudio.o module
If some config item is specified both from the tvcards array and as
insmod option, the insmod option takes precedence.
Good luck,
Gerd
PS: If you have a new working entry, mail it to me.
--
Gerd Knorr <kraxel@bytesex.org>

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

@@ -0,0 +1,3 @@
Philips http://www.Semiconductors.COM/pip/
Conexant http://www.conexant.com/
Micronas http://www.micronas.com/en/home/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.

30
Documentation/video4linux/cx18.txt Normal file
View File

@@ -0,0 +1,30 @@
Some notes regarding the cx18 driver for the Conexant CX23418 MPEG
encoder chip:
1) Currently supported are:
- Hauppauge HVR-1600
- Compro VideoMate H900
- Yuan MPC718
- Conexant Raptor PAL/SECAM devkit
2) Some people have problems getting the i2c bus to work.
The symptom is that the eeprom cannot be read and the card is
unusable. This is probably fixed, but if you have problems
then post to the video4linux or ivtv-users mailing list.
3) VBI (raw or sliced) has not yet been implemented.
4) MPEG indexing is not yet implemented.
5) The driver is still a bit rough around the edges, this should
improve over time.
Firmware:
You can obtain the firmware files here:
http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz
Untar and copy the .fw files to your firmware directory.

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

@@ -0,0 +1,120 @@
The cx23416 can produce (and the cx23415 can also read) raw YUV output. The
format of a YUV frame is specific to this chip and is called HM12. 'HM' stands
for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would
be more accurate.
The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per
four pixels.
The data is encoded as two macroblock planes, the first containing the Y
values, the second containing UV macroblocks.
The Y plane is divided into blocks of 16x16 pixels from left to right
and from top to bottom. Each block is transmitted in turn, line-by-line.
So the first 16 bytes are the first line of the top-left block, the
second 16 bytes are the second line of the top-left block, etc. After
transmitting this block the first line of the block on the right to the
first block is transmitted, etc.
The UV plane is divided into blocks of 16x8 UV values going from left
to right, top to bottom. Each block is transmitted in turn, line-by-line.
So the first 16 bytes are the first line of the top-left block and
contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the
second line of 8 UV pairs of the top-left block, etc. After transmitting
this block the first line of the block on the right to the first block is
transmitted, etc.
The code below is given as an example on how to convert HM12 to separate
Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
The width of a frame is always 720 pixels, regardless of the actual specified
width.
If the height is not a multiple of 32 lines, then the captured video is
missing macroblocks at the end and is unusable. So the height must be a
multiple of 32.
--------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static unsigned char frame[576*720*3/2];
static unsigned char framey[576*720];
static unsigned char frameu[576*720 / 4];
static unsigned char framev[576*720 / 4];
static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h)
{
unsigned int y, x, i;
// descramble Y plane
// dstride = 720 = w
// The Y plane is divided into blocks of 16x16 pixels
// Each block in transmitted in turn, line-by-line.
for (y = 0; y < h; y += 16) {
for (x = 0; x < w; x += 16) {
for (i = 0; i < 16; i++) {
memcpy(dst + x + (y + i) * dstride, src, 16);
src += 16;
}
}
}
}
static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h)
{
unsigned int y, x, i;
// descramble U/V plane
// dstride = 720 / 2 = w
// The U/V values are interlaced (UVUV...).
// Again, the UV plane is divided into blocks of 16x16 UV values.
// Each block in transmitted in turn, line-by-line.
for (y = 0; y < h; y += 16) {
for (x = 0; x < w; x += 8) {
for (i = 0; i < 16; i++) {
int idx = x + (y + i) * dstride;
dstu[idx+0] = src[0]; dstv[idx+0] = src[1];
dstu[idx+1] = src[2]; dstv[idx+1] = src[3];
dstu[idx+2] = src[4]; dstv[idx+2] = src[5];
dstu[idx+3] = src[6]; dstv[idx+3] = src[7];
dstu[idx+4] = src[8]; dstv[idx+4] = src[9];
dstu[idx+5] = src[10]; dstv[idx+5] = src[11];
dstu[idx+6] = src[12]; dstv[idx+6] = src[13];
dstu[idx+7] = src[14]; dstv[idx+7] = src[15];
src += 16;
}
}
}
}
/*************************************************************************/
int main(int argc, char **argv)
{
FILE *fin;
int i;
if (argc == 1) fin = stdin;
else fin = fopen(argv[1], "r");
if (fin == NULL) {
fprintf(stderr, "cannot open input\n");
exit(-1);
}
while (fread(frame, sizeof(frame), 1, fin) == 1) {
de_macro_y(framey, frame, 720, 720, 576);
de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2);
fwrite(framey, sizeof(framey), 1, stdout);
fwrite(framev, sizeof(framev), 1, stdout);
fwrite(frameu, sizeof(frameu), 1, stdout);
}
fclose(fin);
return 0;
}
--------------------------------------------------------------------------

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

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

@@ -0,0 +1,817 @@
PVR350 Video decoder registers 0x02002800 -> 0x02002B00
=======================================================
This list has been worked out through trial and error. There will be mistakes
and omissions. Some registers have no obvious effect so it's hard to say what
they do, while others interact with each other, or require a certain load
sequence. Horizontal filter setup is one example, with six registers working
in unison and requiring a certain load sequence to correctly configure. The
indexed colour palette is much easier to set at just two registers, but again
it requires a certain load sequence.
Some registers are fussy about what they are set to. Load in a bad value & the
decoder will fail. A firmware reload will often recover, but sometimes a reset
is required. For registers containing size information, setting them to 0 is
generally a bad idea. For other control registers i.e. 2878, you'll only find
out what values are bad when it hangs.
--------------------------------------------------------------------------------
2800
bit 0
Decoder enable
0 = disable
1 = enable
--------------------------------------------------------------------------------
2804
bits 0:31
Decoder horizontal Y alias register 1
---------------
2808
bits 0:31
Decoder horizontal Y alias register 2
---------------
280C
bits 0:31
Decoder horizontal Y alias register 3
---------------
2810
bits 0:31
Decoder horizontal Y alias register 4
---------------
2814
bits 0:31
Decoder horizontal Y alias register 5
---------------
2818
bits 0:31
Decoder horizontal Y alias trigger
These six registers control the horizontal aliasing filter for the Y plane.
The first five registers must all be loaded before accessing the trigger
(2818), as this register actually clocks the data through for the first
five.
To correctly program set the filter, this whole procedure must be done 16
times. The actual register contents are copied from a lookup-table in the
firmware which contains 4 different filter settings.
--------------------------------------------------------------------------------
281C
bits 0:31
Decoder horizontal UV alias register 1
---------------
2820
bits 0:31
Decoder horizontal UV alias register 2
---------------
2824
bits 0:31
Decoder horizontal UV alias register 3
---------------
2828
bits 0:31
Decoder horizontal UV alias register 4
---------------
282C
bits 0:31
Decoder horizontal UV alias register 5
---------------
2830
bits 0:31
Decoder horizontal UV alias trigger
These six registers control the horizontal aliasing for the UV plane.
Operation is the same as the Y filter, with 2830 being the trigger
register.
--------------------------------------------------------------------------------
2834
bits 0:15
Decoder Y source width in pixels
bits 16:31
Decoder Y destination width in pixels
---------------
2838
bits 0:15
Decoder UV source width in pixels
bits 16:31
Decoder UV destination width in pixels
NOTE: For both registers, the resulting image must be fully visible on
screen. If the image exceeds the right edge both the source and destination
size must be adjusted to reflect the visible portion. For the source width,
you must take into account the scaling when calculating the new value.
--------------------------------------------------------------------------------
283C
bits 0:31
Decoder Y horizontal scaling
Normally = Reg 2854 >> 2
---------------
2840
bits 0:31
Decoder ?? unknown - horizontal scaling
Usually 0x00080514
---------------
2844
bits 0:31
Decoder UV horizontal scaling
Normally = Reg 2854 >> 2
---------------
2848
bits 0:31
Decoder ?? unknown - horizontal scaling
Usually 0x00100514
---------------
284C
bits 0:31
Decoder ?? unknown - Y plane
Usually 0x00200020
---------------
2850
bits 0:31
Decoder ?? unknown - UV plane
Usually 0x00200020
---------------
2854
bits 0:31
Decoder 'master' value for horizontal scaling
---------------
2858
bits 0:31
Decoder ?? unknown
Usually 0
---------------
285C
bits 0:31
Decoder ?? unknown
Normally = Reg 2854 >> 1
---------------
2860
bits 0:31
Decoder ?? unknown
Usually 0
---------------
2864
bits 0:31
Decoder ?? unknown
Normally = Reg 2854 >> 1
---------------
2868
bits 0:31
Decoder ?? unknown
Usually 0
Most of these registers either control horizontal scaling, or appear linked
to it in some way. Register 2854 contains the 'master' value & the other
registers can be calculated from that one. You must also remember to
correctly set the divider in Reg 2874.
To enlarge:
Reg 2854 = (source_width * 0x00200000) / destination_width
Reg 2874 = No divide
To reduce from full size down to half size:
Reg 2854 = (source_width/2 * 0x00200000) / destination width
Reg 2874 = Divide by 2
To reduce from half size down to quarter size:
Reg 2854 = (source_width/4 * 0x00200000) / destination width
Reg 2874 = Divide by 4
The result is always rounded up.
--------------------------------------------------------------------------------
286C
bits 0:15
Decoder horizontal Y buffer offset
bits 15:31
Decoder horizontal UV buffer offset
Offset into the video image buffer. If the offset is gradually incremented,
the on screen image will move left & wrap around higher up on the right.
--------------------------------------------------------------------------------
2870
bits 0:15
Decoder horizontal Y output offset
bits 16:31
Decoder horizontal UV output offset
Offsets the actual video output. Controls output alignment of the Y & UV
planes. The higher the value, the greater the shift to the left. Use
reg 2890 to move the image right.
--------------------------------------------------------------------------------
2874
bits 0:1
Decoder horizontal Y output size divider
00 = No divide
01 = Divide by 2
10 = Divide by 3
bits 4:5
Decoder horizontal UV output size divider
00 = No divide
01 = Divide by 2
10 = Divide by 3
bit 8
Decoder ?? unknown
0 = Normal
1 = Affects video output levels
bit 16
Decoder ?? unknown
0 = Normal
1 = Disable horizontal filter
--------------------------------------------------------------------------------
2878
bit 0
?? unknown
bit 1
osd on/off
0 = osd off
1 = osd on
bit 2
Decoder + osd video timing
0 = NTSC
1 = PAL
bits 3:4
?? unknown
bit 5
Decoder + osd
Swaps upper & lower fields
--------------------------------------------------------------------------------
287C
bits 0:10
Decoder & osd ?? unknown
Moves entire screen horizontally. Starts at 0x005 with the screen
shifted heavily to the right. Incrementing in steps of 0x004 will
gradually shift the screen to the left.
bits 11:31
?? unknown
Normally contents are 0x00101111 (NTSC) or 0x1010111d (PAL)
--------------------------------------------------------------------------------
2880 -------- ?? unknown
2884 -------- ?? unknown
--------------------------------------------------------------------------------
2888
bit 0
Decoder + osd ?? unknown
0 = Normal
1 = Misaligned fields (Correctable through 289C & 28A4)
bit 4
?? unknown
bit 8
?? unknown
Warning: Bad values will require a firmware reload to recover.
Known to be bad are 0x000,0x011,0x100,0x111
--------------------------------------------------------------------------------
288C
bits 0:15
osd ?? unknown
Appears to affect the osd position stability. The higher the value the
more unstable it becomes. Decoder output remains stable.
bits 16:31
osd ?? unknown
Same as bits 0:15
--------------------------------------------------------------------------------
2890
bits 0:11
Decoder output horizontal offset.
Horizontal offset moves the video image right. A small left shift is
possible, but it's better to use reg 2870 for that due to its greater
range.
NOTE: Video corruption will occur if video window is shifted off the right
edge. To avoid this read the notes for 2834 & 2838.
--------------------------------------------------------------------------------
2894
bits 0:23
Decoder output video surround colour.
Contains the colour (in yuv) used to fill the screen when the video is
running in a window.
--------------------------------------------------------------------------------
2898
bits 0:23
Decoder video window colour
Contains the colour (in yuv) used to fill the video window when the
video is turned off.
bit 24
Decoder video output
0 = Video on
1 = Video off
bit 28
Decoder plane order
0 = Y,UV
1 = UV,Y
bit 29
Decoder second plane byte order
0 = Normal (UV)
1 = Swapped (VU)
In normal usage, the first plane is Y & the second plane is UV. Though the
order of the planes can be swapped, only the byte order of the second plane
can be swapped. This isn't much use for the Y plane, but can be useful for
the UV plane.
--------------------------------------------------------------------------------
289C
bits 0:15
Decoder vertical field offset 1
bits 16:31
Decoder vertical field offset 2
Controls field output vertical alignment. The higher the number, the lower
the image on screen. Known starting values are 0x011E0017 (NTSC) &
0x01500017 (PAL)
--------------------------------------------------------------------------------
28A0
bits 0:15
Decoder & osd width in pixels
bits 16:31
Decoder & osd height in pixels
All output from the decoder & osd are disabled beyond this area. Decoder
output will simply go black outside of this region. If the osd tries to
exceed this area it will become corrupt.
--------------------------------------------------------------------------------
28A4
bits 0:11
osd left shift.
Has a range of 0x770->0x7FF. With the exception of 0, any value outside of
this range corrupts the osd.
--------------------------------------------------------------------------------
28A8
bits 0:15
osd vertical field offset 1
bits 16:31
osd vertical field offset 2
Controls field output vertical alignment. The higher the number, the lower
the image on screen. Known starting values are 0x011E0017 (NTSC) &
0x01500017 (PAL)
--------------------------------------------------------------------------------
28AC -------- ?? unknown
|
V
28BC -------- ?? unknown
--------------------------------------------------------------------------------
28C0
bit 0
Current output field
0 = first field
1 = second field
bits 16:31
Current scanline
The scanline counts from the top line of the first field
through to the last line of the second field.
--------------------------------------------------------------------------------
28C4 -------- ?? unknown
|
V
28F8 -------- ?? unknown
--------------------------------------------------------------------------------
28FC
bit 0
?? unknown
0 = Normal
1 = Breaks decoder & osd output
--------------------------------------------------------------------------------
2900
bits 0:31
Decoder vertical Y alias register 1
---------------
2904
bits 0:31
Decoder vertical Y alias register 2
---------------
2908
bits 0:31
Decoder vertical Y alias trigger
These three registers control the vertical aliasing filter for the Y plane.
Operation is similar to the horizontal Y filter (2804). The only real
difference is that there are only two registers to set before accessing
the trigger register (2908). As for the horizontal filter, the values are
taken from a lookup table in the firmware, and the procedure must be
repeated 16 times to fully program the filter.
--------------------------------------------------------------------------------
290C
bits 0:31
Decoder vertical UV alias register 1
---------------
2910
bits 0:31
Decoder vertical UV alias register 2
---------------
2914
bits 0:31
Decoder vertical UV alias trigger
These three registers control the vertical aliasing filter for the UV
plane. Operation is the same as the Y filter, with 2914 being the trigger.
--------------------------------------------------------------------------------
2918
bits 0:15
Decoder Y source height in pixels
bits 16:31
Decoder Y destination height in pixels
---------------
291C
bits 0:15
Decoder UV source height in pixels divided by 2
bits 16:31
Decoder UV destination height in pixels
NOTE: For both registers, the resulting image must be fully visible on
screen. If the image exceeds the bottom edge both the source and
destination size must be adjusted to reflect the visible portion. For the
source height, you must take into account the scaling when calculating the
new value.
--------------------------------------------------------------------------------
2920
bits 0:31
Decoder Y vertical scaling
Normally = Reg 2930 >> 2
---------------
2924
bits 0:31
Decoder Y vertical scaling
Normally = Reg 2920 + 0x514
---------------
2928
bits 0:31
Decoder UV vertical scaling
When enlarging = Reg 2930 >> 2
When reducing = Reg 2930 >> 3
---------------
292C
bits 0:31
Decoder UV vertical scaling
Normally = Reg 2928 + 0x514
---------------
2930
bits 0:31
Decoder 'master' value for vertical scaling
---------------
2934
bits 0:31
Decoder ?? unknown - Y vertical scaling
---------------
2938
bits 0:31
Decoder Y vertical scaling
Normally = Reg 2930
---------------
293C
bits 0:31
Decoder ?? unknown - Y vertical scaling
---------------
2940
bits 0:31
Decoder UV vertical scaling
When enlarging = Reg 2930 >> 1
When reducing = Reg 2930
---------------
2944
bits 0:31
Decoder ?? unknown - UV vertical scaling
---------------
2948
bits 0:31
Decoder UV vertical scaling
Normally = Reg 2940
---------------
294C
bits 0:31
Decoder ?? unknown - UV vertical scaling
Most of these registers either control vertical scaling, or appear linked
to it in some way. Register 2930 contains the 'master' value & all other
registers can be calculated from that one. You must also remember to
correctly set the divider in Reg 296C
To enlarge:
Reg 2930 = (source_height * 0x00200000) / destination_height
Reg 296C = No divide
To reduce from full size down to half size:
Reg 2930 = (source_height/2 * 0x00200000) / destination height
Reg 296C = Divide by 2
To reduce from half down to quarter.
Reg 2930 = (source_height/4 * 0x00200000) / destination height
Reg 296C = Divide by 4
--------------------------------------------------------------------------------
2950
bits 0:15
Decoder Y line index into display buffer, first field
bits 16:31
Decoder Y vertical line skip, first field
--------------------------------------------------------------------------------
2954
bits 0:15
Decoder Y line index into display buffer, second field
bits 16:31
Decoder Y vertical line skip, second field
--------------------------------------------------------------------------------
2958
bits 0:15
Decoder UV line index into display buffer, first field
bits 16:31
Decoder UV vertical line skip, first field
--------------------------------------------------------------------------------
295C
bits 0:15
Decoder UV line index into display buffer, second field
bits 16:31
Decoder UV vertical line skip, second field
--------------------------------------------------------------------------------
2960
bits 0:15
Decoder destination height minus 1
bits 16:31
Decoder destination height divided by 2
--------------------------------------------------------------------------------
2964
bits 0:15
Decoder Y vertical offset, second field
bits 16:31
Decoder Y vertical offset, first field
These two registers shift the Y plane up. The higher the number, the
greater the shift.
--------------------------------------------------------------------------------
2968
bits 0:15
Decoder UV vertical offset, second field
bits 16:31
Decoder UV vertical offset, first field
These two registers shift the UV plane up. The higher the number, the
greater the shift.
--------------------------------------------------------------------------------
296C
bits 0:1
Decoder vertical Y output size divider
00 = No divide
01 = Divide by 2
10 = Divide by 4
bits 8:9
Decoder vertical UV output size divider
00 = No divide
01 = Divide by 2
10 = Divide by 4
--------------------------------------------------------------------------------
2970
bit 0
Decoder ?? unknown
0 = Normal
1 = Affect video output levels
bit 16
Decoder ?? unknown
0 = Normal
1 = Disable vertical filter
--------------------------------------------------------------------------------
2974 -------- ?? unknown
|
V
29EF -------- ?? unknown
--------------------------------------------------------------------------------
2A00
bits 0:2
osd colour mode
000 = 8 bit indexed
001 = 16 bit (565)
010 = 15 bit (555)
011 = 12 bit (444)
100 = 32 bit (8888)
bits 4:5
osd display bpp
01 = 8 bit
10 = 16 bit
11 = 32 bit
bit 8
osd global alpha
0 = Off
1 = On
bit 9
osd local alpha
0 = Off
1 = On
bit 10
osd colour key
0 = Off
1 = On
bit 11
osd ?? unknown
Must be 1
bit 13
osd colour space
0 = ARGB
1 = AYVU
bits 16:31
osd ?? unknown
Must be 0x001B (some kind of buffer pointer ?)
When the bits-per-pixel is set to 8, the colour mode is ignored and
assumed to be 8 bit indexed. For 16 & 32 bits-per-pixel the colour depth
is honoured, and when using a colour depth that requires fewer bytes than
allocated the extra bytes are used as padding. So for a 32 bpp with 8 bit
index colour, there are 3 padding bytes per pixel. It's also possible to
select 16bpp with a 32 bit colour mode. This results in the pixel width
being doubled, but the color key will not work as expected in this mode.
Colour key is as it suggests. You designate a colour which will become
completely transparent. When using 565, 555 or 444 colour modes, the
colour key is always 16 bits wide. The colour to key on is set in Reg 2A18.
Local alpha works differently depending on the colour mode. For 32bpp & 8
bit indexed, local alpha is a per-pixel 256 step transparency, with 0 being
transparent and 255 being solid. For the 16bpp modes 555 & 444, the unused
bit(s) act as a simple transparency switch, with 0 being solid & 1 being
fully transparent. There is no local alpha support for 16bit 565.
Global alpha is a 256 step transparency that applies to the entire osd,
with 0 being transparent & 255 being solid.
It's possible to combine colour key, local alpha & global alpha.
--------------------------------------------------------------------------------
2A04
bits 0:15
osd x coord for left edge
bits 16:31
osd y coord for top edge
---------------
2A08
bits 0:15
osd x coord for right edge
bits 16:31
osd y coord for bottom edge
For both registers, (0,0) = top left corner of the display area. These
registers do not control the osd size, only where it's positioned & how
much is visible. The visible osd area cannot exceed the right edge of the
display, otherwise the osd will become corrupt. See reg 2A10 for
setting osd width.
--------------------------------------------------------------------------------
2A0C
bits 0:31
osd buffer index
An index into the osd buffer. Slowly incrementing this moves the osd left,
wrapping around onto the right edge
--------------------------------------------------------------------------------
2A10
bits 0:11
osd buffer 32 bit word width
Contains the width of the osd measured in 32 bit words. This means that all
colour modes are restricted to a byte width which is divisible by 4.
--------------------------------------------------------------------------------
2A14
bits 0:15
osd height in pixels
bits 16:32
osd line index into buffer
osd will start displaying from this line.
--------------------------------------------------------------------------------
2A18
bits 0:31
osd colour key
Contains the colour value which will be transparent.
--------------------------------------------------------------------------------
2A1C
bits 0:7
osd global alpha
Contains the global alpha value (equiv ivtvfbctl --alpha XX)
--------------------------------------------------------------------------------
2A20 -------- ?? unknown
|
V
2A2C -------- ?? unknown
--------------------------------------------------------------------------------
2A30
bits 0:7
osd colour to change in indexed palette
---------------
2A34
bits 0:31
osd colour for indexed palette
To set the new palette, first load the index of the colour to change into
2A30, then load the new colour into 2A34. The full palette is 256 colours,
so the index range is 0x00-0xFF
--------------------------------------------------------------------------------
2A38 -------- ?? unknown
2A3C -------- ?? unknown
--------------------------------------------------------------------------------
2A40
bits 0:31
osd ?? unknown
Affects overall brightness, wrapping around to black
--------------------------------------------------------------------------------
2A44
bits 0:31
osd ?? unknown
Green tint
--------------------------------------------------------------------------------
2A48
bits 0:31
osd ?? unknown
Red tint
--------------------------------------------------------------------------------
2A4C
bits 0:31
osd ?? unknown
Affects overall brightness, wrapping around to black
--------------------------------------------------------------------------------
2A50
bits 0:31
osd ?? unknown
Colour shift
--------------------------------------------------------------------------------
2A54
bits 0:31
osd ?? unknown
Colour shift
--------------------------------------------------------------------------------
2A58 -------- ?? unknown
|
V
2AFC -------- ?? unknown
--------------------------------------------------------------------------------
2B00
bit 0
osd filter control
0 = filter off
1 = filter on
bits 1:4
osd ?? unknown
--------------------------------------------------------------------------------
v0.4 - 12 March 2007 - Ian Armstrong (ian@iarmst.demon.co.uk)

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

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

@@ -0,0 +1,709 @@
Encoder firmware API description
================================
-------------------------------------------------------------------------------
Name CX2341X_ENC_PING_FW
Enum 128/0x80
Description
Does nothing. Can be used to check if the firmware is responding.
-------------------------------------------------------------------------------
Name CX2341X_ENC_START_CAPTURE
Enum 129/0x81
Description
Commences the capture of video, audio and/or VBI data. All encoding
parameters must be initialized prior to this API call. Captures frames
continuously or until a predefined number of frames have been captured.
Param[0]
Capture stream type:
0=MPEG
1=Raw
2=Raw passthrough
3=VBI
Param[1]
Bitmask:
Bit 0 when set, captures YUV
Bit 1 when set, captures PCM audio
Bit 2 when set, captures VBI (same as param[0]=3)
Bit 3 when set, the capture destination is the decoder
(same as param[0]=2)
Bit 4 when set, the capture destination is the host
Note: this parameter is only meaningful for RAW capture type.
-------------------------------------------------------------------------------
Name CX2341X_ENC_STOP_CAPTURE
Enum 130/0x82
Description
Ends a capture in progress
Param[0]
0=stop at end of GOP (generates IRQ)
1=stop immediate (no IRQ)
Param[1]
Stream type to stop, see param[0] of API 0x81
Param[2]
Subtype, see param[1] of API 0x81
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_AUDIO_ID
Enum 137/0x89
Description
Assigns the transport stream ID of the encoded audio stream
Param[0]
Audio Stream ID
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_VIDEO_ID
Enum 139/0x8B
Description
Set video transport stream ID
Param[0]
Video stream ID
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_PCR_ID
Enum 141/0x8D
Description
Assigns the transport stream ID for PCR packets
Param[0]
PCR Stream ID
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_FRAME_RATE
Enum 143/0x8F
Description
Set video frames per second. Change occurs at start of new GOP.
Param[0]
0=30fps
1=25fps
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_FRAME_SIZE
Enum 145/0x91
Description
Select video stream encoding resolution.
Param[0]
Height in lines. Default 480
Param[1]
Width in pixels. Default 720
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_BIT_RATE
Enum 149/0x95
Description
Assign average video stream bitrate. Note on the last three params:
Param[3] and [4] seem to be always 0, param [5] doesn't seem to be used.
Param[0]
0=variable bitrate, 1=constant bitrate
Param[1]
bitrate in bits per second
Param[2]
peak bitrate in bits per second, divided by 400
Param[3]
Mux bitrate in bits per second, divided by 400. May be 0 (default).
Param[4]
Rate Control VBR Padding
Param[5]
VBV Buffer used by encoder
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_GOP_PROPERTIES
Enum 151/0x97
Description
Setup the GOP structure
Param[0]
GOP size (maximum is 34)
Param[1]
Number of B frames between the I and P frame, plus 1.
For example: IBBPBBPBBPBB --> GOP size: 12, number of B frames: 2+1 = 3
Note that GOP size must be a multiple of (B-frames + 1).
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_ASPECT_RATIO
Enum 153/0x99
Description
Sets the encoding aspect ratio. Changes in the aspect ratio take effect
at the start of the next GOP.
Param[0]
'0000' forbidden
'0001' 1:1 square
'0010' 4:3
'0011' 16:9
'0100' 2.21:1
'0101' reserved
....
'1111' reserved
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_DNR_FILTER_MODE
Enum 155/0x9B
Description
Assign Dynamic Noise Reduction operating mode
Param[0]
Bit0: Spatial filter, set=auto, clear=manual
Bit1: Temporal filter, set=auto, clear=manual
Param[1]
Median filter:
0=Disabled
1=Horizontal
2=Vertical
3=Horiz/Vert
4=Diagonal
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_DNR_FILTER_PROPS
Enum 157/0x9D
Description
These Dynamic Noise Reduction filter values are only meaningful when
the respective filter is set to "manual" (See API 0x9B)
Param[0]
Spatial filter: default 0, range 0:15
Param[1]
Temporal filter: default 0, range 0:31
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_CORING_LEVELS
Enum 159/0x9F
Description
Assign Dynamic Noise Reduction median filter properties.
Param[0]
Threshold above which the luminance median filter is enabled.
Default: 0, range 0:255
Param[1]
Threshold below which the luminance median filter is enabled.
Default: 255, range 0:255
Param[2]
Threshold above which the chrominance median filter is enabled.
Default: 0, range 0:255
Param[3]
Threshold below which the chrominance median filter is enabled.
Default: 255, range 0:255
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_SPATIAL_FILTER_TYPE
Enum 161/0xA1
Description
Assign spatial prefilter parameters
Param[0]
Luminance filter
0=Off
1=1D Horizontal
2=1D Vertical
3=2D H/V Separable (default)
4=2D Symmetric non-separable
Param[1]
Chrominance filter
0=Off
1=1D Horizontal (default)
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_VBI_LINE
Enum 183/0xB7
Description
Selects VBI line number.
Param[0]
Bits 0:4 line number
Bit 31 0=top_field, 1=bottom_field
Bits 0:31 all set specifies "all lines"
Param[1]
VBI line information features: 0=disabled, 1=enabled
Param[2]
Slicing: 0=None, 1=Closed Caption
Almost certainly not implemented. Set to 0.
Param[3]
Luminance samples in this line.
Almost certainly not implemented. Set to 0.
Param[4]
Chrominance samples in this line
Almost certainly not implemented. Set to 0.
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_STREAM_TYPE
Enum 185/0xB9
Description
Assign stream type
Note: Transport stream is not working in recent firmwares.
And in older firmwares the timestamps in the TS seem to be
unreliable.
Param[0]
0=Program stream
1=Transport stream
2=MPEG1 stream
3=PES A/V stream
5=PES Video stream
7=PES Audio stream
10=DVD stream
11=VCD stream
12=SVCD stream
13=DVD_S1 stream
14=DVD_S2 stream
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_OUTPUT_PORT
Enum 187/0xBB
Description
Assign stream output port. Normally 0 when the data is copied through
the PCI bus (DMA), and 1 when the data is streamed to another chip
(pvrusb and cx88-blackbird).
Param[0]
0=Memory (default)
1=Streaming
2=Serial
Param[1]
Unknown, but leaving this to 0 seems to work best. Indications are that
this might have to do with USB support, although passing anything but 0
only breaks things.
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_AUDIO_PROPERTIES
Enum 189/0xBD
Description
Set audio stream properties, may be called while encoding is in progress.
Note: all bitfields are consistent with ISO11172 documentation except
bits 2:3 which ISO docs define as:
'11' Layer I
'10' Layer II
'01' Layer III
'00' Undefined
This discrepancy may indicate a possible error in the documentation.
Testing indicated that only Layer II is actually working, and that
the minimum bitrate should be 192 kbps.
Param[0]
Bitmask:
0:1 '00' 44.1Khz
'01' 48Khz
'10' 32Khz
'11' reserved
2:3 '01'=Layer I
'10'=Layer II
4:7 Bitrate:
Index | Layer I | Layer II
------+-------------+------------
'0000' | free format | free format
'0001' | 32 kbit/s | 32 kbit/s
'0010' | 64 kbit/s | 48 kbit/s
'0011' | 96 kbit/s | 56 kbit/s
'0100' | 128 kbit/s | 64 kbit/s
'0101' | 160 kbit/s | 80 kbit/s
'0110' | 192 kbit/s | 96 kbit/s
'0111' | 224 kbit/s | 112 kbit/s
'1000' | 256 kbit/s | 128 kbit/s
'1001' | 288 kbit/s | 160 kbit/s
'1010' | 320 kbit/s | 192 kbit/s
'1011' | 352 kbit/s | 224 kbit/s
'1100' | 384 kbit/s | 256 kbit/s
'1101' | 416 kbit/s | 320 kbit/s
'1110' | 448 kbit/s | 384 kbit/s
Note: For Layer II, not all combinations of total bitrate
and mode are allowed. See ISO11172-3 3-Annex B, Table 3-B.2
8:9 '00'=Stereo
'01'=JointStereo
'10'=Dual
'11'=Mono
Note: the cx23415 cannot decode Joint Stereo properly.
10:11 Mode Extension used in joint_stereo mode.
In Layer I and II they indicate which subbands are in
intensity_stereo. All other subbands are coded in stereo.
'00' subbands 4-31 in intensity_stereo, bound==4
'01' subbands 8-31 in intensity_stereo, bound==8
'10' subbands 12-31 in intensity_stereo, bound==12
'11' subbands 16-31 in intensity_stereo, bound==16
12:13 Emphasis:
'00' None
'01' 50/15uS
'10' reserved
'11' CCITT J.17
14 CRC:
'0' off
'1' on
15 Copyright:
'0' off
'1' on
16 Generation:
'0' copy
'1' original
-------------------------------------------------------------------------------
Name CX2341X_ENC_HALT_FW
Enum 195/0xC3
Description
The firmware is halted and no further API calls are serviced until the
firmware is uploaded again.
-------------------------------------------------------------------------------
Name CX2341X_ENC_GET_VERSION
Enum 196/0xC4
Description
Returns the version of the encoder firmware.
Result[0]
Version bitmask:
Bits 0:15 build
Bits 16:23 minor
Bits 24:31 major
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_GOP_CLOSURE
Enum 197/0xC5
Description
Assigns the GOP open/close property.
Param[0]
0=Open
1=Closed
-------------------------------------------------------------------------------
Name CX2341X_ENC_GET_SEQ_END
Enum 198/0xC6
Description
Obtains the sequence end code of the encoder's buffer. When a capture
is started a number of interrupts are still generated, the last of
which will have Result[0] set to 1 and Result[1] will contain the size
of the buffer.
Result[0]
State of the transfer (1 if last buffer)
Result[1]
If Result[0] is 1, this contains the size of the last buffer, undefined
otherwise.
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_PGM_INDEX_INFO
Enum 199/0xC7
Description
Sets the Program Index Information.
The information is stored as follows:
struct info {
u32 length; // Length of this frame
u32 offset_low; // Offset in the file of the
u32 offset_high; // start of this frame
u32 mask1; // Bits 0-2 are the type mask:
// 1=I, 2=P, 4=B
// 0=End of Program Index, other fields
// are invalid.
u32 pts; // The PTS of the frame
u32 mask2; // Bit 0 is bit 32 of the pts.
};
u32 table_ptr;
struct info index[400];
The table_ptr is the encoder memory address in the table were
*new* entries will be written. Note that this is a ringbuffer,
so the table_ptr will wraparound.
Param[0]
Picture Mask:
0=No index capture
1=I frames
3=I,P frames
7=I,P,B frames
(Seems to be ignored, it always indexes I, P and B frames)
Param[1]
Elements requested (up to 400)
Result[0]
Offset in the encoder memory of the start of the table.
Result[1]
Number of allocated elements up to a maximum of Param[1]
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_VBI_CONFIG
Enum 200/0xC8
Description
Configure VBI settings
Param[0]
Bitmap:
0 Mode '0' Sliced, '1' Raw
1:3 Insertion:
'000' insert in extension & user data
'001' insert in private packets
'010' separate stream and user data
'111' separate stream and private data
8:15 Stream ID (normally 0xBD)
Param[1]
Frames per interrupt (max 8). Only valid in raw mode.
Param[2]
Total raw VBI frames. Only valid in raw mode.
Param[3]
Start codes
Param[4]
Stop codes
Param[5]
Lines per frame
Param[6]
Byte per line
Result[0]
Observed frames per interrupt in raw mode only. Rage 1 to Param[1]
Result[1]
Observed number of frames in raw mode. Range 1 to Param[2]
Result[2]
Memory offset to start or raw VBI data
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_DMA_BLOCK_SIZE
Enum 201/0xC9
Description
Set DMA transfer block size
Param[0]
DMA transfer block size in bytes or frames. When unit is bytes,
supported block sizes are 2^7, 2^8 and 2^9 bytes.
Param[1]
Unit: 0=bytes, 1=frames
-------------------------------------------------------------------------------
Name CX2341X_ENC_GET_PREV_DMA_INFO_MB_10
Enum 202/0xCA
Description
Returns information on the previous DMA transfer in conjunction with
bit 27 of the interrupt mask. Uses mailbox 10.
Result[0]
Type of stream
Result[1]
Address Offset
Result[2]
Maximum size of transfer
-------------------------------------------------------------------------------
Name CX2341X_ENC_GET_PREV_DMA_INFO_MB_9
Enum 203/0xCB
Description
Returns information on the previous DMA transfer in conjunction with
bit 27 or 18 of the interrupt mask. Uses mailbox 9.
Result[0]
Status bits:
0 read completed
1 write completed
2 DMA read error
3 DMA write error
4 Scatter-Gather array error
Result[1]
DMA type
Result[2]
Presentation Time Stamp bits 0..31
Result[3]
Presentation Time Stamp bit 32
-------------------------------------------------------------------------------
Name CX2341X_ENC_SCHED_DMA_TO_HOST
Enum 204/0xCC
Description
Setup DMA to host operation
Param[0]
Memory address of link list
Param[1]
Length of link list (wtf: what units ???)
Param[2]
DMA type (0=MPEG)
-------------------------------------------------------------------------------
Name CX2341X_ENC_INITIALIZE_INPUT
Enum 205/0xCD
Description
Initializes the video input
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_FRAME_DROP_RATE
Enum 208/0xD0
Description
For each frame captured, skip specified number of frames.
Param[0]
Number of frames to skip
-------------------------------------------------------------------------------
Name CX2341X_ENC_PAUSE_ENCODER
Enum 210/0xD2
Description
During a pause condition, all frames are dropped instead of being encoded.
Param[0]
0=Pause encoding
1=Continue encoding
-------------------------------------------------------------------------------
Name CX2341X_ENC_REFRESH_INPUT
Enum 211/0xD3
Description
Refreshes the video input
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_COPYRIGHT
Enum 212/0xD4
Description
Sets stream copyright property
Param[0]
0=Stream is not copyrighted
1=Stream is copyrighted
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_EVENT_NOTIFICATION
Enum 213/0xD5
Description
Setup firmware to notify the host about a particular event. Host must
unmask the interrupt bit.
Param[0]
Event (0=refresh encoder input)
Param[1]
Notification 0=disabled 1=enabled
Param[2]
Interrupt bit
Param[3]
Mailbox slot, -1 if no mailbox required.
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_NUM_VSYNC_LINES
Enum 214/0xD6
Description
Depending on the analog video decoder used, this assigns the number
of lines for field 1 and 2.
Param[0]
Field 1 number of lines:
0x00EF for SAA7114
0x00F0 for SAA7115
0x0105 for Micronas
Param[1]
Field 2 number of lines:
0x00EF for SAA7114
0x00F0 for SAA7115
0x0106 for Micronas
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_PLACEHOLDER
Enum 215/0xD7
Description
Provides a mechanism of inserting custom user data in the MPEG stream.
Param[0]
0=extension & user data
1=private packet with stream ID 0xBD
Param[1]
Rate at which to insert data, in units of frames (for private packet)
or GOPs (for ext. & user data)
Param[2]
Number of data DWORDs (below) to insert
Param[3]
Custom data 0
Param[4]
Custom data 1
Param[5]
Custom data 2
Param[6]
Custom data 3
Param[7]
Custom data 4
Param[8]
Custom data 5
Param[9]
Custom data 6
Param[10]
Custom data 7
Param[11]
Custom data 8
-------------------------------------------------------------------------------
Name CX2341X_ENC_MUTE_VIDEO
Enum 217/0xD9
Description
Video muting
Param[0]
Bit usage:
0 '0'=video not muted
'1'=video muted, creates frames with the YUV color defined below
1:7 Unused
8:15 V chrominance information
16:23 U chrominance information
24:31 Y luminance information
-------------------------------------------------------------------------------
Name CX2341X_ENC_MUTE_AUDIO
Enum 218/0xDA
Description
Audio muting
Param[0]
0=audio not muted
1=audio muted (produces silent mpeg audio stream)
-------------------------------------------------------------------------------
Name CX2341X_ENC_SET_VERT_CROP_LINE
Enum 219/0xDB
Description
Something to do with 'Vertical Crop Line'
Param[0]
If saa7114 and raw VBI capture and 60 Hz, then set to 10001.
Else 0.
-------------------------------------------------------------------------------
Name CX2341X_ENC_MISC
Enum 220/0xDC
Description
Miscellaneous actions. Not known for 100% what it does. It's really a
sort of ioctl call. The first parameter is a command number, the second
the value.
Param[0]
Command number:
1=set initial SCR value when starting encoding (works).
2=set quality mode (apparently some test setting).
3=setup advanced VIM protection handling.
Always 1 for the cx23416 and 0 for cx23415.
4=generate DVD compatible PTS timestamps
5=USB flush mode
6=something to do with the quantization matrix
7=set navigation pack insertion for DVD: adds 0xbf (private stream 2)
packets to the MPEG. The size of these packets is 2048 bytes (including
the header of 6 bytes: 0x000001bf + length). The payload is zeroed and
it is up to the application to fill them in. These packets are apparently
inserted every four frames.
8=enable scene change detection (seems to be a failure)
9=set history parameters of the video input module
10=set input field order of VIM
11=set quantization matrix
12=reset audio interface after channel change or input switch (has no argument).
Needed for the cx2584x, not needed for the mspx4xx, but it doesn't seem to
do any harm calling it regardless.
13=set audio volume delay
14=set audio delay
Param[1]
Command value.

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

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

@@ -0,0 +1,350 @@
OSD firmware API description
============================
Note: this API is part of the decoder firmware, so it's cx23415 only.
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_FRAMEBUFFER
Enum 65/0x41
Description
Return base and length of contiguous OSD memory.
Result[0]
OSD base address
Result[1]
OSD length
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_PIXEL_FORMAT
Enum 66/0x42
Description
Query OSD format
Result[0]
0=8bit index
1=16bit RGB 5:6:5
2=16bit ARGB 1:5:5:5
3=16bit ARGB 1:4:4:4
4=32bit ARGB 8:8:8:8
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_PIXEL_FORMAT
Enum 67/0x43
Description
Assign pixel format
Param[0]
0=8bit index
1=16bit RGB 5:6:5
2=16bit ARGB 1:5:5:5
3=16bit ARGB 1:4:4:4
4=32bit ARGB 8:8:8:8
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_STATE
Enum 68/0x44
Description
Query OSD state
Result[0]
Bit 0 0=off, 1=on
Bits 1:2 alpha control
Bits 3:5 pixel format
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_STATE
Enum 69/0x45
Description
OSD switch
Param[0]
0=off, 1=on
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_OSD_COORDS
Enum 70/0x46
Description
Retrieve coordinates of OSD area blended with video
Result[0]
OSD buffer address
Result[1]
Stride in pixels
Result[2]
Lines in OSD buffer
Result[3]
Horizontal offset in buffer
Result[4]
Vertical offset in buffer
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_OSD_COORDS
Enum 71/0x47
Description
Assign the coordinates of the OSD area to blend with video
Param[0]
buffer address
Param[1]
buffer stride in pixels
Param[2]
lines in buffer
Param[3]
horizontal offset
Param[4]
vertical offset
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_SCREEN_COORDS
Enum 72/0x48
Description
Retrieve OSD screen area coordinates
Result[0]
top left horizontal offset
Result[1]
top left vertical offset
Result[2]
bottom right horizontal offset
Result[3]
bottom right vertical offset
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_SCREEN_COORDS
Enum 73/0x49
Description
Assign the coordinates of the screen area to blend with video
Param[0]
top left horizontal offset
Param[1]
top left vertical offset
Param[2]
bottom left horizontal offset
Param[3]
bottom left vertical offset
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_GLOBAL_ALPHA
Enum 74/0x4A
Description
Retrieve OSD global alpha
Result[0]
global alpha: 0=off, 1=on
Result[1]
bits 0:7 global alpha
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_GLOBAL_ALPHA
Enum 75/0x4B
Description
Update global alpha
Param[0]
global alpha: 0=off, 1=on
Param[1]
global alpha (8 bits)
Param[2]
local alpha: 0=on, 1=off
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_BLEND_COORDS
Enum 78/0x4C
Description
Move start of blending area within display buffer
Param[0]
horizontal offset in buffer
Param[1]
vertical offset in buffer
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_FLICKER_STATE
Enum 79/0x4F
Description
Retrieve flicker reduction module state
Result[0]
flicker state: 0=off, 1=on
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_FLICKER_STATE
Enum 80/0x50
Description
Set flicker reduction module state
Param[0]
State: 0=off, 1=on
-------------------------------------------------------------------------------
Name CX2341X_OSD_BLT_COPY
Enum 82/0x52
Description
BLT copy
Param[0]
'0000' zero
'0001' ~destination AND ~source
'0010' ~destination AND source
'0011' ~destination
'0100' destination AND ~source
'0101' ~source
'0110' destination XOR source
'0111' ~destination OR ~source
'1000' ~destination AND ~source
'1001' destination XNOR source
'1010' source
'1011' ~destination OR source
'1100' destination
'1101' destination OR ~source
'1110' destination OR source
'1111' one
Param[1]
Resulting alpha blending
'01' source_alpha
'10' destination_alpha
'11' source_alpha*destination_alpha+1
(zero if both source and destination alpha are zero)
Param[2]
'00' output_pixel = source_pixel
'01' if source_alpha=0:
output_pixel = destination_pixel
if 256 > source_alpha > 1:
output_pixel = ((source_alpha + 1)*source_pixel +
(255 - source_alpha)*destination_pixel)/256
'10' if destination_alpha=0:
output_pixel = source_pixel
if 255 > destination_alpha > 0:
output_pixel = ((255 - destination_alpha)*source_pixel +
(destination_alpha + 1)*destination_pixel)/256
'11' if source_alpha=0:
source_temp = 0
if source_alpha=255:
source_temp = source_pixel*256
if 255 > source_alpha > 0:
source_temp = source_pixel*(source_alpha + 1)
if destination_alpha=0:
destination_temp = 0
if destination_alpha=255:
destination_temp = destination_pixel*256
if 255 > destination_alpha > 0:
destination_temp = destination_pixel*(destination_alpha + 1)
output_pixel = (source_temp + destination_temp)/256
Param[3]
width
Param[4]
height
Param[5]
destination pixel mask
Param[6]
destination rectangle start address
Param[7]
destination stride in dwords
Param[8]
source stride in dwords
Param[9]
source rectangle start address
-------------------------------------------------------------------------------
Name CX2341X_OSD_BLT_FILL
Enum 83/0x53
Description
BLT fill color
Param[0]
Same as Param[0] on API 0x52
Param[1]
Same as Param[1] on API 0x52
Param[2]
Same as Param[2] on API 0x52
Param[3]
width
Param[4]
height
Param[5]
destination pixel mask
Param[6]
destination rectangle start address
Param[7]
destination stride in dwords
Param[8]
color fill value
-------------------------------------------------------------------------------
Name CX2341X_OSD_BLT_TEXT
Enum 84/0x54
Description
BLT for 8 bit alpha text source
Param[0]
Same as Param[0] on API 0x52
Param[1]
Same as Param[1] on API 0x52
Param[2]
Same as Param[2] on API 0x52
Param[3]
width
Param[4]
height
Param[5]
destination pixel mask
Param[6]
destination rectangle start address
Param[7]
destination stride in dwords
Param[8]
source stride in dwords
Param[9]
source rectangle start address
Param[10]
color fill value
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_FRAMEBUFFER_WINDOW
Enum 86/0x56
Description
Positions the main output window on the screen. The coordinates must be
such that the entire window fits on the screen.
Param[0]
window width
Param[1]
window height
Param[2]
top left window corner horizontal offset
Param[3]
top left window corner vertical offset
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_CHROMA_KEY
Enum 96/0x60
Description
Chroma key switch and color
Param[0]
state: 0=off, 1=on
Param[1]
color
-------------------------------------------------------------------------------
Name CX2341X_OSD_GET_ALPHA_CONTENT_INDEX
Enum 97/0x61
Description
Retrieve alpha content index
Result[0]
alpha content index, Range 0:15
-------------------------------------------------------------------------------
Name CX2341X_OSD_SET_ALPHA_CONTENT_INDEX
Enum 98/0x62
Description
Assign alpha content index
Param[0]
alpha content index, range 0:15

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://www.nenya.be/beor/electronics/rc5.htm and more data
http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
and even a reference to how to decode a bi-phase data stream.
http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
still more info

1717
Documentation/video4linux/extract_xc3028.pl Executable file
View File

File diff suppressed because it is too large Load Diff

178
Documentation/video4linux/fimc.txt Normal file
View File

@@ -0,0 +1,178 @@
Samsung S5P/EXYNOS4 FIMC driver
Copyright (C) 2012 Samsung Electronics Co., Ltd.
---------------------------------------------------------------------------
The FIMC (Fully Interactive Mobile Camera) device available in Samsung
SoC Application Processors is an integrated camera host interface, color
space converter, image resizer and rotator. It's also capable of capturing
data from LCD controller (FIMD) through the SoC internal writeback data
path. There are multiple FIMC instances in the SoCs (up to 4), having
slightly different capabilities, like pixel alignment constraints, rotator
availability, LCD writeback support, etc. The driver is located at
drivers/media/platform/s5p-fimc directory.
1. Supported SoCs
=================
S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
2. Supported features
=====================
- camera parallel interface capture (ITU-R.BT601/565);
- camera serial interface capture (MIPI-CSI2);
- memory-to-memory processing (color space conversion, scaling, mirror
and rotation);
- dynamic pipeline re-configuration at runtime (re-attachment of any FIMC
instance to any parallel video input or any MIPI-CSI front-end);
- runtime PM and system wide suspend/resume
Not currently supported:
- LCD writeback input
- per frame clock gating (mem-to-mem)
3. Files partitioning
=====================
- media device driver
drivers/media/platform/s5p-fimc/fimc-mdevice.[ch]
- camera capture video device driver
drivers/media/platform/s5p-fimc/fimc-capture.c
- MIPI-CSI2 receiver subdev
drivers/media/platform/s5p-fimc/mipi-csis.[ch]
- video post-processor (mem-to-mem)
drivers/media/platform/s5p-fimc/fimc-core.c
- common files
drivers/media/platform/s5p-fimc/fimc-core.h
drivers/media/platform/s5p-fimc/fimc-reg.h
drivers/media/platform/s5p-fimc/regs-fimc.h
4. User space interfaces
========================
4.1. Media device interface
The driver supports Media Controller API as defined at
http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
The media device driver name is "SAMSUNG S5P FIMC".
The purpose of this interface is to allow changing assignment of FIMC instances
to the SoC peripheral camera input at runtime and optionally to control internal
connections of the MIPI-CSIS device(s) to the FIMC entities.
The media device interface allows to configure the SoC for capturing image
data from the sensor through more than one FIMC instance (e.g. for simultaneous
viewfinder and still capture setup).
Reconfiguration is done by enabling/disabling media links created by the driver
during initialization. The internal device topology can be easily discovered
through media entity and links enumeration.
4.2. Memory-to-memory video node
V4L2 memory-to-memory interface at /dev/video? device node. This is standalone
video device, it has no media pads. However please note the mem-to-mem and
capture video node operation on same FIMC instance is not allowed. The driver
detects such cases but the applications should prevent them to avoid an
undefined behaviour.
4.3. Capture video node
The driver supports V4L2 Video Capture Interface as defined at:
http://linuxtv.org/downloads/v4l-dvb-apis/devices.html
At the capture and mem-to-mem video nodes only the multi-planar API is
supported. For more details see:
http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
4.4. Camera capture subdevs
Each FIMC instance exports a sub-device node (/dev/v4l-subdev?), a sub-device
node is also created per each available and enabled at the platform level
MIPI-CSI receiver device (currently up to two).
4.5. sysfs
In order to enable more precise camera pipeline control through the sub-device
API the driver creates a sysfs entry associated with "s5p-fimc-md" platform
device. The entry path is: /sys/platform/devices/s5p-fimc-md/subdev_conf_mode.
In typical use case there could be a following capture pipeline configuration:
sensor subdev -> mipi-csi subdev -> fimc subdev -> video node
When we configure these devices through sub-device API at user space, the
configuration flow must be from left to right, and the video node is
configured as last one.
When we don't use sub-device user space API the whole configuration of all
devices belonging to the pipeline is done at the video node driver.
The sysfs entry allows to instruct the capture node driver not to configure
the sub-devices (format, crop), to avoid resetting the subdevs' configuration
when the last configuration steps at the video node is performed.
For full sub-device control support (subdevs configured at user space before
starting streaming):
# echo "sub-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
For V4L2 video node control only (subdevs configured internally by the host
driver):
# echo "vid-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
This is a default option.
5. Device mapping to video and subdev device nodes
==================================================
There are associated two video device nodes with each device instance in
hardware - video capture and mem-to-mem and additionally a subdev node for
more precise FIMC capture subsystem control. In addition a separate v4l2
sub-device node is created per each MIPI-CSIS device.
How to find out which /dev/video? or /dev/v4l-subdev? is assigned to which
device?
You can either grep through the kernel log to find relevant information, i.e.
# dmesg | grep -i fimc
(note that udev, if present, might still have rearranged the video nodes),
or retrieve the information from /dev/media? with help of the media-ctl tool:
# media-ctl -p
6. Platform support
===================
The machine code (plat-s5p and arch/arm/mach-*) must select following options
CONFIG_S5P_DEV_FIMC0 mandatory
CONFIG_S5P_DEV_FIMC1 \
CONFIG_S5P_DEV_FIMC2 | optional
CONFIG_S5P_DEV_FIMC3 |
CONFIG_S5P_SETUP_FIMC /
CONFIG_S5P_SETUP_MIPIPHY \
CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface
CONFIG_S5P_DEV_CSIS1 /
Except that, relevant s5p_device_fimc? should be registered in the machine code
in addition to a "s5p-fimc-md" platform device to which the media device driver
is bound. The "s5p-fimc-md" device instance is required even if only mem-to-mem
operation is used.
The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be
passed as the "s5p-fimc-md" device platform_data. The platform data structure
is defined in file include/media/s5p_fimc.h.
7. Build
========
This driver depends on following config options:
PLAT_S5P,
PM_RUNTIME,
I2C,
REGULATOR,
VIDEO_V4L2_SUBDEV_API,
If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
optional s5p-csis.ko (MIPI-CSI receiver subdev).

407
Documentation/video4linux/gspca.txt Normal file
View File

@@ -0,0 +1,407 @@
List of the webcams known by gspca.
The modules are:
gspca_main main driver
gspca_xxxx subdriver module with xxxx as follows
xxxx vend:prod
----
spca501 0000:0000 MystFromOri Unknown Camera
spca508 0130:0130 Clone Digital Webcam 11043
zc3xx 03f0:1b07 HP Premium Starter Cam
m5602 0402:5602 ALi Video Camera Controller
spca501 040a:0002 Kodak DVC-325
spca500 040a:0300 Kodak EZ200
zc3xx 041e:041e Creative WebCam Live!
ov519 041e:4003 Video Blaster WebCam Go Plus
spca500 041e:400a Creative PC-CAM 300
sunplus 041e:400b Creative PC-CAM 600
sunplus 041e:4012 PC-Cam350
sunplus 041e:4013 Creative Pccam750
zc3xx 041e:4017 Creative Webcam Mobile PD1090
spca508 041e:4018 Creative Webcam Vista (PD1100)
spca561 041e:401a Creative Webcam Vista (PD1100)
zc3xx 041e:401c Creative NX
spca505 041e:401d Creative Webcam NX ULTRA
zc3xx 041e:401e Creative Nx Pro
zc3xx 041e:401f Creative Webcam Notebook PD1171
pac207 041e:4028 Creative Webcam Vista Plus
zc3xx 041e:4029 Creative WebCam Vista Pro
zc3xx 041e:4034 Creative Instant P0620
zc3xx 041e:4035 Creative Instant P0620D
zc3xx 041e:4036 Creative Live !
sq930x 041e:4038 Creative Joy-IT
zc3xx 041e:403a Creative Nx Pro 2
spca561 041e:403b Creative Webcam Vista (VF0010)
sq930x 041e:403c Creative Live! Ultra
sq930x 041e:403d Creative Live! Ultra for Notebooks
sq930x 041e:4041 Creative Live! Motion
zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250)
ov519 041e:4052 Creative Live! VISTA IM
zc3xx 041e:4053 Creative Live!Cam Video IM
vc032x 041e:405b Creative Live! Cam Notebook Ultra (VC0130)
ov519 041e:405f Creative Live! VISTA VF0330
ov519 041e:4060 Creative Live! VISTA VF0350
ov519 041e:4061 Creative Live! VISTA VF0400
ov519 041e:4064 Creative Live! VISTA VF0420
ov519 041e:4067 Creative Live! Cam Video IM (VF0350)
ov519 041e:4068 Creative Live! VISTA VF0470
spca561 0458:7004 Genius VideoCAM Express V2
sn9c2028 0458:7005 Genius Smart 300, version 2
sunplus 0458:7006 Genius Dsc 1.3 Smart
zc3xx 0458:7007 Genius VideoCam V2
zc3xx 0458:700c Genius VideoCam V3
zc3xx 0458:700f Genius VideoCam Web V2
sonixj 0458:7025 Genius Eye 311Q
sn9c20x 0458:7029 Genius Look 320s
sonixj 0458:702e Genius Slim 310 NB
sn9c20x 0458:704a Genius Slim 1320
sn9c20x 0458:704c Genius i-Look 1321
sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650)
sonixj 045e:00f5 MicroSoft VX3000
sonixj 045e:00f7 MicroSoft VX1000
ov519 045e:028c Micro$oft xbox cam
spca508 0461:0815 Micro Innovation IC200
sunplus 0461:0821 Fujifilm MV-1
zc3xx 0461:0a00 MicroInnovation WebCam320
stv06xx 046d:0840 QuickCam Express
stv06xx 046d:0850 LEGO cam / QuickCam Web
stv06xx 046d:0870 Dexxa WebCam USB
spca500 046d:0890 Logitech QuickCam traveler
vc032x 046d:0892 Logitech Orbicam
vc032x 046d:0896 Logitech Orbicam
vc032x 046d:0897 Logitech QuickCam for Dell notebooks
zc3xx 046d:089d Logitech QuickCam E2500
zc3xx 046d:08a0 Logitech QC IM
zc3xx 046d:08a1 Logitech QC IM 0x08A1 +sound
zc3xx 046d:08a2 Labtec Webcam Pro
zc3xx 046d:08a3 Logitech QC Chat
zc3xx 046d:08a6 Logitech QCim
zc3xx 046d:08a7 Logitech QuickCam Image
zc3xx 046d:08a9 Logitech Notebook Deluxe
zc3xx 046d:08aa Labtec Webcam Notebook
zc3xx 046d:08ac Logitech QuickCam Cool
zc3xx 046d:08ad Logitech QCCommunicate STX
zc3xx 046d:08ae Logitech QuickCam for Notebooks
zc3xx 046d:08af Logitech QuickCam Cool
zc3xx 046d:08b9 Logitech QuickCam Express
zc3xx 046d:08d7 Logitech QCam STX
zc3xx 046d:08d9 Logitech QuickCam IM/Connect
zc3xx 046d:08d8 Logitech Notebook Deluxe
zc3xx 046d:08da Logitech QuickCam Messenger
zc3xx 046d:08dd Logitech QuickCam for Notebooks
spca500 046d:0900 Logitech Inc. ClickSmart 310
spca500 046d:0901 Logitech Inc. ClickSmart 510
sunplus 046d:0905 Logitech ClickSmart 820
tv8532 046d:0920 Logitech QuickCam Express
tv8532 046d:0921 Labtec Webcam
spca561 046d:0928 Logitech QC Express Etch2
spca561 046d:0929 Labtec Webcam Elch2
spca561 046d:092a Logitech QC for Notebook
spca561 046d:092b Labtec Webcam Plus
spca561 046d:092c Logitech QC chat Elch2
spca561 046d:092d Logitech QC Elch2
spca561 046d:092e Logitech QC Elch2
spca561 046d:092f Logitech QuickCam Express Plus
sunplus 046d:0960 Logitech ClickSmart 420
nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring)
sunplus 0471:0322 Philips DMVC1300K
zc3xx 0471:0325 Philips SPC 200 NC
zc3xx 0471:0326 Philips SPC 300 NC
sonixj 0471:0327 Philips SPC 600 NC
sonixj 0471:0328 Philips SPC 700 NC
zc3xx 0471:032d Philips SPC 210 NC
zc3xx 0471:032e Philips SPC 315 NC
sonixj 0471:0330 Philips SPC 710 NC
spca501 0497:c001 Smile International
sunplus 04a5:3003 Benq DC 1300
sunplus 04a5:3008 Benq DC 1500
sunplus 04a5:300a Benq DC 3410
spca500 04a5:300c Benq DC 1016
benq 04a5:3035 Benq DC E300
finepix 04cb:0104 Fujifilm FinePix 4800
finepix 04cb:0109 Fujifilm FinePix A202
finepix 04cb:010b Fujifilm FinePix A203
finepix 04cb:010f Fujifilm FinePix A204
finepix 04cb:0111 Fujifilm FinePix A205
finepix 04cb:0113 Fujifilm FinePix A210
finepix 04cb:0115 Fujifilm FinePix A303
finepix 04cb:0117 Fujifilm FinePix A310
finepix 04cb:0119 Fujifilm FinePix F401
finepix 04cb:011b Fujifilm FinePix F402
finepix 04cb:011d Fujifilm FinePix F410
finepix 04cb:0121 Fujifilm FinePix F601
finepix 04cb:0123 Fujifilm FinePix F700
finepix 04cb:0125 Fujifilm FinePix M603
finepix 04cb:0127 Fujifilm FinePix S300
finepix 04cb:0129 Fujifilm FinePix S304
finepix 04cb:012b Fujifilm FinePix S500
finepix 04cb:012d Fujifilm FinePix S602
finepix 04cb:012f Fujifilm FinePix S700
finepix 04cb:0131 Fujifilm FinePix unknown model
finepix 04cb:013b Fujifilm FinePix unknown model
finepix 04cb:013d Fujifilm FinePix unknown model
finepix 04cb:013f Fujifilm FinePix F420
sunplus 04f1:1001 JVC GC A50
spca561 04fc:0561 Flexcam 100
spca1528 04fc:1528 Sunplus MD80 clone
sunplus 04fc:500c Sunplus CA500C
sunplus 04fc:504a Aiptek Mini PenCam 1.3
sunplus 04fc:504b Maxell MaxPocket LE 1.3
sunplus 04fc:5330 Digitrex 2110
sunplus 04fc:5360 Sunplus Generic
spca500 04fc:7333 PalmPixDC85
sunplus 04fc:ffff Pure DigitalDakota
nw80x 0502:d001 DVC V6
spca501 0506:00df 3Com HomeConnect Lite
sunplus 052b:1507 Megapixel 5 Pretec DC-1007
sunplus 052b:1513 Megapix V4
sunplus 052b:1803 MegaImage VI
nw80x 052b:d001 EZCam Pro p35u
tv8532 0545:808b Veo Stingray
tv8532 0545:8333 Veo Stingray
sunplus 0546:3155 Polaroid PDC3070
sunplus 0546:3191 Polaroid Ion 80
sunplus 0546:3273 Polaroid PDC2030
ov519 054c:0154 Sonny toy4
ov519 054c:0155 Sonny toy5
cpia1 0553:0002 CPIA CPiA (version1) based cameras
zc3xx 055f:c005 Mustek Wcam300A
spca500 055f:c200 Mustek Gsmart 300
sunplus 055f:c211 Kowa Bs888e Microcamera
spca500 055f:c220 Gsmart Mini
sunplus 055f:c230 Mustek Digicam 330K
sunplus 055f:c232 Mustek MDC3500
sunplus 055f:c360 Mustek DV4000 Mpeg4
sunplus 055f:c420 Mustek gSmart Mini 2
sunplus 055f:c430 Mustek Gsmart LCD 2
sunplus 055f:c440 Mustek DV 3000
sunplus 055f:c520 Mustek gSmart Mini 3
sunplus 055f:c530 Mustek Gsmart LCD 3
sunplus 055f:c540 Gsmart D30
sunplus 055f:c630 Mustek MDC4000
sunplus 055f:c650 Mustek MDC5500Z
nw80x 055f:d001 Mustek Wcam 300 mini
zc3xx 055f:d003 Mustek WCam300A
zc3xx 055f:d004 Mustek WCam300 AN
conex 0572:0041 Creative Notebook cx11646
ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera
ov519 05a9:0518 Creative WebCam
ov519 05a9:0519 OV519 Microphone
ov519 05a9:0530 OmniVision
ov534_9 05a9:1550 OmniVision VEHO Filmscanner
ov519 05a9:2800 OmniVision SuperCAM
ov519 05a9:4519 Webcam Classic
ov534_9 05a9:8065 OmniVision test kit ov538+ov9712
ov519 05a9:8519 OmniVision
ov519 05a9:a511 D-Link USB Digital Video Camera
ov519 05a9:a518 D-Link DSB-C310 Webcam
sunplus 05da:1018 Digital Dream Enigma 1.3
stk014 05e1:0893 Syntek DV4000
gl860 05e3:0503 Genesys Logic PC Camera
gl860 05e3:f191 Genesys Logic PC Camera
spca561 060b:a001 Maxell Compact Pc PM3
zc3xx 0698:2003 CTX M730V built in
topro 06a2:0003 TP6800 PC Camera, CmoX CX0342 webcam
topro 06a2:6810 Creative Qmax
nw80x 06a5:0000 Typhoon Webcam 100 USB
nw80x 06a5:d001 Divio based webcams
nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam
spca500 06bd:0404 Agfa CL20
spca500 06be:0800 Optimedia
nw80x 06be:d001 EZCam Pro p35u
sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom
spca506 06e1:a190 ADS Instant VCD
ov534 06f8:3002 Hercules Blog Webcam
ov534_9 06f8:3003 Hercules Dualpix HD Weblog
sonixj 06f8:3004 Hercules Classic Silver
sonixj 06f8:3008 Hercules Deluxe Optical Glass
pac7302 06f8:3009 Hercules Classic Link
pac7302 06f8:301b Hercules Link
nw80x 0728:d001 AVerMedia Camguard
spca508 0733:0110 ViewQuest VQ110
spca501 0733:0401 Intel Create and Share
spca501 0733:0402 ViewQuest M318B
spca505 0733:0430 Intel PC Camera Pro
sunplus 0733:1311 Digital Dream Epsilon 1.3
sunplus 0733:1314 Mercury 2.1MEG Deluxe Classic Cam
sunplus 0733:2211 Jenoptik jdc 21 LCD
sunplus 0733:2221 Mercury Digital Pro 3.1p
sunplus 0733:3261 Concord 3045 spca536a
sunplus 0733:3281 Cyberpix S550V
spca506 0734:043b 3DeMon USB Capture aka
cpia1 0813:0001 QX3 camera
ov519 0813:0002 Dual Mode USB Camera Plus
spca500 084d:0003 D-Link DSC-350
spca500 08ca:0103 Aiptek PocketDV
sunplus 08ca:0104 Aiptek PocketDVII 1.3
sunplus 08ca:0106 Aiptek Pocket DV3100+
mr97310a 08ca:0110 Trust Spyc@m 100
mr97310a 08ca:0111 Aiptek PenCam VGA+
sunplus 08ca:2008 Aiptek Mini PenCam 2 M
sunplus 08ca:2010 Aiptek PocketCam 3M
sunplus 08ca:2016 Aiptek PocketCam 2 Mega
sunplus 08ca:2018 Aiptek Pencam SD 2M
sunplus 08ca:2020 Aiptek Slim 3000F
sunplus 08ca:2022 Aiptek Slim 3200
sunplus 08ca:2024 Aiptek DV3500 Mpeg4
sunplus 08ca:2028 Aiptek PocketCam4M
sunplus 08ca:2040 Aiptek PocketDV4100M
sunplus 08ca:2042 Aiptek PocketDV5100
sunplus 08ca:2050 Medion MD 41437
sunplus 08ca:2060 Aiptek PocketDV5300
tv8532 0923:010f ICM532 cams
mars 093a:050f Mars-Semi Pc-Camera
mr97310a 093a:010e All known CIF cams with this ID
mr97310a 093a:010f All known VGA cams with this ID
pac207 093a:2460 Qtec Webcam 100
pac207 093a:2461 HP Webcam
pac207 093a:2463 Philips SPC 220 NC
pac207 093a:2464 Labtec Webcam 1200
pac207 093a:2468 Webcam WB-1400T
pac207 093a:2470 Genius GF112
pac207 093a:2471 Genius VideoCam ge111
pac207 093a:2472 Genius VideoCam ge110
pac207 093a:2474 Genius iLook 111
pac207 093a:2476 Genius e-Messenger 112
pac7311 093a:2600 PAC7311 Typhoon
pac7311 093a:2601 Philips SPC 610 NC
pac7311 093a:2603 Philips SPC 500 NC
pac7311 093a:2608 Trust WB-3300p
pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
pac7311 093a:260f SnakeCam
pac7302 093a:2620 Apollo AC-905
pac7302 093a:2621 PAC731x
pac7302 093a:2622 Genius Eye 312
pac7302 093a:2624 PAC7302
pac7302 093a:2625 Genius iSlim 310
pac7302 093a:2626 Labtec 2200
pac7302 093a:2627 Genius FaceCam 300
pac7302 093a:2628 Genius iLook 300
pac7302 093a:2629 Genious iSlim 300
pac7302 093a:262a Webcam 300k
pac7302 093a:262c Philips SPC 230 NC
jl2005bcd 0979:0227 Various brands, 19 known cameras supported
jeilinj 0979:0280 Sakar 57379
jeilinj 0979:0280 Sportscam DV15
zc3xx 0ac8:0302 Z-star Vimicro zc0302
vc032x 0ac8:0321 Vimicro generic vc0321
vc032x 0ac8:0323 Vimicro Vc0323
vc032x 0ac8:0328 A4Tech PK-130MG
zc3xx 0ac8:301b Z-Star zc301b
zc3xx 0ac8:303b Vimicro 0x303b
zc3xx 0ac8:305b Z-star Vimicro zc0305b
zc3xx 0ac8:307b PC Camera (ZS0211)
vc032x 0ac8:c001 Sony embedded vimicro
vc032x 0ac8:c002 Sony embedded vimicro
vc032x 0ac8:c301 Samsung Q1 Ultra Premium
spca508 0af9:0010 Hama USB Sightcam 100
spca508 0af9:0011 Hama USB Sightcam 100
ov519 0b62:0059 iBOT2 Webcam
sonixb 0c45:6001 Genius VideoCAM NB
sonixb 0c45:6005 Microdia Sweex Mini Webcam
sonixb 0c45:6007 Sonix sn9c101 + Tas5110D
sonixb 0c45:6009 spcaCam@120
sonixb 0c45:600d spcaCam@120
sonixb 0c45:6011 Microdia PC Camera (SN9C102)
sonixb 0c45:6019 Generic Sonix OV7630
sonixb 0c45:6024 Generic Sonix Tas5130c
sonixb 0c45:6025 Xcam Shanga
sonixb 0c45:6028 Sonix Btc Pc380
sonixb 0c45:6029 spcaCam@150
sonixb 0c45:602c Generic Sonix OV7630
sonixb 0c45:602d LIC-200 LG
sonixb 0c45:602e Genius VideoCam Messenger
sonixj 0c45:6040 Speed NVC 350K
sonixj 0c45:607c Sonix sn9c102p Hv7131R
sonixj 0c45:60c0 Sangha Sn535
sonixj 0c45:60ce USB-PC-Camera-168 (TALK-5067)
sonixj 0c45:60ec SN9C105+MO4000
sonixj 0c45:60fb Surfer NoName
sonixj 0c45:60fc LG-LIC300
sonixj 0c45:60fe Microdia Audio
sonixj 0c45:6100 PC Camera (SN9C128)
sonixj 0c45:6102 PC Camera (SN9C128)
sonixj 0c45:610a PC Camera (SN9C128)
sonixj 0c45:610b PC Camera (SN9C128)
sonixj 0c45:610c PC Camera (SN9C128)
sonixj 0c45:610e PC Camera (SN9C128)
sonixj 0c45:6128 Microdia/Sonix SNP325
sonixj 0c45:612a Avant Camera
sonixj 0c45:612b Speed-Link REFLECT2
sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
sonixj 0c45:6130 Sonix Pccam
sonixj 0c45:6138 Sn9c120 Mo4000
sonixj 0c45:613a Microdia Sonix PC Camera
sonixj 0c45:613b Surfer SN-206
sonixj 0c45:613c Sonix Pccam168
sonixj 0c45:6142 Hama PC-Webcam AC-150
sonixj 0c45:6143 Sonix Pccam168
sonixj 0c45:6148 Digitus DA-70811/ZSMC USB PC Camera ZS211/Microdia
sonixj 0c45:614a Frontech E-Ccam (JIL-2225)
sn9c20x 0c45:6240 PC Camera (SN9C201 + MT9M001)
sn9c20x 0c45:6242 PC Camera (SN9C201 + MT9M111)
sn9c20x 0c45:6248 PC Camera (SN9C201 + OV9655)
sn9c20x 0c45:624c PC Camera (SN9C201 + MT9M112)
sn9c20x 0c45:624e PC Camera (SN9C201 + SOI968)
sn9c20x 0c45:624f PC Camera (SN9C201 + OV9650)
sn9c20x 0c45:6251 PC Camera (SN9C201 + OV9650)
sn9c20x 0c45:6253 PC Camera (SN9C201 + OV9650)
sn9c20x 0c45:6260 PC Camera (SN9C201 + OV7670)
sn9c20x 0c45:6270 PC Camera (SN9C201 + MT9V011/MT9V111/MT9V112)
sn9c20x 0c45:627b PC Camera (SN9C201 + OV7660)
sn9c20x 0c45:627c PC Camera (SN9C201 + HV7131R)
sn9c20x 0c45:627f PC Camera (SN9C201 + OV9650)
sn9c20x 0c45:6280 PC Camera (SN9C202 + MT9M001)
sn9c20x 0c45:6282 PC Camera (SN9C202 + MT9M111)
sn9c20x 0c45:6288 PC Camera (SN9C202 + OV9655)
sn9c20x 0c45:628c PC Camera (SN9C201 + MT9M112)
sn9c20x 0c45:628e PC Camera (SN9C202 + SOI968)
sn9c20x 0c45:628f PC Camera (SN9C202 + OV9650)
sn9c20x 0c45:62a0 PC Camera (SN9C202 + OV7670)
sn9c20x 0c45:62b0 PC Camera (SN9C202 + MT9V011/MT9V111/MT9V112)
sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655)
sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660)
sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R)
sn9c2028 0c45:8001 Wild Planet Digital Spy Camera
sn9c2028 0c45:8003 Sakar #11199, #6637x, #67480 keychain cams
sn9c2028 0c45:8008 Mini-Shotz ms-350
sn9c2028 0c45:800a Vivitar Vivicam 3350B
sunplus 0d64:0303 Sunplus FashionCam DXG
ov519 0e96:c001 TRUST 380 USB2 SPACEC@M
etoms 102c:6151 Qcam Sangha CIF
etoms 102c:6251 Qcam xxxxxx VGA
ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go
zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128
spca561 10fd:7e50 FlyCam Usb 100
zc3xx 10fd:8050 Typhoon Webshot II USB 300k
ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201)
pac207 145f:013a Trust WB-1300N
sn9c20x 145f:013d Trust WB-3600R
vc032x 15b8:6001 HP 2.0 Megapixel
vc032x 15b8:6002 HP 2.0 Megapixel rz406aa
spca501 1776:501c Arowana 300K CMOS Camera
t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops
vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
pac207 2001:f115 D-Link DSB-C120
sq905c 2770:9050 Disney pix micro (CIF)
sq905c 2770:9051 Lego Bionicle
sq905c 2770:9052 Disney pix micro 2 (VGA)
sq905c 2770:905c All 11 known cameras with this ID
sq905 2770:9120 All 24 known cameras with this ID
sq905c 2770:913d All 4 known cameras with this ID
sq930x 2770:930b Sweex Motion Tracking / I-Tec iCam Tracer
sq930x 2770:930c Trust WB-3500T / NSG Robbie 2.0
spca500 2899:012c Toptro Industrial
ov519 8020:ef04 ov519
spca508 8086:0110 Intel Easy PC Camera
spca500 8086:0630 Intel Pocket PC Camera
spca506 99fa:8988 Grandtec V.cap
sn9c20x a168:0610 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
sn9c20x a168:0611 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
sn9c20x a168:0613 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
sn9c20x a168:0618 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
sn9c20x a168:0614 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
sn9c20x a168:0615 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
sn9c20x a168:0617 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
spca561 abcd:cdee Petcam

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://www.nenya.be/beor/electronics/rc5.htm and more data
http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
and even a reference to how to decode a bi-phase data stream.
http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
still more info

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

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

@@ -0,0 +1,123 @@
Vaio Picturebook Motion Eye Camera Driver Readme
------------------------------------------------
Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
Copyright (C) 2001-2002 Alcôve <www.alcove.com>
Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
This driver enable the use of video4linux compatible applications with the
Motion Eye camera. This driver requires the "Sony Laptop Extras" driver (which
can be found in the "Misc devices" section of the kernel configuration utility)
to be compiled and installed (using its "camera=1" parameter).
It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
Grabbing is supported in packed YUV colorspace only.
MJPEG hardware grabbing is supported via a private API (see below).
Hardware supported:
-------------------
This driver supports the 'second' version of the MotionEye camera :)
The first version was connected directly on the video bus of the Neomagic
video card and is unsupported.
The second one, made by Kawasaki Steel is fully supported by this
driver (PCI vendor/device is 0x136b/0xff01)
The third one, present in recent (more or less last year) Picturebooks
(C1M* models), is not supported. The manufacturer has given the specs
to the developers under a NDA (which allows the development of a GPL
driver however), but things are not moving very fast (see
http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
There is a forth model connected on the USB bus in TR1* Vaio laptops.
This camera is not supported at all by the current driver, in fact
little information if any is available for this camera
(USB vendor/device is 0x054c/0x0107).
Driver options:
---------------
Several options can be passed to the meye driver using the standard
module argument syntax (<param>=<value> when passing the option to the
module or meye.<param>=<value> on the kernel boot line when meye is
statically linked into the kernel). Those options are:
gbuffers: number of capture buffers, default is 2 (32 max)
gbufsize: size of each capture buffer, default is 614400
video_nr: video device to register (0 = /dev/video0, etc)
Module use:
-----------
In order to automatically load the meye module on use, you can put those lines
in your /etc/modprobe.d/meye.conf file:
alias char-major-81 videodev
alias char-major-81-0 meye
options meye gbuffers=32
Usage:
------
xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
for display and uncompressed video capture:
xawtv -c /dev/video0 -geometry 640x480
or
xawtv -c /dev/video0 -geometry 320x240
motioneye (<http://popies.net/meye/>)
for getting ppm or jpg snapshots, mjpeg video
Private API:
------------
The driver supports frame grabbing with the video4linux API,
so all video4linux tools (like xawtv) should work with this driver.
Besides the video4linux interface, the driver has a private interface
for accessing the Motion Eye extended parameters (camera sharpness,
agc, video framerate), the shapshot and the MJPEG capture facilities.
This interface consists of several ioctls (prototypes and structures
can be found in include/linux/meye.h):
MEYEIOC_G_PARAMS
MEYEIOC_S_PARAMS
Get and set the extended parameters of the motion eye camera.
The user should always query the current parameters with
MEYEIOC_G_PARAMS, change what he likes and then issue the
MEYEIOC_S_PARAMS call (checking for -EINVAL). The extended
parameters are described by the meye_params structure.
MEYEIOC_QBUF_CAPT
Queue a buffer for capture (the buffers must have been
obtained with a VIDIOCGMBUF call and mmap'ed by the
application). The argument to MEYEIOC_QBUF_CAPT is the
buffer number to queue (or -1 to end capture). The first
call to MEYEIOC_QBUF_CAPT starts the streaming capture.
MEYEIOC_SYNC
Takes as an argument the buffer number you want to sync.
This ioctl blocks until the buffer is filled and ready
for the application to use. It returns the buffer size.
MEYEIOC_STILLCAPT
MEYEIOC_STILLJCAPT
Takes a snapshot in an uncompressed or compressed jpeg format.
This ioctl blocks until the snapshot is done and returns (for
jpeg snapshot) the size of the image. The image data is
available from the first mmap'ed buffer.
Look at the 'motioneye' application code for an actual example.
Bugs / Todo:
------------
- 'motioneye' still uses the meye private v4l1 API extensions.

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

279
Documentation/video4linux/omap3isp.txt Normal file
View File

@@ -0,0 +1,279 @@
OMAP 3 Image Signal Processor (ISP) driver
Copyright (C) 2010 Nokia Corporation
Copyright (C) 2009 Texas Instruments, Inc.
Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Sakari Ailus <sakari.ailus@iki.fi>
David Cohen <dacohen@gmail.com>
Introduction
============
This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
driver located under drivers/media/platform/omap3isp. The original driver was
written by Texas Instruments but since that it has been rewritten (twice) at
Nokia.
The driver has been successfully used on the following versions of OMAP 3:
3430
3530
3630
The driver implements V4L2, Media controller and v4l2_subdev interfaces.
Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
are supported.
Split to subdevs
================
The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
interface to userspace.
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
Each possible link in the ISP is modelled by a link in the Media controller
interface. For an example program see [2].
Controlling the OMAP 3 ISP
==========================
In general, the settings given to the OMAP 3 ISP take effect at the beginning
of the following frame. This is done when the module becomes idle during the
vertical blanking period on the sensor. In memory-to-memory operation the pipe
is run one frame at a time. Applying the settings is done between the frames.
All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
insist on receiving complete frames. Sensors must thus never send the ISP
partial frames.
Autoidle does have issues with some ISP blocks on the 3430, at least.
Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
is non-zero.
Events
======
The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
statistics (AEWB, AF and histogram) subdevs.
The CCDC subdev produces V4L2_EVENT_FRAME_SYNC type event on HS_VS
interrupt which is used to signal frame start. Earlier version of this
driver used V4L2_EVENT_OMAP3ISP_HS_VS for this purpose. The event is
triggered exactly when the reception of the first line of the frame starts
in the CCDC module. The event can be subscribed on the CCDC subdev.
(When using parallel interface one must pay account to correct configuration
of the VS signal polarity. This is automatically correct when using the serial
receivers.)
Each of the statistics subdevs is able to produce events. An event is
generated whenever a statistics buffer can be dequeued by a user space
application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available
are:
V4L2_EVENT_OMAP3ISP_AEWB
V4L2_EVENT_OMAP3ISP_AF
V4L2_EVENT_OMAP3ISP_HIST
The type of the event data is struct omap3isp_stat_event_status for these
ioctls. If there is an error calculating the statistics, there will be an
event as usual, but no related statistics buffer. In this case
omap3isp_stat_event_status.buf_err is set to non-zero.
Private IOCTLs
==============
The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where
possible and practical. Much of the functions provided by the ISP, however,
does not fall under the standard IOCTLs --- gamma tables and configuration of
statistics collection are examples of such.
In general, there is a private ioctl for configuring each of the blocks
containing hardware-dependent functions.
The following private IOCTLs are supported:
VIDIOC_OMAP3ISP_CCDC_CFG
VIDIOC_OMAP3ISP_PRV_CFG
VIDIOC_OMAP3ISP_AEWB_CFG
VIDIOC_OMAP3ISP_HIST_CFG
VIDIOC_OMAP3ISP_AF_CFG
VIDIOC_OMAP3ISP_STAT_REQ
VIDIOC_OMAP3ISP_STAT_EN
The parameter structures used by these ioctls are described in
include/linux/omap3isp.h. The detailed functions of the ISP itself related to
a given ISP block is described in the Technical Reference Manuals (TRMs) ---
see the end of the document for those.
While it is possible to use the ISP driver without any use of these private
IOCTLs it is not possible to obtain optimal image quality this way. The AEWB,
AF and histogram modules cannot be used without configuring them using the
appropriate private IOCTLs.
CCDC and preview block IOCTLs
=============================
The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to
configure, enable and disable functions in the CCDC and preview blocks,
respectively. Both IOCTLs control several functions in the blocks they
control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct
omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG
accepts a pointer to struct omap3isp_prev_update_config. The definition of
both structures is available in [1].
The update field in the structures tells whether to update the configuration
for the specific function and the flag tells whether to enable or disable the
function.
The update and flag bit masks accept the following values. Each separate
functions in the CCDC and preview blocks is associated with a flag (either
disable or enable; part of the flag field in the structure) and a pointer to
configuration data for the function.
Valid values for the update and flag fields are listed here for
VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one
function in the same IOCTL call.
OMAP3ISP_CCDC_ALAW
OMAP3ISP_CCDC_LPF
OMAP3ISP_CCDC_BLCLAMP
OMAP3ISP_CCDC_BCOMP
OMAP3ISP_CCDC_FPC
OMAP3ISP_CCDC_CULL
OMAP3ISP_CCDC_CONFIG_LSC
OMAP3ISP_CCDC_TBL_LSC
The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here:
OMAP3ISP_PREV_LUMAENH
OMAP3ISP_PREV_INVALAW
OMAP3ISP_PREV_HRZ_MED
OMAP3ISP_PREV_CFA
OMAP3ISP_PREV_CHROMA_SUPP
OMAP3ISP_PREV_WB
OMAP3ISP_PREV_BLKADJ
OMAP3ISP_PREV_RGB2RGB
OMAP3ISP_PREV_COLOR_CONV
OMAP3ISP_PREV_YC_LIMIT
OMAP3ISP_PREV_DEFECT_COR
OMAP3ISP_PREV_GAMMABYPASS
OMAP3ISP_PREV_DRK_FRM_CAPTURE
OMAP3ISP_PREV_DRK_FRM_SUBTRACT
OMAP3ISP_PREV_LENS_SHADING
OMAP3ISP_PREV_NF
OMAP3ISP_PREV_GAMMA
The associated configuration pointer for the function may not be NULL when
enabling the function. When disabling a function the configuration pointer is
ignored.
Statistic blocks IOCTLs
=======================
The statistics subdevs do offer more dynamic configuration options than the
other subdevs. They can be enabled, disable and reconfigured when the pipeline
is in streaming state.
The statistics blocks always get the input image data from the CCDC (as the
histogram memory read isn't implemented). The statistics are dequeueable by
the user from the statistics subdev nodes using private IOCTLs.
The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily
reflected by the register level interface offered by the ISP hardware. There
are aspects that are purely related to the driver implementation and these are
discussed next.
VIDIOC_OMAP3ISP_STAT_EN
-----------------------
This private IOCTL enables/disables a statistic module. If this request is
done before streaming, it will take effect as soon as the pipeline starts to
stream. If the pipeline is already streaming, it will take effect as soon as
the CCDC becomes idle.
VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG
-----------------------------------------------------------------------------
Those IOCTLs are used to configure the modules. They require user applications
to have an in-depth knowledge of the hardware. Most of the fields explanation
can be found on OMAP's TRMs. The two following fields common to all the above
configure private IOCTLs require explanation for better understanding as they
are not part of the TRM.
omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size:
The modules handle their buffers internally. The necessary buffer size for the
module's data output depends on the requested configuration. Although the
driver supports reconfiguration while streaming, it does not support a
reconfiguration which requires bigger buffer size than what is already
internally allocated if the module is enabled. It will return -EBUSY on this
case. In order to avoid such condition, either disable/reconfigure/enable the
module or request the necessary buffer size during the first configuration
while the module is disabled.
The internal buffer size allocation considers the requested configuration's
minimum buffer size and the value set on buf_size field. If buf_size field is
out of [minimum, maximum] buffer size range, it's clamped to fit in there.
The driver then selects the biggest value. The corrected buf_size value is
written back to user application.
omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter:
As the configuration doesn't take effect synchronously to the request, the
driver must provide a way to track this information to provide more accurate
data. After a configuration is requested, the config_counter returned to user
space application will be an unique value associated to that request. When
user application receives an event for buffer availability or when a new
buffer is requested, this config_counter is used to match a buffer data and a
configuration.
VIDIOC_OMAP3ISP_STAT_REQ
------------------------
Send to user space the oldest data available in the internal buffer queue and
discards such buffer afterwards. The field omap3isp_stat_data.frame_number
matches with the video buffer's field_count.
Technical reference manuals (TRMs) and other documentation
==========================================================
OMAP 3430 TRM:
<URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip>
Referenced 2011-03-05.
OMAP 35xx TRM:
<URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05.
OMAP 3630 TRM:
<URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip>
Referenced 2011-03-05.
DM 3730 TRM:
<URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06.
References
==========
[1] include/linux/omap3isp.h
[2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary

174
Documentation/video4linux/pxa_camera.txt Normal file
View File

@@ -0,0 +1,174 @@
PXA-Camera Host Driver
======================
Constraints
-----------
a) Image size for YUV422P format
All YUV422P images are enforced to have width x height % 16 = 0.
This is due to DMA constraints, which transfers only planes of 8 byte
multiples.
Global video workflow
---------------------
a) QCI stopped
Initialy, the QCI interface is stopped.
When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
b) QCI started
More buffers can be queued while the QCI is started without halting the
capture. The new buffers are "appended" at the tail of the DMA chain, and
smoothly captured one frame after the other.
Once a buffer is filled in the QCI interface, it is marked as "DONE" and
removed from the active buffers list. It can be then requeud or dequeued by
userland application.
Once the last buffer is filled in, the QCI interface stops.
c) Capture global finite state machine schema
+----+ +---+ +----+
| DQ | | Q | | DQ |
| v | v | v
+-----------+ +------------------------+
| STOP | | Wait for capture start |
+-----------+ Q +------------------------+
+-> | QCI: stop | ------------------> | QCI: run | <------------+
| | DMA: stop | | DMA: stop | |
| +-----------+ +-----> +------------------------+ |
| / | |
| / +---+ +----+ | |
|capture list empty / | Q | | DQ | | QCI Irq EOF |
| / | v | v v |
| +--------------------+ +----------------------+ |
| | DMA hotlink missed | | Capture running | |
| +--------------------+ +----------------------+ |
| | QCI: run | +-----> | QCI: run | <-+ |
| | DMA: stop | / | DMA: run | | |
| +--------------------+ / +----------------------+ | Other |
| ^ /DMA still | | channels |
| | capture list / running | DMA Irq End | not |
| | not empty / | | finished |
| | / v | yet |
| +----------------------+ +----------------------+ | |
| | Videobuf released | | Channel completed | | |
| +----------------------+ +----------------------+ | |
+-- | QCI: run | | QCI: run | --+ |
| DMA: run | | DMA: run | |
+----------------------+ +----------------------+ |
^ / | |
| no overrun / | overrun |
| / v |
+--------------------+ / +----------------------+ |
| Frame completed | / | Frame overran | |
+--------------------+ <-----+ +----------------------+ restart frame |
| QCI: run | | QCI: stop | --------------+
| DMA: run | | DMA: stop |
+--------------------+ +----------------------+
Legend: - each box is a FSM state
- each arrow is the condition to transition to another state
- an arrow with a comment is a mandatory transition (no condition)
- arrow "Q" means : a buffer was enqueued
- arrow "DQ" means : a buffer was dequeued
- "QCI: stop" means the QCI interface is not enabled
- "DMA: stop" means all 3 DMA channels are stopped
- "DMA: run" means at least 1 DMA channel is still running
DMA usage
---------
a) DMA flow
- first buffer queued for capture
Once a first buffer is queued for capture, the QCI is started, but data
transfer is not started. On "End Of Frame" interrupt, the irq handler
starts the DMA chain.
- capture of one videobuffer
The DMA chain starts transferring data into videobuffer RAM pages.
When all pages are transferred, the DMA irq is raised on "ENDINTR" status
- finishing one videobuffer
The DMA irq handler marks the videobuffer as "done", and removes it from
the active running queue
Meanwhile, the next videobuffer (if there is one), is transferred by DMA
- finishing the last videobuffer
On the DMA irq of the last videobuffer, the QCI is stopped.
b) DMA prepared buffer will have this structure
+------------+-----+---------------+-----------------+
| desc-sg[0] | ... | desc-sg[last] | finisher/linker |
+------------+-----+---------------+-----------------+
This structure is pointed by dma->sg_cpu.
The descriptors are used as follows :
- desc-sg[i]: i-th descriptor, transferring the i-th sg
element to the video buffer scatter gather
- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
"f" stands for finisher and "l" for linker.
A typical running chain is :
Videobuffer 1 Videobuffer 2
+---------+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+---+
| |
+----+
After the chaining is finished, the chain looks like :
Videobuffer 1 Videobuffer 2 Videobuffer 3
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
| | | |
+----+ +----+
new_link
c) DMA hot chaining timeslice issue
As DMA chaining is done while DMA _is_ running, the linking may be done
while the DMA jumps from one Videobuffer to another. On the schema, that
would be a problem if the following sequence is encountered :
- DMA chain is Videobuffer1 + Videobuffer2
- pxa_videobuf_queue() is called to queue Videobuffer3
- DMA controller finishes Videobuffer2, and DMA stops
=>
Videobuffer 1 Videobuffer 2
+---------+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-^-+
| | |
+----+ +-- DMA DDADR loads DDADR_STOP
- pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
replaced by a "linker" to Videobuffer3 (creation of new_link)
- pxa_videobuf_queue() finishes
- the DMA irq handler is called, which terminates Videobuffer2
- Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
Videobuffer 1 Videobuffer 2 Videobuffer 3
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
| | | |
+----+ +----+
new_link
DMA DDADR still is DDADR_STOP
- pxa_camera_check_link_miss() is called
This checks if the DMA is finished and a buffer is still on the
pcdev->capture list. If that's the case, the capture will be restarted,
and Videobuffer3 is scheduled on DMA chain.
- the DMA irq handler finishes
Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR()
value, we have the guarantee that the DMA irq handler will be called back
when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
be called again, to reschedule Videobuffer3.
--
Author: Robert Jarzmik <robert.jarzmik@free.fr>

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

139
Documentation/video4linux/sh_mobile_ceu_camera.txt Normal file
View File

@@ -0,0 +1,139 @@
Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
=======================================================================
Terminology
-----------
sensor scales: horizontal and vertical scales, configured by the sensor driver
host scales: -"- host driver
combined scales: sensor_scale * host_scale
Generic scaling / cropping scheme
---------------------------------
-1--
|
-2-- -\
| --\
| --\
+-5-- . -- -3-- -\
| `... -\
| `... -4-- . - -7..
| `.
| `. .6--
|
| . .6'-
| .´
| ... -4'- .´
| ...´ - -7'.
+-5'- .´ -/
| -- -3'- -/
| --/
| --/
-2'- -/
|
|
-1'-
In the above chart minuses and slashes represent "real" data amounts, points and
accents represent "useful" data, basically, CEU scaled and cropped output,
mapped back onto the client's source plane.
Such a configuration can be produced by user requests:
S_CROP(left / top = (5) - (1), width / height = (5') - (5))
S_FMT(width / height = (6') - (6))
Here:
(1) to (1') - whole max width or height
(1) to (2) - sensor cropped left or top
(2) to (2') - sensor cropped width or height
(3) to (3') - sensor scale
(3) to (4) - CEU cropped left or top
(4) to (4') - CEU cropped width or height
(5) to (5') - reverse sensor scale applied to CEU cropped width or height
(2) to (5) - reverse sensor scale applied to CEU cropped left or top
(6) to (6') - CEU scale - user window
S_FMT
-----
Do not touch input rectangle - it is already optimal.
1. Calculate current sensor scales:
scale_s = ((2') - (2)) / ((3') - (3))
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
current sensor scales onto input window - this is user S_CROP:
width_u = (5') - (5) = ((4') - (4)) * scale_s
3. Calculate new combined scales from "effective" input window to requested user
window:
scale_comb = width_u / ((6') - (6))
4. Calculate sensor output window by applying combined scales to real input
window:
width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
5. Apply iterative sensor S_FMT for sensor output window.
subdev->video_ops->s_fmt(.width = width_s_out)
6. Retrieve sensor output window (g_fmt)
7. Calculate new sensor scales:
scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
8. Calculate new CEU crop - apply sensor scales to previously calculated
"effective" crop:
width_ceu = (4')_new - (4)_new = width_u / scale_s_new
left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
9. Use CEU cropping to crop to the new window:
ceu_crop(.width = width_ceu, .left = left_ceu)
10. Use CEU scaling to scale to the requested user window:
scale_ceu = width_ceu / width
S_CROP
------
The API at http://v4l2spec.bytesex.org/spec/x1904.htm says:
"...specification does not define an origin or units. However by convention
drivers should horizontally count unscaled samples relative to 0H."
We choose to follow the advise and interpret cropping units as client input
pixels.
Cropping is performed in the following 6 steps:
1. Request exactly user rectangle from the sensor.
2. If smaller - iterate until a larger one is obtained. Result: sensor cropped
to 2 : 2', target crop 5 : 5', current output format 6' - 6.
3. In the previous step the sensor has tried to preserve its output frame as
good as possible, but it could have changed. Retrieve it again.
4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate
intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2)
5. Calculate and apply host scale = (6' - 6) / (4' - 4)
6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5)
--
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

129
Documentation/video4linux/si470x.txt Normal file
View File

@@ -0,0 +1,129 @@
Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers
Copyright (c) 2009 Tobias Lorenz <tobias.lorenz@gmx.net>
Information from Silicon Labs
=============================
Silicon Laboratories is the manufacturer of the radio ICs, that nowadays are the
most often used radio receivers in cell phones. Usually they are connected with
I2C. But SiLabs also provides a reference design, which integrates this IC,
together with a small microcontroller C8051F321, to form a USB radio.
Part of this reference design is also a radio application in binary and source
code. The software also contains an automatic firmware upgrade to the most
current version. Information on these can be downloaded here:
http://www.silabs.com/usbradio
Supported ICs
=============
The following ICs have a very similar register set, so that they are or will be
supported somewhen by the driver:
- Si4700: FM radio receiver
- Si4701: FM radio receiver, RDS Support
- Si4702: FM radio receiver
- Si4703: FM radio receiver, RDS Support
- Si4704: FM radio receiver, no external antenna required
- Si4705: FM radio receiver, no external antenna required, RDS support, Dig I/O
- Si4706: Enhanced FM RDS/TMC radio receiver, no external antenna required, RDS
Support
- Si4707: Dedicated weather band radio receiver with SAME decoder, RDS Support
- Si4708: Smallest FM receivers
- Si4709: Smallest FM receivers, RDS Support
More information on these can be downloaded here:
http://www.silabs.com/products/mcu/Pages/USBFMRadioRD.aspx
Supported USB devices
=====================
Currently the following USB radios (vendor:product) with the Silicon Labs si470x
chips are known to work:
- 10c4:818a: Silicon Labs USB FM Radio Reference Design
- 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF)
- 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700)
- 10c5:819a: Sanei Electric, Inc. FM USB Radio (sold as DealExtreme.com PCear)
Software
========
Testing is usually done with most application under Debian/testing:
- fmtools - Utility for managing FM tuner cards
- gnomeradio - FM-radio tuner for the GNOME desktop
- gradio - GTK FM radio tuner
- kradio - Comfortable Radio Application for KDE
- radio - ncurses-based radio application
- mplayer - The Ultimate Movie Player For Linux
- v4l2-ctl - Collection of command line video4linux utilities
For example, you can use:
v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all
There is also a library libv4l, which can be used. It's going to have a function
for frequency seeking, either by using hardware functionality as in radio-si470x
or by implementing a function as we currently have in every of the mentioned
programs. Somewhen the radio programs should make use of libv4l.
For processing RDS information, there is a project ongoing at:
http://rdsd.berlios.de/
There is currently no project for making TMC sentences human readable.
Audio Listing
=============
USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to
also select SND_USB_AUDIO, as this is required to get sound from the radio. For
listing you have to redirect the sound, for example using one of the following
commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x).
If you just want to test audio (very poor quality):
cat /dev/dsp1 > /dev/dsp
If you use sox + OSS try:
sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
or using sox + alsa:
sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0
If you use arts try:
arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
If you use mplayer try:
mplayer -radio adevice=hw=1.0:arate=96000 \
-rawaudio rate=96000 \
radio://<frequency>/capture
Module Parameters
=================
After loading the module, you still have access to some of them in the sysfs
mount under /sys/module/radio_si470x/parameters. The contents of read-only files
(0444) are not updated, even if space, band and de are changed using private
video controls. The others are runtime changeable.
Errors
======
Increase tune_timeout, if you often get -EIO errors.
When timed out or band limit is reached, hw_freq_seek returns -EAGAIN.
If you get any errors from snd_usb_audio, please report them to the ALSA people.
Open Issues
===========
V4L minor device allocation and parameter setting is not perfect. A solution is
currently under discussion.
There is an USB interface for downloading/uploading new firmware images. Support
for it can be implemented using the request_firmware interface.
There is a RDS interrupt mode. The driver is already using the same interface
for polling RDS information, but is currently not using the interrupt mode.
There is a LED interface, which can be used to override the LED control
programmed in the firmware. This can be made available using the LED support
functions in the kernel.
Other useful information and links
==================================
http://www.silabs.com/usbradio

176
Documentation/video4linux/si4713.txt Normal file
View File

@@ -0,0 +1,176 @@
Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters
Copyright (c) 2009 Nokia Corporation
Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
Information about the Device
============================
This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address.
Basically, it has transmission and signal noise level measurement features.
The Si4713 integrates transmit functions for FM broadcast stereo transmission.
The chip also allows integrated receive power scanning to identify low signal
power FM channels.
The chip is programmed using commands and responses. There are also several
properties which can change the behavior of this chip.
Users must comply with local regulations on radio frequency (RF) transmission.
Device driver description
=========================
There are two modules to handle this device. One is a I2C device driver
and the other is a platform driver.
The I2C device driver exports a v4l2-subdev interface to the kernel.
All properties can also be accessed by v4l2 extended controls interface, by
using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls).
The platform device driver exports a v4l2 radio device interface to user land.
So, it uses the I2C device driver as a sub device in order to send the user
commands to the actual device. Basically it is a wrapper to the I2C device driver.
Applications can use v4l2 radio API to specify frequency of operation, mute state,
etc. But mostly of its properties will be present in the extended controls.
When the v4l2 mute property is set to 1 (true), the driver will turn the chip off.
Properties description
======================
The properties can be accessed using v4l2 extended controls.
Here is an output from v4l2-ctl util:
/ # v4l2-ctl -d /dev/radio0 --all -L
Driver Info:
Driver name : radio-si4713
Card type : Silicon Labs Si4713 Modulator
Bus info :
Driver version: 0
Capabilities : 0x00080800
RDS Output
Modulator
Audio output: 0 (FM Modulator Audio Out)
Frequency: 1408000 (88.000000 MHz)
Video Standard = 0x00000000
Modulator:
Name : FM Modulator
Capabilities : 62.5 Hz stereo rds
Frequency range : 76.0 MHz - 108.0 MHz
Subchannel modulation: stereo+rds
User Controls
mute (bool) : default=1 value=0
FM Radio Modulator Controls
rds_signal_deviation (int) : min=0 max=90000 step=10 default=200 value=200 flags=slider
rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0
rds_program_type (int) : min=0 max=31 step=1 default=0 value=0
rds_ps_name (str) : min=0 max=96 step=8 value='si4713 '
rds_radio_text (str) : min=0 max=384 step=32 value=''
audio_limiter_feature_enabled (bool) : default=1 value=1
audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider
audio_limiter_deviation (int) : min=0 max=90000 step=10 default=66250 value=66250 flags=slider
audio_compression_feature_enabl (bool) : default=1 value=1
audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider
audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider
audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=0 flags=slider
audio_compression_release_time (int) : min=100000 max=1000000 step=100000 default=1000000 value=1000000 flags=slider
pilot_tone_feature_enabled (bool) : default=1 value=1
pilot_tone_deviation (int) : min=0 max=90000 step=10 default=6750 value=6750 flags=slider
pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider
pre_emphasis_settings (menu) : min=0 max=2 default=1 value=1
tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider
tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider
/ #
Here is a summary of them:
* Pilot is an audible tone sent by the device.
pilot_frequency - Configures the frequency of the stereo pilot tone.
pilot_deviation - Configures pilot tone frequency deviation level.
pilot_enabled - Enables or disables the pilot tone feature.
* The si4713 device is capable of applying audio compression to the transmitted signal.
acomp_enabled - Enables or disables the audio dynamic range control feature.
acomp_gain - Sets the gain for audio dynamic range control.
acomp_threshold - Sets the threshold level for audio dynamic range control.
acomp_attack_time - Sets the attack time for audio dynamic range control.
acomp_release_time - Sets the release time for audio dynamic range control.
* Limiter setups audio deviation limiter feature. Once a over deviation occurs,
it is possible to adjust the front-end gain of the audio input and always
prevent over deviation.
limiter_enabled - Enables or disables the limiter feature.
limiter_deviation - Configures audio frequency deviation level.
limiter_release_time - Sets the limiter release time.
* Tuning power
power_level - Sets the output power level for signal transmission.
antenna_capacitor - This selects the value of antenna tuning capacitor manually
or automatically if set to zero.
* RDS related
rds_ps_name - Sets the RDS ps name field for transmission.
rds_radio_text - Sets the RDS radio text for transmission.
rds_pi - Sets the RDS PI field for transmission.
rds_pty - Sets the RDS PTY field for transmission.
* Region related
preemphasis - sets the preemphasis to be applied for transmission.
RNL
===
This device also has an interface to measure received noise level. To do that, you should
ioctl the device node. Here is an code of example:
int main (int argc, char *argv[])
{
struct si4713_rnl rnl;
int fd = open("/dev/radio0", O_RDWR);
int rval;
if (argc < 2)
return -EINVAL;
if (fd < 0)
return fd;
sscanf(argv[1], "%d", &rnl.frequency);
rval = ioctl(fd, SI4713_IOC_MEASURE_RNL, &rnl);
if (rval < 0)
return rval;
printf("received noise level: %d\n", rnl.rnl);
close(fd);
}
The struct si4713_rnl and SI4713_IOC_MEASURE_RNL are defined under
include/media/si4713.h.
Stereo/Mono and RDS subchannels
===============================
The device can also be configured using the available sub channels for
transmission. To do that use S/G_MODULATOR ioctl and configure txsubchans properly.
Refer to the V4L2 API specification for proper use of this ioctl.
Testing
=======
Testing is usually done with v4l2-ctl utility for managing FM tuner cards.
The tool can be found in v4l-dvb repository under v4l2-apps/util directory.
Example for setting rds ps name:
# v4l2-ctl -d /dev/radio0 --set-ctrl=rds_ps_name="Dummy"

187
Documentation/video4linux/si476x.txt Normal file
View File

@@ -0,0 +1,187 @@
SI476x Driver Readme
------------------------------------------------
Copyright (C) 2013 Andrey Smirnov <andrew.smirnov@gmail.com>
TODO for the driver
------------------------------
- According to the SiLabs' datasheet it is possible to update the
firmware of the radio chip in the run-time, thus bringing it to the
most recent version. Unfortunately I couldn't find any mentioning of
the said firmware update for the old chips that I tested the driver
against, so for chips like that the driver only exposes the old
functionality.
Parameters exposed over debugfs
-------------------------------
SI476x allow user to get multiple characteristics that can be very
useful for EoL testing/RF performance estimation, parameters that have
very little to do with V4L2 subsystem. Such parameters are exposed via
debugfs and can be accessed via regular file I/O operations.
The drivers exposes following files:
* /sys/kernel/debug/<device-name>/acf
This file contains ACF(Automatically Controlled Features) status
information. The contents of the file is binary data of the
following layout:
Offset | Name | Description
====================================================================
0x00 | blend_int | Flag, set when stereo separation has
| | crossed below the blend threshold
--------------------------------------------------------------------
0x01 | hblend_int | Flag, set when HiBlend cutoff
| | frequency is lower than threshold
--------------------------------------------------------------------
0x02 | hicut_int | Flag, set when HiCut cutoff
| | frequency is lower than threshold
--------------------------------------------------------------------
0x03 | chbw_int | Flag, set when channel filter
| | bandwidth is less than threshold
--------------------------------------------------------------------
0x04 | softmute_int | Flag indicating that softmute
| | attenuation has increased above
| | softmute threshold
--------------------------------------------------------------------
0x05 | smute | 0 - Audio is not soft muted
| | 1 - Audio is soft muted
--------------------------------------------------------------------
0x06 | smattn | Soft mute attenuation level in dB
--------------------------------------------------------------------
0x07 | chbw | Channel filter bandwidth in kHz
--------------------------------------------------------------------
0x08 | hicut | HiCut cutoff frequency in units of
| | 100Hz
--------------------------------------------------------------------
0x09 | hiblend | HiBlend cutoff frequency in units
| | of 100 Hz
--------------------------------------------------------------------
0x10 | pilot | 0 - Stereo pilot is not present
| | 1 - Stereo pilot is present
--------------------------------------------------------------------
0x11 | stblend | Stereo blend in %
--------------------------------------------------------------------
* /sys/kernel/debug/<device-name>/rds_blckcnt
This file contains statistics about RDS receptions. It's binary data
has the following layout:
Offset | Name | Description
====================================================================
0x00 | expected | Number of expected RDS blocks
--------------------------------------------------------------------
0x02 | received | Number of received RDS blocks
--------------------------------------------------------------------
0x04 | uncorrectable | Number of uncorrectable RDS blocks
--------------------------------------------------------------------
* /sys/kernel/debug/<device-name>/agc
This file contains information about parameters pertaining to
AGC(Automatic Gain Control)
The layout is:
Offset | Name | Description
====================================================================
0x00 | mxhi | 0 - FM Mixer PD high threshold is
| | not tripped
| | 1 - FM Mixer PD high threshold is
| | tripped
--------------------------------------------------------------------
0x01 | mxlo | ditto for FM Mixer PD low
--------------------------------------------------------------------
0x02 | lnahi | ditto for FM LNA PD high
--------------------------------------------------------------------
0x03 | lnalo | ditto for FM LNA PD low
--------------------------------------------------------------------
0x04 | fmagc1 | FMAGC1 attenuator resistance
| | (see datasheet for more detail)
--------------------------------------------------------------------
0x05 | fmagc2 | ditto for FMAGC2
--------------------------------------------------------------------
0x06 | pgagain | PGA gain in dB
--------------------------------------------------------------------
0x07 | fmwblang | FM/WB LNA Gain in dB
--------------------------------------------------------------------
* /sys/kernel/debug/<device-name>/rsq
This file contains information about parameters pertaining to
RSQ(Received Signal Quality)
The layout is:
Offset | Name | Description
====================================================================
0x00 | multhint | 0 - multipath value has not crossed
| | the Multipath high threshold
| | 1 - multipath value has crossed
| | the Multipath high threshold
--------------------------------------------------------------------
0x01 | multlint | ditto for Multipath low threshold
--------------------------------------------------------------------
0x02 | snrhint | 0 - received signal's SNR has not
| | crossed high threshold
| | 1 - received signal's SNR has
| | crossed high threshold
--------------------------------------------------------------------
0x03 | snrlint | ditto for low threshold
--------------------------------------------------------------------
0x04 | rssihint | ditto for RSSI high threshold
--------------------------------------------------------------------
0x05 | rssilint | ditto for RSSI low threshold
--------------------------------------------------------------------
0x06 | bltf | Flag indicating if seek command
| | reached/wrapped seek band limit
--------------------------------------------------------------------
0x07 | snr_ready | Indicates that SNR metrics is ready
--------------------------------------------------------------------
0x08 | rssiready | ditto for RSSI metrics
--------------------------------------------------------------------
0x09 | injside | 0 - Low-side injection is being used
| | 1 - High-side injection is used
--------------------------------------------------------------------
0x10 | afcrl | Flag indicating if AFC rails
--------------------------------------------------------------------
0x11 | valid | Flag indicating if channel is valid
--------------------------------------------------------------------
0x12 | readfreq | Current tuned frequency
--------------------------------------------------------------------
0x14 | freqoff | Singed frequency offset in units of
| | 2ppm
--------------------------------------------------------------------
0x15 | rssi | Signed value of RSSI in dBuV
--------------------------------------------------------------------
0x16 | snr | Signed RF SNR in dB
--------------------------------------------------------------------
0x17 | issi | Signed Image Strength Signal
| | indicator
--------------------------------------------------------------------
0x18 | lassi | Signed Low side adjacent Channel
| | Strength indicator
--------------------------------------------------------------------
0x19 | hassi | ditto fpr High side
--------------------------------------------------------------------
0x20 | mult | Multipath indicator
--------------------------------------------------------------------
0x21 | dev | Frequency deviation
--------------------------------------------------------------------
0x24 | assi | Adjascent channel SSI
--------------------------------------------------------------------
0x25 | usn | Ultrasonic noise indicator
--------------------------------------------------------------------
0x26 | pilotdev | Pilot deviation in units of 100 Hz
--------------------------------------------------------------------
0x27 | rdsdev | ditto for RDS
--------------------------------------------------------------------
0x28 | assidev | ditto for ASSI
--------------------------------------------------------------------
0x29 | strongdev | Frequency deviation
--------------------------------------------------------------------
0x30 | rdspi | RDS PI code
--------------------------------------------------------------------
* /sys/kernel/debug/<device-name>/rsq_primary
This file contains information about parameters pertaining to
RSQ(Received Signal Quality) for primary tuner only. Layout is as
the one above.

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

@@ -0,0 +1,592 @@
SN9C1xx PC Camera Controllers
Driver for Linux
=============================
- Documentation -
Index
=====
1. Copyright
2. Disclaimer
3. License
4. Overview and features
5. Module dependencies
6. Module loading
7. Module parameters
8. Optional device control through "sysfs"
9. Supported devices
10. Notes for V4L2 application developers
11. Video frame formats
12. Contact information
13. Credits
1. Copyright
============
Copyright (C) 2004-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
2. Disclaimer
=============
SONiX is a trademark of SONiX Technology Company Limited, inc.
This software is not sponsored or developed by SONiX.
3. License
==========
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
4. Overview and features
========================
This driver attempts to support the video interface of the devices assembling
the SONiX SN9C101, SN9C102, SN9C103, SN9C105 and SN9C120 PC Camera Controllers
("SN9C1xx" from now on).
The driver relies on the Video4Linux2 and USB core modules. It has been
designed to run properly on SMP systems as well.
The latest version of the SN9C1xx driver can be found at the following URL:
http://www.linux-projects.org/
Some of the features of the driver are:
- full compliance with the Video4Linux2 API (see also "Notes for V4L2
application developers" paragraph);
- available mmap or read/poll methods for video streaming through isochronous
data transfers;
- automatic detection of image sensor;
- support for built-in microphone interface;
- support for any window resolutions and optional panning within the maximum
pixel area of image sensor;
- image downscaling with arbitrary scaling factors from 1, 2 and 4 in both
directions (see "Notes for V4L2 application developers" paragraph);
- two different video formats for uncompressed or compressed data in low or
high compression quality (see also "Notes for V4L2 application developers"
and "Video frame formats" paragraphs);
- full support for the capabilities of many of the possible image sensors that
can be connected to the SN9C1xx bridges, including, for instance, red, green,
blue and global gain adjustments and exposure (see "Supported devices"
paragraph for details);
- use of default color settings for sunlight conditions;
- dynamic I/O interface for both SN9C1xx and image sensor control and
monitoring (see "Optional device control through 'sysfs'" paragraph);
- dynamic driver control thanks to various module parameters (see "Module
parameters" paragraph);
- up to 64 cameras can be handled at the same time; they can be connected and
disconnected from the host many times without turning off the computer, if
the system supports hotplugging;
- no known bugs.
5. Module dependencies
======================
For it to work properly, the driver needs kernel support for Video4Linux and
USB.
The following options of the kernel configuration file must be enabled and
corresponding modules must be compiled:
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
To enable advanced debugging functionality on the device through /sysfs:
# Multimedia devices
#
CONFIG_VIDEO_ADV_DEBUG=y
# USB support
#
CONFIG_USB=m
In addition, depending on the hardware being used, the modules below are
necessary:
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
The SN9C103, SN9c105 and SN9C120 controllers also provide a built-in microphone
interface. It is supported by the USB Audio driver thanks to the ALSA API:
# Sound
#
CONFIG_SOUND=y
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
# USB devices
#
CONFIG_SND_USB_AUDIO=m
And finally:
# USB Multimedia devices
#
CONFIG_USB_SN9C102=m
6. Module loading
=================
To use the driver, it is necessary to load the "sn9c102" module into memory
after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
"uhci-hcd" or "ohci-hcd".
Loading can be done as shown below:
[root@localhost home]# modprobe sn9c102
Note that the module is called "sn9c102" for historic reasons, although it
does not just support the SN9C102.
At this point all the devices supported by the driver and connected to the USB
ports should be recognized. You can invoke "dmesg" to analyze kernel messages
and verify that the loading process has gone well:
[user@localhost home]$ dmesg
or, to isolate all the kernel messages generated by the driver:
[user@localhost home]$ dmesg | grep sn9c102
7. Module parameters
====================
Module parameters are listed below:
-------------------------------------------------------------------------------
Name: video_nr
Type: short array (min = 0, max = 64)
Syntax: <-1|n[,...]>
Description: Specify V4L2 minor mode number:
-1 = use next available
n = use minor number n
You can specify up to 64 cameras this way.
For example:
video_nr=-1,2,-1 would assign minor number 2 to the second
recognized camera and use auto for the first one and for every
other camera.
Default: -1
-------------------------------------------------------------------------------
Name: force_munmap
Type: bool array (min = 0, max = 64)
Syntax: <0|1[,...]>
Description: Force the application to unmap previously mapped buffer memory
before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
all the applications support this feature. This parameter is
specific for each detected camera.
0 = do not force memory unmapping
1 = force memory unmapping (save memory)
Default: 0
-------------------------------------------------------------------------------
Name: frame_timeout
Type: uint array (min = 0, max = 64)
Syntax: <0|n[,...]>
Description: Timeout for a video frame in seconds before returning an I/O
error; 0 for infinity. This parameter is specific for each
detected camera and can be changed at runtime thanks to the
/sys filesystem interface.
Default: 2
-------------------------------------------------------------------------------
Name: debug
Type: ushort
Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
2 = significant information
3 = more verbose messages
Level 3 is useful for testing only. It also shows some more
information about the hardware being detected.
This parameter can be changed at runtime thanks to the /sys
filesystem interface.
Default: 2
-------------------------------------------------------------------------------
8. Optional device control through "sysfs" [1]
==========================================
If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled,
it is possible to read and write both the SN9C1xx and the image sensor
registers by using the "sysfs" filesystem interface.
Every time a supported device is recognized, a write-only file named "green" is
created in the /sys/class/video4linux/videoX directory. You can set the green
channel's gain by writing the desired value to it. The value may range from 0
to 15 for the SN9C101 or SN9C102 bridges, from 0 to 127 for the SN9C103,
SN9C105 and SN9C120 bridges.
Similarly, only for the SN9C103, SN9C105 and SN9C120 controllers, blue and red
gain control files are available in the same directory, for which accepted
values may range from 0 to 127.
There are other four entries in the directory above for each registered camera:
"reg", "val", "i2c_reg" and "i2c_val". The first two files control the
SN9C1xx bridge, while the other two control the sensor chip. "reg" and
"i2c_reg" hold the values of the current register index where the following
reading/writing operations are addressed at through "val" and "i2c_val". Their
use is not intended for end-users. Note that "i2c_reg" and "i2c_val" will not
be created if the sensor does not actually support the standard I2C protocol or
its registers are not 8-bit long. Also, remember that you must be logged in as
root before writing to them.
As an example, suppose we were to want to read the value contained in the
register number 1 of the sensor register table - which is usually the product
identifier - of the camera registered as "/dev/video0":
[root@localhost #] cd /sys/class/video4linux/video0
[root@localhost #] echo 1 > i2c_reg
[root@localhost #] cat i2c_val
Note that "cat" will fail if sensor registers cannot be read.
Now let's set the green gain's register of the SN9C101 or SN9C102 chips to 2:
[root@localhost #] echo 0x11 > reg
[root@localhost #] echo 2 > val
Note that the SN9C1xx always returns 0 when some of its registers are read.
To avoid race conditions, all the I/O accesses to the above files are
serialized.
The sysfs interface also provides the "frame_header" entry, which exports the
frame header of the most recent requested and captured video frame. The header
is always 18-bytes long and is appended to every video frame by the SN9C1xx
controllers. As an example, this additional information can be used by the user
application for implementing auto-exposure features via software.
The following table describes the frame header exported by the SN9C101 and
SN9C102:
Byte # Value or bits Description
------ ------------- -----------
0x00 0xFF Frame synchronisation pattern
0x01 0xFF Frame synchronisation pattern
0x02 0x00 Frame synchronisation pattern
0x03 0xC4 Frame synchronisation pattern
0x04 0xC4 Frame synchronisation pattern
0x05 0x96 Frame synchronisation pattern
0x06 [3:0] Read channel gain control = (1+R_GAIN/8)
[7:4] Blue channel gain control = (1+B_GAIN/8)
0x07 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled
[2:1] Maximum scale factor for compression
[ 3 ] 1 = USB fifo(2K bytes) is full
[ 4 ] 1 = Digital gain is finish
[ 5 ] 1 = Exposure is finish
[7:6] Frame index
0x08 [7:0] Y sum inside Auto-Exposure area (low-byte)
0x09 [7:0] Y sum inside Auto-Exposure area (high-byte)
where Y sum = (R/4 + 5G/16 + B/8) / 32
0x0A [7:0] Y sum outside Auto-Exposure area (low-byte)
0x0B [7:0] Y sum outside Auto-Exposure area (high-byte)
where Y sum = (R/4 + 5G/16 + B/8) / 128
0x0C 0xXX Not used
0x0D 0xXX Not used
0x0E 0xXX Not used
0x0F 0xXX Not used
0x10 0xXX Not used
0x11 0xXX Not used
The following table describes the frame header exported by the SN9C103:
Byte # Value or bits Description
------ ------------- -----------
0x00 0xFF Frame synchronisation pattern
0x01 0xFF Frame synchronisation pattern
0x02 0x00 Frame synchronisation pattern
0x03 0xC4 Frame synchronisation pattern
0x04 0xC4 Frame synchronisation pattern
0x05 0x96 Frame synchronisation pattern
0x06 [6:0] Read channel gain control = (1/2+R_GAIN/64)
0x07 [6:0] Blue channel gain control = (1/2+B_GAIN/64)
[7:4]
0x08 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled
[2:1] Maximum scale factor for compression
[ 3 ] 1 = USB fifo(2K bytes) is full
[ 4 ] 1 = Digital gain is finish
[ 5 ] 1 = Exposure is finish
[7:6] Frame index
0x09 [7:0] Y sum inside Auto-Exposure area (low-byte)
0x0A [7:0] Y sum inside Auto-Exposure area (high-byte)
where Y sum = (R/4 + 5G/16 + B/8) / 32
0x0B [7:0] Y sum outside Auto-Exposure area (low-byte)
0x0C [7:0] Y sum outside Auto-Exposure area (high-byte)
where Y sum = (R/4 + 5G/16 + B/8) / 128
0x0D [1:0] Audio frame number
[ 2 ] 1 = Audio is recording
0x0E [7:0] Audio summation (low-byte)
0x0F [7:0] Audio summation (high-byte)
0x10 [7:0] Audio sample count
0x11 [7:0] Audio peak data in audio frame
The AE area (sx, sy, ex, ey) in the active window can be set by programming the
registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C1xx controllers, where one unit
corresponds to 32 pixels.
[1] The frame headers exported by the SN9C105 and SN9C120 are not described.
9. Supported devices
====================
None of the names of the companies as well as their products will be mentioned
here. They have never collaborated with the author, so no advertising.
From the point of view of a driver, what unambiguously identify a device are
its vendor and product USB identifiers. Below is a list of known identifiers of
devices assembling the SN9C1xx PC camera controllers:
Vendor ID Product ID
--------- ----------
0x0458 0x7025
0x045e 0x00f5
0x045e 0x00f7
0x0471 0x0327
0x0471 0x0328
0x0c45 0x6001
0x0c45 0x6005
0x0c45 0x6007
0x0c45 0x6009
0x0c45 0x600d
0x0c45 0x6011
0x0c45 0x6019
0x0c45 0x6024
0x0c45 0x6025
0x0c45 0x6028
0x0c45 0x6029
0x0c45 0x602a
0x0c45 0x602b
0x0c45 0x602c
0x0c45 0x602d
0x0c45 0x602e
0x0c45 0x6030
0x0c45 0x603f
0x0c45 0x6080
0x0c45 0x6082
0x0c45 0x6083
0x0c45 0x6088
0x0c45 0x608a
0x0c45 0x608b
0x0c45 0x608c
0x0c45 0x608e
0x0c45 0x608f
0x0c45 0x60a0
0x0c45 0x60a2
0x0c45 0x60a3
0x0c45 0x60a8
0x0c45 0x60aa
0x0c45 0x60ab
0x0c45 0x60ac
0x0c45 0x60ae
0x0c45 0x60af
0x0c45 0x60b0
0x0c45 0x60b2
0x0c45 0x60b3
0x0c45 0x60b8
0x0c45 0x60ba
0x0c45 0x60bb
0x0c45 0x60bc
0x0c45 0x60be
0x0c45 0x60c0
0x0c45 0x60c2
0x0c45 0x60c8
0x0c45 0x60cc
0x0c45 0x60ea
0x0c45 0x60ec
0x0c45 0x60ef
0x0c45 0x60fa
0x0c45 0x60fb
0x0c45 0x60fc
0x0c45 0x60fe
0x0c45 0x6102
0x0c45 0x6108
0x0c45 0x610f
0x0c45 0x6130
0x0c45 0x6138
0x0c45 0x613a
0x0c45 0x613b
0x0c45 0x613c
0x0c45 0x613e
The list above does not imply that all those devices work with this driver: up
until now only the ones that assemble the following pairs of SN9C1xx bridges
and image sensors are supported; kernel messages will always tell you whether
this is the case (see "Module loading" paragraph):
Image sensor / SN9C1xx bridge | SN9C10[12] SN9C103 SN9C105 SN9C120
-------------------------------------------------------------------------------
HV7131D Hynix Semiconductor | Yes No No No
HV7131R Hynix Semiconductor | No Yes Yes Yes
MI-0343 Micron Technology | Yes No No No
MI-0360 Micron Technology | No Yes Yes Yes
OV7630 OmniVision Technologies | Yes Yes Yes Yes
OV7660 OmniVision Technologies | No No Yes Yes
PAS106B PixArt Imaging | Yes No No No
PAS202B PixArt Imaging | Yes Yes No No
TAS5110C1B Taiwan Advanced Sensor | Yes No No No
TAS5110D Taiwan Advanced Sensor | Yes No No No
TAS5130D1B Taiwan Advanced Sensor | Yes No No No
"Yes" means that the pair is supported by the driver, while "No" means that the
pair does not exist or is not supported by the driver.
Only some of the available control settings of each image sensor are supported
through the V4L2 interface.
Donations of new models for further testing and support would be much
appreciated. Non-available hardware will not be supported by the author of this
driver.
10. Notes for V4L2 application developers
=========================================
This driver follows the V4L2 API specifications. In particular, it enforces two
rules:
- exactly one I/O method, either "mmap" or "read", is associated with each
file descriptor. Once it is selected, the application must close and reopen the
device to switch to the other I/O method;
- although it is not mandatory, previously mapped buffer memory should always
be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
The same number of buffers as before will be allocated again to match the size
of the new video frames, so you have to map the buffers again before any I/O
attempts on them.
Consistently with the hardware limits, this driver also supports image
downscaling with arbitrary scaling factors from 1, 2 and 4 in both directions.
However, the V4L2 API specifications don't correctly define how the scaling
factor can be chosen arbitrarily by the "negotiation" of the "source" and
"target" rectangles. To work around this flaw, we have added the convention
that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the
scaling factor is restored to 1.
This driver supports two different video formats: the first one is the "8-bit
Sequential Bayer" format and can be used to obtain uncompressed video data
from the device through the current I/O method, while the second one provides
either "raw" compressed video data (without frame headers not related to the
compressed data) or standard JPEG (with frame headers). The compression quality
may vary from 0 to 1 and can be selected or queried thanks to the
VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum flexibility,
both the default active video format and the default compression quality
depend on how the image sensor being used is initialized.
11. Video frame formats [1]
=======================
The SN9C1xx PC Camera Controllers can send images in two possible video
formats over the USB: either native "Sequential RGB Bayer" or compressed.
The compression is used to achieve high frame rates. With regard to the
SN9C101, SN9C102 and SN9C103, the compression is based on the Huffman encoding
algorithm described below, while with regard to the SN9C105 and SN9C120 the
compression is based on the JPEG standard.
The current video format may be selected or queried from the user application
by calling the VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2
API specifications.
The name "Sequential Bayer" indicates the organization of the red, green and
blue pixels in one video frame. Each pixel is associated with a 8-bit long
value and is disposed in memory according to the pattern shown below:
B[0] G[1] B[2] G[3] ... B[m-2] G[m-1]
G[m] R[m+1] G[m+2] R[m+2] ... G[2m-2] R[2m-1]
...
... B[(n-1)(m-2)] G[(n-1)(m-1)]
... G[n(m-2)] R[n(m-1)]
The above matrix also represents the sequential or progressive read-out mode of
the (n, m) Bayer color filter array used in many CCD or CMOS image sensors.
The Huffman compressed video frame consists of a bitstream that encodes for
every R, G, or B pixel the difference between the value of the pixel itself and
some reference pixel value. Pixels are organised in the Bayer pattern and the
Bayer sub-pixels are tracked individually and alternatingly. For example, in
the first line values for the B and G1 pixels are alternatingly encoded, while
in the second line values for the G2 and R pixels are alternatingly encoded.
The pixel reference value is calculated as follows:
- the 4 top left pixels are encoded in raw uncompressed 8-bit format;
- the value in the top two rows is the value of the pixel left of the current
pixel;
- the value in the left column is the value of the pixel above the current
pixel;
- for all other pixels, the reference value is the average of the value of the
pixel on the left and the value of the pixel above the current pixel;
- there is one code in the bitstream that specifies the value of a pixel
directly (in 4-bit resolution);
- pixel values need to be clamped inside the range [0..255] for proper
decoding.
The algorithm purely describes the conversion from compressed Bayer code used
in the SN9C101, SN9C102 and SN9C103 chips to uncompressed Bayer. Additional
steps are required to convert this to a color image (i.e. a color interpolation
algorithm).
The following Huffman codes have been found:
0: +0 (relative to reference pixel value)
100: +4
101: -4?
1110xxxx: set absolute value to xxxx.0000
1101: +11
1111: -11
11001: +20
110000: -20
110001: ??? - these codes are apparently not used
[1] The Huffman compression algorithm has been reverse-engineered and
documented by Bertrik Sikken.
12. Contact information
=======================
The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
'FCE635A4'; the public 1024-bit key should be available at any keyserver;
the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
13. Credits
===========
Many thanks to following persons for their contribute (listed in alphabetical
order):
- David Anderson for the donation of a webcam;
- Luca Capello for the donation of a webcam;
- Philippe Coval for having helped testing the PAS202BCA image sensor;
- Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the
donation of a webcam;
- Dennis Heitmann for the donation of a webcam;
- Jon Hollstrom for the donation of a webcam;
- Nick McGill for the donation of a webcam;
- Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB
image sensor;
- Stefano Mozzi, who donated 45 EU;
- Andrew Pearce for the donation of a webcam;
- John Pullan for the donation of a webcam;
- Bertrik Sikken, who reverse-engineered and documented the Huffman compression
algorithm used in the SN9C101, SN9C102 and SN9C103 controllers and
implemented the first decoder;
- Ronny Standke for the donation of a webcam;
- Mizuno Takafumi for the donation of a webcam;
- an "anonymous" donator (who didn't want his name to be revealed) for the
donation of a webcam.
- an anonymous donator for the donation of four webcams and two boards with ten
image sensors.

164
Documentation/video4linux/soc-camera.txt Normal file
View File

@@ -0,0 +1,164 @@
Soc-Camera Subsystem
====================
Terminology
-----------
The following terms are used in this document:
- camera / camera device / camera sensor - a video-camera sensor chip, capable
of connecting to a variety of systems and interfaces, typically uses i2c for
control and configuration, and a parallel or a serial bus for data.
- camera host - an interface, to which a camera is connected. Typically a
specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
AVR32, i.MX27, i.MX31.
- camera host bus - a connection between a camera host and a camera. Can be
parallel or serial, consists of data and control lines, e.g. clock, vertical
and horizontal synchronization signals.
Purpose of the soc-camera subsystem
-----------------------------------
The soc-camera subsystem initially provided a unified API between camera host
drivers and camera sensor drivers. Later the soc-camera sensor API has been
replaced with the V4L2 standard subdev API. This also made camera driver re-use
with non-soc-camera hosts possible. The camera host API to the soc-camera core
has been preserved.
Soc-camera implements a V4L2 interface to the user, currently only the "mmap"
method is supported by host drivers. However, the soc-camera core also provides
support for the "read" method.
The subsystem has been designed to support multiple camera host interfaces and
multiple cameras per interface, although most applications have only one camera
sensor.
Existing drivers
----------------
As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c,
omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
drivers under drivers/media/i2c/soc_camera/.
Camera host API
---------------
A host camera driver is registered using the
soc_camera_host_register(struct soc_camera_host *);
function. The host object can be initialized as follows:
struct soc_camera_host *ici;
ici->drv_name = DRV_NAME;
ici->ops = &camera_host_ops;
ici->priv = pcdev;
ici->v4l2_dev.dev = &pdev->dev;
ici->nr = pdev->id;
All camera host methods are passed in a struct soc_camera_host_ops:
static struct soc_camera_host_ops camera_host_ops = {
.owner = THIS_MODULE,
.add = camera_add_device,
.remove = camera_remove_device,
.set_fmt = camera_set_fmt_cap,
.try_fmt = camera_try_fmt_cap,
.init_videobuf2 = camera_init_videobuf2,
.poll = camera_poll,
.querycap = camera_querycap,
.set_bus_param = camera_set_bus_param,
/* The rest of host operations are optional */
};
.add and .remove methods are called when a sensor is attached to or detached
from the host. .set_bus_param is used to configure physical connection
parameters between the host and the sensor. .init_videobuf2 is called by
soc-camera core when a video-device is opened, the host driver would typically
call vb2_queue_init() in this method. Further video-buffer management is
implemented completely by the specific camera host driver. If the host driver
supports non-standard pixel format conversion, it should implement a
.get_formats and, possibly, a .put_formats operations. See below for more
details about format conversion. The rest of the methods are called from
respective V4L2 operations.
Camera API
----------
Sensor drivers can use struct soc_camera_link, typically provided by the
platform, and used to specify to which camera host bus the sensor is connected,
and optionally provide platform .power and .reset methods for the camera. This
struct is provided to the camera driver via the I2C client device platform data
and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be
taken, when using soc_camera_vdev_to_subdev() and when accessing struct
soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when
running on an soc-camera host. The actual camera driver operation is implemented
using the V4L2 subdev API. Additionally soc-camera camera drivers can use
auxiliary soc-camera helper functions like soc_camera_power_on() and
soc_camera_power_off(), which switch regulators, provided by the platform and call
board-specific power switching methods. soc_camera_apply_board_flags() takes
camera bus configuration capability flags and applies any board transformations,
e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a
pixel format descriptor, corresponding to a certain media-bus pixel format code.
soc_camera_limit_side() can be used to restrict beginning and length of a frame
side, based on camera capabilities.
VIDIOC_S_CROP and VIDIOC_S_FMT behaviour
----------------------------------------
Above user ioctls modify image geometry as follows:
VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor
pixel. Changing sensor window sizes preserves any scaling factors, therefore
user window sizes change as well.
VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as
much as possible by modifying scaling factors. If the sensor window cannot be
preserved precisely, it may be changed too.
In soc-camera there are two locations, where scaling and cropping can taks
place: in the camera driver and in the host driver. User ioctls are first passed
to the host driver, which then generally passes them down to the camera driver.
It is more efficient to perform scaling and cropping in the camera driver to
save camera bus bandwidth and maximise the framerate. However, if the camera
driver failed to set the required parameters with sufficient precision, the host
driver may decide to also use its own scaling and cropping to fulfill the user's
request.
Camera drivers are interfaced to the soc-camera core and to host drivers over
the v4l2-subdev API, which is completely functional, it doesn't pass any data.
Therefore all camera drivers shall reply to .g_fmt() requests with their current
output geometry. This is necessary to correctly configure the camera bus.
.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling
factors have to be maintained by camera drivers internally. According to the
V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we
rely on camera drivers implementing .cropcap(). If the camera driver does not
support cropping, it may choose to not implement .s_crop(), but to enable
cropping support by the camera host driver at least the .g_crop method must be
implemented.
User window geometry is kept in .user_width and .user_height fields in struct
soc_camera_device and used by the soc-camera core and host drivers. The core
updates these fields upon successful completion of a .s_fmt() call, but if these
fields change elsewhere, e.g. during .s_crop() processing, the host driver is
responsible for updating them.
Format conversion
-----------------
V4L2 distinguishes between pixel formats, as they are stored in memory, and as
they are transferred over a media bus. Soc-camera provides support to
conveniently manage these formats. A table of standard transformations is
maintained by soc-camera core, which describes, what FOURCC pixel format will
be obtained, if a media-bus pixel format is stored in memory according to
certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
sample and stored in memory in the little-endian order with no gaps between
bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These
standard transformations will be used by soc-camera or by camera host drivers to
configure camera drivers to produce the FOURCC format, requested by the user,
using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions,
host drivers can also provide their own conversion rules by implementing a
.get_formats and, if required, a .put_formats methods.
--
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

239
Documentation/video4linux/uvcvideo.txt Normal file
View File

@@ -0,0 +1,239 @@
Linux USB Video Class (UVC) driver
==================================
This file documents some driver-specific aspects of the UVC driver, such as
driver-specific ioctls and implementation notes.
Questions and remarks can be sent to the Linux UVC development mailing list at
linux-uvc-devel@lists.berlios.de.
Extension Unit (XU) support
---------------------------
1. Introduction
The UVC specification allows for vendor-specific extensions through extension
units (XUs). The Linux UVC driver supports extension unit controls (XU controls)
through two separate mechanisms:
- through mappings of XU controls to V4L2 controls
- through a driver-specific ioctl interface
The first one allows generic V4L2 applications to use XU controls by mapping
certain XU controls onto V4L2 controls, which then show up during ordinary
control enumeration.
The second mechanism requires uvcvideo-specific knowledge for the application to
access XU controls but exposes the entire UVC XU concept to user space for
maximum flexibility.
Both mechanisms complement each other and are described in more detail below.
2. Control mappings
The UVC driver provides an API for user space applications to define so-called
control mappings at runtime. These allow for individual XU controls or byte
ranges thereof to be mapped to new V4L2 controls. Such controls appear and
function exactly like normal V4L2 controls (i.e. the stock controls, such as
brightness, contrast, etc.). However, reading or writing of such a V4L2 controls
triggers a read or write of the associated XU control.
The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP.
Previous driver versions (before 0.2.0) required another ioctl to be used
beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver.
This is no longer necessary as newer uvcvideo versions query the information
directly from the device.
For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled
"IOCTL reference" below.
3. Driver specific XU control interface
For applications that need to access XU controls directly, e.g. for testing
purposes, firmware upload, or accessing binary controls, a second mechanism to
access XU controls is provided in the form of a driver-specific ioctl, namely
UVCIOC_CTRL_QUERY.
A call to this ioctl allows applications to send queries to the UVC driver that
directly map to the low-level UVC control requests.
In order to make such a request the UVC unit ID of the control's extension unit
and the control selector need to be known. This information either needs to be
hardcoded in the application or queried using other ways such as by parsing the
UVC descriptor or, if available, using the media controller API to enumerate a
device's entities.
Unless the control size is already known it is necessary to first make a
UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer
and set the buffer size to the correct value. Similarly, to find out whether
UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a
UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET
supported) of the resulting byte indicate which requests are valid.
With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and
UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a
subset of the former ioctl. For the time being they are still supported but
application developers are encouraged to use UVCIOC_CTRL_QUERY instead.
For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled
"IOCTL reference" below.
4. Security
The API doesn't currently provide a fine-grained access control facility. The
UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions.
Suggestions on how to improve this are welcome.
5. Debugging
In order to debug problems related to XU controls or controls in general it is
recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'.
This causes extra output to be written into the system log.
6. IOCTL reference
---- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ----
Argument: struct uvc_xu_control_mapping
Description:
This ioctl creates a mapping between a UVC control or part of a UVC
control and a V4L2 control. Once mappings are defined, userspace
applications can access vendor-defined UVC control through the V4L2
control API.
To create a mapping, applications fill the uvc_xu_control_mapping
structure with information about an existing UVC control defined with
UVCIOC_CTRL_ADD and a new V4L2 control.
A UVC control can be mapped to several V4L2 controls. For instance,
a UVC pan/tilt control could be mapped to separate pan and tilt V4L2
controls. The UVC control is divided into non overlapping fields using
the 'size' and 'offset' fields and are then independently mapped to
V4L2 control.
For signed integer V4L2 controls the data_type field should be set to
UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored.
Return value:
On success 0 is returned. On error -1 is returned and errno is set
appropriately.
ENOMEM
Not enough memory to perform the operation.
EPERM
Insufficient privileges (super user privileges are required).
EINVAL
No such UVC control.
EOVERFLOW
The requested offset and size would overflow the UVC control.
EEXIST
Mapping already exists.
Data types:
* struct uvc_xu_control_mapping
__u32 id V4L2 control identifier
__u8 name[32] V4L2 control name
__u8 entity[16] UVC extension unit GUID
__u8 selector UVC control selector
__u8 size V4L2 control size (in bits)
__u8 offset V4L2 control offset (in bits)
enum v4l2_ctrl_type
v4l2_type V4L2 control type
enum uvc_control_data_type
data_type UVC control data type
struct uvc_menu_info
*menu_info Array of menu entries (for menu controls only)
__u32 menu_count Number of menu entries (for menu controls only)
* struct uvc_menu_info
__u32 value Menu entry value used by the device
__u8 name[32] Menu entry name
* enum uvc_control_data_type
UVC_CTRL_DATA_TYPE_RAW Raw control (byte array)
UVC_CTRL_DATA_TYPE_SIGNED Signed integer
UVC_CTRL_DATA_TYPE_UNSIGNED Unsigned integer
UVC_CTRL_DATA_TYPE_BOOLEAN Boolean
UVC_CTRL_DATA_TYPE_ENUM Enumeration
UVC_CTRL_DATA_TYPE_BITMASK Bitmask
---- UVCIOC_CTRL_QUERY - Query a UVC XU control ----
Argument: struct uvc_xu_control_query
Description:
This ioctl queries a UVC XU control identified by its extension unit ID
and control selector.
There are a number of different queries available that closely
correspond to the low-level control requests described in the UVC
specification. These requests are:
UVC_GET_CUR
Obtain the current value of the control.
UVC_GET_MIN
Obtain the minimum value of the control.
UVC_GET_MAX
Obtain the maximum value of the control.
UVC_GET_DEF
Obtain the default value of the control.
UVC_GET_RES
Query the resolution of the control, i.e. the step size of the
allowed control values.
UVC_GET_LEN
Query the size of the control in bytes.
UVC_GET_INFO
Query the control information bitmap, which indicates whether
get/set requests are supported.
UVC_SET_CUR
Update the value of the control.
Applications must set the 'size' field to the correct length for the
control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for
which the size must be set to 2 and 1, respectively. The 'data' field
must point to a valid writable buffer big enough to hold the indicated
number of data bytes.
Data is copied directly from the device without any driver-side
processing. Applications are responsible for data buffer formatting,
including little-endian/big-endian conversion. This is particularly
important for the result of the UVC_GET_LEN requests, which is always
returned as a little-endian 16-bit integer by the device.
Return value:
On success 0 is returned. On error -1 is returned and errno is set
appropriately.
ENOENT
The device does not support the given control or the specified
extension unit could not be found.
ENOBUFS
The specified buffer size is incorrect (too big or too small).
EINVAL
An invalid request code was passed.
EBADRQC
The given request is not supported by the given control.
EFAULT
The data pointer references an inaccessible memory area.
Data types:
* struct uvc_xu_control_query
__u8 unit Extension unit ID
__u8 selector Control selector
__u8 query Request code to send to the device
__u16 size Control data size (in bytes)
__u8 *data Control value

734
Documentation/video4linux/v4l2-controls.txt Normal file
View File

@@ -0,0 +1,734 @@
Introduction
============
The V4L2 control API seems simple enough, but quickly becomes very hard to
implement correctly in drivers. But much of the code needed to handle controls
is actually not driver specific and can be moved to the V4L core framework.
After all, the only part that a driver developer is interested in is:
1) How do I add a control?
2) How do I set the control's value? (i.e. s_ctrl)
And occasionally:
3) How do I get the control's value? (i.e. g_volatile_ctrl)
4) How do I validate the user's proposed control value? (i.e. try_ctrl)
All the rest is something that can be done centrally.
The control framework was created in order to implement all the rules of the
V4L2 specification with respect to controls in a central place. And to make
life as easy as possible for the driver developer.
Note that the control framework relies on the presence of a struct v4l2_device
for V4L2 drivers and struct v4l2_subdev for sub-device drivers.
Objects in the framework
========================
There are two main objects:
The v4l2_ctrl object describes the control properties and keeps track of the
control's value (both the current value and the proposed new value).
v4l2_ctrl_handler is the object that keeps track of controls. It maintains a
list of v4l2_ctrl objects that it owns and another list of references to
controls, possibly to controls owned by other handlers.
Basic usage for V4L2 and sub-device drivers
===========================================
1) Prepare the driver:
1.1) Add the handler to your driver's top-level struct:
struct foo_dev {
...
struct v4l2_ctrl_handler ctrl_handler;
...
};
struct foo_dev *foo;
1.2) Initialize the handler:
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
The second argument is a hint telling the function how many controls this
handler is expected to handle. It will allocate a hashtable based on this
information. It is a hint only.
1.3) Hook the control handler into the driver:
1.3.1) For V4L2 drivers do this:
struct foo_dev {
...
struct v4l2_device v4l2_dev;
...
struct v4l2_ctrl_handler ctrl_handler;
...
};
foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler;
Where foo->v4l2_dev is of type struct v4l2_device.
Finally, remove all control functions from your v4l2_ioctl_ops:
vidioc_queryctrl, vidioc_querymenu, vidioc_g_ctrl, vidioc_s_ctrl,
vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls.
Those are now no longer needed.
1.3.2) For sub-device drivers do this:
struct foo_dev {
...
struct v4l2_subdev sd;
...
struct v4l2_ctrl_handler ctrl_handler;
...
};
foo->sd.ctrl_handler = &foo->ctrl_handler;
Where foo->sd is of type struct v4l2_subdev.
And set all core control ops in your struct v4l2_subdev_core_ops to these
helpers:
.queryctrl = v4l2_subdev_queryctrl,
.querymenu = v4l2_subdev_querymenu,
.g_ctrl = v4l2_subdev_g_ctrl,
.s_ctrl = v4l2_subdev_s_ctrl,
.g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
.try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
.s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
Note: this is a temporary solution only. Once all V4L2 drivers that depend
on subdev drivers are converted to the control framework these helpers will
no longer be needed.
1.4) Clean up the handler at the end:
v4l2_ctrl_handler_free(&foo->ctrl_handler);
2) Add controls:
You add non-menu controls by calling v4l2_ctrl_new_std:
struct v4l2_ctrl *v4l2_ctrl_new_std(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 min, s32 max, u32 step, s32 def);
Menu controls are added by calling v4l2_ctrl_new_std_menu:
struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 skip_mask, s32 def);
Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu:
struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 def, const s64 *qmenu_int);
Standard menu controls with a driver specific menu are added by calling
v4l2_ctrl_new_std_menu_items:
struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
s32 skip_mask, s32 def, const char * const *qmenu);
These functions are typically called right after the v4l2_ctrl_handler_init:
static const s64 exp_bias_qmenu[] = {
-2, -1, 0, 1, 2
};
static const char * const test_pattern[] = {
"Disabled",
"Vertical Bars",
"Solid Black",
"Solid White",
};
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops,
V4L2_CID_CONTRAST, 0, 255, 1, 128);
v4l2_ctrl_new_std_menu(&foo->ctrl_handler, &foo_ctrl_ops,
V4L2_CID_POWER_LINE_FREQUENCY,
V4L2_CID_POWER_LINE_FREQUENCY_60HZ, 0,
V4L2_CID_POWER_LINE_FREQUENCY_DISABLED);
v4l2_ctrl_new_int_menu(&foo->ctrl_handler, &foo_ctrl_ops,
V4L2_CID_EXPOSURE_BIAS,
ARRAY_SIZE(exp_bias_qmenu) - 1,
ARRAY_SIZE(exp_bias_qmenu) / 2 - 1,
exp_bias_qmenu);
v4l2_ctrl_new_std_menu_items(&foo->ctrl_handler, &foo_ctrl_ops,
V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0,
0, test_pattern);
...
if (foo->ctrl_handler.error) {
int err = foo->ctrl_handler.error;
v4l2_ctrl_handler_free(&foo->ctrl_handler);
return err;
}
The v4l2_ctrl_new_std function returns the v4l2_ctrl pointer to the new
control, but if you do not need to access the pointer outside the control ops,
then there is no need to store it.
The v4l2_ctrl_new_std function will fill in most fields based on the control
ID except for the min, max, step and default values. These are passed in the
last four arguments. These values are driver specific while control attributes
like type, name, flags are all global. The control's current value will be set
to the default value.
The v4l2_ctrl_new_std_menu function is very similar but it is used for menu
controls. There is no min argument since that is always 0 for menu controls,
and instead of a step there is a skip_mask argument: if bit X is 1, then menu
item X is skipped.
The v4l2_ctrl_new_int_menu function creates a new standard integer menu
control with driver-specific items in the menu. It differs from
v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes
as the last argument an array of signed 64-bit integers that form an exact
menu item list.
The v4l2_ctrl_new_std_menu_items function is very similar to
v4l2_ctrl_new_std_menu but takes an extra parameter qmenu, which is the driver
specific menu for an otherwise standard menu control. A good example for this
control is the test pattern control for capture/display/sensors devices that
have the capability to generate test patterns. These test patterns are hardware
specific, so the contents of the menu will vary from device to device.
Note that if something fails, the function will return NULL or an error and
set ctrl_handler->error to the error code. If ctrl_handler->error was already
set, then it will just return and do nothing. This is also true for
v4l2_ctrl_handler_init if it cannot allocate the internal data structure.
This makes it easy to init the handler and just add all controls and only check
the error code at the end. Saves a lot of repetitive error checking.
It is recommended to add controls in ascending control ID order: it will be
a bit faster that way.
3) Optionally force initial control setup:
v4l2_ctrl_handler_setup(&foo->ctrl_handler);
This will call s_ctrl for all controls unconditionally. Effectively this
initializes the hardware to the default control values. It is recommended
that you do this as this ensures that both the internal data structures and
the hardware are in sync.
4) Finally: implement the v4l2_ctrl_ops
static const struct v4l2_ctrl_ops foo_ctrl_ops = {
.s_ctrl = foo_s_ctrl,
};
Usually all you need is s_ctrl:
static int foo_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler);
switch (ctrl->id) {
case V4L2_CID_BRIGHTNESS:
write_reg(0x123, ctrl->val);
break;
case V4L2_CID_CONTRAST:
write_reg(0x456, ctrl->val);
break;
}
return 0;
}
The control ops are called with the v4l2_ctrl pointer as argument.
The new control value has already been validated, so all you need to do is
to actually update the hardware registers.
You're done! And this is sufficient for most of the drivers we have. No need
to do any validation of control values, or implement QUERYCTRL/QUERYMENU. And
G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically supported.
==============================================================================
The remainder of this document deals with more advanced topics and scenarios.
In practice the basic usage as described above is sufficient for most drivers.
===============================================================================
Inheriting Controls
===================
When a sub-device is registered with a V4L2 driver by calling
v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev
and v4l2_device are set, then the controls of the subdev will become
automatically available in the V4L2 driver as well. If the subdev driver
contains controls that already exist in the V4L2 driver, then those will be
skipped (so a V4L2 driver can always override a subdev control).
What happens here is that v4l2_device_register_subdev() calls
v4l2_ctrl_add_handler() adding the controls of the subdev to the controls
of v4l2_device.
Accessing Control Values
========================
The v4l2_ctrl struct contains these two unions:
/* The current control value. */
union {
s32 val;
s64 val64;
char *string;
} cur;
/* The new control value. */
union {
s32 val;
s64 val64;
char *string;
};
Within the control ops you can freely use these. The val and val64 speak for
themselves. The string pointers point to character buffers of length
ctrl->maximum + 1, and are always 0-terminated.
In most cases 'cur' contains the current cached control value. When you create
a new control this value is made identical to the default value. After calling
v4l2_ctrl_handler_setup() this value is passed to the hardware. It is generally
a good idea to call this function.
Whenever a new value is set that new value is automatically cached. This means
that most drivers do not need to implement the g_volatile_ctrl() op. The
exception is for controls that return a volatile register such as a signal
strength read-out that changes continuously. In that case you will need to
implement g_volatile_ctrl like this:
static int foo_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
switch (ctrl->id) {
case V4L2_CID_BRIGHTNESS:
ctrl->val = read_reg(0x123);
break;
}
}
Note that you use the 'new value' union as well in g_volatile_ctrl. In general
controls that need to implement g_volatile_ctrl are read-only controls.
To mark a control as volatile you have to set V4L2_CTRL_FLAG_VOLATILE:
ctrl = v4l2_ctrl_new_std(&sd->ctrl_handler, ...);
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
For try/s_ctrl the new values (i.e. as passed by the user) are filled in and
you can modify them in try_ctrl or set them in s_ctrl. The 'cur' union
contains the current value, which you can use (but not change!) as well.
If s_ctrl returns 0 (OK), then the control framework will copy the new final
values to the 'cur' union.
While in g_volatile/s/try_ctrl you can access the value of all controls owned
by the same handler since the handler's lock is held. If you need to access
the value of controls owned by other handlers, then you have to be very careful
not to introduce deadlocks.
Outside of the control ops you have to go through to helper functions to get
or set a single control value safely in your driver:
s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
These functions go through the control framework just as VIDIOC_G/S_CTRL ioctls
do. Don't use these inside the control ops g_volatile/s/try_ctrl, though, that
will result in a deadlock since these helpers lock the handler as well.
You can also take the handler lock yourself:
mutex_lock(&state->ctrl_handler.lock);
printk(KERN_INFO "String value is '%s'\n", ctrl1->cur.string);
printk(KERN_INFO "Integer value is '%s'\n", ctrl2->cur.val);
mutex_unlock(&state->ctrl_handler.lock);
Menu Controls
=============
The v4l2_ctrl struct contains this union:
union {
u32 step;
u32 menu_skip_mask;
};
For menu controls menu_skip_mask is used. What it does is that it allows you
to easily exclude certain menu items. This is used in the VIDIOC_QUERYMENU
implementation where you can return -EINVAL if a certain menu item is not
present. Note that VIDIOC_QUERYCTRL always returns a step value of 1 for
menu controls.
A good example is the MPEG Audio Layer II Bitrate menu control where the
menu is a list of standardized possible bitrates. But in practice hardware
implementations will only support a subset of those. By setting the skip
mask you can tell the framework which menu items should be skipped. Setting
it to 0 means that all menu items are supported.
You set this mask either through the v4l2_ctrl_config struct for a custom
control, or by calling v4l2_ctrl_new_std_menu().
Custom Controls
===============
Driver specific controls can be created using v4l2_ctrl_new_custom():
static const struct v4l2_ctrl_config ctrl_filter = {
.ops = &ctrl_custom_ops,
.id = V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER,
.name = "Spatial Filter",
.type = V4L2_CTRL_TYPE_INTEGER,
.flags = V4L2_CTRL_FLAG_SLIDER,
.max = 15,
.step = 1,
};
ctrl = v4l2_ctrl_new_custom(&foo->ctrl_handler, &ctrl_filter, NULL);
The last argument is the priv pointer which can be set to driver-specific
private data.
The v4l2_ctrl_config struct also has a field to set the is_private flag.
If the name field is not set, then the framework will assume this is a standard
control and will fill in the name, type and flags fields accordingly.
Active and Grabbed Controls
===========================
If you get more complex relationships between controls, then you may have to
activate and deactivate controls. For example, if the Chroma AGC control is
on, then the Chroma Gain control is inactive. That is, you may set it, but
the value will not be used by the hardware as long as the automatic gain
control is on. Typically user interfaces can disable such input fields.
You can set the 'active' status using v4l2_ctrl_activate(). By default all
controls are active. Note that the framework does not check for this flag.
It is meant purely for GUIs. The function is typically called from within
s_ctrl.
The other flag is the 'grabbed' flag. A grabbed control means that you cannot
change it because it is in use by some resource. Typical examples are MPEG
bitrate controls that cannot be changed while capturing is in progress.
If a control is set to 'grabbed' using v4l2_ctrl_grab(), then the framework
will return -EBUSY if an attempt is made to set this control. The
v4l2_ctrl_grab() function is typically called from the driver when it
starts or stops streaming.
Control Clusters
================
By default all controls are independent from the others. But in more
complex scenarios you can get dependencies from one control to another.
In that case you need to 'cluster' them:
struct foo {
struct v4l2_ctrl_handler ctrl_handler;
#define AUDIO_CL_VOLUME (0)
#define AUDIO_CL_MUTE (1)
struct v4l2_ctrl *audio_cluster[2];
...
};
state->audio_cluster[AUDIO_CL_VOLUME] =
v4l2_ctrl_new_std(&state->ctrl_handler, ...);
state->audio_cluster[AUDIO_CL_MUTE] =
v4l2_ctrl_new_std(&state->ctrl_handler, ...);
v4l2_ctrl_cluster(ARRAY_SIZE(state->audio_cluster), state->audio_cluster);
From now on whenever one or more of the controls belonging to the same
cluster is set (or 'gotten', or 'tried'), only the control ops of the first
control ('volume' in this example) is called. You effectively create a new
composite control. Similar to how a 'struct' works in C.
So when s_ctrl is called with V4L2_CID_AUDIO_VOLUME as argument, you should set
all two controls belonging to the audio_cluster:
static int foo_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler);
switch (ctrl->id) {
case V4L2_CID_AUDIO_VOLUME: {
struct v4l2_ctrl *mute = ctrl->cluster[AUDIO_CL_MUTE];
write_reg(0x123, mute->val ? 0 : ctrl->val);
break;
}
case V4L2_CID_CONTRAST:
write_reg(0x456, ctrl->val);
break;
}
return 0;
}
In the example above the following are equivalent for the VOLUME case:
ctrl == ctrl->cluster[AUDIO_CL_VOLUME] == state->audio_cluster[AUDIO_CL_VOLUME]
ctrl->cluster[AUDIO_CL_MUTE] == state->audio_cluster[AUDIO_CL_MUTE]
In practice using cluster arrays like this becomes very tiresome. So instead
the following equivalent method is used:
struct {
/* audio cluster */
struct v4l2_ctrl *volume;
struct v4l2_ctrl *mute;
};
The anonymous struct is used to clearly 'cluster' these two control pointers,
but it serves no other purpose. The effect is the same as creating an
array with two control pointers. So you can just do:
state->volume = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
state->mute = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
v4l2_ctrl_cluster(2, &state->volume);
And in foo_s_ctrl you can use these pointers directly: state->mute->val.
Note that controls in a cluster may be NULL. For example, if for some
reason mute was never added (because the hardware doesn't support that
particular feature), then mute will be NULL. So in that case we have a
cluster of 2 controls, of which only 1 is actually instantiated. The
only restriction is that the first control of the cluster must always be
present, since that is the 'master' control of the cluster. The master
control is the one that identifies the cluster and that provides the
pointer to the v4l2_ctrl_ops struct that is used for that cluster.
Obviously, all controls in the cluster array must be initialized to either
a valid control or to NULL.
In rare cases you might want to know which controls of a cluster actually
were set explicitly by the user. For this you can check the 'is_new' flag of
each control. For example, in the case of a volume/mute cluster the 'is_new'
flag of the mute control would be set if the user called VIDIOC_S_CTRL for
mute only. If the user would call VIDIOC_S_EXT_CTRLS for both mute and volume
controls, then the 'is_new' flag would be 1 for both controls.
The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
Handling autogain/gain-type Controls with Auto Clusters
=======================================================
A common type of control cluster is one that handles 'auto-foo/foo'-type
controls. Typical examples are autogain/gain, autoexposure/exposure,
autowhitebalance/red balance/blue balance. In all cases you have one control
that determines whether another control is handled automatically by the hardware,
or whether it is under manual control from the user.
If the cluster is in automatic mode, then the manual controls should be
marked inactive and volatile. When the volatile controls are read the
g_volatile_ctrl operation should return the value that the hardware's automatic
mode set up automatically.
If the cluster is put in manual mode, then the manual controls should become
active again and the volatile flag is cleared (so g_volatile_ctrl is no longer
called while in manual mode). In addition just before switching to manual mode
the current values as determined by the auto mode are copied as the new manual
values.
Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since
changing that control affects the control flags of the manual controls.
In order to simplify this a special variation of v4l2_ctrl_cluster was
introduced:
void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
u8 manual_val, bool set_volatile);
The first two arguments are identical to v4l2_ctrl_cluster. The third argument
tells the framework which value switches the cluster into manual mode. The
last argument will optionally set V4L2_CTRL_FLAG_VOLATILE for the non-auto controls.
If it is false, then the manual controls are never volatile. You would typically
use that if the hardware does not give you the option to read back to values as
determined by the auto mode (e.g. if autogain is on, the hardware doesn't allow
you to obtain the current gain value).
The first control of the cluster is assumed to be the 'auto' control.
Using this function will ensure that you don't need to handle all the complex
flag and volatile handling.
VIDIOC_LOG_STATUS Support
=========================
This ioctl allow you to dump the current status of a driver to the kernel log.
The v4l2_ctrl_handler_log_status(ctrl_handler, prefix) can be used to dump the
value of the controls owned by the given handler to the log. You can supply a
prefix as well. If the prefix didn't end with a space, then ': ' will be added
for you.
Different Handlers for Different Video Nodes
============================================
Usually the V4L2 driver has just one control handler that is global for
all video nodes. But you can also specify different control handlers for
different video nodes. You can do that by manually setting the ctrl_handler
field of struct video_device.
That is no problem if there are no subdevs involved but if there are, then
you need to block the automatic merging of subdev controls to the global
control handler. You do that by simply setting the ctrl_handler field in
struct v4l2_device to NULL. Now v4l2_device_register_subdev() will no longer
merge subdev controls.
After each subdev was added, you will then have to call v4l2_ctrl_add_handler
manually to add the subdev's control handler (sd->ctrl_handler) to the desired
control handler. This control handler may be specific to the video_device or
for a subset of video_device's. For example: the radio device nodes only have
audio controls, while the video and vbi device nodes share the same control
handler for the audio and video controls.
If you want to have one handler (e.g. for a radio device node) have a subset
of another handler (e.g. for a video device node), then you should first add
the controls to the first handler, add the other controls to the second
handler and finally add the first handler to the second. For example:
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...);
v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler, NULL);
The last argument to v4l2_ctrl_add_handler() is a filter function that allows
you to filter which controls will be added. Set it to NULL if you want to add
all controls.
Or you can add specific controls to a handler:
volume = v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_BRIGHTNESS, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_CONTRAST, ...);
v4l2_ctrl_add_ctrl(&radio_ctrl_handler, volume);
What you should not do is make two identical controls for two handlers.
For example:
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_AUDIO_MUTE, ...);
This would be bad since muting the radio would not change the video mute
control. The rule is to have one control for each hardware 'knob' that you
can twiddle.
Finding Controls
================
Normally you have created the controls yourself and you can store the struct
v4l2_ctrl pointer into your own struct.
But sometimes you need to find a control from another handler that you do
not own. For example, if you have to find a volume control from a subdev.
You can do that by calling v4l2_ctrl_find:
struct v4l2_ctrl *volume;
volume = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_AUDIO_VOLUME);
Since v4l2_ctrl_find will lock the handler you have to be careful where you
use it. For example, this is not a good idea:
struct v4l2_ctrl_handler ctrl_handler;
v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...);
v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...);
...and in video_ops.s_ctrl:
case V4L2_CID_BRIGHTNESS:
contrast = v4l2_find_ctrl(&ctrl_handler, V4L2_CID_CONTRAST);
...
When s_ctrl is called by the framework the ctrl_handler.lock is already taken, so
attempting to find another control from the same handler will deadlock.
It is recommended not to use this function from inside the control ops.
Inheriting Controls
===================
When one control handler is added to another using v4l2_ctrl_add_handler, then
by default all controls from one are merged to the other. But a subdev might
have low-level controls that make sense for some advanced embedded system, but
not when it is used in consumer-level hardware. In that case you want to keep
those low-level controls local to the subdev. You can do this by simply
setting the 'is_private' flag of the control to 1:
static const struct v4l2_ctrl_config ctrl_private = {
.ops = &ctrl_custom_ops,
.id = V4L2_CID_...,
.name = "Some Private Control",
.type = V4L2_CTRL_TYPE_INTEGER,
.max = 15,
.step = 1,
.is_private = 1,
};
ctrl = v4l2_ctrl_new_custom(&foo->ctrl_handler, &ctrl_private, NULL);
These controls will now be skipped when v4l2_ctrl_add_handler is called.
V4L2_CTRL_TYPE_CTRL_CLASS Controls
==================================
Controls of this type can be used by GUIs to get the name of the control class.
A fully featured GUI can make a dialog with multiple tabs with each tab
containing the controls belonging to a particular control class. The name of
each tab can be found by querying a special control with ID <control class | 1>.
Drivers do not have to care about this. The framework will automatically add
a control of this type whenever the first control belonging to a new control
class is added.
Adding Notify Callbacks
=======================
Sometimes the platform or bridge driver needs to be notified when a control
from a sub-device driver changes. You can set a notify callback by calling
this function:
void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);
Whenever the give control changes value the notify callback will be called
with a pointer to the control and the priv pointer that was passed with
v4l2_ctrl_notify. Note that the control's handler lock is held when the
notify function is called.
There can be only one notify function per control handler. Any attempt
to set another notify function will cause a WARN_ON.

1063
Documentation/video4linux/v4l2-framework.txt Normal file
View File

File diff suppressed because it is too large Load Diff

355
Documentation/video4linux/videobuf Normal file
View File

@@ -0,0 +1,355 @@
An introduction to the videobuf layer
Jonathan Corbet <corbet@lwn.net>
Current as of 2.6.33
The videobuf layer functions as a sort of glue layer between a V4L2 driver
and user space. It handles the allocation and management of buffers for
the storage of video frames. There is a set of functions which can be used
to implement many of the standard POSIX I/O system calls, including read(),
poll(), and, happily, mmap(). Another set of functions can be used to
implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
including buffer allocation, queueing and dequeueing, and streaming
control. Using videobuf imposes a few design decisions on the driver
author, but the payback comes in the form of reduced code in the driver and
a consistent implementation of the V4L2 user-space API.
Buffer types
Not all video devices use the same kind of buffers. In fact, there are (at
least) three common variations:
- Buffers which are scattered in both the physical and (kernel) virtual
address spaces. (Almost) all user-space buffers are like this, but it
makes great sense to allocate kernel-space buffers this way as well when
it is possible. Unfortunately, it is not always possible; working with
this kind of buffer normally requires hardware which can do
scatter/gather DMA operations.
- Buffers which are physically scattered, but which are virtually
contiguous; buffers allocated with vmalloc(), in other words. These
buffers are just as hard to use for DMA operations, but they can be
useful in situations where DMA is not available but virtually-contiguous
buffers are convenient.
- Buffers which are physically contiguous. Allocation of this kind of
buffer can be unreliable on fragmented systems, but simpler DMA
controllers cannot deal with anything else.
Videobuf can work with all three types of buffers, but the driver author
must pick one at the outset and design the driver around that decision.
[It's worth noting that there's a fourth kind of buffer: "overlay" buffers
which are located within the system's video memory. The overlay
functionality is considered to be deprecated for most use, but it still
shows up occasionally in system-on-chip drivers where the performance
benefits merit the use of this technique. Overlay buffers can be handled
as a form of scattered buffer, but there are very few implementations in
the kernel and a description of this technique is currently beyond the
scope of this document.]
Data structures, callbacks, and initialization
Depending on which type of buffers are being used, the driver should
include one of the following files:
<media/videobuf-dma-sg.h> /* Physically scattered */
<media/videobuf-vmalloc.h> /* vmalloc() buffers */
<media/videobuf-dma-contig.h> /* Physically contiguous */
The driver's data structure describing a V4L2 device should include a
struct videobuf_queue instance for the management of the buffer queue,
along with a list_head for the queue of available buffers. There will also
need to be an interrupt-safe spinlock which is used to protect (at least)
the queue.
The next step is to write four simple callbacks to help videobuf deal with
the management of buffers:
struct videobuf_queue_ops {
int (*buf_setup)(struct videobuf_queue *q,
unsigned int *count, unsigned int *size);
int (*buf_prepare)(struct videobuf_queue *q,
struct videobuf_buffer *vb,
enum v4l2_field field);
void (*buf_queue)(struct videobuf_queue *q,
struct videobuf_buffer *vb);
void (*buf_release)(struct videobuf_queue *q,
struct videobuf_buffer *vb);
};
buf_setup() is called early in the I/O process, when streaming is being
initiated; its purpose is to tell videobuf about the I/O stream. The count
parameter will be a suggested number of buffers to use; the driver should
check it for rationality and adjust it if need be. As a practical rule, a
minimum of two buffers are needed for proper streaming, and there is
usually a maximum (which cannot exceed 32) which makes sense for each
device. The size parameter should be set to the expected (maximum) size
for each frame of data.
Each buffer (in the form of a struct videobuf_buffer pointer) will be
passed to buf_prepare(), which should set the buffer's size, width, height,
and field fields properly. If the buffer's state field is
VIDEOBUF_NEEDS_INIT, the driver should pass it to:
int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb,
struct v4l2_framebuffer *fbuf);
Among other things, this call will usually allocate memory for the buffer.
Finally, the buf_prepare() function should set the buffer's state to
VIDEOBUF_PREPARED.
When a buffer is queued for I/O, it is passed to buf_queue(), which should
put it onto the driver's list of available buffers and set its state to
VIDEOBUF_QUEUED. Note that this function is called with the queue spinlock
held; if it tries to acquire it as well things will come to a screeching
halt. Yes, this is the voice of experience. Note also that videobuf may
wait on the first buffer in the queue; placing other buffers in front of it
could again gum up the works. So use list_add_tail() to enqueue buffers.
Finally, buf_release() is called when a buffer is no longer intended to be
used. The driver should ensure that there is no I/O active on the buffer,
then pass it to the appropriate free routine(s):
/* Scatter/gather drivers */
int videobuf_dma_unmap(struct videobuf_queue *q,
struct videobuf_dmabuf *dma);
int videobuf_dma_free(struct videobuf_dmabuf *dma);
/* vmalloc drivers */
void videobuf_vmalloc_free (struct videobuf_buffer *buf);
/* Contiguous drivers */
void videobuf_dma_contig_free(struct videobuf_queue *q,
struct videobuf_buffer *buf);
One way to ensure that a buffer is no longer under I/O is to pass it to:
int videobuf_waiton(struct videobuf_buffer *vb, int non_blocking, int intr);
Here, vb is the buffer, non_blocking indicates whether non-blocking I/O
should be used (it should be zero in the buf_release() case), and intr
controls whether an interruptible wait is used.
File operations
At this point, much of the work is done; much of the rest is slipping
videobuf calls into the implementation of the other driver callbacks. The
first step is in the open() function, which must initialize the
videobuf queue. The function to use depends on the type of buffer used:
void videobuf_queue_sg_init(struct videobuf_queue *q,
struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
enum v4l2_field field,
unsigned int msize,
void *priv);
void videobuf_queue_vmalloc_init(struct videobuf_queue *q,
struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
enum v4l2_field field,
unsigned int msize,
void *priv);
void videobuf_queue_dma_contig_init(struct videobuf_queue *q,
struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
enum v4l2_field field,
unsigned int msize,
void *priv);
In each case, the parameters are the same: q is the queue structure for the
device, ops is the set of callbacks as described above, dev is the device
structure for this video device, irqlock is an interrupt-safe spinlock to
protect access to the data structures, type is the buffer type used by the
device (cameras will use V4L2_BUF_TYPE_VIDEO_CAPTURE, for example), field
describes which field is being captured (often V4L2_FIELD_NONE for
progressive devices), msize is the size of any containing structure used
around struct videobuf_buffer, and priv is a private data pointer which
shows up in the priv_data field of struct videobuf_queue. Note that these
are void functions which, evidently, are immune to failure.
V4L2 capture drivers can be written to support either of two APIs: the
read() system call and the rather more complicated streaming mechanism. As
a general rule, it is necessary to support both to ensure that all
applications have a chance of working with the device. Videobuf makes it
easy to do that with the same code. To implement read(), the driver need
only make a call to one of:
ssize_t videobuf_read_one(struct videobuf_queue *q,
char __user *data, size_t count,
loff_t *ppos, int nonblocking);
ssize_t videobuf_read_stream(struct videobuf_queue *q,
char __user *data, size_t count,
loff_t *ppos, int vbihack, int nonblocking);
Either one of these functions will read frame data into data, returning the
amount actually read; the difference is that videobuf_read_one() will only
read a single frame, while videobuf_read_stream() will read multiple frames
if they are needed to satisfy the count requested by the application. A
typical driver read() implementation will start the capture engine, call
one of the above functions, then stop the engine before returning (though a
smarter implementation might leave the engine running for a little while in
anticipation of another read() call happening in the near future).
The poll() function can usually be implemented with a direct call to:
unsigned int videobuf_poll_stream(struct file *file,
struct videobuf_queue *q,
poll_table *wait);
Note that the actual wait queue eventually used will be the one associated
with the first available buffer.
When streaming I/O is done to kernel-space buffers, the driver must support
the mmap() system call to enable user space to access the data. In many
V4L2 drivers, the often-complex mmap() implementation simplifies to a
single call to:
int videobuf_mmap_mapper(struct videobuf_queue *q,
struct vm_area_struct *vma);
Everything else is handled by the videobuf code.
The release() function requires two separate videobuf calls:
void videobuf_stop(struct videobuf_queue *q);
int videobuf_mmap_free(struct videobuf_queue *q);
The call to videobuf_stop() terminates any I/O in progress - though it is
still up to the driver to stop the capture engine. The call to
videobuf_mmap_free() will ensure that all buffers have been unmapped; if
so, they will all be passed to the buf_release() callback. If buffers
remain mapped, videobuf_mmap_free() returns an error code instead. The
purpose is clearly to cause the closing of the file descriptor to fail if
buffers are still mapped, but every driver in the 2.6.32 kernel cheerfully
ignores its return value.
ioctl() operations
The V4L2 API includes a very long list of driver callbacks to respond to
the many ioctl() commands made available to user space. A number of these
- those associated with streaming I/O - turn almost directly into videobuf
calls. The relevant helper functions are:
int videobuf_reqbufs(struct videobuf_queue *q,
struct v4l2_requestbuffers *req);
int videobuf_querybuf(struct videobuf_queue *q, struct v4l2_buffer *b);
int videobuf_qbuf(struct videobuf_queue *q, struct v4l2_buffer *b);
int videobuf_dqbuf(struct videobuf_queue *q, struct v4l2_buffer *b,
int nonblocking);
int videobuf_streamon(struct videobuf_queue *q);
int videobuf_streamoff(struct videobuf_queue *q);
So, for example, a VIDIOC_REQBUFS call turns into a call to the driver's
vidioc_reqbufs() callback which, in turn, usually only needs to locate the
proper struct videobuf_queue pointer and pass it to videobuf_reqbufs().
These support functions can replace a great deal of buffer management
boilerplate in a lot of V4L2 drivers.
The vidioc_streamon() and vidioc_streamoff() functions will be a bit more
complex, of course, since they will also need to deal with starting and
stopping the capture engine.
Buffer allocation
Thus far, we have talked about buffers, but have not looked at how they are
allocated. The scatter/gather case is the most complex on this front. For
allocation, the driver can leave buffer allocation entirely up to the
videobuf layer; in this case, buffers will be allocated as anonymous
user-space pages and will be very scattered indeed. If the application is
using user-space buffers, no allocation is needed; the videobuf layer will
take care of calling get_user_pages() and filling in the scatterlist array.
If the driver needs to do its own memory allocation, it should be done in
the vidioc_reqbufs() function, *after* calling videobuf_reqbufs(). The
first step is a call to:
struct videobuf_dmabuf *videobuf_to_dma(struct videobuf_buffer *buf);
The returned videobuf_dmabuf structure (defined in
<media/videobuf-dma-sg.h>) includes a couple of relevant fields:
struct scatterlist *sglist;
int sglen;
The driver must allocate an appropriately-sized scatterlist array and
populate it with pointers to the pieces of the allocated buffer; sglen
should be set to the length of the array.
Drivers using the vmalloc() method need not (and cannot) concern themselves
with buffer allocation at all; videobuf will handle those details. The
same is normally true of contiguous-DMA drivers as well; videobuf will
allocate the buffers (with dma_alloc_coherent()) when it sees fit. That
means that these drivers may be trying to do high-order allocations at any
time, an operation which is not always guaranteed to work. Some drivers
play tricks by allocating DMA space at system boot time; videobuf does not
currently play well with those drivers.
As of 2.6.31, contiguous-DMA drivers can work with a user-supplied buffer,
as long as that buffer is physically contiguous. Normal user-space
allocations will not meet that criterion, but buffers obtained from other
kernel drivers, or those contained within huge pages, will work with these
drivers.
Filling the buffers
The final part of a videobuf implementation has no direct callback - it's
the portion of the code which actually puts frame data into the buffers,
usually in response to interrupts from the device. For all types of
drivers, this process works approximately as follows:
- Obtain the next available buffer and make sure that somebody is actually
waiting for it.
- Get a pointer to the memory and put video data there.
- Mark the buffer as done and wake up the process waiting for it.
Step (1) above is done by looking at the driver-managed list_head structure
- the one which is filled in the buf_queue() callback. Because starting
the engine and enqueueing buffers are done in separate steps, it's possible
for the engine to be running without any buffers available - in the
vmalloc() case especially. So the driver should be prepared for the list
to be empty. It is equally possible that nobody is yet interested in the
buffer; the driver should not remove it from the list or fill it until a
process is waiting on it. That test can be done by examining the buffer's
done field (a wait_queue_head_t structure) with waitqueue_active().
A buffer's state should be set to VIDEOBUF_ACTIVE before being mapped for
DMA; that ensures that the videobuf layer will not try to do anything with
it while the device is transferring data.
For scatter/gather drivers, the needed memory pointers will be found in the
scatterlist structure described above. Drivers using the vmalloc() method
can get a memory pointer with:
void *videobuf_to_vmalloc(struct videobuf_buffer *buf);
For contiguous DMA drivers, the function to use is:
dma_addr_t videobuf_to_dma_contig(struct videobuf_buffer *buf);
The contiguous DMA API goes out of its way to hide the kernel-space address
of the DMA buffer from drivers.
The final step is to set the size field of the relevant videobuf_buffer
structure to the actual size of the captured image, set state to
VIDEOBUF_DONE, then call wake_up() on the done queue. At this point, the
buffer is owned by the videobuf layer and the driver should not touch it
again.
Developers who are interested in more information can go into the relevant
header files; there are a few low-level functions declared there which have
not been talked about here. Also worthwhile is the vivi driver
(drivers/media/platform/vivi.c), which is maintained as an example of how V4L2
drivers should be written. Vivi only uses the vmalloc() API, but it's good
enough to get started with. Note also that all of these calls are exported
GPL-only, so they will not be available to non-GPL kernel modules.

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://www.slackwaresupport.com/howtos/Webcam-HOWTO
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

69
Documentation/video4linux/zr364xx.txt Normal file
View File

@@ -0,0 +1,69 @@
Zoran 364xx based USB webcam module version 0.72
site: http://royale.zerezo.com/zr364xx/
mail: royale@zerezo.com
introduction:
This brings support under Linux for the Aiptek PocketDV 3300 in webcam mode.
If you just want to get on your PC the pictures and movies on the camera, you should use the usb-storage module instead.
The driver works with several other cameras in webcam mode (see the list below).
Maybe this code can work for other JPEG/USB cams based on the Coach chips from Zoran?
Possible chipsets are : ZR36430 (ZR36430BGC) and maybe ZR36431, ZR36440, ZR36442...
You can try the experience changing the vendor/product ID values (look at the source code).
You can get these values by looking at /var/log/messages when you plug your camera, or by typing : cat /proc/bus/usb/devices.
If you manage to use your cam with this code, you can send me a mail (royale@zerezo.com) with the name of your cam and a patch if needed.
This is a beta release of the driver.
Since version 0.70, this driver is only compatible with V4L2 API and 2.6.x kernels.
If you need V4L1 or 2.4x kernels support, please use an older version, but the code is not maintained anymore.
Good luck!
install:
In order to use this driver, you must compile it with your kernel.
Location: Device Drivers -> Multimedia devices -> Video For Linux -> Video Capture Adapters -> V4L USB devices
usage:
modprobe zr364xx debug=X mode=Y
- debug : set to 1 to enable verbose debug messages
- mode : 0 = 320x240, 1 = 160x120, 2 = 640x480
You can then use the camera with V4L2 compatible applications, for example Ekiga.
To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M count=1
links :
http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV)
http://www.harmwal.nl/pccam880/ (this project also supports cameras based on this chipset)
supported devices:
------ ------- ----------- -----
Vendor Product Distributor Model
------ ------- ----------- -----
0x08ca 0x0109 Aiptek PocketDV 3300
0x08ca 0x0109 Maxell Maxcam PRO DV3
0x041e 0x4024 Creative PC-CAM 880
0x0d64 0x0108 Aiptek Fidelity 3200
0x0d64 0x0108 Praktica DCZ 1.3 S
0x0d64 0x0108 Genius Digital Camera (?)
0x0d64 0x0108 DXG Technology Fashion Cam
0x0546 0x3187 Polaroid iON 230
0x0d64 0x3108 Praktica Exakta DC 2200
0x0d64 0x3108 Genius G-Shot D211
0x0595 0x4343 Concord Eye-Q Duo 1300
0x0595 0x4343 Concord Eye-Q Duo 2000
0x0595 0x4343 Fujifilm EX-10
0x0595 0x4343 Ricoh RDC-6000
0x0595 0x4343 Digitrex DSC 1300
0x0595 0x4343 Firstline FDC 2000
0x0bb0 0x500d Concord EyeQ Go Wireless
0x0feb 0x2004 CRS Electronic 3.3 Digital Camera
0x0feb 0x2004 Packard Bell DSC-300
0x055f 0xb500 Mustek MDC 3000
0x08ca 0x2062 Aiptek PocketDV 5700
0x052b 0x1a18 Chiphead Megapix V12
0x04c8 0x0729 Konica Revio 2
0x04f2 0xa208 Creative PC-CAM 850
0x0784 0x0040 Traveler Slimline X5
0x06d6 0x0034 Trust Powerc@m 750
0x0a17 0x0062 Pentax Optio 50L
0x06d6 0x003b Trust Powerc@m 970Z
0x0a17 0x004e Pentax Optio 50
0x041e 0x405d Creative DiVi CAM 516
0x08ca 0x2102 Aiptek DV T300
0x06d6 0x003d Trust Powerc@m 910Z