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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux