Video4Linux2 - en - 图文(3)

incrementing from there; once the driver returns EINVAL the application knows that it has

?

? ?

?

exhausted the list. Input number zero should exist for all input-capable devices.

__u8 name[32]: the name of the input, as set by the driver. In simple cases, it can simply be \correspond to what is printed by the connector.

__u32 type: the type of input. There are currently only

two: V4L2_INPUT_TYPE_TUNER and V4L2_INPUT_TYPE_CAMERA.

__u32 audioset: describes which audio inputs can be associated with this video input. Audio inputs are enumerated by index number just like video inputs (we'll get to audio in another installment), but not all combinations of audio and video can be selected. This field is a bitmask with a bit set for each audio input which works with the video input being enumerated. If no audio inputs are supported, or if only a single input can be selected, the driver can simply leave this field as zero.

__u32 tuner: if this input is a tuner (type is set to V4L2_INPUT_TYPE_TUNER), this field will contain an index number corresponding to the tuner device. Enumeration and control of tuners will be covered in a future installment too.

v4l2_std_id std: describes which video standard(s) are supported by the device.

__u32 status: gives the status of the input. The full set of flags can be found in the V4L2 documentation; in short, each bit set in status describes a problem. These can include no power, no signal, no synchronization lock, or the presence of Macrovision, among other unfortunate events.

__u32 reserved[4]: reserved fields. Drivers should set them to zero.

? ?

?

Normally, the driver will set all of the fields above and return zero. If index is outside the range of supported inputs, -EINVALshould be returned instead; there is not much else that can go wrong in this call.

When the application wants to change the current input, the driver will receive a call to its vidioc_s_input() callback:

int (*vidioc_s_input) (struct file *file, void *private_data, unsigned int index);

The index value has the same meaning as before - it identifies which input is of interest. The driver should program the hardware to use that input and return zero. Other possible return values are -EINVAL (for a bogus index number) or -EIO (for hardware trouble). Drivers should implement this callback even if they only support a single input.

There is also a callback to query which input is currently active:

int (*vidioc_g_input) (struct file *file, void *private_data, unsigned int *index);

Here, the driver sets *index to the index number of the currently active input. Outputs

The process for enumerating and selecting outputs is very similar to that for inputs, so the description here will be a little more brief. The callback for output enumeration looks like this:

int (*vidioc_enumoutput) (struct file *file, void *private_data struct v4l2_output *output);

The fields of the v4l2_output structure are:

? ? ?

__u32 index: the index value corresponding to the output. This index works the same way

? ? ? ?

as the input index: it starts at zero and goes up from there. __u8 name[32]: the name of the output.

__u32 type: the type of the output. The supported output types are V4L2_OUTPUT_TYPE_MODULATOR for an analog TV

modulator, V4L2_OUTPUT_TYPE_ANALOG for basic analog video output,

and V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY for analog VGA overlay devices.

__u32 audioset: the set of audio outputs which can operate with this video output. __u32 modulator: the index of the modulator associated with this device (for those of type V4L2_OUTPUT_TYPE_MODULATOR).

v4l2_std_id std: the video standards supported by this output. __u32 reserved[4]: reserved fields, should be set to zero.

There are callbacks for getting and setting the current output setting; they mirror the input callbacks:

int (*vidioc_g_output) (struct file *file, void *private_data, unsigned int *index);

int (*vidioc_s_output) (struct file *file, void *private_data, unsigned int index);

Any device which supports video output should have all three output callbacks defined, even if there is only one possible output.

With these methods in place, a V4L2 application can determine which inputs and outputs are available on a given device and choose between them. The task of determining just what kind of video data flows through those inputs and outputs is rather more complicated, however. The next installment in this series will begin to look at video data formats and how to negotiate a format with user space.

Video4Linux2 part 5a: colors and formats

[Posted January 24, 2007 by corbet] The LWN.net Video4Linux2 API series. This is the fifth article in the irregular LWN series on writing video drivers for Linux. Those who have not yet read the introductory article may want to start there. Before any application can work with a video device, it must come to an understanding with the driver about how video data will be formatted. This negotiation can be a rather complex process, resulting from the facts that (1) video hardware varies widely in the formats it can handle, and (2) performing format transformations in the kernel is frowned upon. So the application must be able to find out what formats are supported by the hardware and set up a configuration which is workable for everybody involved. This article will cover the basics of how formats are described; the next installment will get into the API implemented by V4L2 drivers to negotiate formats with applications. Col …… 此处隐藏：7898字，全部文档内容请下载后查看。喜欢就下载吧 ……