Table of Contents
There are a wide variety of radio interfaces available for PC's, and these are generally very simple to program. The biggest problem with supporting such devices is normally extracting documentation from the vendor.
The radio interface supports a simple set of control ioctls standardised across all radio and tv interfaces. It does not support read or write, which are used for video streams. The reason radio cards do not allow you to read the audio stream into an application is that without exception they provide a connection on to a soundcard. Soundcards can be used to read the radio data just fine.
The Video4linux core provides an interface for registering devices. The first step in writing our radio card driver is to register it.
static struct video_device my_radio
{
"My radio",
VID_TYPE_TUNER,
VID_HARDWARE_MYRADIO,
radio_open.
radio_close,
NULL, /* no read */
NULL, /* no write */
NULL, /* no poll */
radio_ioctl,
NULL, /* no special init function */
NULL /* no private data */
};
This declares our video4linux device driver interface. The VID_TYPE_ value defines what kind of an interface we are, and defines basic capabilities.
The only defined value relevant for a radio card is VID_TYPE_TUNER which indicates that the device can be tuned. Clearly our radio is going to have some way to change channel so it is tuneable.
The VID_HARDWARE_ types are unique to each device. Numbers are assigned by
<alan@redhat.com> when device drivers are going to be released. Until then you
can pull a suitably large number out of your hat and use it. 10000 should be
safe for a very long time even allowing for the huge number of vendors
making new and different radio cards at the moment.
We declare an open and close routine, but we do not need read or write, which are used to read and write video data to or from the card itself. As we have no read or write there is no poll function.
The private initialise function is run when the device is registered. In this driver we've already done all the work needed. The final pointer is a private data pointer that can be used by the device driver to attach and retrieve private data structures. We set this field "priv" to NULL for the moment.
Having the structure defined is all very well but we now need to register it with the kernel.
static int io = 0x320;
int __init myradio_init(struct video_init *v)
{
if(!request_region(io, MY_IO_SIZE, "myradio"))
{
printk(KERN_ERR
"myradio: port 0x%03X is in use.\n", io);
return -EBUSY;
}
if(video_device_register(&my_radio, VFL_TYPE_RADIO)==-1) {
release_region(io, MY_IO_SIZE);
return -EINVAL;
}
return 0;
}
The first stage of the initialisation, as is normally the case, is to check that the I/O space we are about to fiddle with doesn't belong to some other driver. If it is we leave well alone. If the user gives the address of the wrong device then we will spot this. These policies will generally avoid crashing the machine.
Now we ask the Video4Linux layer to register the device for us. We hand it our carefully designed video_device structure and also tell it which group of devices we want it registered with. In this case VFL_TYPE_RADIO.
The types available are
Table 2.1. Device Types
| VFL_TYPE_RADIO | /dev/radio{n} | Radio devices are assigned in this block. As with all of these selections the actual number assignment is done by the video layer accordijng to what is free. |
| VFL_TYPE_GRABBER | /dev/video{n} | Video capture devices and also -- counter-intuitively for the name -- hardware video playback devices such as MPEG2 cards. |
| VFL_TYPE_VBI | /dev/vbi{n} | The VBI devices capture the hidden lines on a television picture that carry further information like closed caption data, teletext (primarily in Europe) and now Intercast and the ATVEC internet television encodings. |
| VFL_TYPE_VTX | /dev/vtx[n} | VTX is 'Videotext' also known as 'Teletext'. This is a system for sending numbered, 40x25, mostly textual page images over the hidden lines. Unlike the /dev/vbi interfaces, this is for 'smart' decoder chips. (The use of the word smart here has to be taken in context, the smartest teletext chips are fairly dumb pieces of technology). |
We are most definitely a radio.
Finally we allocate our I/O space so that nobody treads on us and return 0 to signify general happiness with the state of the universe.