Device nodes and character devices
When a driver module loads, the device manager udev will "automagically" create device nodes on the /dev hierarchy.
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 whatever1). 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 device which controls the tuner and demodulator. (different types of these hardware components for the different DTV standards)
- demux
- The demux controls the filters for processing the transport stream (TS).
- dvr
- The dvr which is a logical device that is associated with the demux character device ... it delivers up the TS for either:
- dvr
- The demux controls the filters for processing the transport stream (TS).
- (1) immediate playback --- in which case it has to be decoded either:
- a) on the device itself [its rare for PC devices to have hardware decoding, but not so for STB] 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) ]
- or
- (2) saving to disk for later playback.
- (1) immediate playback --- in which case it has to be decoded either:
- net
- The net character device which controls IP-over-DVB (i.e. satellite based internet service)
- video
- The video 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 TV or computer 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, /dev/video.
- audio
- The audio device controls the MPEG2 audio decoder of the DVB hardware (if present ... so called, full-featured devices)
- ca
- The ca device which controls conditional access hardware (like CI, CAM)
Not all of the character devices defined by the 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 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:
ls -l /dev/v4l
What you should find 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.
V4L character devices
| Device File | Minor Range | Function |
|---|---|---|
| /dev/video, /dev/video0 to /dev/video63 | 0-63 |
|
| /dev/radio, /dev/radio0 to /dev/radio63 | 64-127 |
|
| /dev/vtx, /dev/vtx0 to /dev/vtx31 | 192-223 |
|
| /dev/vbi, /dev/vbi0 to /dev/vbi31 | 224-239 |
|
The most prominently recognized are the /dev/videoN character devices (whereby, in terms of enumerating the devices installed in the system, N=0 to whatever1). 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.
- Framebuffer
- Video Capture Interface
- /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.
- RDS Interface
- Radio Interface
- /dev/vtx
- Teletext Interface Chips
- devices receiving and demodulating Teletext data [ETS 300 706, ITU BT.653],
- character device file names /dev/vtx0 to /dev/vtx31, device major number 81, minor numbers 192 to 223.
- Teletext Interface Chips
- /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.
- Raw VBI Data Interface
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.
Endnotes
- Note 1: 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)
Also See
- For more comprehensive information, it suggested that you review the DVB and V4L APIs