Re: RFC: V4L2 API and radio devices with multiple tuners
On 22.05.2012 19:26, Rémi Denis-Courmont wrote: Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. OK, then I was misunderstanding it. Unfortunately I have no enough V4L2 API experience to comment that :i regards Antti -- http://palosaari.fi/ -- 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: RFC: V4L2 API and radio devices with multiple tuners
On Tue May 22 2012 22:45:44 Hans de Goede wrote: > Hi, > > On 05/22/2012 06:26 PM, Rémi Denis-Courmont wrote: > > Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : > >> On 19.05.2012 21:20, Hans de Goede wrote: > >>> Currently the V4L2 API does not allow for radio devices with more then 1 > >>> tuner, > >>> which is a bit of a historical oversight, since many radio devices have 2 > >>> tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 > >>> tuner > >>> really does not work well, as they have 2 completely separate frequency > >>> bands > >>> they handle, as well as different properties (the FM part usually is > >>> stereo capable, the AM part is not). > >>> > >>> It is important to realize here that usually the AM/FM tuners are part > >>> of 1 chip, and often have only 1 frequency register which is used in > >>> both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, > >>> and from a V4L2 API pov these modes are best modeled as 2 tuners. > >>> This is at least true for the radio-cadet card and the tea575x, > >>> which are the only 2 AM capable radio devices we currently know about. > >> > >> For DVB API we changed just opposite direction - from multi-frontend to > >> single-frontend. I think one device per one standard is good choice. > > > > If I understand Hans correctly, he suggests to use two tuners on a *single* > > radio device node, much like a single video device nodes can have multiple > > video inputs. So I think you agree with Hans, and so do I. > > Correct, although the plan has changed in the mean time to model the 1 tuner > as 1 tuner, and extend the v4l2 tuner API to deal with a tuner which can > tune multiple bands. Which seems the best way forward :) FYI: the ADS Cadet board is also tea5757 based (no surprise there). I've put up a picture of the board here: http://hverkuil.home.xs4all.nl/ADS%20Cadet%20RDX-1187.jpg 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: RFC: V4L2 API and radio devices with multiple tuners
Hi, On 05/22/2012 06:26 PM, Rémi Denis-Courmont wrote: Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. Correct, although the plan has changed in the mean time to model the 1 tuner as 1 tuner, and extend the v4l2 tuner API to deal with a tuner which can tune multiple bands. Which seems the best way forward :) 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: RFC: V4L2 API and radio devices with multiple tuners
Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : > On 19.05.2012 21:20, Hans de Goede wrote: > > Currently the V4L2 API does not allow for radio devices with more then 1 > > tuner, > > which is a bit of a historical oversight, since many radio devices have 2 > > tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 > > tuner > > really does not work well, as they have 2 completely separate frequency > > bands > > they handle, as well as different properties (the FM part usually is > > stereo capable, the AM part is not). > > > > It is important to realize here that usually the AM/FM tuners are part > > of 1 chip, and often have only 1 frequency register which is used in > > both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, > > and from a V4L2 API pov these modes are best modeled as 2 tuners. > > This is at least true for the radio-cadet card and the tea575x, > > which are the only 2 AM capable radio devices we currently know about. > > For DVB API we changed just opposite direction - from multi-frontend to > single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: RFC: V4L2 API and radio devices with multiple tuners
I propose that once I have received my radio-cadet card and I have had some time to test it that we talk it over on irc. It seems we are close to a result. BTW, multiple tuners for a radio device should definitely be possible and we do need to clarify the spec in that respect. There isn't actually any board with multiple tuners, although the Hauppauge PVR-500 (ivtv based) comes close as it has separate TV and radio tuners instead of the usual 'one tuner fits all' approach. Regards, Hans On Sun May 20 2012 13:50:52 Hans de Goede wrote: > Hi, > > On 05/20/2012 12:23 PM, Hans Verkuil wrote: > > Hi Hans, > > > > I'm CC-ing Manjunatha Halli as well as due to his work on adding support > > for the weather band: > > > > http://www.spinics.net/lists/kernel/msg1340986.html > > > > The question is whether the weather band and the AM band should be treated > > the same. The wl128x will implement the weather band as part of the single > > tuner, the cadet currently implements the AM band as a separate tuner. > > > > Given the fact that the wl128x and the radioSHARK both have only one > > physical tuner (and that's almost certainly the case for the cadet radio > > as well) I am not so sure whether we should handle this as two tuners. The > > approach taken for the wl128x seems at first glance a better solution. > > > > However, when I have my cadet card I'd like to experiment with it first and > > see what the best approach is to solve this problem. > > I agree that since it is a single tuner, it makes sense to treat is as such :) > The problem is that it has very distinctive properties depending on whether > it is operating in AM or FM mode, ie the bands are: 87.5 - 108 Mhz and > 530 - 1710 kHz. Now we can just represent that as the tuner being capable to > tune from 530 kHz - 108 Mhz but that won't result in a good UI experience > in userspace at all. > > I still agree that since it is a single tuner, it makes sense to treat is as > such, > and since there are no overlapping frequencies, treating it as one tuner is > not a problem for most of the API, the only trouble some part really is > G_TUNER, since it cannot deal with having multiple frequency ranges, nor > with different properties per frequency range. > > We could introduce a subidx concept, and a related > tuner capability. Add if that capability is present, then userspace > can query different frequency ranges and there separate properties > by calling g_tuner with the same index but a different subidx until > it returns -EINVAL. > > We can use one of the reserved fields for the subidx, or ... > > We could store the subidx in the higher 16 bits of index, since index > is way larger then we need anyways, and this also avoids the > theoretical problems with apps not clearing the reserved fields we could > use for a proper subidx again. > > I personally prefer just using a separate field for it. > > > > > > On Sat May 19 2012 20:20:57 Hans de Goede wrote: > >> Hi Hans et all, > >> > >> Currently the V4L2 API does not allow for radio devices with more then 1 > >> tuner, > >> which is a bit of a historical oversight, since many radio devices have 2 > >> tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 > >> tuner > >> really does not work well, as they have 2 completely separate frequency > >> bands > >> they handle, as well as different properties (the FM part usually is stereo > >> capable, the AM part is not). > >> > >> It is important to realize here that usually the AM/FM tuners are part > >> of 1 chip, and often have only 1 frequency register which is used in > >> both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, > >> and from a V4L2 API pov these modes are best modeled as 2 tuners. > >> This is at least true for the radio-cadet card and the tea575x, > >> which are the only 2 AM capable radio devices we currently know about. > >> > >> Currently the V4L2 spec says the following on this subject: > >> http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html > >> "Radio devices have exactly one tuner with index zero, no video inputs." > >> > >> This text can easily be changed into allowing multiple tuners, without > >> any API change from the app pov, existing apps will be limited to > >> accessing just the first tuner though (probably best to always > >> make this the FM one). > > > > I agree. This text should change. > > Well if we go with the actually it is a single tuner concept above it > does not need to change, and we avoid the problems below... > > >> > >> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html > >> "... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, > >> which is determined by the current video input." > >> > >> This is a problem, video devices when they have multiple tuners often > >> do so with the purpose of being able to watch/record multiple channels > >> at the same time, and thus multiple tuners are usually connected to > >> differen
Re: RFC: V4L2 API and radio devices with multiple tuners
Hi, On 05/20/2012 12:23 PM, Hans Verkuil wrote: Hi Hans, I'm CC-ing Manjunatha Halli as well as due to his work on adding support for the weather band: http://www.spinics.net/lists/kernel/msg1340986.html The question is whether the weather band and the AM band should be treated the same. The wl128x will implement the weather band as part of the single tuner, the cadet currently implements the AM band as a separate tuner. Given the fact that the wl128x and the radioSHARK both have only one physical tuner (and that's almost certainly the case for the cadet radio as well) I am not so sure whether we should handle this as two tuners. The approach taken for the wl128x seems at first glance a better solution. However, when I have my cadet card I'd like to experiment with it first and see what the best approach is to solve this problem. I agree that since it is a single tuner, it makes sense to treat is as such :) The problem is that it has very distinctive properties depending on whether it is operating in AM or FM mode, ie the bands are: 87.5 - 108 Mhz and 530 - 1710 kHz. Now we can just represent that as the tuner being capable to tune from 530 kHz - 108 Mhz but that won't result in a good UI experience in userspace at all. I still agree that since it is a single tuner, it makes sense to treat is as such, and since there are no overlapping frequencies, treating it as one tuner is not a problem for most of the API, the only trouble some part really is G_TUNER, since it cannot deal with having multiple frequency ranges, nor with different properties per frequency range. We could introduce a subidx concept, and a related tuner capability. Add if that capability is present, then userspace can query different frequency ranges and there separate properties by calling g_tuner with the same index but a different subidx until it returns -EINVAL. We can use one of the reserved fields for the subidx, or ... We could store the subidx in the higher 16 bits of index, since index is way larger then we need anyways, and this also avoids the theoretical problems with apps not clearing the reserved fields we could use for a proper subidx again. I personally prefer just using a separate field for it. On Sat May 19 2012 20:20:57 Hans de Goede wrote: Hi Hans et all, Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. Currently the V4L2 spec says the following on this subject: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html "Radio devices have exactly one tuner with index zero, no video inputs." This text can easily be changed into allowing multiple tuners, without any API change from the app pov, existing apps will be limited to accessing just the first tuner though (probably best to always make this the FM one). I agree. This text should change. Well if we go with the actually it is a single tuner concept above it does not need to change, and we avoid the problems below... http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html "... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, which is determined by the current video input." This is a problem, video devices when they have multiple tuners often do so with the purpose of being able to watch/record multiple channels at the same time, and thus multiple tuners are usually connected to different inputs / frame-grabbers, and the input<-> tuner mapping done for video devices makes sense there. As the spec states, radio devices have no video inputs, so VIDIOC_S_INPUT cannot be used on them. Which means we need another way to get/set the active tuner (the tuner mode) for a radio device. Correct. The spec contradicts itself here for radio devices and that needs to be solved. Only if we assume there can be more then 1 tuner on a radio dev. Lets look at the getting of the active tuner first. We cannot use VIDIOC_G_TUNER for this, since this is used to enumerate tuners, so it should return info on the tuner with the specified index, rather then the active tuner. I agree. VIDEOC_G_FREQUENCY otoh looks like a good candidate to use for this, for radio devices we can simply ignore the passed in tuner field, and instead return the active tuner and the current
Re: RFC: V4L2 API and radio devices with multiple tuners
Hi Hans, I'm CC-ing Manjunatha Halli as well as due to his work on adding support for the weather band: http://www.spinics.net/lists/kernel/msg1340986.html The question is whether the weather band and the AM band should be treated the same. The wl128x will implement the weather band as part of the single tuner, the cadet currently implements the AM band as a separate tuner. Given the fact that the wl128x and the radioSHARK both have only one physical tuner (and that's almost certainly the case for the cadet radio as well) I am not so sure whether we should handle this as two tuners. The approach taken for the wl128x seems at first glance a better solution. However, when I have my cadet card I'd like to experiment with it first and see what the best approach is to solve this problem. On Sat May 19 2012 20:20:57 Hans de Goede wrote: > Hi Hans et all, > > Currently the V4L2 API does not allow for radio devices with more then 1 > tuner, > which is a bit of a historical oversight, since many radio devices have 2 > tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner > really does not work well, as they have 2 completely separate frequency bands > they handle, as well as different properties (the FM part usually is stereo > capable, the AM part is not). > > It is important to realize here that usually the AM/FM tuners are part > of 1 chip, and often have only 1 frequency register which is used in > both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, > and from a V4L2 API pov these modes are best modeled as 2 tuners. > This is at least true for the radio-cadet card and the tea575x, > which are the only 2 AM capable radio devices we currently know about. > > Currently the V4L2 spec says the following on this subject: > http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html > "Radio devices have exactly one tuner with index zero, no video inputs." > > This text can easily be changed into allowing multiple tuners, without > any API change from the app pov, existing apps will be limited to > accessing just the first tuner though (probably best to always > make this the FM one). I agree. This text should change. > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html > "... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, > which is determined by the current video input." > > This is a problem, video devices when they have multiple tuners often > do so with the purpose of being able to watch/record multiple channels > at the same time, and thus multiple tuners are usually connected to > different inputs / frame-grabbers, and the input <-> tuner mapping done > for video devices makes sense there. > > As the spec states, radio devices have no video inputs, so > VIDIOC_S_INPUT cannot be used on them. Which means we need another > way to get/set the active tuner (the tuner mode) for a radio device. Correct. The spec contradicts itself here for radio devices and that needs to be solved. > Lets look at the getting of the active tuner first. We cannot use > VIDIOC_G_TUNER for this, since this is used to enumerate tuners, > so it should return info on the tuner with the specified index, > rather then the active tuner. I agree. > VIDEOC_G_FREQUENCY otoh looks like a good candidate to use for this, > for radio devices we can simply ignore the passed in tuner field, > and instead return the active tuner and the current frequency. > This means there will be no way to get the frequency for the non > active tuner (mode), this is fine, since the non active tuner > does not have a (valid) frequency anyways. This would mean that the spec changes for this ioctl. I'm not certain I like that. > If we choose for VIDIOC_G_FREQUENCY to always return info on the > active tuner it makes sense to use VIDIOC_S_FREQUENCY to select > the active tuner. So for radio devices it will not only change > the currently tuned frequency for the indicated tuner, but if > the indicated tuner was not the active tuner it will make it the > active tuner. Ack. > Which leaves the question of what to do with VIDIOC_S_HW_FREQ_SEEK, > since VIDIOC_S_HW_FREQ_SEEK needs a valid begin frequency as a pre > condition, and the frequency ranges differ between different > tuners it makes sense to only allow VIDIOC_S_HW_FREQ_SEEK on > the active tuner. I see S_HW_FREQ_SEEK as an extended variation on S_FREQUENCY, so I believe calling S_HW_FREQ_SEEK should also change the current tuner. > So this leaves one last problem, what to > return from VIDIOC_S_HW_FREQ_SEEK if it tries to seek for > a non active tuner. I'm tending towards saying -EBUSY, since some > parts of the tuners are shared, so the non active tuner cannot > seek because those shared parts are otherwise used. *If* we decide that S_HW_FREQ_SEEK cannot change the current tuner, then -EBUSY would be a good error code. The problem is really that you are trying to use G_FREQUENCY to figure out what the active tuner is. T
Re: RFC: V4L2 API and radio devices with multiple tuners
Hi, On 05/19/2012 08:30 PM, Ondrej Zary wrote: On Saturday 19 May 2012 20:20:57 Hans de Goede wrote: Hi Hans et all, Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. When working on tea575x driver, I thought that it would be nice to implement AM. But found that none of my cards with TEA575x has implemented the AM part. I have a tea5757 device which does implement the AM part, the Griffin radioSHARK, and I'm working on a driver for it now, including some mods to the existing tea575x driver, this is one of the reasons I CC-ed you on this RFC. If you would like to get a radioSHARK yourself, you can get one here: http://www.ebay.com/itm/Griffin-RadioShark-PC-MAC-AM-FM-Desktop-Radio-/140547171120?pt=LH_DefaultDomain_0&hash=item20b943a330 Do you have any comments on my proposal how to deal with these devices API wise? The components required to receive AM radio (according to the chip datasheet) are missing. Right I already expected that my WIP patch to add AM support to the tea575x driver adds a has_am boolean and only makes AM available if that is set. I hope to post a set of tea575x patches this evening, most are non controversial so unless someone (ie you) yells stop I'm going to include them in my next pull request to Mauro for 3.5 (which will hopefully happen tomorrow). Unless some quick consensus can be reached on how to deal with the radio device with dual mode tuner API issue I'll leave out the AM patch from my pullreq. 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: RFC: V4L2 API and radio devices with multiple tuners
On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. From DVB FE change there is now some problems as a frequency limits and other parameters are shared between all the standards... For example cxd2820r demod, which is DVB-T/T2/C, says it supports even DVB-C2 as 2nd generation flag is derived from the DVB-T2. regards Antti -- http://palosaari.fi/ -- 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: RFC: V4L2 API and radio devices with multiple tuners
On Saturday 19 May 2012 20:20:57 Hans de Goede wrote: > Hi Hans et all, > > Currently the V4L2 API does not allow for radio devices with more then 1 > tuner, which is a bit of a historical oversight, since many radio devices > have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as > 1 tuner really does not work well, as they have 2 completely separate > frequency bands they handle, as well as different properties (the FM part > usually is stereo capable, the AM part is not). > > It is important to realize here that usually the AM/FM tuners are part > of 1 chip, and often have only 1 frequency register which is used in > both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, > and from a V4L2 API pov these modes are best modeled as 2 tuners. > This is at least true for the radio-cadet card and the tea575x, > which are the only 2 AM capable radio devices we currently know about. When working on tea575x driver, I thought that it would be nice to implement AM. But found that none of my cards with TEA575x has implemented the AM part. The components required to receive AM radio (according to the chip datasheet) are missing. -- Ondrej Zary -- 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
RFC: V4L2 API and radio devices with multiple tuners
Hi Hans et all, Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. Currently the V4L2 spec says the following on this subject: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html "Radio devices have exactly one tuner with index zero, no video inputs." This text can easily be changed into allowing multiple tuners, without any API change from the app pov, existing apps will be limited to accessing just the first tuner though (probably best to always make this the FM one). http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html "... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, which is determined by the current video input." This is a problem, video devices when they have multiple tuners often do so with the purpose of being able to watch/record multiple channels at the same time, and thus multiple tuners are usually connected to different inputs / frame-grabbers, and the input <-> tuner mapping done for video devices makes sense there. As the spec states, radio devices have no video inputs, so VIDIOC_S_INPUT cannot be used on them. Which means we need another way to get/set the active tuner (the tuner mode) for a radio device. Lets look at the getting of the active tuner first. We cannot use VIDIOC_G_TUNER for this, since this is used to enumerate tuners, so it should return info on the tuner with the specified index, rather then the active tuner. VIDEOC_G_FREQUENCY otoh looks like a good candidate to use for this, for radio devices we can simply ignore the passed in tuner field, and instead return the active tuner and the current frequency. This means there will be no way to get the frequency for the non active tuner (mode), this is fine, since the non active tuner does not have a (valid) frequency anyways. If we choose for VIDIOC_G_FREQUENCY to always return info on the active tuner it makes sense to use VIDIOC_S_FREQUENCY to select the active tuner. So for radio devices it will not only change the currently tuned frequency for the indicated tuner, but if the indicated tuner was not the active tuner it will make it the active tuner. Which leaves the question of what to do with VIDIOC_S_HW_FREQ_SEEK, since VIDIOC_S_HW_FREQ_SEEK needs a valid begin frequency as a pre condition, and the frequency ranges differ between different tuners it makes sense to only allow VIDIOC_S_HW_FREQ_SEEK on the active tuner. So this leaves one last problem, what to return from VIDIOC_S_HW_FREQ_SEEK if it tries to seek for a non active tuner. I'm tending towards saying -EBUSY, since some parts of the tuners are shared, so the non active tuner cannot seek because those shared parts are otherwise used. 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
