Re: [RFCv1 PATCH 7/7] tuner-core: s_tuner should not change tuner mode.

[Andy Walls <awalls@md.metrocast.net>]

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