VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use)
The last argument gives you a certain amount of control over the device
-kernel number used (i.e. the X in videoX). Normally you will pass -1 to
-let the v4l2 framework pick the first free number. But if a driver creates
-many devices, then it can be useful to have different video devices in
-separate ranges. For example, video capture devices start at 0, video
-output devices start at 16.
-
-So you can use the last argument to specify a minimum kernel number and
-the v4l2 framework will try to pick the first free number that is equal
+device node number used (i.e. the X in videoX). Normally you will pass -1
+to let the v4l2 framework pick the first free number. But sometimes users
+want to select a specific node number. It is common that drivers allow
+the user to select a specific device node number through a driver module
+option. That number is then passed to this function and video_register_device
+will attempt to select that device node number. If that number was already
+in use, then the next free device node number will be selected and it
+will send a warning to the kernel log.
+
+Another use-case is if a driver creates many devices. In that case it can
+be useful to place different video devices in separate ranges. For example,
+video capture devices start at 0, video output devices start at 16.
+So you can use the last argument to specify a minimum device node number
+and the v4l2 framework will try to pick the first free number that is equal
or higher to what you passed. If that fails, then it will just pick the
first free number.
+Since in this case you do not care about a warning about not being able
+to select the specified device node number, you can call the function
+video_register_device_no_warn() instead.
+
Whenever a device node is created some attributes are also created for you.
If you look in /sys/class/video4linux you see the devices. Go into e.g.
video0 and you will see 'name' and 'index' attributes. The 'name' attribute
-is the 'name' field of the video_device struct. The 'index' attribute is
-a device node index that can be assigned by the driver, or that is calculated
-for you.
-
-If you call video_register_device(), then the index is just increased by
-1 for each device node you register. The first video device node you register
-always starts off with 0.
+is the 'name' field of the video_device struct.
-Alternatively you can call video_register_device_index() which is identical
-to video_register_device(), but with an extra index argument. Here you can
-pass a specific index value (between 0 and 31) that should be used.
+The 'index' attribute is the index of the device node: for each call to
+video_register_device() the index is just increased by 1. The first video
+device node you register always starts with index 0.
Users can setup udev rules that utilize the index attribute to make fancy
device names (e.g. 'mpegX' for MPEG video capture device nodes).
- vfl_type: the device type passed to video_register_device.
- minor: the assigned device minor number.
-- num: the device kernel number (i.e. the X in videoX).
-- index: the device index number (calculated or set explicitly using
- video_register_device_index).
+- num: the device node number (i.e. the X in videoX).
+- index: the device index number.
If the registration failed, then you need to call video_device_release()
to free the allocated video_device struct, or free your own struct if the
There are a few useful helper functions:
+- file/video_device private data
+
You can set/get driver private data in the video_device struct using:
void *video_get_drvdata(struct video_device *vdev);
returns the video_device belonging to the file struct.
-The final helper function combines video_get_drvdata with
-video_devdata:
+The video_drvdata function combines video_get_drvdata with video_devdata:
void *video_drvdata(struct file *file);
struct v4l2_device *v4l2_dev = vdev->v4l2_dev;
+- Device node name
+
+The video_device node kernel name can be retrieved using
+
+const char *video_device_node_name(struct video_device *vdev);
+
+The name is used as a hint by userspace tools such as udev. The function
+should be used where possible instead of accessing the video_device::num and
+video_device::minor fields.
+
+
video buffer helper functions
-----------------------------
-The v4l2 core API provides a standard method for dealing with video
-buffers. Those methods allow a driver to implement read(), mmap() and
-overlay() on a consistent way.
-
-There are currently methods for using video buffers on devices that
-supports DMA with scatter/gather method (videobuf-dma-sg), DMA with
-linear access (videobuf-dma-contig), and vmalloced buffers, mostly
-used on USB drivers (videobuf-vmalloc).
-
-Any driver using videobuf should provide operations (callbacks) for
-four handlers:
-
-ops->buf_setup - calculates the size of the video buffers and avoid they
- to waste more than some maximum limit of RAM;
-ops->buf_prepare - fills the video buffer structs and calls
- videobuf_iolock() to alloc and prepare mmaped memory;
-ops->buf_queue - advices the driver that another buffer were
- requested (by read() or by QBUF);
-ops->buf_release - frees any buffer that were allocated.
-
-In order to use it, the driver need to have a code (generally called at
-interrupt context) that will properly handle the buffer request lists,
-announcing that a new buffer were filled.
-
-The irq handling code should handle the videobuf task lists, in order
-to advice videobuf that a new frame were filled, in order to honor to a
-request. The code is generally like this one:
- if (list_empty(&dma_q->active))
- return;
-
- buf = list_entry(dma_q->active.next, struct vbuffer, vb.queue);
-
- if (!waitqueue_active(&buf->vb.done))
- return;
-
- /* Some logic to handle the buf may be needed here */
-
- list_del(&buf->vb.queue);
- do_gettimeofday(&buf->vb.ts);
- wake_up(&buf->vb.done);
-
-Those are the videobuffer functions used on drivers, implemented on
-videobuf-core:
-
-- Videobuf init functions
- videobuf_queue_sg_init()
- Initializes the videobuf infrastructure. This function should be
- called before any other videobuf function on drivers that uses DMA
- Scatter/Gather buffers.
-
- videobuf_queue_dma_contig_init
- Initializes the videobuf infrastructure. This function should be
- called before any other videobuf function on drivers that need DMA
- contiguous buffers.
-
- videobuf_queue_vmalloc_init()
- Initializes the videobuf infrastructure. This function should be
- called before any other videobuf function on USB (and other drivers)
- that need a vmalloced type of videobuf.
-
-- videobuf_iolock()
- Prepares the videobuf memory for the proper method (read, mmap, overlay).
-
-- videobuf_queue_is_busy()
- Checks if a videobuf is streaming.
-
-- videobuf_queue_cancel()
- Stops video handling.
-
-- videobuf_mmap_free()
- frees mmap buffers.
-
-- videobuf_stop()
- Stops video handling, ends mmap and frees mmap and other buffers.
-
-- V4L2 api functions. Those functions correspond to VIDIOC_foo ioctls:
- videobuf_reqbufs(), videobuf_querybuf(), videobuf_qbuf(),
- videobuf_dqbuf(), videobuf_streamon(), videobuf_streamoff().
-
-- V4L1 api function (corresponds to VIDIOCMBUF ioctl):
- videobuf_cgmbuf()
- This function is used to provide backward compatibility with V4L1
- API.
-
-- Some help functions for read()/poll() operations:
- videobuf_read_stream()
- For continuous stream read()
- videobuf_read_one()
- For snapshot read()
- videobuf_poll_stream()
- polling help function
-
-The better way to understand it is to take a look at vivi driver. One
-of the main reasons for vivi is to be a videobuf usage example. the
-vivi_thread_tick() does the task that the IRQ callback would do on PCI
-drivers (or the irq callback on USB).
+The v4l2 core API provides a set of standard methods (called "videobuf")
+for dealing with video buffers. Those methods allow a driver to implement
+read(), mmap() and overlay() in a consistent way. There are currently
+methods for using video buffers on devices that supports DMA with
+scatter/gather method (videobuf-dma-sg), DMA with linear access
+(videobuf-dma-contig), and vmalloced buffers, mostly used on USB drivers
+(videobuf-vmalloc).
+
+Please see Documentation/video4linux/videobuf for more information on how
+to use the videobuf layer.
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff