1 |
1275 |
phoenix |
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
Video4Linux Programming
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
Alan
|
10 |
|
|
Cox
|
11 |
|
|
|
12 |
|
|
|
13 |
|
|
alan@redhat.com
|
14 |
|
|
|
15 |
|
|
|
16 |
|
|
|
17 |
|
|
|
18 |
|
|
|
19 |
|
|
|
20 |
|
|
2000
|
21 |
|
|
Alan Cox
|
22 |
|
|
|
23 |
|
|
|
24 |
|
|
|
25 |
|
|
|
26 |
|
|
This documentation is free software; you can redistribute
|
27 |
|
|
it and/or modify it under the terms of the GNU General Public
|
28 |
|
|
License as published by the Free Software Foundation; either
|
29 |
|
|
version 2 of the License, or (at your option) any later
|
30 |
|
|
version.
|
31 |
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
|
|
This program is distributed in the hope that it will be
|
35 |
|
|
useful, but WITHOUT ANY WARRANTY; without even the implied
|
36 |
|
|
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
37 |
|
|
See the GNU General Public License for more details.
|
38 |
|
|
|
39 |
|
|
|
40 |
|
|
|
41 |
|
|
You should have received a copy of the GNU General Public
|
42 |
|
|
License along with this program; if not, write to the Free
|
43 |
|
|
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
44 |
|
|
MA 02111-1307 USA
|
45 |
|
|
|
46 |
|
|
|
47 |
|
|
|
48 |
|
|
For more details see the file COPYING in the source
|
49 |
|
|
distribution of Linux.
|
50 |
|
|
|
51 |
|
|
|
52 |
|
|
|
53 |
|
|
|
54 |
|
|
|
55 |
|
|
|
56 |
|
|
|
57 |
|
|
Introduction
|
58 |
|
|
|
59 |
|
|
Parts of this document first appeared in Linux Magazine under a
|
60 |
|
|
ninety day exclusivity.
|
61 |
|
|
|
62 |
|
|
|
63 |
|
|
Video4Linux is intended to provide a common programming interface
|
64 |
|
|
for the many TV and capture cards now on the market, as well as
|
65 |
|
|
parallel port and USB video cameras. Radio, teletext decoders and
|
66 |
|
|
vertical blanking data interfaces are also provided.
|
67 |
|
|
|
68 |
|
|
|
69 |
|
|
|
70 |
|
|
Radio Devices
|
71 |
|
|
|
72 |
|
|
There are a wide variety of radio interfaces available for PC's, and these
|
73 |
|
|
are generally very simple to program. The biggest problem with supporting
|
74 |
|
|
such devices is normally extracting documentation from the vendor.
|
75 |
|
|
|
76 |
|
|
|
77 |
|
|
The radio interface supports a simple set of control ioctls standardised
|
78 |
|
|
across all radio and tv interfaces. It does not support read or write, which
|
79 |
|
|
are used for video streams. The reason radio cards do not allow you to read
|
80 |
|
|
the audio stream into an application is that without exception they provide
|
81 |
|
|
a connection on to a soundcard. Soundcards can be used to read the radio
|
82 |
|
|
data just fine.
|
83 |
|
|
|
84 |
|
|
|
85 |
|
|
Registering Radio Devices
|
86 |
|
|
|
87 |
|
|
The Video4linux core provides an interface for registering devices. The
|
88 |
|
|
first step in writing our radio card driver is to register it.
|
89 |
|
|
|
90 |
|
|
|
91 |
|
|
|
92 |
|
|
|
93 |
|
|
static struct video_device my_radio
|
94 |
|
|
{
|
95 |
|
|
"My radio",
|
96 |
|
|
VID_TYPE_TUNER,
|
97 |
|
|
VID_HARDWARE_MYRADIO,
|
98 |
|
|
radio_open.
|
99 |
|
|
radio_close,
|
100 |
|
|
NULL, /* no read */
|
101 |
|
|
NULL, /* no write */
|
102 |
|
|
NULL, /* no poll */
|
103 |
|
|
radio_ioctl,
|
104 |
|
|
NULL, /* no special init function */
|
105 |
|
|
NULL /* no private data */
|
106 |
|
|
};
|
107 |
|
|
|
108 |
|
|
|
109 |
|
|
|
110 |
|
|
|
111 |
|
|
This declares our video4linux device driver interface. The VID_TYPE_ value
|
112 |
|
|
defines what kind of an interface we are, and defines basic capabilities.
|
113 |
|
|
|
114 |
|
|
|
115 |
|
|
The only defined value relevant for a radio card is VID_TYPE_TUNER which
|
116 |
|
|
indicates that the device can be tuned. Clearly our radio is going to have some
|
117 |
|
|
way to change channel so it is tuneable.
|
118 |
|
|
|
119 |
|
|
|
120 |
|
|
The VID_HARDWARE_ types are unique to each device. Numbers are assigned by
|
121 |
|
|
alan@redhat.com when device drivers are going to be released. Until then you
|
122 |
|
|
can pull a suitably large number out of your hat and use it. 10000 should be
|
123 |
|
|
safe for a very long time even allowing for the huge number of vendors
|
124 |
|
|
making new and different radio cards at the moment.
|
125 |
|
|
|
126 |
|
|
|
127 |
|
|
We declare an open and close routine, but we do not need read or write,
|
128 |
|
|
which are used to read and write video data to or from the card itself. As
|
129 |
|
|
we have no read or write there is no poll function.
|
130 |
|
|
|
131 |
|
|
|
132 |
|
|
The private initialise function is run when the device is registered. In
|
133 |
|
|
this driver we've already done all the work needed. The final pointer is a
|
134 |
|
|
private data pointer that can be used by the device driver to attach and
|
135 |
|
|
retrieve private data structures. We set this field "priv" to NULL for
|
136 |
|
|
the moment.
|
137 |
|
|
|
138 |
|
|
|
139 |
|
|
Having the structure defined is all very well but we now need to register it
|
140 |
|
|
with the kernel.
|
141 |
|
|
|
142 |
|
|
|
143 |
|
|
|
144 |
|
|
|
145 |
|
|
static int io = 0x320;
|
146 |
|
|
|
147 |
|
|
int __init myradio_init(struct video_init *v)
|
148 |
|
|
{
|
149 |
|
|
if(!request_region(io, MY_IO_SIZE, "myradio"))
|
150 |
|
|
{
|
151 |
|
|
printk(KERN_ERR
|
152 |
|
|
"myradio: port 0x%03X is in use.\n", io);
|
153 |
|
|
return -EBUSY;
|
154 |
|
|
}
|
155 |
|
|
|
156 |
|
|
if(video_device_register(&my_radio, VFL_TYPE_RADIO)==-1) {
|
157 |
|
|
release_region(io, MY_IO_SIZE);
|
158 |
|
|
return -EINVAL;
|
159 |
|
|
}
|
160 |
|
|
return 0;
|
161 |
|
|
}
|
162 |
|
|
|
163 |
|
|
|
164 |
|
|
|
165 |
|
|
The first stage of the initialisation, as is normally the case, is to check
|
166 |
|
|
that the I/O space we are about to fiddle with doesn't belong to some other
|
167 |
|
|
driver. If it is we leave well alone. If the user gives the address of the
|
168 |
|
|
wrong device then we will spot this. These policies will generally avoid
|
169 |
|
|
crashing the machine.
|
170 |
|
|
|
171 |
|
|
|
172 |
|
|
Now we ask the Video4Linux layer to register the device for us. We hand it
|
173 |
|
|
our carefully designed video_device structure and also tell it which group
|
174 |
|
|
of devices we want it registered with. In this case VFL_TYPE_RADIO.
|
175 |
|
|
|
176 |
|
|
|
177 |
|
|
The types available are
|
178 |
|
|
|
179 |
|
|
Device Types
180 |
|
|
|
181 |
|
|
182 |
|
|
|
|
183 |
|
|
VFL_TYPE_RADIO>/dev/radio{n}>
|
184 |
|
|
|
185 |
|
|
Radio devices are assigned in this block. As with all of these
|
186 |
|
|
selections the actual number assignment is done by the video layer
|
187 |
|
|
accordijng to what is free.
|
188 |
|
|
|
|
189 |
|
|
VFL_TYPE_GRABBER>/dev/video{n}>
|
190 |
|
|
Video capture devices and also -- counter-intuitively for the name --
|
191 |
|
|
hardware video playback devices such as MPEG2 cards.
|
192 |
|
|
|
|
193 |
|
|
VFL_TYPE_VBI>/dev/vbi{n}>
|
194 |
|
|
The VBI devices capture the hidden lines on a television picture
|
195 |
|
|
that carry further information like closed caption data, teletext
|
196 |
|
|
(primarily in Europe) and now Intercast and the ATVEC internet
|
197 |
|
|
television encodings.
|
198 |
|
|
|
|
199 |
|
|
VFL_TYPE_VTX>/dev/vtx[n}>
|
200 |
|
|
VTX is 'Videotext' also known as 'Teletext'. This is a system for
|
201 |
|
|
sending numbered, 40x25, mostly textual page images over the hidden
|
202 |
|
|
lines. Unlike the /dev/vbi interfaces, this is for 'smart' decoder
|
203 |
|
|
chips. (The use of the word smart here has to be taken in context,
|
204 |
|
|
the smartest teletext chips are fairly dumb pieces of technology).
|
205 |
|
|
|
206 |
|
|
|
207 |
|
|
|
|
208 |
|
|
|
209 |
|
|
|
|
210 |
|
|
|
211 |
|
|
We are most definitely a radio.
|
212 |
|
|
|
213 |
|
|
|
214 |
|
|
Finally we allocate our I/O space so that nobody treads on us and return 0
|
215 |
|
|
to signify general happiness with the state of the universe.
|
216 |
|
|
|
217 |
|
|
|
218 |
|
|
|
219 |
|
|
Opening And Closing The Radio
|
220 |
|
|
|
221 |
|
|
|
222 |
|
|
The functions we declared in our video_device are mostly very simple.
|
223 |
|
|
Firstly we can drop in what is basically standard code for open and close.
|
224 |
|
|
|
225 |
|
|
|
226 |
|
|
|
227 |
|
|
|
228 |
|
|
static int users = 0;
|
229 |
|
|
|
230 |
|
|
static int radio_open(stuct video_device *dev, int flags)
|
231 |
|
|
{
|
232 |
|
|
if(users)
|
233 |
|
|
return -EBUSY;
|
234 |
|
|
users++;
|
235 |
|
|
MOD_INC_USE_COUNT;
|
236 |
|
|
return 0;
|
237 |
|
|
}
|
238 |
|
|
|
239 |
|
|
|
240 |
|
|
|
241 |
|
|
At open time we need to do nothing but check if someone else is also using
|
242 |
|
|
the radio card. If nobody is using it we make a note that we are using it,
|
243 |
|
|
then we ensure that nobody unloads our driver on us.
|
244 |
|
|
|
245 |
|
|
|
246 |
|
|
|
247 |
|
|
|
248 |
|
|
static int radio_close(struct video_device *dev)
|
249 |
|
|
{
|
250 |
|
|
users--;
|
251 |
|
|
MOD_DEC_USE_COUNT;
|
252 |
|
|
}
|
253 |
|
|
|
254 |
|
|
|
255 |
|
|
|
256 |
|
|
At close time we simply need to reduce the user count and allow the module
|
257 |
|
|
to become unloadable.
|
258 |
|
|
|
259 |
|
|
|
260 |
|
|
If you are sharp you will have noticed neither the open nor the close
|
261 |
|
|
routines attempt to reset or change the radio settings. This is intentional.
|
262 |
|
|
It allows an application to set up the radio and exit. It avoids a user
|
263 |
|
|
having to leave an application running all the time just to listen to the
|
264 |
|
|
radio.
|
265 |
|
|
|
266 |
|
|
|
267 |
|
|
|
268 |
|
|
The Ioctl Interface
|
269 |
|
|
|
270 |
|
|
This leaves the ioctl routine, without which the driver will not be
|
271 |
|
|
terribly useful to anyone.
|
272 |
|
|
|
273 |
|
|
|
274 |
|
|
|
275 |
|
|
|
276 |
|
|
static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
|
277 |
|
|
{
|
278 |
|
|
switch(cmd)
|
279 |
|
|
{
|
280 |
|
|
case VIDIOCGCAP:
|
281 |
|
|
{
|
282 |
|
|
struct video_capability v;
|
283 |
|
|
v.type = VID_TYPE_TUNER;
|
284 |
|
|
v.channels = 1;
|
285 |
|
|
v.audios = 1;
|
286 |
|
|
v.maxwidth = 0;
|
287 |
|
|
v.minwidth = 0;
|
288 |
|
|
v.maxheight = 0;
|
289 |
|
|
v.minheight = 0;
|
290 |
|
|
strcpy(v.name, "My Radio");
|
291 |
|
|
if(copy_to_user(arg, &v, sizeof(v)))
|
292 |
|
|
return -EFAULT;
|
293 |
|
|
return 0;
|
294 |
|
|
}
|
295 |
|
|
|
296 |
|
|
|
297 |
|
|
|
298 |
|
|
VIDIOCGCAP is the first ioctl all video4linux devices must support. It
|
299 |
|
|
allows the applications to find out what sort of a card they have found and
|
300 |
|
|
to figure out what they want to do about it. The fields in the structure are
|
301 |
|
|
|
302 |
|
|
struct video_capability fields
303 |
|
|
|
304 |
|
|
305 |
|
|
|
|
306 |
|
|
name>The device text name. This is intended for the user.>
|
307 |
|
|
|
|
308 |
|
|
channels>The number of different channels you can tune on
|
309 |
|
|
this card. It could even by zero for a card that has
|
310 |
|
|
no tuning capability. For our simple FM radio it is 1.
|
311 |
|
|
An AM/FM radio would report 2.
|
312 |
|
|
|
|
313 |
|
|
audios>The number of audio inputs on this device. For our
|
314 |
|
|
radio there is only one audio input.
|
315 |
|
|
|
|
316 |
|
|
minwidth,minheight>The smallest size the card is capable of capturing
|
317 |
|
|
images in. We set these to zero. Radios do not
|
318 |
|
|
capture pictures
|
319 |
|
|
|
|
320 |
|
|
maxwidth,maxheight>The largest image size the card is capable of
|
321 |
|
|
capturing. For our radio we report 0.
|
322 |
|
|
|
323 |
|
|
|
|
324 |
|
|
type>This reports the capabilities of the device, and
|
325 |
|
|
matches the field we filled in in the struct
|
326 |
|
|
video_device when registering.
|
327 |
|
|
|
328 |
|
|
|
|
329 |
|
|
|
330 |
|
|
|
|
331 |
|
|
|
332 |
|
|
Having filled in the fields, we use copy_to_user to copy the structure into
|
333 |
|
|
the users buffer. If the copy fails we return an EFAULT to the application
|
334 |
|
|
so that it knows it tried to feed us garbage.
|
335 |
|
|
|
336 |
|
|
|
337 |
|
|
The next pair of ioctl operations select which tuner is to be used and let
|
338 |
|
|
the application find the tuner properties. We have only a single FM band
|
339 |
|
|
tuner in our example device.
|
340 |
|
|
|
341 |
|
|
|
342 |
|
|
|
343 |
|
|
|
344 |
|
|
case VIDIOCGTUNER:
|
345 |
|
|
{
|
346 |
|
|
struct video_tuner v;
|
347 |
|
|
if(copy_from_user(&v, arg, sizeof(v))!=0)
|
348 |
|
|
return -EFAULT;
|
349 |
|
|
if(v.tuner)
|
350 |
|
|
return -EINVAL;
|
351 |
|
|
v.rangelow=(87*16000);
|
352 |
|
|
v.rangehigh=(108*16000);
|
353 |
|
|
v.flags = VIDEO_TUNER_LOW;
|
354 |
|
|
v.mode = VIDEO_MODE_AUTO;
|
355 |
|
|
v.signal = 0xFFFF;
|
356 |
|
|
strcpy(v.name, "FM");
|
357 |
|
|
if(copy_to_user(&v, arg, sizeof(v))!=0)
|
358 |
|
|
return -EFAULT;
|
359 |
|
|
return 0;
|
360 |
|
|
}
|
361 |
|
|
|
362 |
|
|
|
363 |
|
|
|
364 |
|
|
The VIDIOCGTUNER ioctl allows applications to query a tuner. The application
|
365 |
|
|
sets the tuner field to the tuner number it wishes to query. The query does
|
366 |
|
|
not change the tuner that is being used, it merely enquires about the tuner
|
367 |
|
|
in question.
|
368 |
|
|
|
369 |
|
|
|
370 |
|
|
We have exactly one tuner so after copying the user buffer to our temporary
|
371 |
|
|
structure we complain if they asked for a tuner other than tuner 0.
|
372 |
|
|
|
373 |
|
|
|
374 |
|
|
The video_tuner structure has the following fields
|
375 |
|
|
|
376 |
|
|
struct video_tuner fields
377 |
|
|
|
378 |
|
|
379 |
|
|
|
|
380 |
|
|
int tuner>The number of the tuner in question
|
381 |
|
|
|
|
382 |
|
|
char name[32]>A text description of this tuner. "FM" will do fine.
|
383 |
|
|
This is intended for the application.
|
384 |
|
|
|
|
385 |
|
|
u32 flags>
|
386 |
|
|
Tuner capability flags
|
387 |
|
|
|
388 |
|
|
|
|
389 |
|
|
u16 mode>The current reception mode
|
390 |
|
|
|
391 |
|
|
|
|
392 |
|
|
u16 signal>The signal strength scaled between 0 and 65535. If
|
393 |
|
|
a device cannot tell the signal strength it should
|
394 |
|
|
report 65535. Many simple cards contain only a
|
395 |
|
|
signal/no signal bit. Such cards will report either
|
396 |
|
|
|
397 |
|
|
|
398 |
|
|
|
|
399 |
|
|
u32 rangelow, rangehigh>
|
400 |
|
|
The range of frequencies supported by the radio
|
401 |
|
|
or TV. It is scaled according to the VIDEO_TUNER_LOW
|
402 |
|
|
flag.
|
403 |
|
|
|
404 |
|
|
|
405 |
|
|
|
|
406 |
|
|
|
407 |
|
|
|
|
408 |
|
|
|
409 |
|
|
struct video_tuner flags
410 |
|
|
|
411 |
|
|
412 |
|
|
|
|
413 |
|
|
VIDEO_TUNER_PAL>A PAL TV tuner
|
414 |
|
|
|
|
415 |
|
|
VIDEO_TUNER_NTSC>An NTSC (US) TV tuner
|
416 |
|
|
|
|
417 |
|
|
VIDEO_TUNER_SECAM>A SECAM (French) TV tuner
|
418 |
|
|
|
|
419 |
|
|
VIDEO_TUNER_LOW>
|
420 |
|
|
The tuner frequency is scaled in 1/16th of a KHz
|
421 |
|
|
steps. If not it is in 1/16th of a MHz steps
|
422 |
|
|
|
423 |
|
|
|
|
424 |
|
|
VIDEO_TUNER_NORM>The tuner can set its format
|
425 |
|
|
|
|
426 |
|
|
VIDEO_TUNER_STEREO_ON>The tuner is currently receiving a stereo signal
|
427 |
|
|
|
428 |
|
|
|
|
429 |
|
|
|
430 |
|
|
|
|
431 |
|
|
|
432 |
|
|
struct video_tuner modes
433 |
|
|
|
434 |
|
|
435 |
|
|
|
|
436 |
|
|
VIDEO_MODE_PAL>PAL Format
|
437 |
|
|
|
|
438 |
|
|
VIDEO_MODE_NTSC>NTSC Format (USA)
|
439 |
|
|
|
|
440 |
|
|
VIDEO_MODE_SECAM>French Format
|
441 |
|
|
|
|
442 |
|
|
VIDEO_MODE_AUTO>A device that does not need to do
|
443 |
|
|
TV format switching
|
444 |
|
|
|
445 |
|
|
|
|
446 |
|
|
|
447 |
|
|
|
|
448 |
|
|
|
449 |
|
|
The settings for the radio card are thus fairly simple. We report that we
|
450 |
|
|
are a tuner called "FM" for FM radio. In order to get the best tuning
|
451 |
|
|
resolution we report VIDEO_TUNER_LOW and select tuning to 1/16th of KHz. Its
|
452 |
|
|
unlikely our card can do that resolution but it is a fair bet the card can
|
453 |
|
|
do better than 1/16th of a MHz. VIDEO_TUNER_LOW is appropriate to almost all
|
454 |
|
|
radio usage.
|
455 |
|
|
|
456 |
|
|
|
457 |
|
|
We report that the tuner automatically handles deciding what format it is
|
458 |
|
|
receiving - true enough as it only handles FM radio. Our example card is
|
459 |
|
|
also incapable of detecting stereo or signal strengths so it reports a
|
460 |
|
|
strength of 0xFFFF (maximum) and no stereo detected.
|
461 |
|
|
|
462 |
|
|
|
463 |
|
|
To finish off we set the range that can be tuned to be 87-108Mhz, the normal
|
464 |
|
|
FM broadcast radio range. It is important to find out what the card is
|
465 |
|
|
actually capable of tuning. It is easy enough to simply use the FM broadcast
|
466 |
|
|
range. Unfortunately if you do this you will discover the FM broadcast
|
467 |
|
|
ranges in the USA, Europe and Japan are all subtly different and some users
|
468 |
|
|
cannot receive all the stations they wish.
|
469 |
|
|
|
470 |
|
|
|
471 |
|
|
The application also needs to be able to set the tuner it wishes to use. In
|
472 |
|
|
our case, with a single tuner this is rather simple to arrange.
|
473 |
|
|
|
474 |
|
|
|
475 |
|
|
|
476 |
|
|
case VIDIOCSTUNER:
|
477 |
|
|
{
|
478 |
|
|
struct video_tuner v;
|
479 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
480 |
|
|
return -EFAULT;
|
481 |
|
|
if(v.tuner != 0)
|
482 |
|
|
return -EINVAL;
|
483 |
|
|
return 0;
|
484 |
|
|
}
|
485 |
|
|
|
486 |
|
|
|
487 |
|
|
|
488 |
|
|
We copy the user supplied structure into kernel memory so we can examine it.
|
489 |
|
|
If the user has selected a tuner other than zero we reject the request. If
|
490 |
|
|
they wanted tuner 0 then, surprisingly enough, that is the current tuner already.
|
491 |
|
|
|
492 |
|
|
|
493 |
|
|
The next two ioctls we need to provide are to get and set the frequency of
|
494 |
|
|
the radio. These both use an unsigned long argument which is the frequency.
|
495 |
|
|
The scale of the frequency depends on the VIDEO_TUNER_LOW flag as I
|
496 |
|
|
mentioned earlier on. Since we have VIDEO_TUNER_LOW set this will be in
|
497 |
|
|
1/16ths of a KHz.
|
498 |
|
|
|
499 |
|
|
|
500 |
|
|
|
501 |
|
|
static unsigned long current_freq;
|
502 |
|
|
|
503 |
|
|
|
504 |
|
|
|
505 |
|
|
case VIDIOCGFREQ:
|
506 |
|
|
if(copy_to_user(arg, ¤t_freq,
|
507 |
|
|
sizeof(unsigned long))
|
508 |
|
|
return -EFAULT;
|
509 |
|
|
return 0;
|
510 |
|
|
|
511 |
|
|
|
512 |
|
|
|
513 |
|
|
Querying the frequency in our case is relatively simple. Our radio card is
|
514 |
|
|
too dumb to let us query the signal strength so we remember our setting if
|
515 |
|
|
we know it. All we have to do is copy it to the user.
|
516 |
|
|
|
517 |
|
|
|
518 |
|
|
|
519 |
|
|
|
520 |
|
|
case VIDIOCSFREQ:
|
521 |
|
|
{
|
522 |
|
|
u32 freq;
|
523 |
|
|
if(copy_from_user(arg, &freq,
|
524 |
|
|
sizeof(unsigned long))!=0)
|
525 |
|
|
return -EFAULT;
|
526 |
|
|
if(hardware_set_freq(freq)<0)
|
527 |
|
|
return -EINVAL;
|
528 |
|
|
current_freq = freq;
|
529 |
|
|
return 0;
|
530 |
|
|
}
|
531 |
|
|
|
532 |
|
|
|
533 |
|
|
|
534 |
|
|
Setting the frequency is a little more complex. We begin by copying the
|
535 |
|
|
desired frequency into kernel space. Next we call a hardware specific routine
|
536 |
|
|
to set the radio up. This might be as simple as some scaling and a few
|
537 |
|
|
writes to an I/O port. For most radio cards it turns out a good deal more
|
538 |
|
|
complicated and may involve programming things like a phase locked loop on
|
539 |
|
|
the card. This is what documentation is for.
|
540 |
|
|
|
541 |
|
|
|
542 |
|
|
The final set of operations we need to provide for our radio are the
|
543 |
|
|
volume controls. Not all radio cards can even do volume control. After all
|
544 |
|
|
there is a perfectly good volume control on the sound card. We will assume
|
545 |
|
|
our radio card has a simple 4 step volume control.
|
546 |
|
|
|
547 |
|
|
|
548 |
|
|
There are two ioctls with audio we need to support
|
549 |
|
|
|
550 |
|
|
|
551 |
|
|
|
552 |
|
|
static int current_volume=0;
|
553 |
|
|
|
554 |
|
|
case VIDIOCGAUDIO:
|
555 |
|
|
{
|
556 |
|
|
struct video_audio v;
|
557 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
558 |
|
|
return -EFAULT;
|
559 |
|
|
if(v.audio != 0)
|
560 |
|
|
return -EINVAL;
|
561 |
|
|
v.volume = 16384*current_volume;
|
562 |
|
|
v.step = 16384;
|
563 |
|
|
strcpy(v.name, "Radio");
|
564 |
|
|
v.mode = VIDEO_SOUND_MONO;
|
565 |
|
|
v.balance = 0;
|
566 |
|
|
v.base = 0;
|
567 |
|
|
v.treble = 0;
|
568 |
|
|
|
569 |
|
|
if(copy_to_user(arg. &v, sizeof(v)))
|
570 |
|
|
return -EFAULT;
|
571 |
|
|
return 0;
|
572 |
|
|
}
|
573 |
|
|
|
574 |
|
|
|
575 |
|
|
|
576 |
|
|
Much like the tuner we start by copying the user structure into kernel
|
577 |
|
|
space. Again we check if the user has asked for a valid audio input. We have
|
578 |
|
|
only input 0 and we punt if they ask for another input.
|
579 |
|
|
|
580 |
|
|
|
581 |
|
|
Then we fill in the video_audio structure. This has the following format
|
582 |
|
|
|
583 |
|
|
struct video_audio fields
584 |
|
|
|
585 |
|
|
586 |
|
|
|
|
587 |
|
|
audio>The input the user wishes to query>
|
588 |
|
|
|
|
589 |
|
|
volume>The volume setting on a scale of 0-65535>
|
590 |
|
|
|
|
591 |
|
|
base>The base level on a scale of 0-65535>
|
592 |
|
|
|
|
593 |
|
|
treble>The treble level on a scale of 0-65535>
|
594 |
|
|
|
|
595 |
|
|
flags>The features this audio device supports
|
596 |
|
|
|
597 |
|
|
|
|
598 |
|
|
name>A text name to display to the user. We picked
|
599 |
|
|
"Radio" as it explains things quite nicely.>
|
600 |
|
|
|
|
601 |
|
|
mode>The current reception mode for the audio
|
602 |
|
|
|
603 |
|
|
We report MONO because our card is too stupid to know if it is in
|
604 |
|
|
mono or stereo.
|
605 |
|
|
|
606 |
|
|
|
|
607 |
|
|
balance>The stereo balance on a scale of 0-65535, 32768 is
|
608 |
|
|
middle.>
|
609 |
|
|
|
|
610 |
|
|
step>The step by which the volume control jumps. This is
|
611 |
|
|
used to help make it easy for applications to set
|
612 |
|
|
slider behaviour.>
|
613 |
|
|
|
614 |
|
|
|
|
615 |
|
|
|
616 |
|
|
|
|
617 |
|
|
|
618 |
|
|
struct video_audio flags
619 |
|
|
|
620 |
|
|
621 |
|
|
|
|
622 |
|
|
VIDEO_AUDIO_MUTE>The audio is currently muted. We
|
623 |
|
|
could fake this in our driver but we
|
624 |
|
|
choose not to bother.
|
625 |
|
|
|
|
626 |
|
|
VIDEO_AUDIO_MUTABLE>The input has a mute option
|
627 |
|
|
|
|
628 |
|
|
VIDEO_AUDIO_TREBLE>The input has a treble control
|
629 |
|
|
|
|
630 |
|
|
VIDEO_AUDIO_BASS>The input has a base control
|
631 |
|
|
|
632 |
|
|
|
|
633 |
|
|
|
634 |
|
|
|
|
635 |
|
|
|
636 |
|
|
struct video_audio modes
637 |
|
|
|
638 |
|
|
639 |
|
|
|
|
640 |
|
|
VIDEO_SOUND_MONO>Mono sound
|
641 |
|
|
|
|
642 |
|
|
VIDEO_SOUND_STEREO>Stereo sound
|
643 |
|
|
|
|
644 |
|
|
VIDEO_SOUND_LANG1>Alternative language 1 (TV specific)
|
645 |
|
|
|
|
646 |
|
|
VIDEO_SOUND_LANG2>Alternative language 2 (TV specific)
|
647 |
|
|
|
648 |
|
|
|
|
649 |
|
|
|
650 |
|
|
|
|
651 |
|
|
|
652 |
|
|
Having filled in the structure we copy it back to user space.
|
653 |
|
|
|
654 |
|
|
|
655 |
|
|
The VIDIOCSAUDIO ioctl allows the user to set the audio parameters in the
|
656 |
|
|
video_audio structure. The driver does its best to honour the request.
|
657 |
|
|
|
658 |
|
|
|
659 |
|
|
|
660 |
|
|
case VIDIOCSAUDIO:
|
661 |
|
|
{
|
662 |
|
|
struct video_audio v;
|
663 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
664 |
|
|
return -EFAULT;
|
665 |
|
|
if(v.audio)
|
666 |
|
|
return -EINVAL;
|
667 |
|
|
current_volume = v/16384;
|
668 |
|
|
hardware_set_volume(current_volume);
|
669 |
|
|
return 0;
|
670 |
|
|
}
|
671 |
|
|
|
672 |
|
|
|
673 |
|
|
|
674 |
|
|
In our case there is very little that the user can set. The volume is
|
675 |
|
|
basically the limit. Note that we could pretend to have a mute feature
|
676 |
|
|
by rewriting this to
|
677 |
|
|
|
678 |
|
|
|
679 |
|
|
|
680 |
|
|
case VIDIOCSAUDIO:
|
681 |
|
|
{
|
682 |
|
|
struct video_audio v;
|
683 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
684 |
|
|
return -EFAULT;
|
685 |
|
|
if(v.audio)
|
686 |
|
|
return -EINVAL;
|
687 |
|
|
current_volume = v/16384;
|
688 |
|
|
if(v.flags&VIDEO_AUDIO_MUTE)
|
689 |
|
|
hardware_set_volume(0);
|
690 |
|
|
else
|
691 |
|
|
hardware_set_volume(current_volume);
|
692 |
|
|
current_muted = v.flags &
|
693 |
|
|
VIDEO_AUDIO_MUTE;
|
694 |
|
|
return 0;
|
695 |
|
|
}
|
696 |
|
|
|
697 |
|
|
|
698 |
|
|
|
699 |
|
|
This with the corresponding changes to the VIDIOCGAUDIO code to report the
|
700 |
|
|
state of the mute flag we save and to report the card has a mute function,
|
701 |
|
|
will allow applications to use a mute facility with this card. It is
|
702 |
|
|
questionable whether this is a good idea however. User applications can already
|
703 |
|
|
fake this themselves and kernel space is precious.
|
704 |
|
|
|
705 |
|
|
|
706 |
|
|
We now have a working radio ioctl handler. So we just wrap up the function
|
707 |
|
|
|
708 |
|
|
|
709 |
|
|
|
710 |
|
|
|
711 |
|
|
}
|
712 |
|
|
return -ENOIOCTLCMD;
|
713 |
|
|
}
|
714 |
|
|
|
715 |
|
|
|
716 |
|
|
|
717 |
|
|
and pass the Video4Linux layer back an error so that it knows we did not
|
718 |
|
|
understand the request we got passed.
|
719 |
|
|
|
720 |
|
|
|
721 |
|
|
|
722 |
|
|
Module Wrapper
|
723 |
|
|
|
724 |
|
|
Finally we add in the usual module wrapping and the driver is done.
|
725 |
|
|
|
726 |
|
|
|
727 |
|
|
|
728 |
|
|
#ifndef MODULE
|
729 |
|
|
|
730 |
|
|
static int io = 0x300;
|
731 |
|
|
|
732 |
|
|
#else
|
733 |
|
|
|
734 |
|
|
static int io = -1;
|
735 |
|
|
|
736 |
|
|
|
737 |
|
|
MODULE_AUTHOR("Alan Cox");
|
738 |
|
|
MODULE_DESCRIPTION("A driver for an imaginary radio card.");
|
739 |
|
|
MODULE_PARM(io, "i");
|
740 |
|
|
MODULE_PARM_DESC(io, "I/O address of the card.");
|
741 |
|
|
|
742 |
|
|
EXPORT_NO_SYMBOLS;
|
743 |
|
|
|
744 |
|
|
int init_module(void)
|
745 |
|
|
{
|
746 |
|
|
if(io==-1)
|
747 |
|
|
{
|
748 |
|
|
printk(KERN_ERR
|
749 |
|
|
"You must set an I/O address with io=0x???\n");
|
750 |
|
|
return -EINVAL;
|
751 |
|
|
}
|
752 |
|
|
return myradio_init(NULL);
|
753 |
|
|
}
|
754 |
|
|
|
755 |
|
|
void cleanup_module(void)
|
756 |
|
|
{
|
757 |
|
|
video_unregister_device(&my_radio);
|
758 |
|
|
release_region(io, MY_IO_SIZE);
|
759 |
|
|
}
|
760 |
|
|
|
761 |
|
|
#endif
|
762 |
|
|
|
763 |
|
|
|
764 |
|
|
|
765 |
|
|
In this example we set the IO base by default if the driver is compiled into
|
766 |
|
|
the kernel where you cannot pass a parameter. For the module we require the
|
767 |
|
|
user sets the parameter. We set io to a nonsense port (-1) so that we can
|
768 |
|
|
tell if the user supplied an io parameter or not.
|
769 |
|
|
|
770 |
|
|
|
771 |
|
|
We use MODULE_ defines to give an author for the card driver and a
|
772 |
|
|
description. We also use them to declare that io is an integer and it is the
|
773 |
|
|
address of the card.
|
774 |
|
|
|
775 |
|
|
|
776 |
|
|
The clean-up routine unregisters the video_device we registered, and frees
|
777 |
|
|
up the I/O space. Note that the unregister takes the actual video_device
|
778 |
|
|
structure as its argument. Unlike the file operations structure which can be
|
779 |
|
|
shared by all instances of a device a video_device structure as an actual
|
780 |
|
|
instance of the device. If you are registering multiple radio devices you
|
781 |
|
|
need to fill in one structure per device (most likely by setting up a
|
782 |
|
|
template and copying it to each of the actual device structures).
|
783 |
|
|
|
784 |
|
|
|
785 |
|
|
|
786 |
|
|
|
787 |
|
|
Video Capture Devices
|
788 |
|
|
|
789 |
|
|
Video Capture Device Types
|
790 |
|
|
|
791 |
|
|
The video capture devices share the same interfaces as radio devices. In
|
792 |
|
|
order to explain the video capture interface I will use the example of a
|
793 |
|
|
camera that has no tuners or audio input. This keeps the example relatively
|
794 |
|
|
clean. To get both combine the two driver examples.
|
795 |
|
|
|
796 |
|
|
|
797 |
|
|
Video capture devices divide into four categories. A little technology
|
798 |
|
|
backgrounder. Full motion video even at television resolution (which is
|
799 |
|
|
actually fairly low) is pretty resource-intensive. You are continually
|
800 |
|
|
passing megabytes of data every second from the capture card to the display.
|
801 |
|
|
several alternative approaches have emerged because copying this through the
|
802 |
|
|
processor and the user program is a particularly bad idea .
|
803 |
|
|
|
804 |
|
|
|
805 |
|
|
The first is to add the television image onto the video output directly.
|
806 |
|
|
This is also how some 3D cards work. These basic cards can generally drop the
|
807 |
|
|
video into any chosen rectangle of the display. Cards like this, which
|
808 |
|
|
include most mpeg1 cards that used the feature connector, aren't very
|
809 |
|
|
friendly in a windowing environment. They don't understand windows or
|
810 |
|
|
clipping. The video window is always on the top of the display.
|
811 |
|
|
|
812 |
|
|
|
813 |
|
|
Chroma keying is a technique used by cards to get around this. It is an old
|
814 |
|
|
television mixing trick where you mark all the areas you wish to replace
|
815 |
|
|
with a single clear colour that isn't used in the image - TV people use an
|
816 |
|
|
incredibly bright blue while computing people often use a particularly
|
817 |
|
|
virulent purple. Bright blue occurs on the desktop. Anyone with virulent
|
818 |
|
|
purple windows has another problem besides their TV overlay.
|
819 |
|
|
|
820 |
|
|
|
821 |
|
|
The third approach is to copy the data from the capture card to the video
|
822 |
|
|
card, but to do it directly across the PCI bus. This relieves the processor
|
823 |
|
|
from doing the work but does require some smartness on the part of the video
|
824 |
|
|
capture chip, as well as a suitable video card. Programming this kind of
|
825 |
|
|
card and more so debugging it can be extremely tricky. There are some quite
|
826 |
|
|
complicated interactions with the display and you may also have to cope with
|
827 |
|
|
various chipset bugs that show up when PCI cards start talking to each
|
828 |
|
|
other.
|
829 |
|
|
|
830 |
|
|
|
831 |
|
|
To keep our example fairly simple we will assume a card that supports
|
832 |
|
|
overlaying a flat rectangular image onto the frame buffer output, and which
|
833 |
|
|
can also capture stuff into processor memory.
|
834 |
|
|
|
835 |
|
|
|
836 |
|
|
|
837 |
|
|
Registering Video Capture Devices
|
838 |
|
|
|
839 |
|
|
This time we need to add more functions for our camera device.
|
840 |
|
|
|
841 |
|
|
|
842 |
|
|
static struct video_device my_camera
|
843 |
|
|
{
|
844 |
|
|
"My Camera",
|
845 |
|
|
VID_TYPE_OVERLAY|VID_TYPE_SCALES|\
|
846 |
|
|
VID_TYPE_CAPTURE|VID_TYPE_CHROMAKEY,
|
847 |
|
|
VID_HARDWARE_MYCAMERA,
|
848 |
|
|
camera_open.
|
849 |
|
|
camera_close,
|
850 |
|
|
camera_read, /* no read */
|
851 |
|
|
NULL, /* no write */
|
852 |
|
|
camera_poll, /* no poll */
|
853 |
|
|
camera_ioctl,
|
854 |
|
|
NULL, /* no special init function */
|
855 |
|
|
NULL /* no private data */
|
856 |
|
|
};
|
857 |
|
|
|
858 |
|
|
|
859 |
|
|
We need a read() function which is used for capturing data from
|
860 |
|
|
the card, and we need a poll function so that a driver can wait for the next
|
861 |
|
|
frame to be captured.
|
862 |
|
|
|
863 |
|
|
|
864 |
|
|
We use the extra video capability flags that did not apply to the
|
865 |
|
|
radio interface. The video related flags are
|
866 |
|
|
|
867 |
|
|
Capture Capabilities
868 |
|
|
|
869 |
|
|
870 |
|
|
|
|
871 |
|
|
VID_TYPE_CAPTURE>We support image capture>
|
872 |
|
|
|
|
873 |
|
|
VID_TYPE_TELETEXT>A teletext capture device (vbi{n])>
|
874 |
|
|
|
|
875 |
|
|
VID_TYPE_OVERLAY>The image can be directly overlaid onto the
|
876 |
|
|
frame buffer>
|
877 |
|
|
|
|
878 |
|
|
VID_TYPE_CHROMAKEY>Chromakey can be used to select which parts
|
879 |
|
|
of the image to display>
|
880 |
|
|
|
|
881 |
|
|
VID_TYPE_CLIPPING>It is possible to give the board a list of
|
882 |
|
|
rectangles to draw around. >
|
883 |
|
|
|
|
884 |
|
|
VID_TYPE_FRAMERAM>The video capture goes into the video memory
|
885 |
|
|
and actually changes it. Applications need
|
886 |
|
|
to know this so they can clean up after the
|
887 |
|
|
card>
|
888 |
|
|
|
|
889 |
|
|
VID_TYPE_SCALES>The image can be scaled to various sizes,
|
890 |
|
|
rather than being a single fixed size.>
|
891 |
|
|
|
|
892 |
|
|
VID_TYPE_MONOCHROME>The capture will be monochrome. This isn't a
|
893 |
|
|
complete answer to the question since a mono
|
894 |
|
|
camera on a colour capture card will still
|
895 |
|
|
produce mono output.>
|
896 |
|
|
|
|
897 |
|
|
VID_TYPE_SUBCAPTURE>The card allows only part of its field of
|
898 |
|
|
view to be captured. This enables
|
899 |
|
|
applications to avoid copying all of a large
|
900 |
|
|
image into memory when only some section is
|
901 |
|
|
relevant.>
|
902 |
|
|
|
903 |
|
|
|
|
904 |
|
|
|
905 |
|
|
|
|
906 |
|
|
|
907 |
|
|
We set VID_TYPE_CAPTURE so that we are seen as a capture card,
|
908 |
|
|
VID_TYPE_CHROMAKEY so the application knows it is time to draw in virulent
|
909 |
|
|
purple, and VID_TYPE_SCALES because we can be resized.
|
910 |
|
|
|
911 |
|
|
|
912 |
|
|
Our setup is fairly similar. This time we also want an interrupt line
|
913 |
|
|
for the 'frame captured' signal. Not all cards have this so some of them
|
914 |
|
|
cannot handle poll().
|
915 |
|
|
|
916 |
|
|
|
917 |
|
|
|
918 |
|
|
|
919 |
|
|
static int io = 0x320;
|
920 |
|
|
static int irq = 11;
|
921 |
|
|
|
922 |
|
|
int __init mycamera_init(struct video_init *v)
|
923 |
|
|
{
|
924 |
|
|
if(!request_region(io, MY_IO_SIZE, "mycamera"))
|
925 |
|
|
{
|
926 |
|
|
printk(KERN_ERR
|
927 |
|
|
"mycamera: port 0x%03X is in use.\n", io);
|
928 |
|
|
return -EBUSY;
|
929 |
|
|
}
|
930 |
|
|
|
931 |
|
|
if(video_device_register(&my_camera,
|
932 |
|
|
VFL_TYPE_GRABBER)==-1) {
|
933 |
|
|
release_region(io, MY_IO_SIZE);
|
934 |
|
|
return -EINVAL;
|
935 |
|
|
}
|
936 |
|
|
return 0;
|
937 |
|
|
}
|
938 |
|
|
|
939 |
|
|
|
940 |
|
|
|
941 |
|
|
This is little changed from the needs of the radio card. We specify
|
942 |
|
|
VFL_TYPE_GRABBER this time as we want to be allocated a /dev/video name.
|
943 |
|
|
|
944 |
|
|
|
945 |
|
|
|
946 |
|
|
Opening And Closing The Capture Device
|
947 |
|
|
|
948 |
|
|
|
949 |
|
|
|
950 |
|
|
static int users = 0;
|
951 |
|
|
|
952 |
|
|
static int camera_open(stuct video_device *dev, int flags)
|
953 |
|
|
{
|
954 |
|
|
if(users)
|
955 |
|
|
return -EBUSY;
|
956 |
|
|
if(request_irq(irq, camera_irq, 0, "camera", dev)<0)
|
957 |
|
|
return -EBUSY;
|
958 |
|
|
users++;
|
959 |
|
|
MOD_INC_USE_COUNT;
|
960 |
|
|
return 0;
|
961 |
|
|
}
|
962 |
|
|
|
963 |
|
|
|
964 |
|
|
static int camera_close(struct video_device *dev)
|
965 |
|
|
{
|
966 |
|
|
users--;
|
967 |
|
|
free_irq(irq, dev);
|
968 |
|
|
MOD_DEC_USE_COUNT;
|
969 |
|
|
}
|
970 |
|
|
|
971 |
|
|
|
972 |
|
|
The open and close routines are also quite similar. The only real change is
|
973 |
|
|
that we now request an interrupt for the camera device interrupt line. If we
|
974 |
|
|
cannot get the interrupt we report EBUSY to the application and give up.
|
975 |
|
|
|
976 |
|
|
|
977 |
|
|
|
978 |
|
|
Interrupt Handling
|
979 |
|
|
|
980 |
|
|
Our example handler is for an ISA bus device. If it was PCI you would be
|
981 |
|
|
able to share the interrupt and would have set SA_SHIRQ to indicate a
|
982 |
|
|
shared IRQ. We pass the device pointer as the interrupt routine argument. We
|
983 |
|
|
don't need to since we only support one card but doing this will make it
|
984 |
|
|
easier to upgrade the driver for multiple devices in the future.
|
985 |
|
|
|
986 |
|
|
|
987 |
|
|
Our interrupt routine needs to do little if we assume the card can simply
|
988 |
|
|
queue one frame to be read after it captures it.
|
989 |
|
|
|
990 |
|
|
|
991 |
|
|
|
992 |
|
|
|
993 |
|
|
static struct wait_queue *capture_wait;
|
994 |
|
|
static int capture_ready = 0;
|
995 |
|
|
|
996 |
|
|
static void camera_irq(int irq, void *dev_id,
|
997 |
|
|
struct pt_regs *regs)
|
998 |
|
|
{
|
999 |
|
|
capture_ready=1;
|
1000 |
|
|
wake_up_interruptible(&capture_wait);
|
1001 |
|
|
}
|
1002 |
|
|
|
1003 |
|
|
|
1004 |
|
|
The interrupt handler is nice and simple for this card as we are assuming
|
1005 |
|
|
the card is buffering the frame for us. This means we have little to do but
|
1006 |
|
|
wake up anybody interested. We also set a capture_ready flag, as we may
|
1007 |
|
|
capture a frame before an application needs it. In this case we need to know
|
1008 |
|
|
that a frame is ready. If we had to collect the frame on the interrupt life
|
1009 |
|
|
would be more complex.
|
1010 |
|
|
|
1011 |
|
|
|
1012 |
|
|
The two new routines we need to supply are camera_read which returns a
|
1013 |
|
|
frame, and camera_poll which waits for a frame to become ready.
|
1014 |
|
|
|
1015 |
|
|
|
1016 |
|
|
|
1017 |
|
|
|
1018 |
|
|
static int camera_poll(struct video_device *dev,
|
1019 |
|
|
struct file *file, struct poll_table *wait)
|
1020 |
|
|
{
|
1021 |
|
|
poll_wait(file, &capture_wait, wait);
|
1022 |
|
|
if(capture_read)
|
1023 |
|
|
return POLLIN|POLLRDNORM;
|
1024 |
|
|
return 0;
|
1025 |
|
|
}
|
1026 |
|
|
|
1027 |
|
|
|
1028 |
|
|
|
1029 |
|
|
Our wait queue for polling is the capture_wait queue. This will cause the
|
1030 |
|
|
task to be woken up by our camera_irq routine. We check capture_read to see
|
1031 |
|
|
if there is an image present and if so report that it is readable.
|
1032 |
|
|
|
1033 |
|
|
|
1034 |
|
|
|
1035 |
|
|
Reading The Video Image
|
1036 |
|
|
|
1037 |
|
|
|
1038 |
|
|
|
1039 |
|
|
static long camera_read(struct video_device *dev, char *buf,
|
1040 |
|
|
unsigned long count)
|
1041 |
|
|
{
|
1042 |
|
|
struct wait_queue wait = { current, NULL };
|
1043 |
|
|
u8 *ptr;
|
1044 |
|
|
int len;
|
1045 |
|
|
int i;
|
1046 |
|
|
|
1047 |
|
|
add_wait_queue(&capture_wait, &wait);
|
1048 |
|
|
|
1049 |
|
|
while(!capture_ready)
|
1050 |
|
|
{
|
1051 |
|
|
if(file->flags&O_NDELAY)
|
1052 |
|
|
{
|
1053 |
|
|
remove_wait_queue(&capture_wait, &wait);
|
1054 |
|
|
current->state = TASK_RUNNING;
|
1055 |
|
|
return -EWOULDBLOCK;
|
1056 |
|
|
}
|
1057 |
|
|
if(signal_pending(current))
|
1058 |
|
|
{
|
1059 |
|
|
remove_wait_queue(&capture_wait, &wait);
|
1060 |
|
|
current->state = TASK_RUNNING;
|
1061 |
|
|
return -ERESTARTSYS;
|
1062 |
|
|
}
|
1063 |
|
|
schedule();
|
1064 |
|
|
current->state = TASK_INTERRUPTIBLE;
|
1065 |
|
|
}
|
1066 |
|
|
remove_wait_queue(&capture_wait, &wait);
|
1067 |
|
|
current->state = TASK_RUNNING;
|
1068 |
|
|
|
1069 |
|
|
|
1070 |
|
|
|
1071 |
|
|
The first thing we have to do is to ensure that the application waits until
|
1072 |
|
|
the next frame is ready. The code here is almost identical to the mouse code
|
1073 |
|
|
we used earlier in this chapter. It is one of the common building blocks of
|
1074 |
|
|
Linux device driver code and probably one which you will find occurs in any
|
1075 |
|
|
drivers you write.
|
1076 |
|
|
|
1077 |
|
|
|
1078 |
|
|
We wait for a frame to be ready, or for a signal to interrupt our waiting. If a
|
1079 |
|
|
signal occurs we need to return from the system call so that the signal can
|
1080 |
|
|
be sent to the application itself. We also check to see if the user actually
|
1081 |
|
|
wanted to avoid waiting - ie if they are using non-blocking I/O and have other things
|
1082 |
|
|
to get on with.
|
1083 |
|
|
|
1084 |
|
|
|
1085 |
|
|
Next we copy the data from the card to the user application. This is rarely
|
1086 |
|
|
as easy as our example makes out. We will add capture_w, and capture_h here
|
1087 |
|
|
to hold the width and height of the captured image. We assume the card only
|
1088 |
|
|
supports 24bit RGB for now.
|
1089 |
|
|
|
1090 |
|
|
|
1091 |
|
|
|
1092 |
|
|
|
1093 |
|
|
|
1094 |
|
|
capture_ready = 0;
|
1095 |
|
|
|
1096 |
|
|
ptr=(u8 *)buf;
|
1097 |
|
|
len = capture_w * 3 * capture_h; /* 24bit RGB */
|
1098 |
|
|
|
1099 |
|
|
if(len>count)
|
1100 |
|
|
len=count; /* Doesn't all fit */
|
1101 |
|
|
|
1102 |
|
|
for(i=0; i<len; i++)
|
1103 |
|
|
{
|
1104 |
|
|
put_user(inb(io+IMAGE_DATA), ptr);
|
1105 |
|
|
ptr++;
|
1106 |
|
|
}
|
1107 |
|
|
|
1108 |
|
|
hardware_restart_capture();
|
1109 |
|
|
|
1110 |
|
|
return i;
|
1111 |
|
|
}
|
1112 |
|
|
|
1113 |
|
|
|
1114 |
|
|
|
1115 |
|
|
For a real hardware device you would try to avoid the loop with put_user().
|
1116 |
|
|
Each call to put_user() has a time overhead checking whether the accesses to user
|
1117 |
|
|
space are allowed. It would be better to read a line into a temporary buffer
|
1118 |
|
|
then copy this to user space in one go.
|
1119 |
|
|
|
1120 |
|
|
|
1121 |
|
|
Having captured the image and put it into user space we can kick the card to
|
1122 |
|
|
get the next frame acquired.
|
1123 |
|
|
|
1124 |
|
|
|
1125 |
|
|
|
1126 |
|
|
Video Ioctl Handling
|
1127 |
|
|
|
1128 |
|
|
As with the radio driver the major control interface is via the ioctl()
|
1129 |
|
|
function. Video capture devices support the same tuner calls as a radio
|
1130 |
|
|
device and also support additional calls to control how the video functions
|
1131 |
|
|
are handled. In this simple example the card has no tuners to avoid making
|
1132 |
|
|
the code complex.
|
1133 |
|
|
|
1134 |
|
|
|
1135 |
|
|
|
1136 |
|
|
|
1137 |
|
|
|
1138 |
|
|
static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
|
1139 |
|
|
{
|
1140 |
|
|
switch(cmd)
|
1141 |
|
|
{
|
1142 |
|
|
case VIDIOCGCAP:
|
1143 |
|
|
{
|
1144 |
|
|
struct video_capability v;
|
1145 |
|
|
v.type = VID_TYPE_CAPTURE|\
|
1146 |
|
|
VID_TYPE_CHROMAKEY|\
|
1147 |
|
|
VID_TYPE_SCALES|\
|
1148 |
|
|
VID_TYPE_OVERLAY;
|
1149 |
|
|
v.channels = 1;
|
1150 |
|
|
v.audios = 0;
|
1151 |
|
|
v.maxwidth = 640;
|
1152 |
|
|
v.minwidth = 16;
|
1153 |
|
|
v.maxheight = 480;
|
1154 |
|
|
v.minheight = 16;
|
1155 |
|
|
strcpy(v.name, "My Camera");
|
1156 |
|
|
if(copy_to_user(arg, &v, sizeof(v)))
|
1157 |
|
|
return -EFAULT;
|
1158 |
|
|
return 0;
|
1159 |
|
|
}
|
1160 |
|
|
|
1161 |
|
|
|
1162 |
|
|
|
1163 |
|
|
|
1164 |
|
|
The first ioctl we must support and which all video capture and radio
|
1165 |
|
|
devices are required to support is VIDIOCGCAP. This behaves exactly the same
|
1166 |
|
|
as with a radio device. This time, however, we report the extra capabilities
|
1167 |
|
|
we outlined earlier on when defining our video_dev structure.
|
1168 |
|
|
|
1169 |
|
|
|
1170 |
|
|
We now set the video flags saying that we support overlay, capture,
|
1171 |
|
|
scaling and chromakey. We also report size limits - our smallest image is
|
1172 |
|
|
16x16 pixels, our largest is 640x480.
|
1173 |
|
|
|
1174 |
|
|
|
1175 |
|
|
To keep things simple we report no audio and no tuning capabilities at all.
|
1176 |
|
|
|
1177 |
|
|
|
1178 |
|
|
|
1179 |
|
|
case VIDIOCGCHAN:
|
1180 |
|
|
{
|
1181 |
|
|
struct video_channel v;
|
1182 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
1183 |
|
|
return -EFAULT;
|
1184 |
|
|
if(v.channel != 0)
|
1185 |
|
|
return -EINVAL;
|
1186 |
|
|
v.flags = 0;
|
1187 |
|
|
v.tuners = 0;
|
1188 |
|
|
v.type = VIDEO_TYPE_CAMERA;
|
1189 |
|
|
v.norm = VIDEO_MODE_AUTO;
|
1190 |
|
|
strcpy(v.name, "Camera Input");break;
|
1191 |
|
|
if(copy_to_user(&v, arg, sizeof(v)))
|
1192 |
|
|
return -EFAULT;
|
1193 |
|
|
return 0;
|
1194 |
|
|
}
|
1195 |
|
|
|
1196 |
|
|
|
1197 |
|
|
|
1198 |
|
|
|
1199 |
|
|
This follows what is very much the standard way an ioctl handler looks
|
1200 |
|
|
in Linux. We copy the data into a kernel space variable and we check that the
|
1201 |
|
|
request is valid (in this case that the input is 0). Finally we copy the
|
1202 |
|
|
camera info back to the user.
|
1203 |
|
|
|
1204 |
|
|
|
1205 |
|
|
The VIDIOCGCHAN ioctl allows a user to ask about video channels (that is
|
1206 |
|
|
inputs to the video card). Our example card has a single camera input. The
|
1207 |
|
|
fields in the structure are
|
1208 |
|
|
|
1209 |
|
|
struct video_channel fields
1210 |
|
|
|
1211 |
|
|
1212 |
|
|
|
|
1213 |
|
|
|
1214 |
|
|
channel>The channel number we are selecting
|
1215 |
|
|
|
|
1216 |
|
|
name>The name for this channel. This is intended
|
1217 |
|
|
to describe the port to the user.
|
1218 |
|
|
Appropriate names are therefore things like
|
1219 |
|
|
"Camera" "SCART input"
|
1220 |
|
|
|
|
1221 |
|
|
flags>Channel properties
|
1222 |
|
|
|
|
1223 |
|
|
type>Input type
|
1224 |
|
|
|
|
1225 |
|
|
norm>The current television encoding being used
|
1226 |
|
|
if relevant for this channel.
|
1227 |
|
|
|
1228 |
|
|
|
1229 |
|
|
|
|
1230 |
|
|
|
1231 |
|
|
|
|
1232 |
|
|
struct video_channel flags
1233 |
|
|
|
1234 |
|
|
1235 |
|
|
|
|
1236 |
|
|
VIDEO_VC_TUNER>Channel has a tuner.
|
1237 |
|
|
|
|
1238 |
|
|
VIDEO_VC_AUDIO>Channel has audio.
|
1239 |
|
|
|
1240 |
|
|
|
|
1241 |
|
|
|
1242 |
|
|
|
|
1243 |
|
|
struct video_channel types
1244 |
|
|
|
1245 |
|
|
1246 |
|
|
|
|
1247 |
|
|
VIDEO_TYPE_TV>Television input.
|
1248 |
|
|
|
|
1249 |
|
|
VIDEO_TYPE_CAMERA>Fixed camera input.
|
1250 |
|
|
|
|
1251 |
|
|
0>Type is unknown.
|
1252 |
|
|
|
1253 |
|
|
|
|
1254 |
|
|
|
1255 |
|
|
|
|
1256 |
|
|
struct video_channel norms
1257 |
|
|
|
1258 |
|
|
1259 |
|
|
|
|
1260 |
|
|
VIDEO_MODE_PAL>PAL encoded Television
|
1261 |
|
|
|
|
1262 |
|
|
VIDEO_MODE_NTSC>NTSC (US) encoded Television
|
1263 |
|
|
|
|
1264 |
|
|
VIDEO_MODE_SECAM>SECAM (French) Television
|
1265 |
|
|
|
|
1266 |
|
|
VIDEO_MODE_AUTO>Automatic switching, or format does not
|
1267 |
|
|
matter
|
1268 |
|
|
|
1269 |
|
|
|
|
1270 |
|
|
|
1271 |
|
|
|
|
1272 |
|
|
|
1273 |
|
|
The corresponding VIDIOCSCHAN ioctl allows a user to change channel and to
|
1274 |
|
|
request the norm is changed - for example to switch between a PAL or an NTSC
|
1275 |
|
|
format camera.
|
1276 |
|
|
|
1277 |
|
|
|
1278 |
|
|
|
1279 |
|
|
|
1280 |
|
|
case VIDIOCSCHAN:
|
1281 |
|
|
{
|
1282 |
|
|
struct video_channel v;
|
1283 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
1284 |
|
|
return -EFAULT;
|
1285 |
|
|
if(v.channel != 0)
|
1286 |
|
|
return -EINVAL;
|
1287 |
|
|
if(v.norm != VIDEO_MODE_AUTO)
|
1288 |
|
|
return -EINVAL;
|
1289 |
|
|
return 0;
|
1290 |
|
|
}
|
1291 |
|
|
|
1292 |
|
|
|
1293 |
|
|
|
1294 |
|
|
|
1295 |
|
|
The implementation of this call in our driver is remarkably easy. Because we
|
1296 |
|
|
are assuming fixed format hardware we need only check that the user has not
|
1297 |
|
|
tried to change anything.
|
1298 |
|
|
|
1299 |
|
|
|
1300 |
|
|
The user also needs to be able to configure and adjust the picture they are
|
1301 |
|
|
seeing. This is much like adjusting a television set. A user application
|
1302 |
|
|
also needs to know the palette being used so that it knows how to display
|
1303 |
|
|
the image that has been captured. The VIDIOCGPICT and VIDIOCSPICT ioctl
|
1304 |
|
|
calls provide this information.
|
1305 |
|
|
|
1306 |
|
|
|
1307 |
|
|
|
1308 |
|
|
|
1309 |
|
|
case VIDIOCGPICT
|
1310 |
|
|
{
|
1311 |
|
|
struct video_picture v;
|
1312 |
|
|
v.brightness = hardware_brightness();
|
1313 |
|
|
v.hue = hardware_hue();
|
1314 |
|
|
v.colour = hardware_saturation();
|
1315 |
|
|
v.contrast = hardware_brightness();
|
1316 |
|
|
/* Not settable */
|
1317 |
|
|
v.whiteness = 32768;
|
1318 |
|
|
v.depth = 24; /* 24bit */
|
1319 |
|
|
v.palette = VIDEO_PALETTE_RGB24;
|
1320 |
|
|
if(copy_to_user(&v, arg,
|
1321 |
|
|
sizeof(v)))
|
1322 |
|
|
return -EFAULT;
|
1323 |
|
|
return 0;
|
1324 |
|
|
}
|
1325 |
|
|
|
1326 |
|
|
|
1327 |
|
|
|
1328 |
|
|
|
1329 |
|
|
The brightness, hue, color, and contrast provide the picture controls that
|
1330 |
|
|
are akin to a conventional television. Whiteness provides additional
|
1331 |
|
|
control for greyscale images. All of these values are scaled between 0-65535
|
1332 |
|
|
and have 32768 as the mid point setting. The scaling means that applications
|
1333 |
|
|
do not have to worry about the capability range of the hardware but can let
|
1334 |
|
|
it make a best effort attempt.
|
1335 |
|
|
|
1336 |
|
|
|
1337 |
|
|
Our depth is 24, as this is in bits. We will be returning RGB24 format. This
|
1338 |
|
|
has one byte of red, then one of green, then one of blue. This then repeats
|
1339 |
|
|
for every other pixel in the image. The other common formats the interface
|
1340 |
|
|
defines are
|
1341 |
|
|
|
1342 |
|
|
Framebuffer Encodings
1343 |
|
|
|
1344 |
|
|
1345 |
|
|
|
|
1346 |
|
|
GREY>Linear greyscale. This is for simple cameras and the
|
1347 |
|
|
like>
|
1348 |
|
|
|
|
1349 |
|
|
RGB565>The top 5 bits hold 32 red levels, the next six bits
|
1350 |
|
|
hold green and the low 5 bits hold blue. >
|
1351 |
|
|
|
|
1352 |
|
|
RGB555>The top bit is clear. The red green and blue levels
|
1353 |
|
|
each occupy five bits.>
|
1354 |
|
|
|
1355 |
|
|
|
|
1356 |
|
|
|
1357 |
|
|
|
|
1358 |
|
|
|
1359 |
|
|
Additional modes are support for YUV capture formats. These are common for
|
1360 |
|
|
TV and video conferencing applications.
|
1361 |
|
|
|
1362 |
|
|
|
1363 |
|
|
The VIDIOCSPICT ioctl allows a user to set some of the picture parameters.
|
1364 |
|
|
Exactly which ones are supported depends heavily on the card itself. It is
|
1365 |
|
|
possible to support many modes and effects in software. In general doing
|
1366 |
|
|
this in the kernel is a bad idea. Video capture is a performance-sensitive
|
1367 |
|
|
application and the programs can often do better if they aren't being
|
1368 |
|
|
'helped' by an overkeen driver writer. Thus for our device we will report
|
1369 |
|
|
RGB24 only and refuse to allow a change.
|
1370 |
|
|
|
1371 |
|
|
|
1372 |
|
|
|
1373 |
|
|
|
1374 |
|
|
case VIDIOCSPICT:
|
1375 |
|
|
{
|
1376 |
|
|
struct video_picture v;
|
1377 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
1378 |
|
|
return -EFAULT;
|
1379 |
|
|
if(v.depth!=24 ||
|
1380 |
|
|
v.palette != VIDEO_PALETTE_RGB24)
|
1381 |
|
|
return -EINVAL;
|
1382 |
|
|
set_hardware_brightness(v.brightness);
|
1383 |
|
|
set_hardware_hue(v.hue);
|
1384 |
|
|
set_hardware_saturation(v.colour);
|
1385 |
|
|
set_hardware_brightness(v.contrast);
|
1386 |
|
|
return 0;
|
1387 |
|
|
}
|
1388 |
|
|
|
1389 |
|
|
|
1390 |
|
|
|
1391 |
|
|
|
1392 |
|
|
We check the user has not tried to change the palette or the depth. We do
|
1393 |
|
|
not want to carry out some of the changes and then return an error. This may
|
1394 |
|
|
confuse the application which will be assuming no change occurred.
|
1395 |
|
|
|
1396 |
|
|
|
1397 |
|
|
In much the same way as you need to be able to set the picture controls to
|
1398 |
|
|
get the right capture images, many cards need to know what they are
|
1399 |
|
|
displaying onto when generating overlay output. In some cases getting this
|
1400 |
|
|
wrong even makes a nasty mess or may crash the computer. For that reason
|
1401 |
|
|
the VIDIOCSBUF ioctl used to set up the frame buffer information may well
|
1402 |
|
|
only be usable by root.
|
1403 |
|
|
|
1404 |
|
|
|
1405 |
|
|
We will assume our card is one of the old ISA devices with feature connector
|
1406 |
|
|
and only supports a couple of standard video modes. Very common for older
|
1407 |
|
|
cards although the PCI devices are way smarter than this.
|
1408 |
|
|
|
1409 |
|
|
|
1410 |
|
|
|
1411 |
|
|
|
1412 |
|
|
static struct video_buffer capture_fb;
|
1413 |
|
|
|
1414 |
|
|
case VIDIOCGFBUF:
|
1415 |
|
|
{
|
1416 |
|
|
if(copy_to_user(arg, &capture_fb,
|
1417 |
|
|
sizeof(capture_fb)))
|
1418 |
|
|
return -EFAULT;
|
1419 |
|
|
return 0;
|
1420 |
|
|
|
1421 |
|
|
}
|
1422 |
|
|
|
1423 |
|
|
|
1424 |
|
|
|
1425 |
|
|
|
1426 |
|
|
We keep the frame buffer information in the format the ioctl uses. This
|
1427 |
|
|
makes it nice and easy to work with in the ioctl calls.
|
1428 |
|
|
|
1429 |
|
|
|
1430 |
|
|
|
1431 |
|
|
case VIDIOCSFBUF:
|
1432 |
|
|
{
|
1433 |
|
|
struct video_buffer v;
|
1434 |
|
|
|
1435 |
|
|
if(!capable(CAP_SYS_ADMIN))
|
1436 |
|
|
return -EPERM;
|
1437 |
|
|
|
1438 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
1439 |
|
|
return -EFAULT;
|
1440 |
|
|
if(v.width!=320 && v.width!=640)
|
1441 |
|
|
return -EINVAL;
|
1442 |
|
|
if(v.height!=200 && v.height!=240
|
1443 |
|
|
&& v.height!=400
|
1444 |
|
|
&& v.height !=480)
|
1445 |
|
|
return -EINVAL;
|
1446 |
|
|
memcpy(&capture_fb, &v, sizeof(v));
|
1447 |
|
|
hardware_set_fb(&v);
|
1448 |
|
|
return 0;
|
1449 |
|
|
}
|
1450 |
|
|
|
1451 |
|
|
|
1452 |
|
|
|
1453 |
|
|
|
1454 |
|
|
|
1455 |
|
|
The capable() function checks a user has the required capability. The Linux
|
1456 |
|
|
operating system has a set of about 30 capabilities indicating privileged
|
1457 |
|
|
access to services. The default set up gives the superuser (uid 0) all of
|
1458 |
|
|
them and nobody else has any.
|
1459 |
|
|
|
1460 |
|
|
|
1461 |
|
|
We check that the user has the SYS_ADMIN capability, that is they are
|
1462 |
|
|
allowed to operate as the machine administrator. We don't want anyone but
|
1463 |
|
|
the administrator making a mess of the display.
|
1464 |
|
|
|
1465 |
|
|
|
1466 |
|
|
Next we check for standard PC video modes (320 or 640 wide with either
|
1467 |
|
|
EGA or VGA depths). If the mode is not a standard video mode we reject it as
|
1468 |
|
|
not supported by our card. If the mode is acceptable we save it so that
|
1469 |
|
|
VIDIOCFBUF will give the right answer next time it is called. The
|
1470 |
|
|
hardware_set_fb() function is some undescribed card specific function to
|
1471 |
|
|
program the card for the desired mode.
|
1472 |
|
|
|
1473 |
|
|
|
1474 |
|
|
Before the driver can display an overlay window it needs to know where the
|
1475 |
|
|
window should be placed, and also how large it should be. If the card
|
1476 |
|
|
supports clipping it needs to know which rectangles to omit from the
|
1477 |
|
|
display. The video_window structure is used to describe the way the image
|
1478 |
|
|
should be displayed.
|
1479 |
|
|
|
1480 |
|
|
struct video_window fields
1481 |
|
|
|
1482 |
|
|
1483 |
|
|
|
|
1484 |
|
|
width>The width in pixels of the desired image. The card
|
1485 |
|
|
may use a smaller size if this size is not available>
|
1486 |
|
|
|
|
1487 |
|
|
height>The height of the image. The card may use a smaller
|
1488 |
|
|
size if this size is not available.>
|
1489 |
|
|
|
|
1490 |
|
|
x> The X position of the top left of the window. This
|
1491 |
|
|
is in pixels relative to the left hand edge of the
|
1492 |
|
|
picture. Not all cards can display images aligned on
|
1493 |
|
|
any pixel boundary. If the position is unsuitable
|
1494 |
|
|
the card adjusts the image right and reduces the
|
1495 |
|
|
width.>
|
1496 |
|
|
|
|
1497 |
|
|
y> The Y position of the top left of the window. This
|
1498 |
|
|
is counted in pixels relative to the top edge of the
|
1499 |
|
|
picture. As with the width if the card cannot
|
1500 |
|
|
display starting on this line it will adjust the
|
1501 |
|
|
values.>
|
1502 |
|
|
|
|
1503 |
|
|
chromakey>The colour (expressed in RGB32 format) for the
|
1504 |
|
|
chromakey colour if chroma keying is being used. >
|
1505 |
|
|
|
|
1506 |
|
|
clips>An array of rectangles that must not be drawn
|
1507 |
|
|
over.>
|
1508 |
|
|
|
|
1509 |
|
|
clipcount>The number of clips in this array.>
|
1510 |
|
|
|
1511 |
|
|
|
|
1512 |
|
|
|
1513 |
|
|
|
|
1514 |
|
|
|
1515 |
|
|
Each clip is a struct video_clip which has the following fields
|
1516 |
|
|
|
1517 |
|
|
video_clip fields
1518 |
|
|
|
1519 |
|
|
1520 |
|
|
|
|
1521 |
|
|
x, y>Co-ordinates relative to the display>
|
1522 |
|
|
|
|
1523 |
|
|
width, height>Width and height in pixels>
|
1524 |
|
|
|
|
1525 |
|
|
next>A spare field for the application to use>
|
1526 |
|
|
|
1527 |
|
|
|
|
1528 |
|
|
|
1529 |
|
|
|
|
1530 |
|
|
|
1531 |
|
|
The driver is required to ensure it always draws in the area requested or a smaller area, and that it never draws in any of the areas that are clipped.
|
1532 |
|
|
This may well mean it has to leave alone. small areas the application wished to be
|
1533 |
|
|
drawn.
|
1534 |
|
|
|
1535 |
|
|
|
1536 |
|
|
Our example card uses chromakey so does not have to address most of the
|
1537 |
|
|
clipping. We will add a video_window structure to our global variables to
|
1538 |
|
|
remember our parameters, as we did with the frame buffer.
|
1539 |
|
|
|
1540 |
|
|
|
1541 |
|
|
|
1542 |
|
|
|
1543 |
|
|
case VIDIOCGWIN:
|
1544 |
|
|
{
|
1545 |
|
|
if(copy_to_user(arg, &capture_win,
|
1546 |
|
|
sizeof(capture_win)))
|
1547 |
|
|
return -EFAULT;
|
1548 |
|
|
return 0;
|
1549 |
|
|
}
|
1550 |
|
|
|
1551 |
|
|
|
1552 |
|
|
case VIDIOCSWIN:
|
1553 |
|
|
{
|
1554 |
|
|
struct video_window v;
|
1555 |
|
|
if(copy_from_user(&v, arg, sizeof(v)))
|
1556 |
|
|
return -EFAULT;
|
1557 |
|
|
if(v.width > 640 || v.height > 480)
|
1558 |
|
|
return -EINVAL;
|
1559 |
|
|
if(v.width < 16 || v.height < 16)
|
1560 |
|
|
return -EINVAL;
|
1561 |
|
|
hardware_set_key(v.chromakey);
|
1562 |
|
|
hardware_set_window(v);
|
1563 |
|
|
memcpy(&capture_win, &v, sizeof(v));
|
1564 |
|
|
capture_w = v.width;
|
1565 |
|
|
capture_h = v.height;
|
1566 |
|
|
return 0;
|
1567 |
|
|
}
|
1568 |
|
|
|
1569 |
|
|
|
1570 |
|
|
|
1571 |
|
|
|
1572 |
|
|
Because we are using Chromakey our setup is fairly simple. Mostly we have to
|
1573 |
|
|
check the values are sane and load them into the capture card.
|
1574 |
|
|
|
1575 |
|
|
|
1576 |
|
|
With all the setup done we can now turn on the actual capture/overlay. This
|
1577 |
|
|
is done with the VIDIOCCAPTURE ioctl. This takes a single integer argument
|
1578 |
|
|
where 0 is on and 1 is off.
|
1579 |
|
|
|
1580 |
|
|
|
1581 |
|
|
|
1582 |
|
|
|
1583 |
|
|
case VIDIOCCAPTURE:
|
1584 |
|
|
{
|
1585 |
|
|
int v;
|
1586 |
|
|
if(get_user(v, (int *)arg))
|
1587 |
|
|
return -EFAULT;
|
1588 |
|
|
if(v==0)
|
1589 |
|
|
hardware_capture_off();
|
1590 |
|
|
else
|
1591 |
|
|
{
|
1592 |
|
|
if(capture_fb.width == 0
|
1593 |
|
|
|| capture_w == 0)
|
1594 |
|
|
return -EINVAL;
|
1595 |
|
|
hardware_capture_on();
|
1596 |
|
|
}
|
1597 |
|
|
return 0;
|
1598 |
|
|
}
|
1599 |
|
|
|
1600 |
|
|
|
1601 |
|
|
|
1602 |
|
|
|
1603 |
|
|
We grab the flag from user space and either enable or disable according to
|
1604 |
|
|
its value. There is one small corner case we have to consider here. Suppose
|
1605 |
|
|
that the capture was requested before the video window or the frame buffer
|
1606 |
|
|
had been set up. In those cases there will be unconfigured fields in our
|
1607 |
|
|
card data, as well as unconfigured hardware settings. We check for this case and
|
1608 |
|
|
return an error if the frame buffer or the capture window width is zero.
|
1609 |
|
|
|
1610 |
|
|
|
1611 |
|
|
|
1612 |
|
|
|
1613 |
|
|
default:
|
1614 |
|
|
return -ENOIOCTLCMD;
|
1615 |
|
|
}
|
1616 |
|
|
}
|
1617 |
|
|
|
1618 |
|
|
|
1619 |
|
|
|
1620 |
|
|
We don't need to support any other ioctls, so if we get this far, it is time
|
1621 |
|
|
to tell the video layer that we don't now what the user is talking about.
|
1622 |
|
|
|
1623 |
|
|
|
1624 |
|
|
|
1625 |
|
|
Other Functionality
|
1626 |
|
|
|
1627 |
|
|
The Video4Linux layer supports additional features, including a high
|
1628 |
|
|
performance mmap() based capture mode and capturing part of the image.
|
1629 |
|
|
These features are out of the scope of the book. You should however have enough
|
1630 |
|
|
example code to implement most simple video4linux devices for radio and TV
|
1631 |
|
|
cards.
|
1632 |
|
|
|
1633 |
|
|
|
1634 |
|
|
|
1635 |
|
|
|
1636 |
|
|
Known Bugs And Assumptions
|
1637 |
|
|
|
1638 |
|
|
|
1639 |
|
|
Multiple Opens
|
1640 |
|
|
|
1641 |
|
|
|
1642 |
|
|
The driver assumes multiple opens should not be allowed. A driver
|
1643 |
|
|
can work around this but not cleanly.
|
1644 |
|
|
|
1645 |
|
|
|
1646 |
|
|
|
1647 |
|
|
API Deficiencies
|
1648 |
|
|
|
1649 |
|
|
|
1650 |
|
|
The existing API poorly reflects compression capable devices. There
|
1651 |
|
|
are plans afoot to merge V4L, V4L2 and some other ideas into a
|
1652 |
|
|
better interface.
|
1653 |
|
|
|
1654 |
|
|
|
1655 |
|
|
|
1656 |
|
|
|
1657 |
|
|
|
1658 |
|
|
|
1659 |
|
|
|
1660 |
|
|
|
1661 |
|
|
Public Functions Provided
|
1662 |
|
|
!Edrivers/media/video/videodev.c
|
1663 |
|
|
|
1664 |
|
|
|
1665 |
|
|
|