The control mechanism as originally designed was meant to be used for user settings (brightness, saturation, etc). However, it turned out to be a very useful model for implementing more complicated driver APIs where each driver implements only a subset of a larger API.

The MPEG encoding API was the driving force behind designing and implementing this extended control mechanism: the MPEG standard is quite large and the currently supported hardware MPEG encoders each only implement a subset of this standard. Further more, many parameters relating to how the video is encoded into an MPEG stream are specific to the MPEG encoding chip since the MPEG standard only defines the format of the resulting MPEG stream, not how the video is actually encoded into that format.

Unfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API.

Even though the MPEG encoding API was the first effort to use the Extended Control API, nowadays there are also other classes of Extended Controls, such as Camera Controls and FM Transmitter Controls. The Extended Controls API as well as all Extended Controls classes are described in the following text.

Three new ioctls are available: VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS and VIDIOC_TRY_EXT_CTRLS. These ioctls act on arrays of controls (as opposed to the VIDIOC_G_CTRL and VIDIOC_S_CTRL ioctls that act on a single control). This is needed since it is often required to atomically change several controls at once.

Each of the new ioctls expects a pointer to a struct v4l2_ext_controls. This structure contains a pointer to the control array, a count of the number of controls in that array and a control class. Control classes are used to group similar controls into a single class. For example, control class V4L2_CTRL_CLASS_USER contains all user controls (i. e. all controls that can also be set using the old VIDIOC_S_CTRL ioctl). Control class V4L2_CTRL_CLASS_MPEG contains all controls relating to MPEG encoding, etc.

All controls in the control array must belong to the specified control class. An error is returned if this is not the case.

It is also possible to use an empty control array (count == 0) to check whether the specified control class is supported.

The control array is a struct v4l2_ext_control array. The v4l2_ext_control structure is very similar to struct v4l2_control, except for the fact that it also allows for 64-bit values and pointers to be passed.

Since the struct v4l2_ext_control supports pointers it is now also possible to have controls with compound types such as N-dimensional arrays and/or structures. You need to specify the V4L2_CTRL_FLAG_NEXT_COMPOUND when enumerating controls to actually be able to see such compound controls. In other words, these controls with compound types should only be used programmatically.

Since such compound controls need to expose more information about themselves than is possible with VIDIOC_QUERYCTRL the VIDIOC_QUERY_EXT_CTRL ioctl was added. In particular, this ioctl gives the dimensions of the N-dimensional array if this control consists of more than one element.

It is important to realize that due to the flexibility of controls it is necessary to check whether the control you want to set actually is supported in the driver and what the valid range of values is. So use the VIDIOC_QUERYCTRL (or VIDIOC_QUERY_EXT_CTRL) and VIDIOC_QUERYMENU ioctls to check this. Also note that it is possible that some of the menu indices in a control of type V4L2_CTRL_TYPE_MENU may not be supported (VIDIOC_QUERYMENU will return an error). A good example is the list of supported MPEG audio bitrates. Some drivers only support one or two bitrates, others support a wider range.

All controls use machine endianness.

The recommended way to enumerate over the extended controls is by using VIDIOC_QUERYCTRL in combination with the V4L2_CTRL_FLAG_NEXT_CTRL flag:

struct v4l2_queryctrl qctrl;

qctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL;
while (0 == ioctl (fd, VIDIOC_QUERYCTRL, &qctrl)) {
	/* ... */
	qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
}

The initial control ID is set to 0 ORed with the V4L2_CTRL_FLAG_NEXT_CTRL flag. The VIDIOC_QUERYCTRL ioctl will return the first control with a higher ID than the specified one. When no such controls are found an error is returned.

If you want to get all controls within a specific control class, then you can set the initial qctrl.id value to the control class and add an extra check to break out of the loop when a control of another control class is found:

qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL;
while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &qctrl)) {
	if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_MPEG)
		break;
		/* ... */
	qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
}

The 32-bit qctrl.id value is subdivided into three bit ranges: the top 4 bits are reserved for flags (e. g. V4L2_CTRL_FLAG_NEXT_CTRL) and are not actually part of the ID. The remaining 28 bits form the control ID, of which the most significant 12 bits define the control class and the least significant 16 bits identify the control within the control class. It is guaranteed that these last 16 bits are always non-zero for controls. The range of 0x1000 and up are reserved for driver-specific controls. The macro V4L2_CTRL_ID2CLASS(id) returns the control class ID based on a control ID.

