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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
