On Thu, May 24, 2012 at 2:12 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > 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 :) Sure... I will implement this proposal and send the patches :) > > Thanks & Regards, > > Hans -- Regards Halli -- 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
