Re: Discussion: How to deal with radio tuners which can tune to multiple bands
Hi, Just noticed the following on: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html#id2570531 This specification does not define radio output devices., iow no radio modulators, but we agreed upon making the band changes to the modulator too, and this makes sense because AFAIK we do support radio modulators. I hit this while working on adding support for the proposed API to v4l2-ctl, as I wanted to only print the band stuff for radio type devices, but the modulator struct has no type! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
On Sun May 27 2012 11:06:27 Hans de Goede wrote: Hi, Just noticed the following on: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html#id2570531 This specification does not define radio output devices., iow no radio modulators, but we agreed upon making the band changes to the modulator too, and this makes sense because AFAIK we do support radio modulators. I hit this while working on adding support for the proposed API to v4l2-ctl, as I wanted to only print the band stuff for radio type devices, but the modulator struct has no type! Regards, Hans Yeah, that section needs to be rewritten. We have no TV modulators at all. If a video/vbi node supports G/S_MODULATOR, then it is a TV modulator. If a radio node supports it, then it is a radio modulator. Even for g/s_freq and g/s_tuner the type field is now determined strictly by the type of the node. It is no longer possible to e.g. query the radio tuner from a video node. It used to be possible (as least in theory) in the past, but that was crazy. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
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. That also solves case 2. No need for an extra band in v4l2_frequency. This is IMHO a big problem, a GUI radio app will quite likely when it starts get all the current settings and display them without modifying any settings, so it needs a way to find out which band is active. 2) What if first a band aware radio app sets a non default band, and then a non band aware radio app comes along, it does a g_tuner on the default-band, using the lo / high freq-s to build its UI, then the users picks a frequency, and the app does a s_freq, and the result is a frequency outside of what the app thinks are the lo / high freq limits because a different band is active - not good. So I think we need to slightly modify the proposal, esp. to deal with 1), 2) is a corner case and not really all that important on its own IMHO. I suggest fixing 1) by not only adding a band field to v4l2_tuner, so that the different ranges for different bands can be queried, but also adding a band field to v4l2_frequency, so that the current active band can be reported by g_frequency. Once we make g_frequency report the active band, it makes sense to make s_frequency set the active band. I don't really like this. You run into the same weird situation with G_TUNER that I did (as that was one of my ideas as well) where you set band to e.g. the weather band and get back the corresponding frequency range, but the other fields like signal and rxsubchans still refer to the *current* band. That's confusing and not logical. We would then need no changes to s_tuner at all, it will still only have audmode as writeable setting and thus *not* set the active band. Effectively s_tuner would just completely ignore the passed in band. Keeping audmode as a global (not band specific) setting, and likewise g_tuner would always return CAP_STEREO stereo if some bands are stereo capable. This also nicely fixes 2). Since the reserved fields should be 0, so a s_frequency by a non band aware app will set the band to the default band. ### So here is a new / amended version of my band proposal: 1) Introduce the concept of bands, for radio tuners only 2) Define the following bands: #define V4L2_BAND_DEFAULT 0 #define V4L2_BAND_FM_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */ #define V4L2_BAND_FM_JAPAN 2 /* 76 MHz - 90 MHz */ #define V4L2_BAND_FM_RUSSIAN3 /* 65.8 MHz - 74 MHz */ #define V4L2_BAND_FM_WEATHER4 /* 162.4 MHz - 162.55 MHz */ #define V4L2_BAND_AM_MW 5 3) radio tuners indicate if they understand any of the non default bands with the following tuner caps: #define V4L2_TUNER_CAP_BAND_FM_EUROPE_US0x0001 #define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002 #define V4L2_TUNER_CAP_BAND_FM_RUSSIAN0x0004 #define V4L2_TUNER_CAP_BAND_FM_WEATHER0x0008 #define V4L2_TUNER_CAP_BAND_AM_MW 0x0010 A (radio) tuner should always support RADIO_BAND_DEFAULT, so there is no capability flag for this 4) Add a band field to v4l2_tuner, apps can query the exact rangelow and rangehigh values for a specific band by doing a g_tuner with band set to that band. All v4l2_tuner fields returned by g_tuner will be independent of the selected band (iow constant) except for: rangelow, rangehigh, rxsubchans and signal. 4a) rangelow, rangehigh will be the actual values for that band 4b) rxsubchans and signal will be 0 if a g_tuner is done for a band different then the active band, for the active band they will reflect the actual values. So I would do this as: 4) Add a band field to v4l2_tuner. Calling g_tuner will set this to the current band. You change it by calling s_tuner. CAP_STEREO and audmode are global properties, not per-band. CAP_STEREO really refers to whether the
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
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. This is IMHO a big problem, a GUI radio app will quite likely when it starts get all the current settings and display them without modifying any settings, so it needs a way to find out which band is active. 2) What if first a band aware radio app sets a non default band, and then a non band aware radio app comes along, it does a g_tuner on the default-band, using the lo / high freq-s to build its UI, then the users picks a frequency, and the app does a s_freq, and the result is a frequency outside of what the app thinks are the lo / high freq limits because a different band is active - not good. So I think we need to slightly modify the proposal, esp. to deal with 1), 2) is a corner case and not really all that important on its own IMHO. I suggest fixing 1) by not only adding a band field to v4l2_tuner, so that the different ranges for different bands can be queried, but also adding a band field to v4l2_frequency, so that the current active band can be reported by g_frequency. Once we make g_frequency report the active band, it makes sense to make s_frequency set the active band. I don't really like this. You run into the same weird situation with G_TUNER that I did (as that was one of my ideas as well) where you set band to e.g. the weather band and get back the corresponding frequency range, but the other fields like signal and rxsubchans still refer to the *current* band. That's confusing and not logical. Right, notice how my proposal says that signal and rxsubchans will always report 0 except when doing a g_tuner for the active band. This is not ideal, but IMHO better then not being able to do read-only enumeration of the bands. We would then need no changes to s_tuner at all, it will still only have audmode as writeable setting and thus *not* set the active band. Effectively s_tuner would just completely ignore the passed in band. Keeping audmode as a global (not band specific) setting, and likewise g_tuner would always return CAP_STEREO stereo if some bands are stereo capable. This also nicely fixes 2). Since the reserved fields should be 0, so a s_frequency by a non band aware app will set the band to the default band. ### So here is a new / amended version of my band proposal: 1) Introduce the concept of bands, for radio tuners only 2) Define the following bands: #define V4L2_BAND_DEFAULT 0 #define V4L2_BAND_FM_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */ #define V4L2_BAND_FM_JAPAN 2 /* 76 MHz - 90 MHz */ #define V4L2_BAND_FM_RUSSIAN3 /* 65.8 MHz - 74 MHz */ #define V4L2_BAND_FM_WEATHER4 /* 162.4 MHz - 162.55 MHz */ #define V4L2_BAND_AM_MW 5 3) radio tuners indicate if they understand any of the non default bands with the following tuner caps: #define V4L2_TUNER_CAP_BAND_FM_EUROPE_US0x0001 #define V4L2_TUNER_CAP_BAND_FM_JAPAN0x0002 #define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004 #define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008 #define V4L2_TUNER_CAP_BAND_AM_MW 0x0010 A (radio) tuner should always support RADIO_BAND_DEFAULT, so there is no capability flag for this 4) Add a band field to
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
On Wed 23 May 2012 20:29:20 Hans de Goede wrote: Hi, As discussed before 2 different use-cases have come up where we want some knowledge of there being different radio bands added to the v4l2 API. In Manjunatha Halli's case, if I understand things correctly, he wants to limit hw_freq_seek to a certain band, rather then the receiver happily trying to seek to frequencies which are not relevant for the use case in question. To that purpose his patch proposes adding a band field to the v4l2_hw_freq_seek struct, which can have one of the following values: FM_BAND_TYPE_ALL All Bands from 65.8 MHz till 108 Mhz or 162.55 MHz if weather band I suggested that this be renamed to FM_BAND_DEFAULT (and that the _TYPE part of the names will be removed). The default band is usually the widest band (often 76-108) that the hardware can handle. FM_BAND_TYPE_EUROPE_USEurope or US band(87.5 Mhz - 108 MHz) FM_BAND_TYPE_JAPANJapan band(76 MHz - 90 MHz) FM_BAND_TYPE_RUSSIAN OIRT or Russian band(65.8 MHz - 74 MHz) FM_BAND_TYPE_WEATHER Weather band(162.4 MHz - 162.55 MHz) In my case the problem is that the TEA5757 tuner can tune both AM and FM (but note at the same time, it is a single tuner): AM 530 - 1710 kHz FM 87.5 - 108 MHz In my case part of the problem is that the userspace UI for the tuner cannot simply depict the frequency range as one large slider. For FM devices having a slider going from 65.8 - 162.55 MHz is far from ideal, esp. as there is a large whole of nothing in the 108-162 Mhz making the non functional area of the sliders range larger then the functional area. For AM and FM capable devices representing the entire range (530 Khz - 162.55 Mhz) is not just not ideal it is simply unworkable! So we don't just want to limit the range a VIDIOC_S_HW_FREQ_SEEK can seek over, we also want to let user space know for manual tuning that we've several ranges, and allow it to query information such as min / max freq, stereo capable, etc. per range. As discussed with Hans V. this can best be done by extending struct v4l2_tuner with a band field. Our (Hans V. and me) first idea here was to let this field work like an index, where userspace can enumerate available bands by calling VIDIOC_G_TUNER, incrementing band each time until -EINVAL gets returned. Not quite. The available bands are signaled through the v4l2_tuner capabilities field, so the app will know which bands there are. So there is no need to increment the band. So that completes the intro, also known as setting the stage :) ### Taking the intersection between the 2 proposals and the 2 problems makes things interesting :) Dividing the VIDIOC_G_TUNER results into bands also makes sense for the FM case, at least in a 65.8 - 108 Mhz and a 162 Mhz band, to avoid having a not tunable gap in the range reported to userspace. But, allowing a EU citizen to tune below 87.5 is also not really useful, nor allowing a Japanese citizen to tune above the 90 Mhz, etc. So from presenting the user with a sensible UI pov, it makes sense to not use 2 bands with FM, but to expose all supported bands to userspace as they really are. This also makes sense from a demod pov, since FM demodulation for Japanese FM is different then for EU/US FM, so maybe the hardware needs to be poked to switch modes. Right. Note that some radio chip drivers already do this effectively by having a module parameter to select which band to use. So lets expose all the FM bands from Manjunatha Halli's proposal in VIDIOC_G_TUNER results. If we then go for the classic enumeration strategy where userspace can enumerate available bands by calling VIDIOC_G_TUNER, incrementing band each time until -EINVAL gets returned, we get another problem... How does user space know which band is which (other then checking min/max frequency which is ugly!) ? We could make the tuner name field different for each band, and let the app display a menu with tuner names for the user to select a band, but that is ugly too. Not only would doing something like that be ugly, it also makes it as good as impossible for userspace to automatically select the right band based on location. So doing the classic v4l2 enum trick where we increment band each time until we get -EINVAL is not a good idea IMHO. Luckily Manjunatha Halli's proposal already gives us a solution, we can define a fixed set of bands (adding SW/MW/LW bands for AM), and userspace can enumerate by trying a G_TUNER for all bands it is interested in. ### 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
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
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_DEFAULTEntire 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_MWMid Wave AM band, covered frequencies are tuner dependent 257 RADIO_BAND_AM_LWLong Wave AM band, covered frequencies are tuner dependent 258 RADIO_BAND_AM_SWShort 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
On Thu, May 24, 2012 at 2:12 PM, Hans de Goede hdego...@redhat.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Discussion: How to deal with radio tuners which can tune to multiple bands
Hi, As discussed before 2 different use-cases have come up where we want some knowledge of there being different radio bands added to the v4l2 API. In Manjunatha Halli's case, if I understand things correctly, he wants to limit hw_freq_seek to a certain band, rather then the receiver happily trying to seek to frequencies which are not relevant for the use case in question. To that purpose his patch proposes adding a band field to the v4l2_hw_freq_seek struct, which can have one of the following values: FM_BAND_TYPE_ALLAll Bands from 65.8 MHz till 108 Mhz or 162.55 MHz if weather band FM_BAND_TYPE_EUROPE_US Europe or US band(87.5 Mhz - 108 MHz) FM_BAND_TYPE_JAPAN Japan band(76 MHz - 90 MHz) FM_BAND_TYPE_RUSSIANOIRT or Russian band(65.8 MHz - 74 MHz) FM_BAND_TYPE_WEATHERWeather band(162.4 MHz - 162.55 MHz) In my case the problem is that the TEA5757 tuner can tune both AM and FM (but note at the same time, it is a single tuner): AM 530 - 1710 kHz FM 87.5 - 108 MHz In my case part of the problem is that the userspace UI for the tuner cannot simply depict the frequency range as one large slider. For FM devices having a slider going from 65.8 - 162.55 MHz is far from ideal, esp. as there is a large whole of nothing in the 108-162 Mhz making the non functional area of the sliders range larger then the functional area. For AM and FM capable devices representing the entire range (530 Khz - 162.55 Mhz) is not just not ideal it is simply unworkable! So we don't just want to limit the range a VIDIOC_S_HW_FREQ_SEEK can seek over, we also want to let user space know for manual tuning that we've several ranges, and allow it to query information such as min / max freq, stereo capable, etc. per range. As discussed with Hans V. this can best be done by extending struct v4l2_tuner with a band field. Our (Hans V. and me) first idea here was to let this field work like an index, where userspace can enumerate available bands by calling VIDIOC_G_TUNER, incrementing band each time until -EINVAL gets returned. So that completes the intro, also known as setting the stage :) ### Taking the intersection between the 2 proposals and the 2 problems makes things interesting :) Dividing the VIDIOC_G_TUNER results into bands also makes sense for the FM case, at least in a 65.8 - 108 Mhz and a 162 Mhz band, to avoid having a not tunable gap in the range reported to userspace. But, allowing a EU citizen to tune below 87.5 is also not really useful, nor allowing a Japanese citizen to tune above the 90 Mhz, etc. So from presenting the user with a sensible UI pov, it makes sense to not use 2 bands with FM, but to expose all supported bands to userspace as they really are. This also makes sense from a demod pov, since FM demodulation for Japanese FM is different then for EU/US FM, so maybe the hardware needs to be poked to switch modes. Note that some radio chip drivers already do this effectively by having a module parameter to select which band to use. So lets expose all the FM bands from Manjunatha Halli's proposal in VIDIOC_G_TUNER results. If we then go for the classic enumeration strategy where userspace can enumerate available bands by calling VIDIOC_G_TUNER, incrementing band each time until -EINVAL gets returned, we get another problem... How does user space know which band is which (other then checking min/max frequency which is ugly!) ? We could make the tuner name field different for each band, and let the app display a menu with tuner names for the user to select a band, but that is ugly too. Not only would doing something like that be ugly, it also makes it as good as impossible for userspace to automatically select the right band based on location. So doing the classic v4l2 enum trick where we increment band each time until we get -EINVAL is not a good idea IMHO. Luckily Manjunatha Halli's proposal already gives us a solution, we can define a fixed set of bands (adding SW/MW/LW bands for AM), and userspace can enumerate by trying a G_TUNER for all bands it is interested in. ### 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_DEFAULTEntire 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
Re: Discussion: How to deal with radio tuners which can tune to multiple bands
Hi, On 05/23/2012 09:24 PM, halli manjunatha wrote: On Wed, May 23, 2012 at 1:29 PM, Hans de Goedehdego...@redhat.com wrote: snip my super long proposal intro :) ### 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_DEFAULTEntire 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_MWMid Wave AM band, covered frequencies are tuner dependent 257 RADIO_BAND_AM_LWLong Wave AM band, covered frequencies are tuner dependent 258 RADIO_BAND_AM_SWShort Wave AM band, covered frequencies are tuner dependent First - Here driver will add the list of Band which it supports in the VIDEOC_G_TUNER capability flag We could do that, although then the indexes for the AM bands need to be lowered. I'm not sure if we should do this though. It will save a number of ioctl calls, but those are cheap (as long as they don't hit the hardware) and they are only done during enumeration by the app (iow not repeatedly) So we've a trade-off here between making it easier for the app (the app has to do less ioctls and can just test capability bits) and between being conservative with capability bits. I've a slight preference for the just let the app call g_tuner a number of times to find out about supported bands because we don't know what sort of bands we will add in the future and if we get too many bands we may run out of capability bits. With that said I'm not against the capability bits approach, just explaining my reasoning. If Hans V. says he prefers the capability bits too, I'm fine with going that way. *) 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. Second - User Application do VIDEOC_G_TUNER and checks the struct v4l2_tuner.capability for the list of bands supported by Driver. See above :) 5) Apps can select the active band by doing a VIDIOC_S_TUNER with the band field set to the desired band. Third - Here App sets the chip to the required band. Ack. 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. Fourth - As already chip is set to a band set_frequency for frequency within the activated band will work. But I think its better to report 'ERANGE' to the frequencies which are out of band limit. So that UI app also knows that set frequency failed and it will show the bar to the last frequency. The spec currently states that the behavior for s_freq is to set the frequency to the nearest supported frequency, rather then report an error, so we're stuck with that. Also note that the driver may also change the frequency even if it is inside the range, because the hardware may not be able to do the exact requested frequency. So any good written app should always do a g_freq after a s_freq and show the user what he actually got. 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. I agree. I think / hope that covers everything we need. Suggestions ? Comments ? Solution seems fine for me I'm happy to hear that! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
