diff options
Diffstat (limited to 'Documentation/video4linux')
-rw-r--r-- | Documentation/video4linux/CARDLIST.cx88 | 2 | ||||
-rw-r--r-- | Documentation/video4linux/CARDLIST.saa7134 | 7 | ||||
-rw-r--r-- | Documentation/video4linux/cafe_ccic | 54 | ||||
-rw-r--r-- | Documentation/video4linux/zr36120.txt | 162 |
4 files changed, 61 insertions, 164 deletions
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 8755b3e7b09e..62e32b49cec9 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 | |||
@@ -43,7 +43,7 @@ | |||
43 | 42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025,1822:0019] | 43 | 42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025,1822:0019] |
44 | 43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1,12ab:2300] | 44 | 43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1,12ab:2300] |
45 | 44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54] | 45 | 44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54] |
46 | 45 -> KWorld HardwareMpegTV XPert [17de:0840] | 46 | 45 -> KWorld HardwareMpegTV XPert [17de:0840,1421:0305] |
47 | 46 -> DViCO FusionHDTV DVB-T Hybrid [18ac:db40,18ac:db44] | 47 | 46 -> DViCO FusionHDTV DVB-T Hybrid [18ac:db40,18ac:db44] |
48 | 47 -> pcHDTV HD5500 HDTV [7063:5500] | 48 | 47 -> pcHDTV HD5500 HDTV [7063:5500] |
49 | 48 -> Kworld MCE 200 Deluxe [17de:0841] | 49 | 48 -> Kworld MCE 200 Deluxe [17de:0841] |
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 53ce6a39083c..f6201cc37ec5 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
@@ -76,7 +76,7 @@ | |||
76 | 75 -> AVerMedia AVerTVHD MCE A180 [1461:1044] | 76 | 75 -> AVerMedia AVerTVHD MCE A180 [1461:1044] |
77 | 76 -> SKNet MonsterTV Mobile [1131:4ee9] | 77 | 76 -> SKNet MonsterTV Mobile [1131:4ee9] |
78 | 77 -> Pinnacle PCTV 40i/50i/110i (saa7133) [11bd:002e] | 78 | 77 -> Pinnacle PCTV 40i/50i/110i (saa7133) [11bd:002e] |
79 | 78 -> ASUSTeK P7131 Dual [1043:4862] | 79 | 78 -> ASUSTeK P7131 Dual [1043:4862,1043:4876] |
80 | 79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B) | 80 | 79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B) |
81 | 80 -> ASUS Digimatrix TV [1043:0210] | 81 | 80 -> ASUS Digimatrix TV [1043:0210] |
82 | 81 -> Philips Tiger reference design [1131:2018] | 82 | 81 -> Philips Tiger reference design [1131:2018] |
@@ -99,3 +99,8 @@ | |||
99 | 98 -> Proteus Pro 2309 [0919:2003] | 99 | 98 -> Proteus Pro 2309 [0919:2003] |
100 | 99 -> AVerMedia TV Hybrid A16AR [1461:2c00] | 100 | 99 -> AVerMedia TV Hybrid A16AR [1461:2c00] |
101 | 100 -> Asus Europa2 OEM [1043:4860] | 101 | 100 -> Asus Europa2 OEM [1043:4860] |
102 | 101 -> Pinnacle PCTV 310i [11bd:002f] | ||
103 | 102 -> Avermedia AVerTV Studio 507 [1461:9715] | ||
104 | 103 -> Compro Videomate DVB-T200A | ||
105 | 104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6701] | ||
106 | 105 -> Terratec Cinergy HT PCMCIA [153b:1172] | ||
diff --git a/Documentation/video4linux/cafe_ccic b/Documentation/video4linux/cafe_ccic new file mode 100644 index 000000000000..88821022a5de --- /dev/null +++ b/Documentation/video4linux/cafe_ccic | |||
@@ -0,0 +1,54 @@ | |||
1 | "cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera | ||
2 | controller. This is the controller found in first-generation OLPC systems, | ||
3 | and this driver was written with support from the OLPC project. | ||
4 | |||
5 | Current status: the core driver works. It can generate data in YUV422, | ||
6 | RGB565, and RGB444 formats. (Anybody looking at the code will see RGB32 as | ||
7 | well, but that is a debugging aid which will be removed shortly). VGA and | ||
8 | QVGA modes work; CIF is there but the colors remain funky. Only the OV7670 | ||
9 | sensor is known to work with this controller at this time. | ||
10 | |||
11 | To try it out: either of these commands will work: | ||
12 | |||
13 | mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound | ||
14 | mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound | ||
15 | |||
16 | The "xawtv" utility also works; gqcam does not, for unknown reasons. | ||
17 | |||
18 | There are a few load-time options, most of which can be changed after | ||
19 | loading via sysfs as well: | ||
20 | |||
21 | - alloc_bufs_at_load: Normally, the driver will not allocate any DMA | ||
22 | buffers until the time comes to transfer data. If this option is set, | ||
23 | then worst-case-sized buffers will be allocated at module load time. | ||
24 | This option nails down the memory for the life of the module, but | ||
25 | perhaps decreases the chances of an allocation failure later on. | ||
26 | |||
27 | - dma_buf_size: The size of DMA buffers to allocate. Note that this | ||
28 | option is only consulted for load-time allocation; when buffers are | ||
29 | allocated at run time, they will be sized appropriately for the current | ||
30 | camera settings. | ||
31 | |||
32 | - n_dma_bufs: The controller can cycle through either two or three DMA | ||
33 | buffers. Normally, the driver tries to use three buffers; on faster | ||
34 | systems, however, it will work well with only two. | ||
35 | |||
36 | - min_buffers: The minimum number of streaming I/O buffers that the driver | ||
37 | will consent to work with. Default is one, but, on slower systems, | ||
38 | better behavior with mplayer can be achieved by setting to a higher | ||
39 | value (like six). | ||
40 | |||
41 | - max_buffers: The maximum number of streaming I/O buffers; default is | ||
42 | ten. That number was carefully picked out of a hat and should not be | ||
43 | assumed to actually mean much of anything. | ||
44 | |||
45 | - flip: If this boolean parameter is set, the sensor will be instructed to | ||
46 | invert the video image. Whether it makes sense is determined by how | ||
47 | your particular camera is mounted. | ||
48 | |||
49 | Work is ongoing with this driver, stay tuned. | ||
50 | |||
51 | jon | ||
52 | |||
53 | Jonathan Corbet | ||
54 | corbet@lwn.net | ||
diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt deleted file mode 100644 index 1a1c2d03a5c8..000000000000 --- a/Documentation/video4linux/zr36120.txt +++ /dev/null | |||
@@ -1,162 +0,0 @@ | |||
1 | Driver for Trust Computer Products Framegrabber, version 0.6.1 | ||
2 | ------ --- ----- -------- -------- ------------ ------- - - - | ||
3 | |||
4 | - ZORAN ------------------------------------------------------ | ||
5 | Author: Pauline Middelink <middelin@polyware.nl> | ||
6 | Date: 18 September 1999 | ||
7 | Version: 0.6.1 | ||
8 | |||
9 | - Description ------------------------------------------------ | ||
10 | |||
11 | Video4Linux compatible driver for an unknown brand framegrabber | ||
12 | (Sold in the Netherlands by TRUST Computer Products) and various | ||
13 | other zoran zr36120 based framegrabbers. | ||
14 | |||
15 | The card contains a ZR36120 Multimedia PCI Interface and a Philips | ||
16 | SAA7110 Onechip Frontend videodecoder. There is also an DSP of | ||
17 | which I have forgotten the number, since i will never get that thing | ||
18 | to work without specs from the vendor itself. | ||
19 | |||
20 | The SAA711x are capable of processing 6 different video inputs, | ||
21 | CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or | ||
22 | SECAM and delivering a YUV datastream. On my card the input | ||
23 | 'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2. | ||
24 | |||
25 | I have some reports of other cards working with the mentioned | ||
26 | chip sets. For a list of other working cards please have a look | ||
27 | at the cards named in the tvcards struct in the beginning of | ||
28 | zr36120.c | ||
29 | |||
30 | After some testing, I discovered that the carddesigner messed up | ||
31 | on the I2C interface. The Zoran chip includes 2 lines SDA and SCL | ||
32 | which (s)he connected reversely. So we have to clock on the SDA | ||
33 | and r/w data on the SCL pin. Life is fun... Each cardtype now has | ||
34 | a bit which signifies if you have a card with the same deficiency. | ||
35 | |||
36 | Oh, for the completeness of this story I must mention that my | ||
37 | card delivers the VSYNC pulse of the SAA chip to GIRQ1, not | ||
38 | GIRQ0 as some other cards have. This is also incorporated in | ||
39 | the driver be clearing/setting the 'useirq1' bit in the tvcard | ||
40 | description. | ||
41 | |||
42 | Another problems of continuous capturing data with a Zoran chip | ||
43 | is something nasty inside the chip. It effectively halves the | ||
44 | fps we ought to get... Here is the scenario: capturing frames | ||
45 | to memory is done in the so-called snapshot mode. In this mode | ||
46 | the Zoran stops after capturing a frame worth of data and wait | ||
47 | till the application set GRAB bit to indicate readiness for the | ||
48 | next frame. After detecting a set bit, the chip neatly waits | ||
49 | till the start of a frame, captures it and it goes back to off. | ||
50 | Smart ppl will notice the problem here. Its the waiting on the | ||
51 | _next_ frame each time we set the GRAB bit... Oh well, 12,5 fps | ||
52 | is still plenty fast for me. | ||
53 | -- update 28/7/1999 -- | ||
54 | Don't believe a word I just said... Proof is the output | ||
55 | of `streamer -t 300 -r 25 -f avi15 -o /dev/null` | ||
56 | ++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
57 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
58 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
59 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
60 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
61 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
62 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
63 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
64 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
65 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
66 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
67 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- | ||
68 | syncer: done | ||
69 | writer: done | ||
70 | (note the /dev/null is prudent here, my system is not able to | ||
71 | grab /and/ write 25 fps to a file... gifts welcome :) ) | ||
72 | The technical reasoning follows: The zoran completed the last | ||
73 | frame, the VSYNC goes low, and GRAB is cleared. The interrupt | ||
74 | routine starts to work since its VSYNC driven, and again | ||
75 | activates the GRAB bit. A few ms later the VSYNC (re-)rises and | ||
76 | the zoran starts to work on a new and freshly broadcasted frame.... | ||
77 | |||
78 | For pointers I used the specs of both chips. Below are the URLs: | ||
79 | http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf | ||
80 | http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf | ||
81 | Some alternatives for the Philips SAA 7110 datasheet are: | ||
82 | http://www.datasheetcatalog.com/datasheets_pdf/S/A/A/7/SAA7110.shtml | ||
83 | http://www.datasheetarchive.com/search.php?search=SAA7110&sType=part | ||
84 | |||
85 | The documentation has very little on absolute numbers or timings | ||
86 | needed for the various modes/resolutions, but there are other | ||
87 | programs you can borrow those from. | ||
88 | |||
89 | ------ Install -------------------------------------------- | ||
90 | Read the file called TODO. Note its long list of limitations. | ||
91 | |||
92 | Build a kernel with VIDEO4LINUX enabled. Activate the | ||
93 | BT848 driver; we need this because we have need for the | ||
94 | other modules (i2c and videodev) it enables. | ||
95 | |||
96 | To install this software, extract it into a suitable directory. | ||
97 | Examine the makefile and change anything you don't like. Type "make". | ||
98 | |||
99 | After making the modules check if you have the much needed | ||
100 | /dev/video devices. If not, execute the following 4 lines: | ||
101 | mknod /dev/video c 81 0 | ||
102 | mknod /dev/video1 c 81 1 | ||
103 | mknod /dev/video2 c 81 2 | ||
104 | mknod /dev/video3 c 81 3 | ||
105 | mknod /dev/video4 c 81 4 | ||
106 | |||
107 | After making/checking the devices do: | ||
108 | modprobe i2c | ||
109 | modprobe videodev | ||
110 | modprobe saa7110 (optional) | ||
111 | modprobe saa7111 (optional) | ||
112 | modprobe tuner (optional) | ||
113 | insmod zoran cardtype=<n> | ||
114 | |||
115 | <n> is the cardtype of the card you have. The cardnumber can | ||
116 | be found in the source of zr36120. Look for tvcards. If your | ||
117 | card is not there, please try if any other card gives some | ||
118 | response, and mail me if you got a working tvcard addition. | ||
119 | |||
120 | PS. <TVCard editors behold!) | ||
121 | Don't forget to set video_input to the number of inputs | ||
122 | you defined in the video_mux part of the tvcard definition. | ||
123 | It's a common error to add a channel but not incrementing | ||
124 | video_input and getting angry with me/v4l/linux/linus :( | ||
125 | |||
126 | You are now ready to test the framegrabber with your favorite | ||
127 | video4linux compatible tool | ||
128 | |||
129 | ------ Application ---------------------------------------- | ||
130 | |||
131 | This device works with all Video4Linux compatible applications, | ||
132 | given the limitations in the TODO file. | ||
133 | |||
134 | ------ API ------------------------------------------------ | ||
135 | |||
136 | This uses the V4L interface as of kernel release 2.1.116, and in | ||
137 | fact has not been tested on any lower version. There are a couple | ||
138 | of minor differences due to the fact that the amount of data returned | ||
139 | with each frame varies, and no doubt there are discrepancies due to my | ||
140 | misunderstanding of the API. I intend to convert this driver to the | ||
141 | new V4L2 API when it has stabilized more. | ||
142 | |||
143 | ------ Current state -------------------------------------- | ||
144 | |||
145 | The driver is capable of overlaying a video image in screen, and | ||
146 | even capable of grabbing frames. It uses the BIGPHYSAREA patch | ||
147 | to allocate lots of large memory blocks when tis patch is | ||
148 | found in the kernel, but it doesn't need it. | ||
149 | The consequence is that, when loading the driver as a module, | ||
150 | the module may tell you it's out of memory, but 'free' says | ||
151 | otherwise. The reason is simple; the modules wants its memory | ||
152 | contiguous, not fragmented, and after a long uptime there | ||
153 | probably isn't a fragment of memory large enough... | ||
154 | |||
155 | The driver uses a double buffering scheme, which should really | ||
156 | be an n-way buffer, depending on the size of allocated framebuffer | ||
157 | and the requested grab-size/format. | ||
158 | This current version also fixes a dead-lock situation during irq | ||
159 | time, which really, really froze my system... :) | ||
160 | |||
161 | Good luck. | ||
162 | Pauline | ||