On Mon, Nov 24, 2008 at 6:27 PM, Michael Krufky <[EMAIL PROTECTED]> wrote: > On Mon, Nov 24, 2008 at 6:05 PM, Mike Isely <[EMAIL PROTECTED]> wrote: >> On Mon, 24 Nov 2008, Michael Krufky wrote: >> >> [...] >> >>> >>> I've been meaning to respond to this all day long, but I've been short >>> on spare time. I will keep this short and sweet. >>> >>> I did a diff comparison between the code in the ubuntu-intrepid kernel >>> versus the code in the v4l-dvb tree. The following is a description >>> of the changes of the major components that have to do with the ATSC / >>> QAM tuner components in the HVR1950: >>> >>> 1) TDA18271 -- no change (other than some compat code and the removal >>> of a no-op break statement) >>> >>> 2) S5H1411 -- very small changes. I looked these over with the author >>> of the driver and we do not believe these to be causing the issue, but >>> anything is possible. >>> >>> 3) PVRUSB2 -- some larger changes that I cannot review or describe >>> fairly given the lack of time that I have for this. >> >> [...] >> >> I just skimmed the diff rather quickly. >> >> The vast majority of the changes are what one would expect when >> transforming the source code for a driver from the v4l-dvb repository >> into the Linux kernel, e.g. stripping out various "if 0" bits, removing >> kernel-version-specific sections, getting rid of compat.h, etc. Every >> driver in v4l-dvb has changes like these and they are all known to be >> safe of course. The transformation is mechanical in nature; it is done >> via a script by the v4l-dvb maintainer when pushing changes up to the >> kernel tree. >> >> Of the remaining changes, nearly all have to do with adding cropping >> support, which is in v4l-dvb but (not surprisingly) won't be in 2.6.27.y >> since that's a feature addition that appeared long after the 2.6.27 >> merge window closed. Beyond that, there are a few other minor bits to >> help with overall functional stability (e.g. avoid an oops if the driver >> is attempted to be associated with a device ID that it doesn't know >> about, something that can only happen if an alien device ID is forced >> into the driver at run-time). >> >> None of the changes however have anything to do with tuning. >> >> I'm not trying to "point the finger" here. Allow me to explain (and >> feel free to tell me where I went astray)... Until this reply I thought >> I had understood the situation: Back in the early 2.6.27.y releases >> (over a month ago), there was apparently a problem which impacted the >> ability to do digital tuning on the HVR-1950 - exactly the problem >> described in this thread. The root cause had to do with some issues >> with the underlying tuner driver for the HVR-1950's tuner, not the >> pvrusb2 driver itself. Mike Krufky and I talked about that at the time, >> and it just so happens that Steve Toth just the previous day had >> committed tuner fixes into v4l-dvb that radically improved this >> situation. I have since confirmed that v4l-dvb is fine in this regard >> for the HVR-1950 - without any related pvrusb fixes needed. Obviously >> those changes weren't in any mainline kernel then. Since that time I >> believe the tuner fixes have indeed gotten into 2.6.27.y and probably >> also 2.6.26.y (but I haven't personally tested that at this point). So >> AFAIK, there is nothing wrong with 2.6.27.y - at least with respect to >> the pvrusb2 driver or anything it depends upon. >> >> After seeing roccomoretti's reply, I interpreted that to mean that the >> fixes hadn't made their way into the Ubuntu kernel yet. But now with >> Mike's comparison between the Ubuntu sources and v4l-dvb I'm a little >> confused. Are you sure roccomoretti that you were running the kernel >> version that Mike just compared? >> >> I don't run Ubuntu here, so I do not know what "2.6.27-7" corresponds >> with. That *could* correspond to vanilla kernel 2.6.27.7, but I don't >> really know. (In Debian this would definitely not be the case.) >> >> It might be a good experiment to grab vanilla kernel 2.6.27.7 from >> kernel.org, build that, and see if the tuning problem shows up again. >> If so, then we can compare the vanilla kernel tree with v4l-dvb and >> eliminate another source of uncertainty. > > DOH! > > I totally overlooked what Mike Isely just pointed out. > > I was looking at the ubuntu-intrepid kernel from a week or two ago... > The most recent version tag is, "UBUNTU: Ubuntu-2.6.27-10.20" > > I just looked back in history, and 2.6.27-7 does not include the > s5h1411 fixes that Mike was referring to. > > Please try the latest ubuntu-intrepid kernel 2.6.27-10 or later, and > report back as to whether or not the problem is yet reproducible. > > Thanks Mike -- I missed that one :-P
Apparently, 2.6.27-7 is the current release intrepid kernel. This kernel does not yet have the required fixes, but they are in the ubuntu-intrepid git tree. If you file a bug on Ubuntu's bug tracking system located at http://bugs.launchpad.net , maybe that can help get the Ubuntu kernel maintainers to release that fix sooner. Either way, it will be fixed in the intrepid release kernel eventually. -Mike _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
