Hi,
On 05/24/2012 05:00 PM, Hans Verkuil wrote:
On Wed 23 May 2012 20:29:20 Hans de Goede wrote:
<snip>
###
So given all of the above I would like to propose the following:
1) Add a "band" field to struct v4l2_tuner, and a capability
indicating if the driver understands / uses this field
2) This field is only valid for radio tuners, for tv tuners it
should always be 0 (as it was sofar as it is reserved atm)
3) This field can have a number of fixed values, for now we have:
0 RADIO_BAND_DEFAULT Entire FM band supported by the tuner, or "default"
band if different bands require switching the tuner to
a different mode, or entire AM band supported by the
tuner for AM only tuners.
1 RADIO_BAND_FM_EUROPE_US Europe or US band(87.5 Mhz - 108 MHz) *
2 RADIO_BAND_FM_JAPAN Japan band(76 MHz - 90 MHz) *
3 RADIO_BAND_FM_RUSSIAN OIRT or Russian band(65.8 MHz - 74 MHz) *
4 RADIO_BAND_FM_WEATHER Weather band(162.4 MHz - 162.55 MHz) *
256 RADIO_BAND_AM_MW Mid Wave AM band, covered frequencies are tuner dependent
257 RADIO_BAND_AM_LW Long Wave AM band, covered frequencies are tuner dependent
258 RADIO_BAND_AM_SW Short Wave AM band, covered frequencies are tuner dependent
I wouldn't add LW and SW as long as we don't have hardware that supports it.
Ok.
*) Reported (and available) frequency range might be different based on hardware
capabilities
Notice how 0, which the current reserved field should be set to for old apps,
should always cover as much of FM as possible, or AM for AM only tuners, to
preserve functionality for old non band aware v4l2 radio apps.
A (radio) tuner should always support RADIO_BAND_DEFAULT
4) Apps can find out which bands are supported by doing a VIDIOC_G_TUNER
with band set to the desired value. If the passed band is not available
-EINVAL will be returned.
I would propose to add capability flags signaling the presence of each bands.
There are 24 bits available, and the number of bands is very limited. I see
no problem here.
This way an application doesn't need to cycle through all possible bands, but
it can select one immediately.
Ok so that is 2 votes for using capability bits, so lets go with that solution
rather then requiring the app to do a g_tuner with all possible bands to
find out which bands are available.
5) Apps can select the active band by doing a VIDIOC_S_TUNER with the band
field set to the desired band.
OK. Note that the current frequency will have to be clamped to the new band.
6) Doing a VIDIOC_S_FREQUENCY with a frequency which falls outside of the
current band will *not* result in an automatic band switch, instead the
passed frequency will be clamped to fit into the current band.
OK.
7) Doing a VIDIOC_S_HW_FREQ_SEEK will seek in the currently active band,
this matches existing behavior where the seek starts at the currently
active frequency.
Sounds good. Then we don't need to add a band field here as was in Halli's
first proposal.
I think / hope that covers everything we need. Suggestions ? Comments ?
Modulators. v4l2_modulator needs a band field as well. The capabilities are
already shared with v4l2_tuner, so that doesn't need to change.
Ah, yes modulators, good one, ack.
Manjunatha, since the final proposal is close to yours, and you already have
a patch for that including all the necessary documentation updates, can I ask
you to update your patch to implement this proposal?
I must admit another reason is that I don't really have a lot of time to work
on this atm, and it would be good to get this finalized soon, so that we will
be ready well in advance of the 3.6 cycle start :)
Thanks & Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
