diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/dvb/cards.txt | 4 | ||||
| -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 |
5 files changed, 63 insertions, 166 deletions
diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt index ca58e339d85..cc09187a5db 100644 --- a/Documentation/dvb/cards.txt +++ b/Documentation/dvb/cards.txt @@ -22,10 +22,10 @@ o Frontends drivers: - ves1x93 : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993) - cx24110 : Conexant HM1221/HM1811 (cx24110 or cx24106 demod, cx24108 PLL) - grundig_29504-491 : Grundig 29504-491 (Philips TDA8083 demodulator), tsa5522 PLL - - mt312 : Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLL + - mt312 : Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLLi, Technisat Sky2Pc with bios Rev. 2.3 - stv0299 : Alps BSRU6 (tsa5059 PLL), LG TDQB-S00x (tsa5059 PLL), LG TDQF-S001F (sl1935 PLL), Philips SU1278 (tua6100 PLL), - Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB + Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB, Technisat Sky2Pc with bios Rev. 2.6 DVB-C: - ves1820 : various (ves1820 demodulator, sp5659c or spXXXX PLL) - at76c651 : Atmel AT76c651(B) with DAT7021 PLL diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 8755b3e7b09..62e32b49cec 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -43,7 +43,7 @@ 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] + 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] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 53ce6a39083..f6201cc37ec 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -76,7 +76,7 @@ 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] + 78 -> ASUSTeK P7131 Dual [1043:4862,1043:4876] 79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B) 80 -> ASUS Digimatrix TV [1043:0210] 81 -> Philips Tiger reference design [1131:2018] @@ -99,3 +99,8 @@ 98 -> Proteus Pro 2309 [0919:2003] 99 -> AVerMedia TV Hybrid A16AR [1461:2c00] 100 -> Asus Europa2 OEM [1043:4860] +101 -> Pinnacle PCTV 310i [11bd:002f] +102 -> Avermedia AVerTV Studio 507 [1461:9715] +103 -> Compro Videomate DVB-T200A +104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6701] +105 -> Terratec Cinergy HT PCMCIA [153b:1172] diff --git a/Documentation/video4linux/cafe_ccic b/Documentation/video4linux/cafe_ccic new file mode 100644 index 00000000000..88821022a5d --- /dev/null +++ b/Documentation/video4linux/cafe_ccic @@ -0,0 +1,54 @@ +"cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera +controller. This is the controller found in first-generation OLPC systems, +and this driver was written with support from the OLPC project. + +Current status: the core driver works. It can generate data in YUV422, +RGB565, and RGB444 formats. (Anybody looking at the code will see RGB32 as +well, but that is a debugging aid which will be removed shortly). VGA and +QVGA modes work; CIF is there but the colors remain funky. Only the OV7670 +sensor is known to work with this controller at this time. + +To try it out: either of these commands will work: + + mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound + mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound + +The "xawtv" utility also works; gqcam does not, for unknown reasons. + +There are a few load-time options, most of which can be changed after +loading via sysfs as well: + + - alloc_bufs_at_load: Normally, the driver will not allocate any DMA + buffers until the time comes to transfer data. If this option is set, + then worst-case-sized buffers will be allocated at module load time. + This option nails down the memory for the life of the module, but + perhaps decreases the chances of an allocation failure later on. + + - dma_buf_size: The size of DMA buffers to allocate. Note that this + option is only consulted for load-time allocation; when buffers are + allocated at run time, they will be sized appropriately for the current + camera settings. + + - n_dma_bufs: The controller can cycle through either two or three DMA + buffers. Normally, the driver tries to use three buffers; on faster + systems, however, it will work well with only two. + + - min_buffers: The minimum number of streaming I/O buffers that the driver + will consent to work with. Default is one, but, on slower systems, + better behavior with mplayer can be achieved by setting to a higher + value (like six). + + - max_buffers: The maximum number of streaming I/O buffers; default is + ten. That number was carefully picked out of a hat and should not be + assumed to actually mean much of anything. + + - flip: If this boolean parameter is set, the sensor will be instructed to + invert the video image. Whether it makes sense is determined by how + your particular camera is mounted. + +Work is ongoing with this driver, stay tuned. + +jon + +Jonathan Corbet +corbet@lwn.net diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt deleted file mode 100644 index 1a1c2d03a5c..00000000000 --- a/Documentation/video4linux/zr36120.txt +++ /dev/null @@ -1,162 +0,0 @@ -Driver for Trust Computer Products Framegrabber, version 0.6.1 ------- --- ----- -------- -------- ------------ ------- - - - - -- ZORAN ------------------------------------------------------ - Author: Pauline Middelink <middelin@polyware.nl> - Date: 18 September 1999 -Version: 0.6.1 - -- Description ------------------------------------------------ - -Video4Linux compatible driver for an unknown brand framegrabber -(Sold in the Netherlands by TRUST Computer Products) and various -other zoran zr36120 based framegrabbers. - -The card contains a ZR36120 Multimedia PCI Interface and a Philips -SAA7110 Onechip Frontend videodecoder. There is also an DSP of -which I have forgotten the number, since i will never get that thing -to work without specs from the vendor itself. - -The SAA711x are capable of processing 6 different video inputs, -CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or -SECAM and delivering a YUV datastream. On my card the input -'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2. - -I have some reports of other cards working with the mentioned -chip sets. For a list of other working cards please have a look -at the cards named in the tvcards struct in the beginning of -zr36120.c - -After some testing, I discovered that the carddesigner messed up -on the I2C interface. The Zoran chip includes 2 lines SDA and SCL -which (s)he connected reversely. So we have to clock on the SDA -and r/w data on the SCL pin. Life is fun... Each cardtype now has -a bit which signifies if you have a card with the same deficiency. - -Oh, for the completeness of this story I must mention that my -card delivers the VSYNC pulse of the SAA chip to GIRQ1, not -GIRQ0 as some other cards have. This is also incorporated in -the driver be clearing/setting the 'useirq1' bit in the tvcard -description. - -Another problems of continuous capturing data with a Zoran chip -is something nasty inside the chip. It effectively halves the -fps we ought to get... Here is the scenario: capturing frames -to memory is done in the so-called snapshot mode. In this mode -the Zoran stops after capturing a frame worth of data and wait -till the application set GRAB bit to indicate readiness for the -next frame. After detecting a set bit, the chip neatly waits -till the start of a frame, captures it and it goes back to off. -Smart ppl will notice the problem here. Its the waiting on the -_next_ frame each time we set the GRAB bit... Oh well, 12,5 fps -is still plenty fast for me. --- update 28/7/1999 -- -Don't believe a word I just said... Proof is the output -of `streamer -t 300 -r 25 -f avi15 -o /dev/null` - ++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 - +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- - syncer: done - writer: done -(note the /dev/null is prudent here, my system is not able to - grab /and/ write 25 fps to a file... gifts welcome :) ) -The technical reasoning follows: The zoran completed the last -frame, the VSYNC goes low, and GRAB is cleared. The interrupt -routine starts to work since its VSYNC driven, and again -activates the GRAB bit. A few ms later the VSYNC (re-)rises and -the zoran starts to work on a new and freshly broadcasted frame.... - -For pointers I used the specs of both chips. Below are the URLs: - http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf - http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf -Some alternatives for the Philips SAA 7110 datasheet are: - http://www.datasheetcatalog.com/datasheets_pdf/S/A/A/7/SAA7110.shtml - http://www.datasheetarchive.com/search.php?search=SAA7110&sType=part - -The documentation has very little on absolute numbers or timings -needed for the various modes/resolutions, but there are other -programs you can borrow those from. - ------- Install -------------------------------------------- -Read the file called TODO. Note its long list of limitations. - -Build a kernel with VIDEO4LINUX enabled. Activate the -BT848 driver; we need this because we have need for the -other modules (i2c and videodev) it enables. - -To install this software, extract it into a suitable directory. -Examine the makefile and change anything you don't like. Type "make". - -After making the modules check if you have the much needed -/dev/video devices. If not, execute the following 4 lines: - mknod /dev/video c 81 0 - mknod /dev/video1 c 81 1 - mknod /dev/video2 c 81 2 - mknod /dev/video3 c 81 3 - mknod /dev/video4 c 81 4 - -After making/checking the devices do: - modprobe i2c - modprobe videodev - modprobe saa7110 (optional) - modprobe saa7111 (optional) - modprobe tuner (optional) - insmod zoran cardtype=<n> - -<n> is the cardtype of the card you have. The cardnumber can -be found in the source of zr36120. Look for tvcards. If your -card is not there, please try if any other card gives some -response, and mail me if you got a working tvcard addition. - -PS. <TVCard editors behold!) - Don't forget to set video_input to the number of inputs - you defined in the video_mux part of the tvcard definition. - It's a common error to add a channel but not incrementing - video_input and getting angry with me/v4l/linux/linus :( - -You are now ready to test the framegrabber with your favorite -video4linux compatible tool - ------- Application ---------------------------------------- - -This device works with all Video4Linux compatible applications, -given the limitations in the TODO file. - ------- API ------------------------------------------------ - -This uses the V4L interface as of kernel release 2.1.116, and in -fact has not been tested on any lower version. There are a couple -of minor differences due to the fact that the amount of data returned -with each frame varies, and no doubt there are discrepancies due to my -misunderstanding of the API. I intend to convert this driver to the -new V4L2 API when it has stabilized more. - ------- Current state -------------------------------------- - -The driver is capable of overlaying a video image in screen, and -even capable of grabbing frames. It uses the BIGPHYSAREA patch -to allocate lots of large memory blocks when tis patch is -found in the kernel, but it doesn't need it. -The consequence is that, when loading the driver as a module, -the module may tell you it's out of memory, but 'free' says -otherwise. The reason is simple; the modules wants its memory -contiguous, not fragmented, and after a long uptime there -probably isn't a fragment of memory large enough... - -The driver uses a double buffering scheme, which should really -be an n-way buffer, depending on the size of allocated framebuffer -and the requested grab-size/format. -This current version also fixes a dead-lock situation during irq -time, which really, really froze my system... :) - -Good luck. - Pauline |