Hi Hans, Thanks for the feedback.
On Sat, Jan 1, 2011 at 4:18 PM, Hans Verkuil <hverk...@xs4all.nl> wrote: >> This basically means that a video tuner will bail out, which sounds >> good because the rest of the function supposedly assumes a radio >> device. However, as a result the has_signal() call (which returns >> signal strength) will never be executed for video tuners. You >> wouldn't notice this if a video decoder subdev is responsible for >> showing signal strength, but if you're expecting the tuner to provide >> the info, the call will never happen. > > I am not aware of any tuner that does that. I think that for video this > is always done by a video decoder. That said, it isn't pretty, but a lot > of this is legacy code and I wouldn't want to change it. The Xceive tuners have their analog demodulator onboard, so they make available a 0-100% signal strength. > After digging some more I think that check_mode is a poor function. There are > two things that check_mode does: checking if the tuner support radio and/or tv > mode (that's fine), and if it is in standby: not so fine. That should be a > separate function since filling in frequency ranges can be done regardless of > the standby state. Yeah, I didn't realize myself that is what check_mode was doing until I had this problem. I'll see if I can cook up a patch which returns the appropriate data even when in standby, while trying to minimize the risk of introducing a regression. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