If the driver does not support extended controls, then VIDIOC_QUERYCTRL will fail when used in combination with V4L2_CTRL_FLAG_NEXT_CTRL. In that case the old method of enumerating control should be used (see Example 1.8, “Enumerating all user controls”). But if it is supported, then it is guaranteed to enumerate over all controls, including driver-private controls.

It is possible to create control panels for a graphical user interface where the user can select the various controls. Basically you will have to iterate over all controls using the method described above. Each control class starts with a control of type V4L2_CTRL_TYPE_CTRL_CLASS. VIDIOC_QUERYCTRL will return the name of this control class which can be used as the title of a tab page within a control panel.

The flags field of struct v4l2_queryctrl also contains hints on the behavior of the control. See the VIDIOC_QUERYCTRL documentation for more details.

Below all controls within the Codec control class are described. First the generic controls, then controls specific for certain hardware.

Note: These controls are applicable to all codecs and not just MPEG. The defines are prefixed with V4L2_CID_MPEG/V4L2_MPEG as the controls were originally made for MPEG codecs and later extended to cover all encoding formats.

The Camera class includes controls for mechanical (or equivalent digital) features of a device such as controllable lenses or sensors.

The FM Transmitter (FM_TX) class includes controls for common features of FM transmissions capable devices. Currently this class includes parameters for audio compression, pilot tone generation, audio deviation limiter, RDS transmission and tuning power features.

For more details about RDS specification, refer to [IEC 62106] document, from CENELEC.

The V4L2 flash controls are intended to provide generic access to flash controller devices. Flash controller devices are typically used in digital cameras.

The interface can support both LED and xenon flash devices. As of writing this, there is no xenon flash driver using this interface.

The JPEG class includes controls for common features of JPEG encoders and decoders. Currently it includes features for codecs implementing progressive baseline DCT compression process with Huffman entrophy coding.

For more details about JPEG specification, refer to [ITU-T.81], [JFIF], [W3C JPEG JFIF].

The Image Source control class is intended for low-level control of image source devices such as image sensors. The devices feature an analogue to digital converter and a bus transmitter to transmit the image data out of the device.

The Image Source control class is intended for low-level control of image processing functions. Unlike V4L2_CID_IMAGE_SOURCE_CLASS, the controls in this class affect processing the image, and do not control capturing of it.

The Digital Video control class is intended to control receivers and transmitters for VGA, DVI (Digital Visual Interface), HDMI ([HDMI]) and DisplayPort ([DP]). These controls are generally expected to be private to the receiver or transmitter subdevice that implements them, so they are only exposed on the /dev/v4l-subdev* device node.

Note that these devices can have multiple input or output pads which are hooked up to e.g. HDMI connectors. Even though the subdevice will receive or transmit video from/to only one of those pads, the other pads can still be active when it comes to EDID (Extended Display Identification Data, [EDID]) and HDCP (High-bandwidth Digital Content Protection System, [HDCP]) processing, allowing the device to do the fairly slow EDID/HDCP handling in advance. This allows for quick switching between connectors.

These pads appear in several of the controls in this section as bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1, etc. The maximum value of the control is the set of valid pads.

The FM Receiver (FM_RX) class includes controls for common features of FM Reception capable devices.

The Detect class includes controls for common features of various motion or object detection capable devices.

The RF Tuner (RF_TUNER) class includes controls for common features of devices having RF tuner.

In this context, RF tuner is radio receiver circuit between antenna and demodulator. It receives radio frequency (RF) from the antenna and converts that received signal to lower intermediate frequency (IF) or baseband frequency (BB). Tuners that could do baseband output are often called Zero-IF tuners. Older tuners were typically simple PLL tuners inside a metal box, whilst newer ones are highly integrated chips without a metal box "silicon tuners". These controls are mostly applicable for new feature rich silicon tuners, just because older tuners does not have much adjustable features.

For more information about RF tuners see Tuner (radio) and RF front end from Wikipedia.