Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 06/22/2012 06:15 PM, Mauro Carvalho Chehab wrote:
> Em 22-06-2012 11:07, Hans Verkuil escreveu:

<snip>

>>> Reusing G_TUNER/S_TUNER or not, the issue is that a bitfield parameter for
>>> frequency range is not actually able to express what are the supported
>>> ranges. As I said before, the tuner ranges can only be properly expressed
>>> by an array with:
>>> 	- range low/high;
>>> 	- modulation (AM, FM, ...);
>>> 	- sub-carriers (mono, stereo, lang1, lang2);
>>> 	- properties (RDS, seek caps, ...).
>>
>> Agreed.
>>
>> So, in my opinion we still need the band field, but instead of this being a
>> fixed band it is an index.
>>
>> In order to enumerate over all bands I propose a new ioctl:
>>
>> VIDIOC_ENUM_TUNER_BAND
>>
>> with struct:
>>
>> struct v4l2_tuner_band {
>> 	__u32 tuner;
>> 	__u32 index;
>> 	char name[32];
>> 	__u32 capability;	/* The same as in v4l2_tuner */
>> 	__u32 rangelow;
>> 	__u32 rangehigh;
>> 	__u32 reserved[7];
>> };
>>
>> It enumerates the supported bands by the tuner, each with a human readable name,
>> frequency range and capabilities.
>>
>> If you change the band using S_TUNER, then G_TUNER will return the frequency range
>> and capabilities from the corresponding v4l2_tuner_band struct.
>>
>> The only capability that needs to be added is one that tells the application that
>> the tuner has the capability to do band enumeration (V4L2_TUNER_CAP_HAS_BANDS or
>> something).
>>
>> I am not 100% certain about the name field: it is very nice for apps, but we do
>> need some guidelines here.
>>
>> A similar struct would be needed for modulators if we ever need to add support for
>> modulators with multiple bands.
>>
>> We could perhaps rename v4l2_tuner_band to just v4l2_band to make it tuner/modulator
>> agnostic.

I've not replied before because I've been thinking about Hans V's proposal for a bit,
I've come to the conclusion that Hans V's proposal is better, because it avoids a
discrepancy in how tuners work between tv and radio, which is something which worried
me about my own proposal. Hans V's proposal also has the benefit that it will work fine
for tv-tuners too, so if we ever need bands for tv tuners we can use the *same* API.

> The above proposal would be great if we were starting to write the radio API today, but
> your proposal is not backward compatible with the status quo.

Huh? Hans V. is proposing adding a band field to the tuner struct (using one of the
reserved fields) and adding a new ioctl to enumerate bands. Old apps will have that field
set to 0 on a S_TUNER, selecting band 0, and G_TUNER will give info on the current band,
where-as S/G_FREQ will be unmodified (they will work on the current band). I don't see how
this breaks current apps...

Anyways both proposals seem workable to me, although I prefer Hans V.'s one. Lets just pick
one and get on with this.

Regards,

Hans




>
> Regards,
> Mauro
>