Just a warning to avoid double work: I'll post a patch with all the needed changes tomorrow (or Monday at the latest). That will also include changes from my RFC on improving the hardware seek. Regards, Hans On Sat May 26 2012 20:38:52 Hans de Goede wrote: > Hi, > > On 05/26/2012 08:22 PM, Hans Verkuil wrote: > > On Sat May 26 2012 20:09:53 Hans de Goede wrote: > >> Hi, > >> > >> On 05/26/2012 06:40 PM, Hans Verkuil wrote: > >>> On Sat May 26 2012 18:02:34 Hans de Goede wrote: > >>>> Hi, > >>>> > >>>> On 05/24/2012 09:12 PM, Hans de Goede wrote: > >>>>> Hi, > >>>>> > >>>>> On 05/24/2012 05:00 PM, Hans Verkuil wrote: > >>>>>>> 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? > >>>>> > >>>> > >>>> So I've been working a bit on adding AM support to the tea575x driver using > >>>> the agreed upon API, some observations from this: > >>>> > >>>> 1) There is no way to get which band is currently active > >>> > >>> Huh? Didn't G_TUNER return the current band? That's how I interpreted the > >>> proposal. G_TUNER returns the available bands in capabilities and the current > >>> band and its frequency range. You want to find the frequency range of another > >>> band you call have to call S_TUNER first to select that other band, and then > >>> G_TUNER to discover its range. > >> > >> Ah, we misunderstood each other there, I thought G_TUNER would honor the band > >> passed in and return info on that band. > >> > >>> That also solves case 2. No need for an extra band in v4l2_frequency. > >> > >> Right, the downside to this is that there is no way to just enumerate things > >> without actually changing anything. It would be nice if for example v4l2-ctl > >> could lists all bands including ranges as a 100% read-only operation. > >> > >> Note I'm ok with the way you propose to handle things, just pointing out > >> one (obvious) shortcoming of doing things this way. I think it is a short coming > >> we can live with, but we should be aware of it. > > > > Well, the important thing is that you know what bands are supported, and you > > know because of the capabilities. > > I agree. > > > I don't really think you have to query the > > exact range of other than the current band: the band's name is already a good > > indication of what the range will be, you just don't know the exact boundaries > > until you switch to that band. Which I believe is perfectly reasonable. > > I agree, so lets go with your proposal / my original proposal as interpreted by > you :) > > 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
