On 06.04.2010 14:07, Teemu Rantanen wrote:
Hi,
the right way, of course, is to fix the driver, and make vdr check what device can do. I'm glad Petri had time to test it, and I hope to see the patch in next version of vdr. But I couldn't use the driver patch even if I wanted to patch kernel myself, as I actually have 3 devices with TDA10023 frontend, and only one of them is "reddo" :-)
Well, as I said, then the driver needs to detect which one is the "reddo" and only clear the FE_CAN_QAM256 for that particular one.
But i'm afraid my time for this project just run out. I'll continue later if/when the reddo driver patch arrives, I will test it, but until then I'll have to manage with the plugin, even if it crashes or not at exit(). I'll make an empty plugin with an empty hook, and if it still crashes at exit() it's not my fault :-)
I'll be glad to apply any fix to the core VDR code you can come up with.
One more thought. Would it be possible to add vendor/product id as a method for cDevice (as well as the utility method for filename->id). And
First of all somebody should clarify the names. Is it idVendor or subsystem_vendor?
would it be possible (for a plugin) to manage device feature list and remove QAM256 from the reddo device. This way the plugin wouldn't have to actually do anything anymore when vdr is running, only fix this one time at plugin startup, and everything else would work 100% the same way before/after the driver is changed.
With a properly working driver you won't even need this at all ;-)
Even though this isn't the right way, but we aren't living in a perfect world :-)
I'm afraid that would only take the pressure off of fixing the driver.
2010/4/5 Klaus Schmidinger <Klaus.Schmidinger@tvdr.de mailto:Klaus.Schmidinger@tvdr.de>
Well, then the driver needs to make a finer distinction and *properly* set FE_CAN_QAM256.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr