Manu Abraham writes: > No that is wrong.. That was because Jamie originally made dummy frontend > routines for the dst, and thereby somebody who moved the code around, > without the idea, thought the dst was a frontend driver. Many people do > think that the dst is a frontend. *This was actually wrong*. > > There might be more dst hardware, that we have not seen yet ! I have one > such thing, which i am yet to get the driver moving, but waiting to > finish upon this. Yes, there is. The Twinhan DVB-S USB hardware uses the same kind of messages to the frontend, just via USB instead of the Bt878 I2C port. > As per what you state, then the CA features and the rest of the other > features will also be in the frontend, which is not the case as per the > linux DVB API. Exactly. One would need another layer with a "Twinhan command protocol" and the card driver only supplies the I2C, USB, etc. interface. This is kind of overkill right now when all cards on the market with this protocol are Bt878 based (or is the DVB-S USB adapter available?). In any case I would still keep the frontend and CA code for Twinhan in one file. > > You should have a look at the budget-core driver and the associated > > sub drivers, they all do the same as this. > > > > Nope.. It is totally different.. I too thought like that before i laid > my hands on the documents awhile back. Yes, the other cards are different because they still give access to the actual frontend I2C bus. The Twinhan cards hide this behind another abstraction layer. Ralph
