Hi all,

The support in drivers for the V4L2 control API is currently very chaotic.
Few if any drivers support the API correctly. Especially the support for the
new extended controls is very much hit and miss.

Combine that with the requirements for the upcoming embedded devices that
will want to use controls much more actively and you end up with a big mess.

I've wanted to fix this for a long time and last week I finally had the time.

The new framework works like a charm and massively reduces the complexity in
drivers when it comes to control handling. And just as importantly, any driver
that uses it is fully compliant to the V4L spec. Something that application
writers will appreciate.

I have converted the cx2341x.c module and tested it with ivtv since that is
by far the most complex example of control handling. The new code is much,
much cleaner.

The documentation is available here:


The tree with my code is available here:


What is very nice is that controls are now exposed in sysfs:

$ l /sys/class/video4linux/video0/controls/
audio_crc                    chroma_gain                   
spatial_chroma_filter_type  video_bitrate_mode
audio_emphasis               contrast                      spatial_filter       
audio_encoding               hue                           spatial_filter_mode  
audio_layer_ii_bitrate       insert_navigation_packets     
spatial_luma_filter_type    video_gop_size
audio_mute                   median_chroma_filter_maximum  stream_type          
audio_sampling_frequency     median_chroma_filter_minimum  stream_vbi_format    
audio_stereo_mode            median_filter_type            temporal_filter      
audio_stereo_mode_extension  median_luma_filter_maximum    temporal_filter_mode 
balance                      median_luma_filter_minimum    video_aspect         
brightness                   mute                          video_b_frames
chroma_agc                   saturation                    video_bitrate

Writing and reading controls from sysfs is fully transparent and requires
no support from the driver.

Other highlights:

  S_EXT_CTRLS, G_EXT_CTRLS or TRY_EXT_CTRLS in either bridge drivers
  or subdevs. New wrapper functions are provided that can just be plugged in.
- When subdevices are added their controls can be automatically merged
  with the bridge driver's controls.
- Most drivers just need to implement s_ctrl to set the controls.
  The framework handles the locking and tries to be as 'atomic' as possible.
- Ready for the subdev device nodes: the same mechanism applies to subdevs
  and their device nodes as well. Sub-device drivers can make controls
  local, preventing them from being merged with bridge drivers.
- Takes care of backwards compatibility handling of VIDIOC_S_CTRL and
  VIDIOC_G_CTRL. Handling of V4L2_CID_PRIVATE_BASE is fully transparent.

There is one thing though that needs to be proven first: can uvc use it as
well? The UVC driver is unusual in that it can dynamically add controls.

The framework should be able to handle this, but it would be great if Laurent
can take a good look at it.

BTW, I've also completely overhauled the vivi driver. I've used it to test
the control handling, but I took the opportunity to do a big clean up of that
driver. The combination of vivi + qv4l2 made testing of the more unusual
integer64 and string control types much easier.



Hans Verkuil - video4linux developer - sponsored by TANDBERG
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to