RFC: new V4L control framework

RFC: new V4L control framework

[Hans Verkuil]

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:

http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt

The tree with my code is available here:

http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/

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              video_encoding
audio_encoding               hue                           spatial_filter_mode         video_gop_closure
audio_layer_ii_bitrate       insert_navigation_packets     spatial_luma_filter_type    video_gop_size
audio_mute                   median_chroma_filter_maximum  stream_type                 video_mute
audio_sampling_frequency     median_chroma_filter_minimum  stream_vbi_format           video_mute_yuv
audio_stereo_mode            median_filter_type            temporal_filter             video_peak_bitrate
audio_stereo_mode_extension  median_luma_filter_maximum    temporal_filter_mode        video_temporal_decimation
balance                      median_luma_filter_minimum    video_aspect                volume
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:

- No need to implement VIDIOC_QUERYCTRL, QUERYMENU, S_CTRL, G_CTRL,
  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.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: new V4L control framework

[Andy Walls]

On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
> 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:
> 
> http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt

>From reading the Documentation.  Things look very much improved.

However:

"When a subdevice is registered with a bridge driver and the ctrl_handler
fields of both v4l2_subdev and v4l2_device are set, then the controls of the
subdev will become automatically available in the bridge driver as well. If
the subdev driver contains controls that already exist in the bridge driver,
then those will be skipped (so a bridge driver can always override a subdev
control)."

I think I have 2 cases where that is undesriable:

1. cx18 volume control: av_core subdev has a volume control (which the
bridge driver currently reports as it's volume control) and the cs5435
subdev has a volume control.

I'd really need them *both* to be controllable by the user.  I'd also
like them to appear as a single (bridge driver) volume control to the
user - as that is what a user would expect.


2. ivtv volume control for an AverTV M113 card.  The CX2584x chip is
normally the volume control.  However, due to some poor baseband audio
noise performance on this card, it is advantagous to adjust the volume
control on the WM8739 subdev that feeds I2S audio into the CX2584x chip.
Here, I would like a secondary volume control, not an override of the
primary.

(Here's my old hack:
	http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 )


Maybe there's a way to use the control clusters to handle some of this.
I'm a bit too tired to figure it all out at the moment.

Regards,
Andy

Re: RFC: new V4L control framework

[Hans Verkuil]

On Monday 05 April 2010 04:58:02 Andy Walls wrote:
> On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
> > 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:
> > 
> > http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt
> 
> >From reading the Documentation.  Things look very much improved.
> 
> However:
> 
> "When a subdevice is registered with a bridge driver and the ctrl_handler
> fields of both v4l2_subdev and v4l2_device are set, then the controls of the
> subdev will become automatically available in the bridge driver as well. If
> the subdev driver contains controls that already exist in the bridge driver,
> then those will be skipped (so a bridge driver can always override a subdev
> control)."
> 
> I think I have 2 cases where that is undesriable:
> 
> 1. cx18 volume control: av_core subdev has a volume control (which the
> bridge driver currently reports as it's volume control) and the cs5435
> subdev has a volume control.
> 
> I'd really need them *both* to be controllable by the user.  I'd also
> like them to appear as a single (bridge driver) volume control to the
> user - as that is what a user would expect.

So the bridge driver implements the volume control, but the bridge's s_ctrl
operation will in turn control the subdev's volume implementation, right?
That's no problem. I do need to add a few utility functions to make this
easy, though. I realized that I need that anyway when I worked on converting
bttv yesterday.

Of course, once we can create device nodes for sub-devices, then the controls
of the cs5435 will show up there as well so the user can have direct access
to that volume control. But that's not really for applications, though.

> 2. ivtv volume control for an AverTV M113 card.  The CX2584x chip is
> normally the volume control.  However, due to some poor baseband audio
> noise performance on this card, it is advantagous to adjust the volume
> control on the WM8739 subdev that feeds I2S audio into the CX2584x chip.
> Here, I would like a secondary volume control, not an override of the
> primary.
> 
> (Here's my old hack:
> 	http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 )
> 
> 
> Maybe there's a way to use the control clusters to handle some of this.
> I'm a bit too tired to figure it all out at the moment.

Interesting use case. I have several ideas, but I need some time to think
about it a bit more. Basically you want to be able to merge-and-remap
controls. Or perhaps even allow some sort of control hierarchy.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: new V4L control framework

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> On Monday 05 April 2010 04:58:02 Andy Walls wrote:
>> On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
>>> 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:
>>>
>>> http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt
>> >From reading the Documentation.  Things look very much improved.
>>
>> However:
>>
>> "When a subdevice is registered with a bridge driver and the ctrl_handler
>> fields of both v4l2_subdev and v4l2_device are set, then the controls of the
>> subdev will become automatically available in the bridge driver as well. If
>> the subdev driver contains controls that already exist in the bridge driver,
>> then those will be skipped (so a bridge driver can always override a subdev
>> control)."
>>
>> I think I have 2 cases where that is undesriable:
>>
>> 1. cx18 volume control: av_core subdev has a volume control (which the
>> bridge driver currently reports as it's volume control) and the cs5435
>> subdev has a volume control.
>>
>> I'd really need them *both* to be controllable by the user.  I'd also
>> like them to appear as a single (bridge driver) volume control to the
>> user - as that is what a user would expect.
> 
> So the bridge driver implements the volume control, but the bridge's s_ctrl
> operation will in turn control the subdev's volume implementation, right?
> That's no problem. I do need to add a few utility functions to make this
> easy, though. I realized that I need that anyway when I worked on converting
> bttv yesterday.

I think this is a common case for some audio controls: in general, bridge drivers
have a set of volume adjustments, but, depending on how the audio is connected
(I2S, analog input, analog directly wired to an output pin or to an  AC97 chip), 
the bridge volume may or may not work, and you may need to map the sub-device
volume control.

Em28xx is probably an interesting case, since it is designed to work with an
AC97 audio chip, but it also supports I2S. Older designs were shipped with a
msp34xx audio chip, while newer designs come with an Empia202 or with other
AC97 chips. Depending on the specific hardware, the volume should be controlled
into either one of the devices.
> 
> Of course, once we can create device nodes for sub-devices, then the controls
> of the cs5435 will show up there as well so the user can have direct access
> to that volume control. But that's not really for applications, though.

I don't think  that a "technical" volume control  per subdevice would make sense,
 except on a very few cases, where you might need to deal with more than one volume
control, to avoid distortions. On most cases, you need to use just one of
the controls.
>> 2. ivtv volume control for an AverTV M113 card.  The CX2584x chip is
>> normally the volume control.  However, due to some poor baseband audio
>> noise performance on this card, it is advantagous to adjust the volume
>> control on the WM8739 subdev that feeds I2S audio into the CX2584x chip.
>> Here, I would like a secondary volume control, not an override of the
>> primary.
>>
>> (Here's my old hack:
>> 	http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 )
>>
>>
>> Maybe there's a way to use the control clusters to handle some of this.
>> I'm a bit too tired to figure it all out at the moment.
> 
> Interesting use case. I have several ideas, but I need some time to think
> about it a bit more. Basically you want to be able to merge-and-remap
> controls. Or perhaps even allow some sort of control hierarchy.

I'd say that the bridge driver should be able to disable the visibility of
a control from userspace, while keeping being able of accessing it for its
own control implementations.

-- 

Cheers,
Mauro

Re: RFC: new V4L control framework

[Devin Heitmueller]

On Sun, Apr 4, 2010 at 10:58 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> I think I have 2 cases where that is undesriable:
>
> 1. cx18 volume control: av_core subdev has a volume control (which the
> bridge driver currently reports as it's volume control) and the cs5435
> subdev has a volume control.
>
> I'd really need them *both* to be controllable by the user.  I'd also
> like them to appear as a single (bridge driver) volume control to the
> user - as that is what a user would expect.

For what it's worth, I've got a similar problem I am going to need to
deal with.  I'm working on a hardware design which has a volume
control built into the audio processor, as well as a separate i2c
controllable volume control (a cs3308).

So I am indeed *very* interested in seeing the best approach for
dealing with this issue.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: RFC: new V4L control framework

[Hans Verkuil]

On Monday 05 April 2010 17:41:47 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> > On Monday 05 April 2010 04:58:02 Andy Walls wrote:
> >> On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
> >>> 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:
> >>>
> >>> http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt
> >> >From reading the Documentation.  Things look very much improved.
> >>
> >> However:
> >>
> >> "When a subdevice is registered with a bridge driver and the ctrl_handler
> >> fields of both v4l2_subdev and v4l2_device are set, then the controls of the
> >> subdev will become automatically available in the bridge driver as well. If
> >> the subdev driver contains controls that already exist in the bridge driver,
> >> then those will be skipped (so a bridge driver can always override a subdev
> >> control)."
> >>
> >> I think I have 2 cases where that is undesriable:
> >>
> >> 1. cx18 volume control: av_core subdev has a volume control (which the
> >> bridge driver currently reports as it's volume control) and the cs5435
> >> subdev has a volume control.
> >>
> >> I'd really need them *both* to be controllable by the user.  I'd also
> >> like them to appear as a single (bridge driver) volume control to the
> >> user - as that is what a user would expect.
> > 
> > So the bridge driver implements the volume control, but the bridge's s_ctrl
> > operation will in turn control the subdev's volume implementation, right?
> > That's no problem. I do need to add a few utility functions to make this
> > easy, though. I realized that I need that anyway when I worked on converting
> > bttv yesterday.
> 
> I think this is a common case for some audio controls: in general, bridge drivers
> have a set of volume adjustments, but, depending on how the audio is connected
> (I2S, analog input, analog directly wired to an output pin or to an  AC97 chip), 
> the bridge volume may or may not work, and you may need to map the sub-device
> volume control.
> 
> Em28xx is probably an interesting case, since it is designed to work with an
> AC97 audio chip, but it also supports I2S. Older designs were shipped with a
> msp34xx audio chip, while newer designs come with an Empia202 or with other
> AC97 chips. Depending on the specific hardware, the volume should be controlled
> into either one of the devices.

There are a few possibilities:

1) The bridge controls the volume. Easy, just make a bridge volume control and
that will hide any subdev volume controls you might have.

2) The subdev handles the volume. Easy again, just don't make a bridge volume
control. I am not sure whether I should make some code to remove a control.
Right now you can only add, not remove, which makes the framework a lot easier.
Some sort of removal scheme could be made, but it would be more like hiding
controls than actually removing it (as that would make pointer management so
much harder).

3) The bridge controls the volume, but needs to cooperate with the subdev's
volume control. Fairly easy: make a bridge volume control, get a pointer to
the subdev's volume control and let the volume control code of the bridge
use that pointer to manipulate the volume of the subdev. Note that the bridge
has to know how that control works. The min/max/step values for such a control
may not match those of the bridge.

4) The user needs to see both volume controls. While this is possible once
subdevs have their own device nodes, this is really meant for embedded systems
and not for use with consumer hardware. 

One option is to make a new set of control IDs to control the secondary audio
controls. Then all I need to do in the control framework is to make something
like:

v4l2_ctrl_add_ctrl_remap(struct v4l2_ctrl_handler *hdl,
			 struct v4l2_ctrl_info *cinfo,
			 u32 new_id);

However, that requires new control IDs (and who knows for what other controls
we need to do this as well in the future) and a lot of manual work in the
driver. Also, they won't be visible in applications unless those applications
are recompiled with the new V4L2_CID_LASTP1 value (or unless they use the new
FLAG_NEXT_CTRL).

Another option would be to set aside a range of IDs at the end of each control
class that could be used as a 'remap' area.

For example: the IDs for user class controls go from 0x980000-0x98ffff. Of
which anything >= 0x981000 is a private control (i.e. specific to a driver).
We could set aside 0x98f000-0x98ffff for remapped controls.

So if you want to make a subdev's volume control available as a secondary
control you can do something like this:

v4l2_ctrl_add_ctrl_remap(struct v4l2_ctrl_handler *hdl,
			 struct v4l2_ctrl_info *cinfo,
			 const char *fmt);

The framework will pick a new ID from the remap range and add this control
with the name created using snprintf(fmt, sz, cinfo->name). Since this control
is remapped as a private control it will be seen by old applications as well
since they just iterate from V4L2_CID_PRIVATE_BASE, and the framework handles
that transparently.

It is even possible to do this for all controls from a subdev, e.g.:

v4l2_ctrl_add_handler_remap(struct v4l2_ctrl_handler *hdl,
			    struct v4l2_ctrl_handler *add,
			    const char *fmt);

Every control in 'add' that already exists in 'hdl' would then be remapped
and a new name is generated.

> > Of course, once we can create device nodes for sub-devices, then the controls
> > of the cs5435 will show up there as well so the user can have direct access
> > to that volume control. But that's not really for applications, though.
> 
> I don't think  that a "technical" volume control  per subdevice would make sense,
>  except on a very few cases, where you might need to deal with more than one volume
> control, to avoid distortions. On most cases, you need to use just one of
> the controls.

I agree.

> >> 2. ivtv volume control for an AverTV M113 card.  The CX2584x chip is
> >> normally the volume control.  However, due to some poor baseband audio
> >> noise performance on this card, it is advantagous to adjust the volume
> >> control on the WM8739 subdev that feeds I2S audio into the CX2584x chip.
> >> Here, I would like a secondary volume control, not an override of the
> >> primary.
> >>
> >> (Here's my old hack:
> >> 	http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 )
> >>
> >>
> >> Maybe there's a way to use the control clusters to handle some of this.
> >> I'm a bit too tired to figure it all out at the moment.
> > 
> > Interesting use case. I have several ideas, but I need some time to think
> > about it a bit more. Basically you want to be able to merge-and-remap
> > controls. Or perhaps even allow some sort of control hierarchy.
> 
> I'd say that the bridge driver should be able to disable the visibility of
> a control from userspace, while keeping being able of accessing it for its
> own control implementations.

Sure, that's already possible since that is true for 95% of all use cases.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: new V4L control framework

[Hans Verkuil]

On Monday 05 April 2010 20:11:13 Hans Verkuil wrote:
> Another option would be to set aside a range of IDs at the end of each control
> class that could be used as a 'remap' area.
> 
> For example: the IDs for user class controls go from 0x980000-0x98ffff. Of
> which anything >= 0x981000 is a private control (i.e. specific to a driver).
> We could set aside 0x98f000-0x98ffff for remapped controls.
> 
> So if you want to make a subdev's volume control available as a secondary
> control you can do something like this:
> 
> v4l2_ctrl_add_ctrl_remap(struct v4l2_ctrl_handler *hdl,
> 			 struct v4l2_ctrl_info *cinfo,
> 			 const char *fmt);
> 
> The framework will pick a new ID from the remap range and add this control
> with the name created using snprintf(fmt, sz, cinfo->name). Since this control
> is remapped as a private control it will be seen by old applications as well
> since they just iterate from V4L2_CID_PRIVATE_BASE, and the framework handles
> that transparently.
> 
> It is even possible to do this for all controls from a subdev, e.g.:
> 
> v4l2_ctrl_add_handler_remap(struct v4l2_ctrl_handler *hdl,
> 			    struct v4l2_ctrl_handler *add,
> 			    const char *fmt);
> 
> Every control in 'add' that already exists in 'hdl' would then be remapped
> and a new name is generated.

I implemented this scheme in this tree:

http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw-remap/

I also hacked vivi to use this. After creating a second handler with volume,
mute and saturation controls I added this line to merge the two:

v4l2_ctrl_add_handler_remap(&dev->hdl, &dev->hdl2, "Secondary %s");

The end result is this:

$ v4l2-ctl --list-ctrls

User Controls

                     brightness (int)  : min=0 max=255 step=1 default=127 value=127 flags=slider
                       contrast (int)  : min=0 max=255 step=1 default=16 value=16 flags=slider
                     saturation (int)  : min=0 max=255 step=1 default=127 value=127 flags=slider
                            hue (int)  : min=-128 max=127 step=1 default=0 value=0 flags=slider
                         volume (int)  : min=0 max=255 step=1 default=200 value=200 flags=slider
                           mute (bool) : default=1 value=1
           integer_test_control (int)  : min=-2147483648 max=2147483647 step=1 default=0 value=0
              toggle_text_color (bool) : default=0 value=0
                       press_me (btn)  : flags=write-only
              menu_test_control (menu) : min=0 max=5 default=1 value=1
         integer64_test_control (int64): value=0
            string_test_control (str)  : min=0 max=100 step=2 value=''
               secondary_volume (int)  : min=0 max=128 step=1 default=20 value=20 flags=slider
           secondary_saturation (int)  : min=100 max=200 step=1 default=150 value=150 flags=slider

So mute was added unchanged while volume and saturation were remapped automatically.
And they showed up in xawtv as well.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: new V4L control framework

[Laurent Pinchart]

Hi Hans,

On Sunday 04 April 2010 17:41:51 Hans Verkuil wrote:
> 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.

Thanks for working on this.

[snip]

> 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.

I really wish I could do it now, but I won't have time to work on this before 
two weeks. I'm sorry about that.

-- 
Regards,

Laurent Pinchart

Re: RFC: new V4L control framework

[Andy Walls]

On Mon, 2010-04-05 at 11:25 +0200, Hans Verkuil wrote:
> On Monday 05 April 2010 04:58:02 Andy Walls wrote:
> > On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:

> > 1. cx18 volume control: av_core subdev has a volume control (which the
> > bridge driver currently reports as it's volume control) and the cs5435
> > subdev has a volume control.
> > 
> > I'd really need them *both* to be controllable by the user.  I'd also
> > like them to appear as a single (bridge driver) volume control to the
> > user - as that is what a user would expect.
> 
> So the bridge driver implements the volume control, but the bridge's s_ctrl
> operation will in turn control the subdev's volume implementation, right?

Yes, I think we're saying the same thing.

The bridge only has one analog audio capture going on at a time and that
volume is what needs to be controlled with the bridge *driver's* s_ctrl.
The actual implementation of volume control for analog audio capture is
performed by different subdevs depending on the input source: av_core
subdev for tuner audio, or cs5345 subdev for line-in audio.


> That's no problem. I do need to add a few utility functions to make this
> easy, though. I realized that I need that anyway when I worked on converting
> bttv yesterday.

Good. :)

> Of course, once we can create device nodes for sub-devices, then the controls
> of the cs5435 will show up there as well so the user can have direct access
> to that volume control. But that's not really for applications, though.

That's convenient.  But yes you are correct.  It is not a control one
would expect an end user app to find and use.


> > 2. ivtv volume control for an AverTV M113 card.  The CX2584x chip is
> > normally the volume control.  However, due to some poor baseband audio
> > noise performance on this card, it is advantagous to adjust the volume
> > control on the WM8739 subdev that feeds I2S audio into the CX2584x chip.
> > Here, I would like a secondary volume control, not an override of the
> > primary.
> > 
> > (Here's my old hack:
> > 	http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 )
> > 
> > 
> > Maybe there's a way to use the control clusters to handle some of this.
> > I'm a bit too tired to figure it all out at the moment.
> 
> Interesting use case. I have several ideas, but I need some time to think
> about it a bit more. Basically you want to be able to merge-and-remap
> controls. Or perhaps even allow some sort of control hierarchy.

Something.  Maybe worst case the user will just have to knwo about the
subdev device node specific volume control and fix it with a start-up
script or module post-install script.

The ideas is really just to crank up the baseband analog audio gain in
as early a stage as possible to improve the noise figure.
http://en.wikipedia.org/wiki/Friis_formulas_for_noise

The WM8739 and CX25841(!) are cascaded on this board, so both sliders
could be active at once.  However, I suspect the CX25841 volume should
be fixed at something less than 0 dB, and the primary volume control
remapped to the WM8739 when using line-in.

Regards,
Andy

RE: new V4L control framework

[Pawel Osciak]

Hi Hans,

>Hans Verkuil wrote:

>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.

This is a bit off-topic, but I feel that any clean-up of vivi would more than
welcome. I use it for testing many different things as well. It would be great
if you could release those cleanup patches separately (without control-related
code)... Please let me know if you'd be planning to do something like that
in the (near) future. Thanks!


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center