Device nodes and character devices

When a driver module loads, the device manager udev will "automagically" create device nodes on the /dev hierarchy.

Note: If you are unfamiliar with what a DVB or V4L device is, please see here

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 ¹). 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 ¹. 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 (i.e. satellite based internet service)
• 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")
• ca
  • The ca character device controls conditional access hardware (i.e. the CI, CAM)

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

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". ²

Character Device Files Defined by the V4L2 API

Device File	Minor Range	Function
/dev/video 3, /dev/video0 to /dev/video63	0-63	Video Capture Interface Video Overlay Interface Video Output Interface Video Output Overlay Interface
/dev/radio 3, /dev/radio0 to /dev/radio63	64-127	Radio Interface AM/FM Radio Devices RDS Interface
/dev/vtx 2, 4, /dev/vtx0 to /dev/vtx31	192-223	Teletext Interface
/dev/vbi 3, /dev/vbi0 to /dev/vbi31	224-239	Raw VBI Data Interface Sliced VBI Data Interface

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 ¹). 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:

• /dev/video
  • Video Capture Interface
    • Video capture devices sample an analog video signal and store the digitized images in memory.
    • /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 (/dev/video0) ³
    • 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
  • 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 ³
  • RDS Interface

• /dev/vtx
  • Teletext Interface Chips
    • devices receiving and demodulating Teletext data [ETS 300 706, ITU BT.653],
    • the Teletext API was integrated into the original V4L API. There are no plans to replace the Teletext API or to integrate it into V4L2. ²
    • the Telextext Interface is accessed by character device file names /dev/vtx0 to /dev/vtx31, device major number 81, minor numbers 192 to 223. ⁴

• /dev/vbi
  • 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.
  • 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: See the V4L2 API for details regarding the Teletext Interface
• 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

External Links

• Wikipedia's udev article
• Wikipedia's device file system (devfs) article
• Wikipedia's Filesystem Hierarchy article