On Sat, 13 Jun 2009, fivenote wrote: > Mike, > > Sorry, but I didn't see this list of steps you asked for last night. > Do you still need me to do this? I think I've done 1-5, but not steps > 6-8.
It's not so important now. I have traction on the problem. But for what it's worth, this probably would have revealed it working correctly for you - since then MythTV would not have gotten a chance to get its fingers into the driver :-) Just to summarize what's going on... >From my limited knowledge of the cx25840 (it is actually a cx25843), there is a hardware scaler in the chip. The cx25840 driver always sets the "native" capture resolution to be 720 pixels wide. So, when we capture 720, there's no scaling needed and the scaler is apparently left disabled. But when the horizontal capture resolution is set to something else, the cx25840 module programs the scaler appropriately to generate that result. When I last looked at this in 2006, the best I could figure was that the chip's hardware scaler was not being correctly programmed, thus anything but 720 produced corrupted video. Another mystery at the time was why only the pvrusb2 driver was being affected by this. A little while later it was discovered that triggering the cx25840 driver's VBI initialization caused the problem to go away - which is why only the pvrusb2 driver was being burned. Other drivers had VBI support but since the pvrusb2 driver did not, I never bothered with that setup. The "fix" I did in 2006 was to trigger essentially a dummy VBI initialization within the cx25840 driver. I really did not understand that chip very well and so I considered myself lucky that this was enough to fix it. Fast forward to now, and things have changed. With stock kernels 2.6.26 -> 2.6.28 (and probably higher - it's all I've tested so far), this problem exists for the HVR-1950 (which also has a cx25843). In fact, since 2.6.26 was the first kernel whose pvrusb2 driver included support for the HVR-1950, that hardware has basically been broken all along :-( However at the same time, the 24xxx device continues to work fine. This is very strange because it's the same chip in both so I really would expect it to either work in both types of hardware or fail in both types. It's even stranger that nobody noticed this until now - HVR-1950 was declared supported well over a year ago. But likely most people using the HVR-1950 are probably only running it in digital mode and thus don't get hit by this. Or maybe others have independantly figured out that 720 works and just haven't bothered to warn me about it. The fact that 24xxx devices worked all along is probably why I missed this. I then discovered that with the current v4l-dvb snapshot, the 24xxx device is also broken the same way! (And given this discovery I strongly suspect that anything but 720 horizontal resolution for the 24xxx is probably broken once again starting with kernel 2.6.30.) That pissed me off. I ended up spending far too much time last night in v4l-dvb trying to figure out when it broke. I basically binary-searched my way through a thousand or so revisions of that repository in an attempt to find when the problem was reintroduced. What fun. But I got my answer (and if I had put a little more thought into it earlier I could have found it quicker). Just now I confirmed it, though unfortunately this does not yet lead to a solution. Last March I made a bunch of pvrusb2 driver changes to support a new driver binding model in v4l-dvb. There is now a concept of a "sub-device" in v4l-dvb, and along with it a new way to link up sub-device drivers when bringing up a driver such as pvrusb2. Previously those sub-device drivers were just I2C client drivers and we used kernel I2C mechanisms to send commands to those client drivers. But now with the new mechanism in place, there is an entirely different means for issuing commands. About 15 minutes ago I wound my v4l-dvb repo back to the point just after I had added sub-device support in the pvrusb2 driver. I also did the same thing with the standalone driver. Then I compiled the standalone driver against that v4l-dvb snapshot and tried the whole thing in kernel 2.6.28.10. I tried it twice. The first time I tried it using the sub-device communication / binding mechanism. Then - with the SAME repository and standalone driver - I did it again using the old mechanism. Unlike the in-V4L version of the pvrusb2 driver, the standalone pvrusb2 driver includes both implementations, selectable at compile time via an ifdef - I do this in order to continue supporting older stock kernels where the new mechanism doesn't exist. So guess what: The problem cleared when I shifted back to the old binding mechanism! I did verify that even with the new sub-device binding mechanism that I'm still issuing that VBI setup command. So that's not the problem. Something else is going on. Either I'm missing something in my use of the new mechanism or the cx25840 driver itself is missing some critical behavior with the new mechanism. I'm going to try to solve that now. The solution, whatever it is, should restore correct 24xxx device behavior. And I'm *hoping* that in fixing this I'm going to then learn enough to understand why HVR-1950 has been broken independant of the binding mechanism in use. If we're lucky I (or somebody) will figure this out before the end of the day today. I think I understand the cx25840 a little better now than 2 years ago so I might be able to get to the bottom of it this time. I welcome help from anyone who might have a good understanding of the cx25840 chip architecture. Cross your fingers. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
