1 Iomega Buz Driver for Linux
2 ===========================
3
4 by Rainer Johanni <Rainer@Johanni.de>
5
6 Compiling and Loading the Driver
7 ================================
8
9 You must run a 2.2.x kernel in order to use this driver.
10
11 To compile the driver, just type make.
12
13 Besides the files in this directory, the driver needs the
14 'videodev' and the 'i2c' module from the Linux kernel.
15 In order to get these modules available, enable module support
16 for VIDEODEV and BTTV (which implies i2c) in your kernel
17 configuration. You find these devices in the menu
18 "Character Devices" in your Kernel Configuration.
19
20 Before you load the driver you must have a video device
21 at major device node 81. If you don't have it yet, do the
22 following (as root!):
23
24 cd /dev
25 mknod video0 c 81 0
26 ln -s video0 video
27
28 Edit the 'update' script if you want to give the driver
29 special options and then type (as root)
30
31 ./update
32
33 to insert all the necessary modules into the kernel.
34
35 If you want to make full use of the Video for Linux uncompressed
36 grabbing facilities, you must either
37
38 - obtain and install the "big_physarea patch" for your kernel and
39 set aside the necessary memory during boot time.
40 There seem to be several versions of this patch against
41 various kernel versions floating around in the net,
42 you may obtain one e.g. from:
43 http://www.polyware.nl/~middelin/patch/bigphysarea-2.2.1.tar.gz
44 You also have to compile your driver AFTER installing that patch
45 in order to get it working
46
47 or
48
49 - start your kernel with the mem=xxx option, where xxx is your
50 real memory minus the memory needed for the buffers.
51 For doing this add an entry in lilo.conf (if you use lilo):
52 append "mem=xxxM"
53 or add a line in your linux.par file (if you use loadlin):
54 mem=xxxM
55
56 The second method is by far easier, however it is dangerous
57 if more than one driver at a time has the idea to use the memory
58 leftover by setting the mem=xxx parameter below the actual
59 memory size.
60
61 Read also below how to use this memory!
62
63
64
65 Driver Options
66 ==============
67
68 You are able to customize the behavior of the driver by giving
69 it some options at start time.
70
71 default_input, default_norm
72 ---------------------------
73
74 As soon as the driver is loaded, the Buz samples video signals
75 from one of its input ports and displays it on its output.
76 The driver uses the Composite Input and the video norm PAL for this.
77 If you want to change this default behavior, set default_input=1
78 (for S-VHS input) or default_norm=1 for NTSC.
79
80 v4l_nbufs, v4l_bufsize
81 ----------------------
82
83 In order to make to make full use of the Video for Linux picture
84 grabbing facilities of the driver (which are needed by many
85 Video for Linux applications), the driver needs a set of
86 physically contiguous buffers for grabbing. These parameters
87 determine how many buffers of which size the driver will
88 allocate at open (the open will fail if it is unable to do so!).
89
90 These values do not affect the MJPEG grabbing facilities of the driver,
91 they are needed for uncompressed image grabbing only!!!
92
93 v4l_nbufs is the number of buffers to allocate, a value of 2 (the default)
94 should be sufficient in almost all cases. Only special applications
95 (streaming captures) will need more buffers and then mostly the
96 MJPEG capturing features of the Buz will be more appropriate.
97 So leave this parameter at it's default unless you know what you do.
98
99 The things for v4l_bufsize are more complicated:
100 v4l_bufsize is set by default to 128 [KB] which is the maximum
101 amount of physically contiguous memory Linux is able to allocate
102 without kernel changes. This is sufficient for grabbing 24 bit color images
103 up to sizes of approx. 240x180 pixels (240*180*3 = 129600, 128 KB = 131072).
104
105 In order to be able to capture bigger images you have either to
106 - obtain and install the "big_physarea patch" and set aside
107 the necessary memory during boot time or
108 - start your kernel with the mem=xxx option, where xxx is your
109 real memory minus the memory needed for the buffers.
110 In that case, useful settings for v4l_bufsize are
111 - 1296 [Kb] for grabbing 24 bit images of max size 768*576
112 - 1728 [Kb] for 32bit images of same size (4*768*576 = 1728 Kb!)
113 You may reduce these numbers accordingly if you know you are only
114 grabbing 720 pixels wide images or NTSC images (max height 480).
115
116 In some cases it may happen that Linux isn't even able to obtain
117 the default 128 KB buffers. If you don't need uncompressed image
118 grabbing at all, set v4l_bufsize to an arbitrary small value (e.g. 4)
119 in order to be able to open the video device.
120
121 vidmem
122 ------
123
124 The video mem address of the video card.
125 The driver has a little database for some videocards
126 to determine it from there. If your video card is not in there
127 you have either to give it to the driver as a parameter
128 or set in in a VIDIOCSFBUF ioctl
129
130 The videocard database is contained in the file "videocards.h"
131 Gernot Ziegler wants to keep an actual version of that file.
132 If your card is not contained in that file, look at
133 http://www.lysator.liu.se/~gz/buz/ for an actual version of
134 "videocards.h".
135
136 triton, natoma
137 --------------
138
139 The driver tries to detect if you have a triton or natome chipset
140 in order to take special measures for these chipsets.
141 If this detection fails but you are sure you have such a chipset,
142 set the corresponding variable to 1.
143 This is a very special option and may go away in the future.
144
145
146
147 Programming interface
148 =====================
149
150 This driver should be fully compliant to Video for Linux, so all
151 tools working with Video for Linux should work with (hopefully)
152 no problems.
153
154 A description of the Video for Linux programming interface can be found at:
155 http://roadrunner.swansea.linux.org.uk/v4lapi.shtml
156
157 Besides the Video for Linux interface, the driver has a "proprietary"
158 interface for accessing the Buz's MJPEG capture and playback facilities.
159
160 The ioctls for that interface are as follows:
161
162 BUZIOC_G_PARAMS
163 BUZIOC_S_PARAMS
164
165 Get and set the parameters of the buz. The user should always
166 do a BUZIOC_G_PARAMS (with a struct buz_params) to obtain the default
167 settings, change what he likes and then make a BUZIOC_S_PARAMS call.
168 A typical application should at least set the members
169 input, norm and decimation of the struct buz_params.
170 For a full description of all members see "buz.h"
171
172 BUZIOC_REQBUFS
173
174 Before being able to capture/playback, the user has to request
175 the buffers he is wanting to use. Fill the structure
176 buz_requestbuffers with the size (recommended: 256*1024) and
177 the number (recommended 32 up to 256). There are no such restrictions
178 as for the Video for Linux buffers, you should LEAVE SUFFICIENT
179 MEMORY for your system however, else strange things will happen ....
180 On return, the buz_requestbuffers structure contains number and
181 size of the actually allocated buffers.
182 You should use these numbers for doing a mmap of the buffers
183 into the user space.
184 The BUZIOC_REQBUFS ioctl also makes it happen, that the next mmap
185 maps the MJPEG buffer instead of the V4L buffers.
186
187 BUZIOC_QBUF_CAPT
188 BUZIOC_QBUF_PLAY
189
190 Queue a buffer for capture or playback. The first call also starts
191 streaming capture. When streaming capture is going on, you may
192 only queue further buffers or issue syncs until streaming
193 capture is switched off again with a argument of -1 to
194 a BUZIOC_QBUF_CAPT/BUZIOC_QBUF_PLAY ioctl.
195
196 BUZIOC_SYNC
197
198 Issue this ioctl when all buffers are queued. This ioctl will
199 block until the first buffer becomes free for saving its
200 data to disk (after BUZIOC_QBUF_CAPT) or for reuse (after BUZIOC_QBUF_PLAY).
201
202 BUZIOC_G_STATUS
203
204 Get the status of the input lines (video source connected/norm).
205 This ioctl may be subject to change.
206
207
208
209
210
211 See the examples directory delivered with this driver
212 for actual coding examples!
This page was automatically generated by the
LXR engine.
Visit the LXR main site for more
information.