When a driver module loads, the device manager [[Wikipedia:udev|udev]] will "automagically" create [[device nodes]] on the ''/dev'' hierarchy.

+

When a driver module loads, the device manager [[Wikipedia:udev|udev]] will "automagically" create '''device nodes''' on the ''/dev'' hierarchy.

<br>

<br>

−

{{Note|If you are unfamiliar with what a DVB or V4L device is, please see [[ |here]] }}

+

{{Note|If you are unfamiliar with what a DVB or V4L device is, please see [[What is V4L or DVB?|here]] }}

<br>

<br>

Line 7:

Line 7:

A properly loaded device module should result in a non-empty ''/dev/dvb'' directory. You can check on whether this is true with the following command:

A properly loaded device module should result in a non-empty ''/dev/dvb'' directory. You can check on whether this is true with the following command:

: <code>ls -l /dev/dvb/</code>

: <code>ls -l /dev/dvb/</code>

−

(alternatively, you can browse your directory structure with the graphical file manager of your choice). More specifically, the output of the above command should reveal that ''/dev/dvb/'' is populated by "adapter''N''" (whereby, in terms of enumerating the devices installed in the system, ''N''=0 to whatever<sup id="fn_1_back">[[#fn_1|1]]</sup>). For example, if you have but a single DVB device installed in your system, then expect to find /dev/dvb/adapter0.

+

(alternatively, you can browse your directory structure with the graphical file manager of your choice). More specifically, the output of the above command should reveal that ''/dev/dvb/'' is populated by "adapter''N''" (whereby, in terms of enumerating the devices installed in the system, ''N''=0 to whatever <sup id="fn_1_back">[[#fn_1|1]]</sup>). For example, if you have but a single DVB device installed in your system, then expect to find /dev/dvb/adapter0.

===DVB character devices===

===DVB character devices===

−

The Linux DVB API provides for six unix style character devices which allow control of the hardware components found on a particular DVB device adapter.It is under each adapterN directory that you will find these character devices. The command

+

The [[Development: Linux DVB API history and future|Linux DVB API]] provides for six unix style character devices which allow control of the hardware components found on a particular DVB device adapter.It is under each adapterN directory that you will find these character devices. The command

: <code>ls -l /dev/dvb/adapter0 </code>

: <code>ls -l /dev/dvb/adapter0 </code>

−

reveals the [[character devices]] associated with adapter0 for which the drivers have control. If you have more then one DVB device, you can see the same for all with

+

reveals the '''character devices''' associated with adapter0 for which the drivers have control. If you have more then one DVB device, you can see the same for all with

: <code>ls -l /dev/dvb/adapter* </code>

: <code>ls -l /dev/dvb/adapter* </code>

−

Similar to the way in which the device adapters are enumerated, the character devices follow the form of ''M''=0 to whatever. For example: ''/dev/dvb/adapter0/frontend0'' .... if the same device had a second frontend, that character device would be enumerated by ''/dev/dvb/adapter0/frontend1'' ... if you had another dvb adapter in the system, then you would see ''/dev/dvb/adapter1/frontend0'' and so forth.

+

Similar to the way in which the device adapters are enumerated, the character devices follow the form of ''M''=0 to whatever <sup id="fn_1_back">[[#fn_1|1]]</sup>. For example: ''/dev/dvb/adapter0/frontend0'' .... if the same device had a second frontend, that character device would be enumerated by ''/dev/dvb/adapter0/frontend1'' ... if you had another dvb adapter in the system, then you would see ''/dev/dvb/adapter1/frontend0'' and so forth.

−

In brief, these are:

+

In brief, these character devices are:

−

* The ''frontend'' device which controls the tuner and demodulator. (different types of these hardware components for the different DTV standards)

+

* ''frontend''

−

* The ''demux'' which controls the filters for processing the transport stream (TS).

+

** The ''frontend'' character device controls the [[tuner]] and [[demodulator]] hardware ... (Note: there are different types of these hardware components for the different [[Digital Video Broadcasting|DTV standards]])

−

** the ''dvr'' which is a logical device that is associated with the demux character device ... it delivers up the TS for either:

+

* ''demux''

−

::(1) immediate playback --- in which case it has to be decoded either:

+

** The ''demux'' character device controls the filters for processing the [[Transport Stream|transport stream]] (TS). In essence, the demultiplexer splits the TS into its component parts (which usually entail being several audio and video streams, as well as some data streams)

−

::: a) on the device itself [its rare for PC devices to have hardware decoding, but not so for STB] or

**** The ''dvr'' is a logical device that is associated with the demux character device ... it delivers up a TS that was multiplexed from the sub-streams specified and filtered, from the original TS, by the demux for either:

−

::or

+

::::(1) immediate playback --- in which case it has to be decoded either:

−

::(2) saving to disk for later playback.

+

::::: a) on the device itself ... [now days its quite rare for PC devices to have hardware decoding ([[Hardware or Software Decoder?|see discussion]]), but this is certainly not the case for [[STB]]s)

−

* the ''net'' character device which controls IP-over-DVB (i.e. satellite based internet service)

+

::::: or

−

* the ''video'' device controls the MPEG2 video decoder of the DVB hardware (if present ... so called, [[full-featured device]]s).....Note that the DVB video device only controls decoding of the MPEG video stream, not its presentation on the TV or computer screen. On PCs this is typically handled by an associated video4linux device, e.g. /dev/video, which allows scaling and deﬁning output windows ... also note -- do NOT confuse this with the video node created by V4L devices (see below), as these are entirely different things

+

::::: b) downstream by the system [the usual route for PC devices -- i.e. software decoding via the host CPU, and possibly assisted by the GPU ... (see [[Hardware_or_Software_Decoder?#Software_Decoding_Devices|here]] for more discussion) ]

:In essence, the ''demux'' decomposes the original TS and selects/filters particular underlining sub-streams and the dvr then repackages those selections within a TS. Typically the multiplexed TS provided by the ''dvr'' would be composed of an individual program stream

+

* ''net''

+

** The ''net'' character device controls the ability to provide IP-over-DVB (e.g. satellite based broadband internet service ... Note: although it is not mentioned in the [http://linuxtv.org/downloads/v4l-dvb-apis/ch14.html API documentation], this functionality is not restricted to satellite (DVB-S) alone -- any DVB capable device can support it, provided you use the dvb net module (i.e. it is possible over DVB-C and DVB-T as well). The dvbnet script in the [[LinuxTV dvb-apps|dvb-apps]] handles this. As an example, both Scientific Atlantic and Cisco have DVB STB devices which can provide such broadband services.)

+

* ''video''

+

** The ''video'' character device controls the MPEG2 video decoder of the DVB hardware (if present ... found on so called "[[Full-featured Card#(i) "Full-Featured" or "Premium" Cards|full-featured device]]s") .... Note: do NOT confuse this with the video character device created by V4L devices (see the [[Device nodes and character devices#V4L_character_devices|discussion below]]), as they are entirely different things. Specifically, the DVB video character device only controls decoding of the MPEG video stream, not its presentation on the computer or TV screen. This later function, on a full-featured device, is typically handled by an associated video4linux device IC, which allows scaling and defining output windows. Control of this later device is established through a V4L character device, specifically, ''/dev/video''.

+

* ''osd''

+

** The ''osd'' character device is not documented in the API, but it stems from the legacy OSD API for so called "[[Full-featured Card#(i) "Full-Featured" or "Premium" Cards|full-featured device]]s". The draft version of the never finished v4 Linux DVB API makes passing mention of this character device: "The Linux DVB API Version 3 was focussed on the popular Siemens PCI DVB card. Due to the pragmatic evolution of the API, there are namespace inconsitencies and inconsitent remains of things that really don’t belong into the API, like ad-hoc DVD subtitle support or a very limited OSD API design." Nonetheless, when dealing with a full-featured card, it will indeed show up under the adapter node, as illustrated by this end user supplied [https://lists.ubuntu.com/archives/ubuntu-users/2008-August/155249.html example].

+

* ''audio''

+

** The ''audio'' character device controls the MPEG2 audio decoder of the DVB hardware (if present ... found on so called [[Full-featured Card#(i) "Full-Featured" or "Premium" Cards|full-featured device]]s")

* Not every device or STB provides conditional access hardware ... i.e. leads to the omission of the ''ca'' character device

−

* the DVB API may also be used for MPEG decoder-only PCI cards, in which case, for these rare devices, there exists no need for the frontend character device

+

* The DVB API may also be used for MPEG decoder-only PCI cards, in which case, for these rare devices, there exists no need for the ''frontend'' character device

−

* some

+

−

In fact, a typical DVB device these days will usually only contain three of these character devices (frontend, demux, net), as well as the special logical device (dvr).

+

In fact, a typical DVB device these days will usually only contain three of these character devices (''frontend'', ''demux'', ''net''), as well as the special logical device (''dvr'').

==For a V4L device==

==For a V4L device==

−

Similarly, with video capture (or, if you prefer, V4L) devices, a properly loaded device module should result in a non-empty ''/dev/v4l'' directory. You can check on whether this is true with the following command:

+

Similarly, with "V4L devices", a properly loaded device module should result in a non-empty ''/dev/v4l'' directory. You can check on whether this is true with the following command:

<code>ls -l /dev/v4l</code>

<code>ls -l /dev/v4l</code>

−

What you should find is a sub directory named "by-path", that contains symbolic links to character device files, whose conventional names and functions summarized below:

+

What you should find in that '''device node''' is a sub directory, named "by-path", that contains symbolic links to '''character device''' files, whose conventional names and functions are summarized in the table below.

+

{{Note|You can determine which device maps to ''videoN'' by matching, for example (in the case of a pci card), the domain:bus:slot.func information provided by the command lspci to the associated links in the by-path directory .... Somewhat similarly, QUERYCAP ioctl() or sysfs can be used to expose which V4L driver maps to ''videoN'' [http://www.mail-archive.com/linux-media@vger.kernel.org/msg70058.html] }}

+

+

===V4L character devices===

+

The [[Development: Video4Linux APIs|V4L2 API]] defines three special character devices. In the table below, and ensuing discussion, we make note of a fourth, the Teletext Interface, which was defined by the older V4L1 API, but is not, nor intended to be, defined in the newer V4L2 API. This fourth character device does, however, receive de facto support given that "for compatibility reasons the character device file names recommended for V4L2 video capture, overlay, radio, teletext and raw vbi capture devices did not change from those used by V4L" and can be serviced "through the V4L2 compatibility layer in the videodev kernel module". <sup id="fn_1_back">[[#fn_2|2]]</sup>

The most prominently recognized are the ''/dev/videoN'' character devices (whereby, in terms of enumerating the devices installed in the system, ''N''=0 to whatever <sup id="fn_1_back">[[#fn_1|1]]</sup>). You can check for them within your system with the following command:

+

<code>ls -l /dev/video*</code>

−

''/dev/video'' directory. You can check on whether this is true with the following command:

+

A more detailed explanation of the V4L character devices are outlined in point form below:

*** accessed through the same character special files as video capture devices.

−

+

*** Note the default function of a ''/dev/video'' device is video capturing. The overlay function is only available after calling the VIDIOC_S_FMT ioctl.

−

+

** Video Output Interface

−

+

*** Video output devices encode stills or image sequences as analog video signal. With this interface applications can control the encoding process and move images from user space to the driver.

−

+

** Video Output Overlay Interface

−

V4L character devices include:

+

*** Some video output devices can overlay a framebuffer image onto the outgoing video signal. Applications can set up such an overlay using this interface, which borrows structures and ioctls of the Video Overlay interface.

−

*

+

*** The OSD function is accessible through the same character special file as the Video Output function. Note the default function of such a ''/dev/video'' device is video capturing or output. The OSD function is only available after calling the VIDIOC_S_FMT ioctl.

***** Contrary to the Video Overlay interface the framebuffer is normally implemented on the TV card and not the graphics card. On Linux it is accessible as a framebuffer device (''/dev/fbN''). Given a V4L2 device, applications can find the corresponding framebuffer device by calling the VIDIOC_G_FBUF ioctl.

−

+

−

Video Capture Interface

+

−

* /dev/video and /dev/video0 to /dev/video63 with major number 81 and minor numbers 0 to 63.

+

−

* Note: /dev/video is typically a symbolic link to the preferred video device.

+

−

* Note the same device files are used for video output devices:

+

−

+

−

Video Overlay Interface (also known as Framebuffer Overlay or Previewing)

+

−

* accessed through the same character special files as video capture devices.

+

−

* Note the default function of a /dev/video device is video capturing. The overlay function is only available after calling the VIDIOC_S_FMT ioctl.

+

−

+

−

Video Output Interface

+

−

* Video output devices encode stills or image sequences as analog video signal. With this interface applications can control the encoding process and move images from user space to the driver.

+

−

+

−

Video Output Overlay Interface

+

−

* Some video output devices can overlay a framebuffer image onto the outgoing video signal. Applications can set up such an overlay using this interface, which borrows structures and ioctls of the Video Overlay interface.

+

−

* The OSD function is accessible through the same character special file as the Video Output function. Note the default function of such a /dev/video device is video capturing or output. The OSD function is only available after calling the VIDIOC_S_FMT ioctl.

+

−

+

−

::Framebuffer

+

−

**Contrary to the Video Overlay interface the framebuffer is normally implemented on the TV card and not the graphics card. On Linux it is accessible as a framebuffer device (/dev/fbN). Given a V4L2 device, applications can find the corresponding framebuffer device by calling the VIDIOC_G_FBUF ioctl.

+

−

+

−

/dev/radio 64-127 AM/FM Radio Devices ... For radio devices that support it,

+

−

accessed through character device special files named /dev/radio and /dev/radio0 to /dev/radio63 with major number 81 and minor numbers 64 to 127.

character device file names /dev/vtx0 to /dev/vtx31, device major number 81, minor numbers 192 to 223.

+

−

+

−

+

−

/dev/vbi 224-239 VBI (Vertical Blanking Interval) Data

+

−

+

−

Raw VBI Data Interface

+

−

* VBI devices are accessed through character device special files named /dev/vbi and /dev/vbi0 to /dev/vbi31 with major number 81 and minor numbers 224 to 255.

+

−

* /dev/vbi is typically a symbolic link to the preferred VBI device.

+

−

* This convention applies to both input and output devices.

+

−

VBI capturing and output is also available as device function under /dev/video. To capture or output raw VBI data with these devices applications must call the VIDIOC_S_FMT ioctl. Accessed as /dev/vbi, raw VBI capturing or output is the default device function.

+

+

* ''/dev/radio''

+

** Radio Interface

+

*** accessed through character device special files named ''/dev/radio'' and ''/dev/radio0'' to ''/dev/radio63'' with major number 81 and minor numbers 64 to 127. Note that ''/dev/radio'' is a symbolic link to ''/dev/radio0'' <sup id="fn_1_back">[[#fn_3|3]]</sup>

+

** RDS Interface

−

Sliced VBI Data Interface

+

* ''/dev/vtx''

−

* Sliced VBI devices use hardware to demodulate data transmitted in the VBI. V4L2 drivers shall not do this by software, see also the raw VBI interface.

+

** Teletext Interface Chips

−

* Sliced VBI capture and output devices are accessed through the same character special files as raw VBI devices.

*** VBI capturing and output is also available as device function under ''/dev/video''. To capture or output raw VBI data with these devices applications must call the VIDIOC_S_FMT ioctl. Accessed as ''/dev/vbi'', raw VBI capturing or output is the default device function.

+

** Sliced VBI Data Interface

+

*** Sliced VBI devices use hardware to demodulate data transmitted in the VBI. V4L2 drivers shall not do this by software, see also the raw VBI interface.

+

*** Sliced VBI capture and output devices are accessed through the same character special files as raw VBI devices.

+

*** When a driver supports both VBI interfaces, the default function of a ''/dev/vbi'' device is raw VBI capturing or output, and the sliced VBI function is only available after calling the VIDIOC_S_FMT ioctl

+

*** Likewise a ''/dev/video'' device may support the sliced VBI API, however the default function here is video capturing or output.

+

Not all of the character devices defined by the V4L2 API need be present for a device, specifically because some functionality is not needed or present on the device. For example, unless the device contains a decoder IC for AM/FM radio reception, the ''/dev/radio'' character device need not be created by the driver.

+

==Associated Nodes and Character Devices for Analog Audio Input/Output==

+

* /dev/mixer

+

* /dev/dsp

==Endnotes==

==Endnotes==

−

*<cite id="fn_1">[[#fn_1_back|Note 1:]] </cite> The real life limitation of the "whatever" comment is given by the max adapter definition in driver (this is usually set at 8, though, this can be adjusted for more by altering the source code and recompiling)

+

*<cite id="fn_1">[[#fn_1_back|Note 1:]] </cite> The real life limitation of the "whatever" comment is given by the max. adapter definition in the respective device driver (Note: this is usually set at 8, though, this can be adjusted for more by altering the source code and recompiling. Also note that a [http://linuxtv.org/hg/v4l-dvb/rev/496b71d9a1c0 patch] was submitted in Sept/09, which will allow configuration of the max adapter definition)

*<cite id="fn_3">[[#fn_2_back|Note 2:]] </cite> The V4L2 API clearly denotes, in the case of the three defined character devices, that the respective base is a symbolic link to the respective N=0 character device (i.e. ''/dev/video'' --> ''/dev/video0''). For the ''video'' and ''radio'' character devices, this is also cited within the {Linux}/Documentation/devices.txt file

+

*<cite id="fn_4">[[#fn_4_back|Note 4:]] </cite> While no mention of it is made in the V4l2 API, presumably the base ''/dev/vtx'' character device is a symbolic link to ''/dev/vtx0''; as this would be similar in case with the three defined character devices.

==Also See==

==Also See==

−

* For more comprehensive information, it suggested that you review the DVB and V4L APIs

+

* For more comprehensive information, it is suggested that you review the DVB and V4L APIs

+

* For more comprehensive information on the associated audio nodes, it is suggested that you review ALSA and/or OSS related materials

Contents

For a DVB device

A properly loaded device module should result in a non-empty /dev/dvb directory. You can check on whether this is true with the following command:

ls -l /dev/dvb/

(alternatively, you can browse your directory structure with the graphical file manager of your choice). More specifically, the output of the above command should reveal that /dev/dvb/ is populated by "adapterN" (whereby, in terms of enumerating the devices installed in the system, N=0 to whatever 1). For example, if you have but a single DVB device installed in your system, then expect to find /dev/dvb/adapter0.

DVB character devices

The Linux DVB API provides for six unix style character devices which allow control of the hardware components found on a particular DVB device adapter.It is under each adapterN directory that you will find these character devices. The command

ls -l /dev/dvb/adapter0

reveals the character devices associated with adapter0 for which the drivers have control. If you have more then one DVB device, you can see the same for all with

ls -l /dev/dvb/adapter*

Similar to the way in which the device adapters are enumerated, the character devices follow the form of M=0 to whatever 1. For example: /dev/dvb/adapter0/frontend0 .... if the same device had a second frontend, that character device would be enumerated by /dev/dvb/adapter0/frontend1 ... if you had another dvb adapter in the system, then you would see /dev/dvb/adapter1/frontend0 and so forth.

In brief, these character devices are:

frontend

The frontend character device controls the tuner and demodulator hardware ... (Note: there are different types of these hardware components for the different DTV standards)

demux

The demux character device controls the filters for processing the transport stream (TS). In essence, the demultiplexer splits the TS into its component parts (which usually entail being several audio and video streams, as well as some data streams)

dvr

The dvr is a logical device that is associated with the demux character device ... it delivers up a TS that was multiplexed from the sub-streams specified and filtered, from the original TS, by the demux for either:

(1) immediate playback --- in which case it has to be decoded either:

a) on the device itself ... [now days its quite rare for PC devices to have hardware decoding (see discussion), but this is certainly not the case for STBs)

or

b) downstream by the system [the usual route for PC devices -- i.e. software decoding via the host CPU, and possibly assisted by the GPU ... (see here for more discussion) ]

or

(2) saving to disk for later playback.

In essence, the demux decomposes the original TS and selects/filters particular underlining sub-streams and the dvr then repackages those selections within a TS. Typically the multiplexed TS provided by the dvr would be composed of an individual program stream

net

The net character device controls the ability to provide IP-over-DVB (e.g. satellite based broadband internet service ... Note: although it is not mentioned in the API documentation, this functionality is not restricted to satellite (DVB-S) alone -- any DVB capable device can support it, provided you use the dvb net module (i.e. it is possible over DVB-C and DVB-T as well). The dvbnet script in the dvb-apps handles this. As an example, both Scientific Atlantic and Cisco have DVB STB devices which can provide such broadband services.)

video

The video character device controls the MPEG2 video decoder of the DVB hardware (if present ... found on so called "full-featured devices") .... Note: do NOT confuse this with the video character device created by V4L devices (see the discussion below), as they are entirely different things. Specifically, the DVB video character device only controls decoding of the MPEG video stream, not its presentation on the computer or TV screen. This later function, on a full-featured device, is typically handled by an associated video4linux device IC, which allows scaling and defining output windows. Control of this later device is established through a V4L character device, specifically, /dev/video.

osd

The osd character device is not documented in the API, but it stems from the legacy OSD API for so called "full-featured devices". The draft version of the never finished v4 Linux DVB API makes passing mention of this character device: "The Linux DVB API Version 3 was focussed on the popular Siemens PCI DVB card. Due to the pragmatic evolution of the API, there are namespace inconsitencies and inconsitent remains of things that really don’t belong into the API, like ad-hoc DVD subtitle support or a very limited OSD API design." Nonetheless, when dealing with a full-featured card, it will indeed show up under the adapter node, as illustrated by this end user supplied example.

audio

The audio character device controls the MPEG2 audio decoder of the DVB hardware (if present ... found on so called full-featured devices")

Not all of the character devices defined by the DVB API need be present for a device, specifically because some functionality is not needed; in point:

Most DVB devices don’t have their own MPEG decoder because:

modern CPUs and the ability to offload decoding to video card GPUs has pretty much long replaced the need of the so called "full feautred" class of DVB devices, or

may be foregone for datacasting type devices (e.g. for data-only uses like “internet over satellite”)

In any regard, for either reason, this results in the omission of the audio and video character devices

Not every device or STB provides conditional access hardware ... i.e. leads to the omission of the ca character device

The DVB API may also be used for MPEG decoder-only PCI cards, in which case, for these rare devices, there exists no need for the frontend character device

In fact, a typical DVB device these days will usually only contain three of these character devices (frontend, demux, net), as well as the special logical device (dvr).

For a V4L device

Similarly, with "V4L devices", a properly loaded device module should result in a non-empty /dev/v4l directory. You can check on whether this is true with the following command:

ls -l /dev/v4l

What you should find in that device node is a sub directory, named "by-path", that contains symbolic links to character device files, whose conventional names and functions are summarized in the table below.

Note: You can determine which device maps to videoN by matching, for example (in the case of a pci card), the domain:bus:slot.func information provided by the command lspci to the associated links in the by-path directory .... Somewhat similarly, QUERYCAP ioctl() or sysfs can be used to expose which V4L driver maps to videoN[1]

V4L character devices

The V4L2 API defines three special character devices. In the table below, and ensuing discussion, we make note of a fourth, the Teletext Interface, which was defined by the older V4L1 API, but is not, nor intended to be, defined in the newer V4L2 API. This fourth character device does, however, receive de facto support given that "for compatibility reasons the character device file names recommended for V4L2 video capture, overlay, radio, teletext and raw vbi capture devices did not change from those used by V4L" and can be serviced "through the V4L2 compatibility layer in the videodev kernel module". 2

The most prominently recognized are the /dev/videoN character devices (whereby, in terms of enumerating the devices installed in the system, N=0 to whatever 1). You can check for them within your system with the following command:

ls -l /dev/video*

A more detailed explanation of the V4L character devices are outlined in point form below:

Video Overlay Interface (also known as Framebuffer Overlay or Previewing)

accessed through the same character special files as video capture devices.

Note the default function of a /dev/video device is video capturing. The overlay function is only available after calling the VIDIOC_S_FMT ioctl.

Video Output Interface

Video output devices encode stills or image sequences as analog video signal. With this interface applications can control the encoding process and move images from user space to the driver.

Video Output Overlay Interface

Some video output devices can overlay a framebuffer image onto the outgoing video signal. Applications can set up such an overlay using this interface, which borrows structures and ioctls of the Video Overlay interface.

The OSD function is accessible through the same character special file as the Video Output function. Note the default function of such a /dev/video device is video capturing or output. The OSD function is only available after calling the VIDIOC_S_FMT ioctl.

Framebuffer

Contrary to the Video Overlay interface the framebuffer is normally implemented on the TV card and not the graphics card. On Linux it is accessible as a framebuffer device (/dev/fbN). Given a V4L2 device, applications can find the corresponding framebuffer device by calling the VIDIOC_G_FBUF ioctl.

/dev/radio

Radio Interface

accessed through character device special files named /dev/radio and /dev/radio0 to /dev/radio63 with major number 81 and minor numbers 64 to 127. Note that /dev/radio is a symbolic link to /dev/radio03

VBI capturing and output is also available as device function under /dev/video. To capture or output raw VBI data with these devices applications must call the VIDIOC_S_FMT ioctl. Accessed as /dev/vbi, raw VBI capturing or output is the default device function.

Sliced VBI Data Interface

Sliced VBI devices use hardware to demodulate data transmitted in the VBI. V4L2 drivers shall not do this by software, see also the raw VBI interface.

Sliced VBI capture and output devices are accessed through the same character special files as raw VBI devices.

When a driver supports both VBI interfaces, the default function of a /dev/vbi device is raw VBI capturing or output, and the sliced VBI function is only available after calling the VIDIOC_S_FMT ioctl

Likewise a /dev/video device may support the sliced VBI API, however the default function here is video capturing or output.

Not all of the character devices defined by the V4L2 API need be present for a device, specifically because some functionality is not needed or present on the device. For example, unless the device contains a decoder IC for AM/FM radio reception, the /dev/radio character device need not be created by the driver.

Associated Nodes and Character Devices for Analog Audio Input/Output

/dev/mixer

/dev/dsp

Endnotes

Note 1: The real life limitation of the "whatever" comment is given by the max. adapter definition in the respective device driver (Note: this is usually set at 8, though, this can be adjusted for more by altering the source code and recompiling. Also note that a patch was submitted in Sept/09, which will allow configuration of the max adapter definition)

Note 2: The V4L2 API clearly denotes, in the case of the three defined character devices, that the respective base is a symbolic link to the respective N=0 character device (i.e. /dev/video --> /dev/video0). For the video and radio character devices, this is also cited within the {Linux}/Documentation/devices.txt file

Note 4: While no mention of it is made in the V4l2 API, presumably the base /dev/vtx character device is a symbolic link to /dev/vtx0; as this would be similar in case with the three defined character devices.

Also See

For more comprehensive information, it is suggested that you review the DVB and V4L APIs

For more comprehensive information on the associated audio nodes, it is suggested that you review ALSA and/or OSS related materials