PageRenderTime 18ms CodeModel.GetById 15ms app.highlight 1ms RepoModel.GetById 1ms app.codeStats 0ms

Plain Text | 159 lines | 132 code | 27 blank | 0 comment | 0 complexity | 1a294f9b3ff9743465e2acbf17cd6906 MD5 | raw file
  1Driver for Trust Computer Products Framegrabber, version 0.6.1
  2------ --- ----- -------- -------- ------------  ------- - - -
  4- ZORAN ------------------------------------------------------
  5 Author: Pauline Middelink <> 
  6   Date: 18 September 1999
  7Version: 0.6.1
  9- Description ------------------------------------------------
 11Video4Linux compatible driver for an unknown brand framegrabber
 12(Sold in the Netherlands by TRUST Computer Products) and various
 13other zoran zr36120 based framegrabbers.
 15The card contains a ZR36120 Multimedia PCI Interface and a Philips
 16SAA7110 Onechip Frontend videodecoder. There is also an DSP of
 17which I have forgotten the number, since i will never get that thing
 18to work without specs from the vendor itself.
 20The SAA711x are capable of processing 6 different video inputs,
 21CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or
 22SECAM and delivering a YUV datastream.  On my card the input
 23'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2.
 25I have some reports of other cards working with the mentioned
 26chip sets. For a list of other working cards please have a look
 27at the cards named in the tvcards struct in the beginning of
 30After some testing, I discovered that the carddesigner messed up
 31on the I2C interface. The Zoran chip includes 2 lines SDA and SCL
 32which (s)he connected reversely. So we have to clock on the SDA
 33and r/w data on the SCL pin. Life is fun... Each cardtype now has
 34a bit which signifies if you have a card with the same deficiency.
 36Oh, for the completeness of this story I must mention that my
 37card delivers the VSYNC pulse of the SAA chip to GIRQ1, not
 38GIRQ0 as some other cards have. This is also incorporated in
 39the driver be clearing/setting the 'useirq1' bit in the tvcard
 42Another problems of continuous capturing data with a Zoran chip
 43is something nasty inside the chip. It effectively halves the
 44fps we ought to get... Here is the scenario: capturing frames
 45to memory is done in the so-called snapshot mode. In this mode
 46the Zoran stops after capturing a frame worth of data and wait
 47till the application set GRAB bit to indicate readiness for the
 48next frame. After detecting a set bit, the chip neatly waits
 49till the start of a frame, captures it and it goes back to off.
 50Smart 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
 52is still plenty fast for me.
 53-- update 28/7/1999 --
 54Don't believe a word I just said... Proof is the output
 55of `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 :) )
 72The technical reasoning follows: The zoran completed the last
 73frame, the VSYNC goes low, and GRAB is cleared. The interrupt
 74routine starts to work since its VSYNC driven, and again
 75activates the GRAB bit. A few ms later the VSYNC (re-)rises and
 76the zoran starts to work on a new and freshly broadcasted frame....
 78For pointers I used the specs of both chips. Below are the URLs:
 82The documentation has very little on absolute numbers or timings
 83needed for the various modes/resolutions, but there are other
 84programs you can borrow those from.
 86------ Install --------------------------------------------
 87Read the file called TODO.  Note its long list of limitations.
 89Build a kernel with VIDEO4LINUX enabled. Activate the
 90BT848 driver; we need this because we have need for the
 91other modules (i2c and videodev) it enables.
 93To install this software, extract it into a suitable directory.
 94Examine the makefile and change anything you don't like.  Type "make".
 96After making the modules check if you have the much needed
 97/dev/video devices. If not, execute the following 4 lines:
 98	mknod /dev/video c 81 0
 99	mknod /dev/video1 c 81 1
100	mknod /dev/video2 c 81 2
101	mknod /dev/video3 c 81 3
102	mknod /dev/video4 c 81 4
104After making/checking the devices do:
105	modprobe i2c
106	modprobe videodev
107	modprobe saa7110	(optional)
108	modprobe saa7111	(optional)
109	modprobe tuner		(optional)
110	insmod zoran cardtype=<n>
112<n> is the cardtype of the card you have. The cardnumber can
113be found in the source of zr36120. Look for tvcards. If your
114card is not there, please try if any other card gives some
115response, and mail me if you got a working tvcard addition. 
117PS. <TVCard editors behold!)
118    Dont forget to set video_input to the number of inputs
119    you defined in the video_mux part of the tvcard definition.
120    Its a common error to add a channel but not incrementing
121    video_input and getting angry with me/v4l/linux/linus :(
123You are now ready to test the framegrabber with your favorite
124video4linux compatible tool
126------ Application ----------------------------------------
128This device works with all Video4Linux compatible applications,
129given the limitations in the TODO file.
131------ API ------------------------------------------------
133This uses the V4L interface as of kernel release 2.1.116, and in
134fact has not been tested on any lower version.  There are a couple
135of minor differences due to the fact that the amount of data returned
136with each frame varies, and no doubt there are discrepancies due to my
137misunderstanding of the API.  I intend to convert this driver to the
138new V4L2 API when it has stabilized more.
140------ Current state --------------------------------------
142The driver is capable of overlaying a video image in screen, and
143even capable of grabbing frames. It uses the BIGPHYSAREA patch
144to allocate lots of large memory blocks when tis patch is
145found in the kernel, but it doesn't need it.
146The consequence is that, when loading the driver as a module,
147the module may tell you it's out of memory, but 'free' says
148otherwise. The reason is simple; the modules wants its memory
149contiguous, not fragmented, and after a long uptime there
150probably isn't a fragment of memory large enough...
152The driver uses a double buffering scheme, which should really
153be an n-way buffer, depending on the size of allocated framebuffer
154and the requested grab-size/format.
155This current version also fixes a dead-lock situation during irq
156time, which really, really froze my system... :)
158Good luck.
159  Pauline