On 06.04.2010 14:07, Teemu Rantanen wrote:
> 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.schmidin...@tvdr.de
> Well, then the driver needs to make a finer distinction and *properly*
> set FE_CAN_QAM256.
> vdr mailing list
vdr mailing list