| Message ID | 4DF4AA3F.5040005@redhat.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu: > Em 12-06-2011 08:36, Hans Verkuil escreveu: >> On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote: >>> Em 11-06-2011 14:27, Hans Verkuil escreveu: >>>> On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote: >>>>> Em 11-06-2011 10:34, Hans Verkuil escreveu: >>>>>> From: Hans Verkuil <hans.verkuil@cisco.com> >>>>>> >>>>>> According to the spec the tuner type field is not used when calling >>>>>> S_TUNER: index, audmode and reserved are the only writable fields. >>>>>> >>>>>> So remove the type check. Instead, just set the audmode if the current >>>>>> tuner mode is set to radio. >>>>> >>>>> I suspect that this patch also breaks support for a separate radio tuner. >>>>> if tuner-type is not properly filled, then the easiest fix would be to >>>>> revert some changes done at the tuner cleanup/fixup patches applied on .39. >>>>> Yet, the previous logic were trying to hint the device mode, with is bad >>>>> (that's why it was changed). >>>>> >>>>> The proper change seems to add a parameter to this callback, set by the >>>>> bridge driver, informing if the device is using radio or video mode. >>>>> We need also to patch the V4L API specs, as it allows using a video node >>>>> for radio, and vice versa. This is not well supported, and it seems silly >>>>> to keep it at the specs and needing to add hints at the drivers due to >>>>> that. >>>> >>>> So, just to make sure I understand correctly what you want. The bridge or >>>> platform drivers will fill in the vf->type (for g/s_frequency) or vt->type >>>> (for g/s_tuner) based on the device node: RADIO if /dev/radio is used, >>>> TV for anything else. >>> >>> Yes. I remember I've reviewed the bridge drivers when I rewrote the tuner code. >>> Of course, I might have left something else. Btw, the older code were also >>> requiring it. >>> >>> The cx18 implementation were merged after the changes, so maybe it is not doing >>> the right thing. >> >> Actually, G_TUNER was wrong for bttv, ivtv, cx18 and pvrusb2. So it wasn't >> just some random driver that failed to set vf/vt->type. > > G_FREQUENCY were broken just on cx18. As I said before, filling the type were > always required. Anyway, I've added a proper documentation for it. See the > patch bellow. > > The same patch should be done also for G_TUNER. > >>>> What about VIDIOC_S_FREQUENCY? The spec says that the app needs to fill this >>>> in. Will we just overwrite vf->type or will we check and return -EINVAL if >>>> the app tries to set e.g. a TV frequency on /dev/radio? >>> >>> That's a very good question. What happens is that the V4L2 API used to allow >>> opening a /dev/radio device for TV (or even for VBI). IMHO, this were a trouble >>> at the API specs. I think that this were changed on newer versions of the spec. >> >> If you want, then I can add an extra patch to my v4 patch series that returns >> -EINVAL in video_ioctl2 if S_FREQUENCY is called with an inconsistent tuner type. >> (inconsistent with the device node's type, that is). > > The reason why check_mode returns -EINVAL is that this error code may need to be > returned to the caller. You should note, however, that the bridge code may need > to be fixed if you return the check_mode error code, as otherwise the error will > simply be discarded or it it will break devices with two tuners. > > For example, currently, bttv driver uses v4l2_device_call_all() for it. > So, any errors returned by it will be simply discarded. > > If some bridge driver is using v4l2_device_call_until_err(), it will stop on the first > tuner that gets an error. > > The solution is to implement a v4l2_device_call_until_not_err() and use it for the > tuner commands. > >>>> Is VIDIOC_S_FREQUENCY allowed to change the tuner mode? E.g. if /dev/radio was >>>> opened, and now I open /dev/video and call S_FREQUENCY with the TV tuner type, >>>> should that change the tuner to tv mode? >>> >>> Yes. I think that some applications like kradio just keeps the device node opened. >>> If we return -EBUSY, those applications will break. The reverse is more tricky: >>> e. g. if /dev/video is streaming, I think that the bridge driver should return >>> -EBUSY if the device can't do both TV and radio at the same time, but this is >>> something that it is device-specific, so such logic, if needed, should be implemented >>> at the bridge driver. >> >> Agreed. >> >>>> I think the type passed to S_FREQUENCY should 1) match the device node's type >>>> (if not, then return -EINVAL) and 2) should match the current mode (if not, >>>> then return -EBUSY). So attempts to change the TV frequency when in radio >>>> mode should fail. This second rule should also be valid for S_TUNER. >>> >>> See above. >>> >>>> What should G_TUNER return on a video node when in radio mode or vice versa? >>>> For G_FREQUENCY you can still return the last used frequency, but that's >>>> much more ambiguous for G_TUNER. One option is to set rxsubchans, signal and >>>> afc all to 0 if you query G_TUNER when 'in the wrong mode'. >>> >>> The current logic should handle this case well. I tested it carefully. Basically, >>> if the device is on Radio mode, and has a separate tuner for TV, the TV tuner >>> should not touch the structure. The Radio tuner should properly fill the values. >> >> I analyzed it again and you are correct. >> >>> Calls to G_TUNER/G_FREQUENCY shouldn't switch the device mode, or they may break >>> applications like kradio, that may be always there during the entire KDE section. >> >> Obviously. >> >>>> The VIDIOC_G/S_MODULATOR ioctls do not have a type and they are RADIO only, >>>> so that's OK. >>>> >>>> And how do we switch between radio and TV? Right now opening the radio node >>>> will set the tuner in radio mode, and calling S_STD will change the mode to >>>> TV again. As mentioned above, what S_FREQUENCY is supposed to do is undefined >>>> at the moment. >>> >>> If S_FREQUENCY is called from /dev/video (or /dev/vbi), it should set it to TV. If >>> it is called from /dev/radio, it should put the device on radio mode. >>> >>> The current logic already does that. I tested it on several devices, with both >>> tea5767 and without it. >>> >>>> What about this: >>>> >>>> Opening /dev/radio effectively starts the radio mode. So if there is TV >>>> capture in progress, then the open should return -EBUSY. Otherwise it >>>> switches the tuner to radio mode. And it stays in radio mode until the >>>> last filehandle of /dev/radio is closed. At that point it will automatically >>>> switch back to TV mode (if there is one, of course). >>> >>> No. This would break existing applications. The mode switch should be done >>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). >> >> This is not what happens today as the switch to radio occurs as soon as you open >> the radio node. It's the reason for the s_radio op. > > The s_radio op is something that I wanted to remove. It was there in the past to feed > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > final queue (I can't remember why). > > I think that the hint logic were completely removed, but we may need to take a look > on the callers for s_radio. I'll check it right now. > The s_radio callback requires some care, as it is used on several places. It is probably safe to remove it from tuner, but a few sub-drivers like msp3400 needs it. The actual troubles seem to happen at the bridge drivers that call it during open(). It should be called only at s_frequency. I opted to keep the callback just to avoid having a bridge driver switching its registers to radio mode, and not having the tuner following it. If we move the radio mode switch at the bridge drivers to s_frequency only, we can just remove this callback from tuner, letting it to be implemented only at the audio decoders. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday, June 12, 2011 13:59:59 Mauro Carvalho Chehab wrote: > Em 12-06-2011 08:36, Hans Verkuil escreveu: > > On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote: > >> Em 11-06-2011 14:27, Hans Verkuil escreveu: > >>> On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote: > >>>> Em 11-06-2011 10:34, Hans Verkuil escreveu: > >>>>> From: Hans Verkuil <hans.verkuil@cisco.com> > >>>>> > >>>>> According to the spec the tuner type field is not used when calling > >>>>> S_TUNER: index, audmode and reserved are the only writable fields. > >>>>> > >>>>> So remove the type check. Instead, just set the audmode if the current > >>>>> tuner mode is set to radio. > >>>> > >>>> I suspect that this patch also breaks support for a separate radio tuner. > >>>> if tuner-type is not properly filled, then the easiest fix would be to > >>>> revert some changes done at the tuner cleanup/fixup patches applied on .39. > >>>> Yet, the previous logic were trying to hint the device mode, with is bad > >>>> (that's why it was changed). > >>>> > >>>> The proper change seems to add a parameter to this callback, set by the > >>>> bridge driver, informing if the device is using radio or video mode. > >>>> We need also to patch the V4L API specs, as it allows using a video node > >>>> for radio, and vice versa. This is not well supported, and it seems silly > >>>> to keep it at the specs and needing to add hints at the drivers due to > >>>> that. > >>> > >>> So, just to make sure I understand correctly what you want. The bridge or > >>> platform drivers will fill in the vf->type (for g/s_frequency) or vt->type > >>> (for g/s_tuner) based on the device node: RADIO if /dev/radio is used, > >>> TV for anything else. > >> > >> Yes. I remember I've reviewed the bridge drivers when I rewrote the tuner code. > >> Of course, I might have left something else. Btw, the older code were also > >> requiring it. > >> > >> The cx18 implementation were merged after the changes, so maybe it is not doing > >> the right thing. > > > > Actually, G_TUNER was wrong for bttv, ivtv, cx18 and pvrusb2. So it wasn't > > just some random driver that failed to set vf/vt->type. > > G_FREQUENCY were broken just on cx18. As I said before, filling the type were > always required. No, it wasn't required in the past. I'm happy with that change, but that should be documented in v4l2-subdev.h since that's where the subdev ops are documented. I will add such documentation in a RFCv5 patch series. > Anyway, I've added a proper documentation for it. See the > patch bellow. > > The same patch should be done also for G_TUNER. And s_tuner. > > >>> What about VIDIOC_S_FREQUENCY? The spec says that the app needs to fill this > >>> in. Will we just overwrite vf->type or will we check and return -EINVAL if > >>> the app tries to set e.g. a TV frequency on /dev/radio? > >> > >> That's a very good question. What happens is that the V4L2 API used to allow > >> opening a /dev/radio device for TV (or even for VBI). IMHO, this were a trouble > >> at the API specs. I think that this were changed on newer versions of the spec. > > > > If you want, then I can add an extra patch to my v4 patch series that returns > > -EINVAL in video_ioctl2 if S_FREQUENCY is called with an inconsistent tuner type. > > (inconsistent with the device node's type, that is). > > The reason why check_mode returns -EINVAL is that this error code may need to be > returned to the caller. You should note, however, that the bridge code may need > to be fixed if you return the check_mode error code, as otherwise the error will > simply be discarded or it it will break devices with two tuners. > > For example, currently, bttv driver uses v4l2_device_call_all() for it. > So, any errors returned by it will be simply discarded. > > If some bridge driver is using v4l2_device_call_until_err(), it will stop on the first > tuner that gets an error. > > The solution is to implement a v4l2_device_call_until_not_err() and use it for the > tuner commands. That's not unreasonably to do at some point in time, but it doesn't actually answer my question, which is: should the core refuse VIDIOC_S_FREQUENCY calls where the type doesn't match the device node (i.e. radio vs tv)? I think it makes no sense to call VIDIOC_S_FREQUENCY on a radio node with type ANALOG_TV. ... > >>> What about this: > >>> > >>> Opening /dev/radio effectively starts the radio mode. So if there is TV > >>> capture in progress, then the open should return -EBUSY. Otherwise it > >>> switches the tuner to radio mode. And it stays in radio mode until the > >>> last filehandle of /dev/radio is closed. At that point it will automatically > >>> switch back to TV mode (if there is one, of course). > >> > >> No. This would break existing applications. The mode switch should be done > >> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). > > > > This is not what happens today as the switch to radio occurs as soon as you open > > the radio node. It's the reason for the s_radio op. > > The s_radio op is something that I wanted to remove. It was there in the past to feed > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > final queue (I can't remember why). > > I think that the hint logic were completely removed, but we may need to take a look > on the callers for s_radio. I'll check it right now. I'm fairly certain s_radio was added to explicitly set the tuner into radio mode. It replaced something even uglier, but I can't remember what that was. > > The V4L2 specification is silent on this topic, unfortunately. And I'm not sure > > how applications handle this. > > > > I think only changing the mode when calling S_FREQUENCY (and S_STD) is a good > > thing since this automatic mode switch when just opening a node goes against > > the V4L2 philosophy. Just opening a node shouldn't change the state of the > > device. > > Agreed. > > commit a307ec69602894c917485f331f8d1fef31c411b8 > Author: Mauro Carvalho Chehab <mchehab@redhat.com> > Date: Sun Jun 12 08:36:34 2011 -0300 > > [media] tuner: fix g_frequency subdev call and properly document it > > The tuner type needs to be initialized before calling g_frequency. > cx18 doesn't do it. Fix the logic and properly document the function. > > While here, remove a duplicated line at cx88. > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > diff --git a/drivers/media/video/cx18/cx18-ioctl.c b/drivers/media/video/cx18/cx18-ioctl.c > index 1933d4d..5463548 100644 > --- a/drivers/media/video/cx18/cx18-ioctl.c > +++ b/drivers/media/video/cx18/cx18-ioctl.c > @@ -611,6 +611,11 @@ static int cx18_g_frequency(struct file *file, void *fh, > if (vf->tuner != 0) > return -EINVAL; > > + if (test_bit(CX18_F_I_RADIO_USER, &cx->i_flags)) > + vf->type = V4L2_TUNER_RADIO; > + else > + vf->type = V4L2_TUNER_ANALOG_TV; > + NACK. This sets the type to the current mode. But what we want is to set the type to the current device node. That's what my RFCv4 does (and that patch requires no driver change). Although, to be honest, I did something similar to this patch in pvrusb2, but that's because I have no idea to get hold of the calling device node there. That hardware abstraction layer in pvrusb2 abstracts way too much :-( > cx18_call_all(cx, tuner, g_frequency, vf); > return 0; > } > diff --git a/drivers/media/video/cx88/cx88-video.c b/drivers/media/video/cx88/cx88-video.c > index cef4f28..13636f7 100644 > --- a/drivers/media/video/cx88/cx88-video.c > +++ b/drivers/media/video/cx88/cx88-video.c > @@ -1394,7 +1394,6 @@ static int vidioc_g_frequency (struct file *file, void *priv, > if (unlikely(UNSET == core->board.tuner_type)) > return -EINVAL; > > - /* f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; */ > f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; > f->frequency = core->freq; Same here. No longer needed with the RFCv4 series. > > diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c > index 5748d04..34cd9b0 100644 > --- a/drivers/media/video/tuner-core.c > +++ b/drivers/media/video/tuner-core.c > @@ -1133,6 +1133,17 @@ static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f) > return 0; > } > > +/** > + * tuner_g_frequency - Gets the tuned frequency for the tuner > + * @sd: pointer to struct v4l2_subdev > + * @f: opinter to struct v4l2_frequency > + * > + * At return, the structure f will be filled with tuner frequency, > + * if the tuner matches the f->type. > + * Note: f->type should be initialized before calling it. > + * as userspace won't initialize f->type, it is up to the bridge driver > + * to set it to either V4L2_TUNER_RADIO or V4L2_TUNER_ANALOG_TV. > + */ > static int tuner_g_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f) > { > struct tuner *t = to_tuner(sd); > > I'll add documentation to v4l2-subdev.h. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote: > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu: > > Em 12-06-2011 08:36, Hans Verkuil escreveu: > >>>> What about this: > >>>> > >>>> Opening /dev/radio effectively starts the radio mode. So if there is TV > >>>> capture in progress, then the open should return -EBUSY. Otherwise it > >>>> switches the tuner to radio mode. And it stays in radio mode until the > >>>> last filehandle of /dev/radio is closed. At that point it will automatically > >>>> switch back to TV mode (if there is one, of course). > >>> > >>> No. This would break existing applications. The mode switch should be done > >>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). > >> > >> This is not what happens today as the switch to radio occurs as soon as you open > >> the radio node. It's the reason for the s_radio op. > > > > The s_radio op is something that I wanted to remove. It was there in the past to feed > > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > > final queue (I can't remember why). > > > > I think that the hint logic were completely removed, but we may need to take a look > > on the callers for s_radio. I'll check it right now. > > > > The s_radio callback requires some care, as it is used on several places. It is probably > safe to remove it from tuner, but a few sub-drivers like msp3400 needs it. The actual > troubles seem to happen at the bridge drivers that call it during open(). It should be > called only at s_frequency. I opted to keep the callback just to avoid having a bridge > driver switching its registers to radio mode, and not having the tuner following it. > > If we move the radio mode switch at the bridge drivers to s_frequency only, we can just > remove this callback from tuner, letting it to be implemented only at the audio decoders. Why would the audio decoders need it? If we do the mode switch when s_freq is called, then the audio decoders can do the same and s_radio can disappear completely. I would like that, but I'm a bit afraid of application breakage since we're changing the behavior of /dev/radio. It seems that pretty much every video driver with radio capability is calling s_radio during open(): bttv, ivtv, saa7134, usbvision, em28xx, cx18, cx88, cx231xx and tm6000. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote: > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote: > > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu: > > > Em 12-06-2011 08:36, Hans Verkuil escreveu: > > >>>> What about this: > > >>>> > > >>>> Opening /dev/radio effectively starts the radio mode. So if there is TV > > >>>> capture in progress, then the open should return -EBUSY. Otherwise it > > >>>> switches the tuner to radio mode. And it stays in radio mode until the > > >>>> last filehandle of /dev/radio is closed. At that point it will automatically > > >>>> switch back to TV mode (if there is one, of course). > > >>> > > >>> No. This would break existing applications. The mode switch should be done > > >>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). > > >> > > >> This is not what happens today as the switch to radio occurs as soon as you open > > >> the radio node. It's the reason for the s_radio op. > > > > > > The s_radio op is something that I wanted to remove. It was there in the past to feed > > > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > > > final queue (I can't remember why). > > > > > > I think that the hint logic were completely removed, but we may need to take a look > > > on the callers for s_radio. I'll check it right now. > > > > > > > The s_radio callback requires some care, as it is used on several places. It is probably > > safe to remove it from tuner, but a few sub-drivers like msp3400 needs it. The actual > > troubles seem to happen at the bridge drivers that call it during open(). It should be > > called only at s_frequency. I opted to keep the callback just to avoid having a bridge > > driver switching its registers to radio mode, and not having the tuner following it. > > > > If we move the radio mode switch at the bridge drivers to s_frequency only, we can just > > remove this callback from tuner, letting it to be implemented only at the audio decoders. > > Why would the audio decoders need it? If we do the mode switch when s_freq is > called, then the audio decoders can do the same and s_radio can disappear completely. > > I would like that, but I'm a bit afraid of application breakage since we're changing > the behavior of /dev/radio. It seems that pretty much every video driver with radio > capability is calling s_radio during open(): bttv, ivtv, saa7134, usbvision, em28xx, > cx18, cx88, cx231xx and tm6000. I think ivtvhopper relies on it: http://www.gateways-home.org/wb/pages/mycoding/--ivtvhopper-java.php Also, per my recommendation, ivtvhopper changes radio freq by using /dev/video24, since V4L2 priorities got in the way: http://ivtvdriver.org/pipermail/ivtv-users/2010-December/010097.html Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday, June 12, 2011 14:53:06 Andy Walls wrote: > On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote: > > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote: > > > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu: > > > > Em 12-06-2011 08:36, Hans Verkuil escreveu: > > > >>>> What about this: > > > >>>> > > > >>>> Opening /dev/radio effectively starts the radio mode. So if there is TV > > > >>>> capture in progress, then the open should return -EBUSY. Otherwise it > > > >>>> switches the tuner to radio mode. And it stays in radio mode until the > > > >>>> last filehandle of /dev/radio is closed. At that point it will automatically > > > >>>> switch back to TV mode (if there is one, of course). > > > >>> > > > >>> No. This would break existing applications. The mode switch should be done > > > >>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). > > > >> > > > >> This is not what happens today as the switch to radio occurs as soon as you open > > > >> the radio node. It's the reason for the s_radio op. > > > > > > > > The s_radio op is something that I wanted to remove. It was there in the past to feed > > > > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > > > > final queue (I can't remember why). > > > > > > > > I think that the hint logic were completely removed, but we may need to take a look > > > > on the callers for s_radio. I'll check it right now. > > > > > > > > > > The s_radio callback requires some care, as it is used on several places. It is probably > > > safe to remove it from tuner, but a few sub-drivers like msp3400 needs it. The actual > > > troubles seem to happen at the bridge drivers that call it during open(). It should be > > > called only at s_frequency. I opted to keep the callback just to avoid having a bridge > > > driver switching its registers to radio mode, and not having the tuner following it. > > > > > > If we move the radio mode switch at the bridge drivers to s_frequency only, we can just > > > remove this callback from tuner, letting it to be implemented only at the audio decoders. > > > > Why would the audio decoders need it? If we do the mode switch when s_freq is > > called, then the audio decoders can do the same and s_radio can disappear completely. > > > > I would like that, but I'm a bit afraid of application breakage since we're changing > > the behavior of /dev/radio. It seems that pretty much every video driver with radio > > capability is calling s_radio during open(): bttv, ivtv, saa7134, usbvision, em28xx, > > cx18, cx88, cx231xx and tm6000. > > I think ivtvhopper relies on it: > > http://www.gateways-home.org/wb/pages/mycoding/--ivtvhopper-java.php > > Also, per my recommendation, ivtvhopper changes radio freq by > using /dev/video24, since V4L2 priorities got in the way: > > http://ivtvdriver.org/pipermail/ivtv-users/2010-December/010097.html Well, radio support for ivtv is weird and we really need a ivtv-alsa (easier said than done). Because it is so non-standard, I am not terribly concerned about it. BTW, one problem with /dev/radio and ivtv (and I think cx18 might have the same problem) is that /dev/radio can be opened only once. A second attempt to open it will result in -EBUSY. That's a driver bug. I wonder if that's really the problem described in the link above instead of priority handling. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2011-06-12 at 15:23 +0200, Hans Verkuil wrote: > On Sunday, June 12, 2011 14:53:06 Andy Walls wrote: > > On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote: > > > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote: > > > > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu: > > > > > Em 12-06-2011 08:36, Hans Verkuil escreveu: > > > > >>>> What about this: > > > > >>>> > > > > >>>> Opening /dev/radio effectively starts the radio mode. So if there is TV > > > > >>>> capture in progress, then the open should return -EBUSY. Otherwise it > > > > >>>> switches the tuner to radio mode. And it stays in radio mode until the > > > > >>>> last filehandle of /dev/radio is closed. At that point it will automatically > > > > >>>> switch back to TV mode (if there is one, of course). > > > > >>> > > > > >>> No. This would break existing applications. The mode switch should be done > > > > >>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). > > > > >> > > > > >> This is not what happens today as the switch to radio occurs as soon as you open > > > > >> the radio node. It's the reason for the s_radio op. > > > > > > > > > > The s_radio op is something that I wanted to remove. It was there in the past to feed > > > > > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > > > > > final queue (I can't remember why). > > > > > > > > > > I think that the hint logic were completely removed, but we may need to take a look > > > > > on the callers for s_radio. I'll check it right now. > > > > > > > > > > > > > The s_radio callback requires some care, as it is used on several places. It is probably > > > > safe to remove it from tuner, but a few sub-drivers like msp3400 needs it. The actual > > > > troubles seem to happen at the bridge drivers that call it during open(). It should be > > > > called only at s_frequency. I opted to keep the callback just to avoid having a bridge > > > > driver switching its registers to radio mode, and not having the tuner following it. > > > > > > > > If we move the radio mode switch at the bridge drivers to s_frequency only, we can just > > > > remove this callback from tuner, letting it to be implemented only at the audio decoders. > > > > > > Why would the audio decoders need it? If we do the mode switch when s_freq is > > > called, then the audio decoders can do the same and s_radio can disappear completely. > > > > > > I would like that, but I'm a bit afraid of application breakage since we're changing > > > the behavior of /dev/radio. It seems that pretty much every video driver with radio > > > capability is calling s_radio during open(): bttv, ivtv, saa7134, usbvision, em28xx, > > > cx18, cx88, cx231xx and tm6000. > > > > I think ivtvhopper relies on it: > > > > http://www.gateways-home.org/wb/pages/mycoding/--ivtvhopper-java.php > > > > Also, per my recommendation, ivtvhopper changes radio freq by > > using /dev/video24, since V4L2 priorities got in the way: > > > > http://ivtvdriver.org/pipermail/ivtv-users/2010-December/010097.html > > Well, radio support for ivtv is weird and we really need a ivtv-alsa (easier > said than done). Because it is so non-standard, I am not terribly concerned > about it. I use /dev/radio & /dev/video24 for FM radio using ivtv-radio, myself. BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds the device nodes open, pinning the cx18-alsa and cx18 modules in kernel. When killed, PulseAudio respawns rapidly and reopens the nodes. Unloading cx18 for development purposes is a real pain when the cx18-alsa module exists. > BTW, one problem with /dev/radio and ivtv (and I think cx18 might have the same > problem) is that /dev/radio can be opened only once. A second attempt to open > it will result in -EBUSY. That's a driver bug. I wonder if that's really the > problem described in the link above instead of priority handling. Gah, I think you are right. It probably was a multiple open() problem on /dev/radio for the app author. I do remember researching that cx18 and ivtv are single open() on /dev/radio. I also remember finding that the V4L2 spec doesn't require multiple opens, and implies drivers need not support it in at least two places: "Multiple Opens In general, V4L2 devices can be opened more than once. When this is supported by the driver, ..." "Name v4l2-open — Open a V4L2 device ... EBUSY The driver does not support multiple opens and the device is already in use. ..." Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls <awalls@md.metrocast.net> wrote: > BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds > the device nodes open, pinning the cx18-alsa and cx18 modules in kernel. > When killed, PulseAudio respawns rapidly and reopens the nodes. > Unloading cx18 for development purposes is a real pain when the > cx18-alsa module exists. We've talked about this before, but something just feels wrong about this. I don't have this problem with other drivers that provide an "-alsa" module. For example, my ngene tree has four ALSA PCM devices and 16 mixer controls, yet PulseAudio doesn't keep the module in use. The more I think about this, the more I suspect this is just some sort of subtle bug in the cx18 ALSA driver where some resource is not being freed. Devin
On Sunday, June 12, 2011 15:44:45 Andy Walls wrote: > On Sun, 2011-06-12 at 15:23 +0200, Hans Verkuil wrote: > > On Sunday, June 12, 2011 14:53:06 Andy Walls wrote: > > > On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote: > > > > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote: > > > > > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu: > > > > > > Em 12-06-2011 08:36, Hans Verkuil escreveu: > > > > > >>>> What about this: > > > > > >>>> > > > > > >>>> Opening /dev/radio effectively starts the radio mode. So if there is TV > > > > > >>>> capture in progress, then the open should return -EBUSY. Otherwise it > > > > > >>>> switches the tuner to radio mode. And it stays in radio mode until the > > > > > >>>> last filehandle of /dev/radio is closed. At that point it will automatically > > > > > >>>> switch back to TV mode (if there is one, of course). > > > > > >>> > > > > > >>> No. This would break existing applications. The mode switch should be done > > > > > >>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). > > > > > >> > > > > > >> This is not what happens today as the switch to radio occurs as soon as you open > > > > > >> the radio node. It's the reason for the s_radio op. > > > > > > > > > > > > The s_radio op is something that I wanted to remove. It was there in the past to feed > > > > > > the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my > > > > > > final queue (I can't remember why). > > > > > > > > > > > > I think that the hint logic were completely removed, but we may need to take a look > > > > > > on the callers for s_radio. I'll check it right now. > > > > > > > > > > > > > > > > The s_radio callback requires some care, as it is used on several places. It is probably > > > > > safe to remove it from tuner, but a few sub-drivers like msp3400 needs it. The actual > > > > > troubles seem to happen at the bridge drivers that call it during open(). It should be > > > > > called only at s_frequency. I opted to keep the callback just to avoid having a bridge > > > > > driver switching its registers to radio mode, and not having the tuner following it. > > > > > > > > > > If we move the radio mode switch at the bridge drivers to s_frequency only, we can just > > > > > remove this callback from tuner, letting it to be implemented only at the audio decoders. > > > > > > > > Why would the audio decoders need it? If we do the mode switch when s_freq is > > > > called, then the audio decoders can do the same and s_radio can disappear completely. > > > > > > > > I would like that, but I'm a bit afraid of application breakage since we're changing > > > > the behavior of /dev/radio. It seems that pretty much every video driver with radio > > > > capability is calling s_radio during open(): bttv, ivtv, saa7134, usbvision, em28xx, > > > > cx18, cx88, cx231xx and tm6000. > > > > > > I think ivtvhopper relies on it: > > > > > > http://www.gateways-home.org/wb/pages/mycoding/--ivtvhopper-java.php > > > > > > Also, per my recommendation, ivtvhopper changes radio freq by > > > using /dev/video24, since V4L2 priorities got in the way: > > > > > > http://ivtvdriver.org/pipermail/ivtv-users/2010-December/010097.html > > > > Well, radio support for ivtv is weird and we really need a ivtv-alsa (easier > > said than done). Because it is so non-standard, I am not terribly concerned > > about it. > > I use /dev/radio & /dev/video24 for FM radio using ivtv-radio, myself. > > BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds > the device nodes open, pinning the cx18-alsa and cx18 modules in kernel. > When killed, PulseAudio respawns rapidly and reopens the nodes. > Unloading cx18 for development purposes is a real pain when the > cx18-alsa module exists. > > > > BTW, one problem with /dev/radio and ivtv (and I think cx18 might have the same > > problem) is that /dev/radio can be opened only once. A second attempt to open > > it will result in -EBUSY. That's a driver bug. I wonder if that's really the > > problem described in the link above instead of priority handling. > > Gah, I think you are right. It probably was a multiple open() problem > on /dev/radio for the app author. > > I do remember researching that cx18 and ivtv are single open() > on /dev/radio. > > I also remember finding that the V4L2 spec doesn't require multiple > opens, and implies drivers need not support it in at least two places: > > "Multiple Opens > > In general, V4L2 devices can be opened more than once. When this > is supported by the driver, ..." > > > "Name > v4l2-open — Open a V4L2 device > > ... > > EBUSY > The driver does not support multiple opens and the > device is already in use. > ..." One of the (loooong) list of TODOs is go through the spec remove such obsolete stuff. You really must be able to open devices multiple times. Many old drivers didn't support multiple opens but I think almost all of them have been fixed now. In ivtv it was probably just laziness as well. v4l2-compliance actually tests for this (try running v4l2-compliance -d /dev/radio0). Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 12-06-2011 09:23, Hans Verkuil escreveu: > On Sunday, June 12, 2011 13:59:59 Mauro Carvalho Chehab wrote: >> Em 12-06-2011 08:36, Hans Verkuil escreveu: >>> On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote: >>>> Em 11-06-2011 14:27, Hans Verkuil escreveu: >>>>> On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote: >>>>>> Em 11-06-2011 10:34, Hans Verkuil escreveu: >>>>>>> From: Hans Verkuil <hans.verkuil@cisco.com> >>>>>>> >>>>>>> According to the spec the tuner type field is not used when calling >>>>>>> S_TUNER: index, audmode and reserved are the only writable fields. >>>>>>> >>>>>>> So remove the type check. Instead, just set the audmode if the current >>>>>>> tuner mode is set to radio. >>>>>> >>>>>> I suspect that this patch also breaks support for a separate radio tuner. >>>>>> if tuner-type is not properly filled, then the easiest fix would be to >>>>>> revert some changes done at the tuner cleanup/fixup patches applied on .39. >>>>>> Yet, the previous logic were trying to hint the device mode, with is bad >>>>>> (that's why it was changed). >>>>>> >>>>>> The proper change seems to add a parameter to this callback, set by the >>>>>> bridge driver, informing if the device is using radio or video mode. >>>>>> We need also to patch the V4L API specs, as it allows using a video node >>>>>> for radio, and vice versa. This is not well supported, and it seems silly >>>>>> to keep it at the specs and needing to add hints at the drivers due to >>>>>> that. >>>>> >>>>> So, just to make sure I understand correctly what you want. The bridge or >>>>> platform drivers will fill in the vf->type (for g/s_frequency) or vt->type >>>>> (for g/s_tuner) based on the device node: RADIO if /dev/radio is used, >>>>> TV for anything else. >>>> >>>> Yes. I remember I've reviewed the bridge drivers when I rewrote the tuner code. >>>> Of course, I might have left something else. Btw, the older code were also >>>> requiring it. >>>> >>>> The cx18 implementation were merged after the changes, so maybe it is not doing >>>> the right thing. >>> >>> Actually, G_TUNER was wrong for bttv, ivtv, cx18 and pvrusb2. So it wasn't >>> just some random driver that failed to set vf/vt->type. >> >> G_FREQUENCY were broken just on cx18. As I said before, filling the type were >> always required. > > No, it wasn't required in the past. I'm happy with that change, but that > should be documented in v4l2-subdev.h since that's where the subdev ops are > documented. I will add such documentation in a RFCv5 patch series. > >> Anyway, I've added a proper documentation for it. See the >> patch bellow. >> >> The same patch should be done also for G_TUNER. > > And s_tuner. > >> >>>>> What about VIDIOC_S_FREQUENCY? The spec says that the app needs to fill this >>>>> in. Will we just overwrite vf->type or will we check and return -EINVAL if >>>>> the app tries to set e.g. a TV frequency on /dev/radio? >>>> >>>> That's a very good question. What happens is that the V4L2 API used to allow >>>> opening a /dev/radio device for TV (or even for VBI). IMHO, this were a trouble >>>> at the API specs. I think that this were changed on newer versions of the spec. >>> >>> If you want, then I can add an extra patch to my v4 patch series that returns >>> -EINVAL in video_ioctl2 if S_FREQUENCY is called with an inconsistent tuner type. >>> (inconsistent with the device node's type, that is). >> >> The reason why check_mode returns -EINVAL is that this error code may need to be >> returned to the caller. You should note, however, that the bridge code may need >> to be fixed if you return the check_mode error code, as otherwise the error will >> simply be discarded or it it will break devices with two tuners. >> >> For example, currently, bttv driver uses v4l2_device_call_all() for it. >> So, any errors returned by it will be simply discarded. >> >> If some bridge driver is using v4l2_device_call_until_err(), it will stop on the first >> tuner that gets an error. >> >> The solution is to implement a v4l2_device_call_until_not_err() and use it for the >> tuner commands. > > That's not unreasonably to do at some point in time, but it doesn't actually > answer my question, which is: should the core refuse VIDIOC_S_FREQUENCY calls > where the type doesn't match the device node (i.e. radio vs tv)? I think it > makes no sense to call VIDIOC_S_FREQUENCY on a radio node with type ANALOG_TV. No. The core shouldn't do it, otherwise tuner will break. The code doesn't know if the opened device is radio or video. > > ... > >>>>> What about this: >>>>> >>>>> Opening /dev/radio effectively starts the radio mode. So if there is TV >>>>> capture in progress, then the open should return -EBUSY. Otherwise it >>>>> switches the tuner to radio mode. And it stays in radio mode until the >>>>> last filehandle of /dev/radio is closed. At that point it will automatically >>>>> switch back to TV mode (if there is one, of course). >>>> >>>> No. This would break existing applications. The mode switch should be done >>>> at S_FREQUENCY (e. g. when the radio application is tuning into a channel). >>> >>> This is not what happens today as the switch to radio occurs as soon as you open >>> the radio node. It's the reason for the s_radio op. >> >> The s_radio op is something that I wanted to remove. It was there in the past to feed >> the TV/radio hint logic. I wrote a patch for it, but I ended by discarding from my >> final queue (I can't remember why). >> >> I think that the hint logic were completely removed, but we may need to take a look >> on the callers for s_radio. I'll check it right now. > > I'm fairly certain s_radio was added to explicitly set the tuner into radio mode. > It replaced something even uglier, but I can't remember what that was. > >>> The V4L2 specification is silent on this topic, unfortunately. And I'm not sure >>> how applications handle this. >>> >>> I think only changing the mode when calling S_FREQUENCY (and S_STD) is a good >>> thing since this automatic mode switch when just opening a node goes against >>> the V4L2 philosophy. Just opening a node shouldn't change the state of the >>> device. >> >> Agreed. >> >> commit a307ec69602894c917485f331f8d1fef31c411b8 >> Author: Mauro Carvalho Chehab <mchehab@redhat.com> >> Date: Sun Jun 12 08:36:34 2011 -0300 >> >> [media] tuner: fix g_frequency subdev call and properly document it >> >> The tuner type needs to be initialized before calling g_frequency. >> cx18 doesn't do it. Fix the logic and properly document the function. >> >> While here, remove a duplicated line at cx88. >> >> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> >> >> diff --git a/drivers/media/video/cx18/cx18-ioctl.c b/drivers/media/video/cx18/cx18-ioctl.c >> index 1933d4d..5463548 100644 >> --- a/drivers/media/video/cx18/cx18-ioctl.c >> +++ b/drivers/media/video/cx18/cx18-ioctl.c >> @@ -611,6 +611,11 @@ static int cx18_g_frequency(struct file *file, void *fh, >> if (vf->tuner != 0) >> return -EINVAL; >> >> + if (test_bit(CX18_F_I_RADIO_USER, &cx->i_flags)) >> + vf->type = V4L2_TUNER_RADIO; >> + else >> + vf->type = V4L2_TUNER_ANALOG_TV; >> + > > NACK. > > This sets the type to the current mode. But what we want is to set the type to > the current device node. That's what my RFCv4 does (and that patch requires no > driver change). I didn't get your RFCv4 patches here yet, but the fix should be at the driver: it needs to set the type before calling g_frequency. G_FREQUENCY shouldn't change the device mode, but, instead, to return the frequency and mode currently in usage.. > Although, to be honest, I did something similar to this patch in pvrusb2, but > that's because I have no idea to get hold of the calling device node there. > That hardware abstraction layer in pvrusb2 abstracts way too much :-( > >> cx18_call_all(cx, tuner, g_frequency, vf); >> return 0; >> } >> diff --git a/drivers/media/video/cx88/cx88-video.c b/drivers/media/video/cx88/cx88-video.c >> index cef4f28..13636f7 100644 >> --- a/drivers/media/video/cx88/cx88-video.c >> +++ b/drivers/media/video/cx88/cx88-video.c >> @@ -1394,7 +1394,6 @@ static int vidioc_g_frequency (struct file *file, void *priv, >> if (unlikely(UNSET == core->board.tuner_type)) >> return -EINVAL; >> >> - /* f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; */ >> f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; >> f->frequency = core->freq; > > Same here. No longer needed with the RFCv4 series. > >> >> diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c >> index 5748d04..34cd9b0 100644 >> --- a/drivers/media/video/tuner-core.c >> +++ b/drivers/media/video/tuner-core.c >> @@ -1133,6 +1133,17 @@ static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f) >> return 0; >> } >> >> +/** >> + * tuner_g_frequency - Gets the tuned frequency for the tuner >> + * @sd: pointer to struct v4l2_subdev >> + * @f: opinter to struct v4l2_frequency >> + * >> + * At return, the structure f will be filled with tuner frequency, >> + * if the tuner matches the f->type. >> + * Note: f->type should be initialized before calling it. >> + * as userspace won't initialize f->type, it is up to the bridge driver >> + * to set it to either V4L2_TUNER_RADIO or V4L2_TUNER_ANALOG_TV. >> + */ >> static int tuner_g_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f) >> { >> struct tuner *t = to_tuner(sd); >> >> > > I'll add documentation to v4l2-subdev.h. The doc should also be at tuner-core. > > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 12-06-2011 10:57, Devin Heitmueller escreveu: > On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls <awalls@md.metrocast.net> wrote: >> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds >> the device nodes open, pinning the cx18-alsa and cx18 modules in kernel. >> When killed, PulseAudio respawns rapidly and reopens the nodes. >> Unloading cx18 for development purposes is a real pain when the >> cx18-alsa module exists. > > We've talked about this before, but something just feels wrong about > this. I don't have this problem with other drivers that provide an > "-alsa" module. For example, my ngene tree has four ALSA PCM devices > and 16 mixer controls, yet PulseAudio doesn't keep the module in use. > > The more I think about this, the more I suspect this is just some sort > of subtle bug in the cx18 ALSA driver where some resource is not being > freed. It is not just cx18 that have this trouble. All drivers under media/video with *-alsa have this issue. Also, all sound drivers suffer from the same issue: # lsmod|grep snd_hda snd_hda_codec_analog 84955 1 snd_hda_intel 25261 2 See: pulseaudio keep the device opened, so dev refcount were incremented. # rmmod snd_hda_codec_analog snd_hda_intel ERROR: Module snd_hda_codec_analog is in use ERROR: Module snd_hda_intel is in use The same happens, for example, with em28xx with snd-usb-audio: # lsmod |grep snd snd_usb_audio 91303 1 # rmmod snd-usb-audio ERROR: Module snd_usb_audio is in use What happens is that open() increments the device refcount. Maybe the ngene has some trick for allowing it, or PulseAudio has some logic to detect ngene (or otherwise it fails to open ngene audio nodes). It may have some dirty ways to trick PulseAudio, for example returning -ENODEV if the process name is pulseaudio, but I can't think on a proper kernel solution for it. The proper solution is to fix PulseAudio. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Devin Heitmueller <dheitmueller@kernellabs.com> wrote: >On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls <awalls@md.metrocast.net> >wrote: >> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds >> the device nodes open, pinning the cx18-alsa and cx18 modules in >kernel. >> When killed, PulseAudio respawns rapidly and reopens the nodes. >> Unloading cx18 for development purposes is a real pain when the >> cx18-alsa module exists. > >We've talked about this before, but something just feels wrong about >this. I don't have this problem with other drivers that provide an >"-alsa" module. For example, my ngene tree has four ALSA PCM devices >and 16 mixer controls, yet PulseAudio doesn't keep the module in use. > >The more I think about this, the more I suspect this is just some sort >of subtle bug in the cx18 ALSA driver where some resource is not being >freed. > >Devin > >-- >Devin J. Heitmueller - Kernel Labs >http://www.kernellabs.com I'll recheck with my shiny new Fedora 15 install maybe later tonight. The only thing that springs to mind that PA may not like is no mixer controls. Some basic code is there in cx18-alsa-mixer.c, but never registered. Pactl does have some magic cmd to let go of the nodes, but I can never remember it. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 12-06-2011 12:34, Andy Walls escreveu: > Devin Heitmueller <dheitmueller@kernellabs.com> wrote: > >> On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls <awalls@md.metrocast.net> >> wrote: >>> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds >>> the device nodes open, pinning the cx18-alsa and cx18 modules in >> kernel. >>> When killed, PulseAudio respawns rapidly and reopens the nodes. >>> Unloading cx18 for development purposes is a real pain when the >>> cx18-alsa module exists. >> >> We've talked about this before, but something just feels wrong about >> this. I don't have this problem with other drivers that provide an >> "-alsa" module. For example, my ngene tree has four ALSA PCM devices >> and 16 mixer controls, yet PulseAudio doesn't keep the module in use. >> >> The more I think about this, the more I suspect this is just some sort >> of subtle bug in the cx18 ALSA driver where some resource is not being >> freed. >> >> Devin >> >> -- >> Devin J. Heitmueller - Kernel Labs >> http://www.kernellabs.com > > I'll recheck with my shiny new Fedora 15 install maybe later tonight. > > The only thing that springs to mind that PA may not like is no mixer controls. Some basic code is there in cx18-alsa-mixer.c, but never registered. > > Pactl does have some magic cmd to let go of the nodes, but I can never remember it. This should do the job: # yum remove -y pulseaudio :) Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/video/cx18/cx18-ioctl.c b/drivers/media/video/cx18/cx18-ioctl.c index 1933d4d..5463548 100644 --- a/drivers/media/video/cx18/cx18-ioctl.c +++ b/drivers/media/video/cx18/cx18-ioctl.c @@ -611,6 +611,11 @@ static int cx18_g_frequency(struct file *file, void *fh, if (vf->tuner != 0) return -EINVAL; + if (test_bit(CX18_F_I_RADIO_USER, &cx->i_flags)) + vf->type = V4L2_TUNER_RADIO; + else + vf->type = V4L2_TUNER_ANALOG_TV; + cx18_call_all(cx, tuner, g_frequency, vf); return 0; } diff --git a/drivers/media/video/cx88/cx88-video.c b/drivers/media/video/cx88/cx88-video.c index cef4f28..13636f7 100644 --- a/drivers/media/video/cx88/cx88-video.c +++ b/drivers/media/video/cx88/cx88-video.c @@ -1394,7 +1394,6 @@ static int vidioc_g_frequency (struct file *file, void *priv, if (unlikely(UNSET == core->board.tuner_type)) return -EINVAL; - /* f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; */ f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; f->frequency = core->freq; diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 5748d04..34cd9b0 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1133,6 +1133,17 @@ static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f) return 0; } +/** + * tuner_g_frequency - Gets the tuned frequency for the tuner + * @sd: pointer to struct v4l2_subdev + * @f: opinter to struct v4l2_frequency + * + * At return, the structure f will be filled with tuner frequency, + * if the tuner matches the f->type. + * Note: f->type should be initialized before calling it. + * as userspace won't initialize f->type, it is up to the bridge driver + * to set it to either V4L2_TUNER_RADIO or V4L2_TUNER_ANALOG_TV. + */ static int tuner_g_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f) { struct tuner *t = to_tuner(sd);