[linux-dvb] Multiple fronends on a single shared ransport bus

Steven Toth stoth at hauppauge.com
Wed Oct 4 18:08:52 CEST 2006


The WinTV-HVR3000 has a single transport bus on the cx2388x shared 
between a cx22702 DVB-T and a cx24123 DVB-S. The windows driver manages 
the hardware to ensure an application can stream from one or the other 

In terms of Linux and the current tree, it's a trivial thing to add 
basic DVB-T only support, or it's a trivial thing to add DVB-S only 
support - mainly because both of these demod/tuners are already 
supported in the tree. Adding dynamic switching between either demod is 
an interesting problem.

On one hand with solution #1 we have the multiproto tree which tries to 
address some of these issues (at the frontend ops only, with no 
considerations to the implementation within the frameworks).

On the other hand with solution #2 (for current support modulation 
schemes) why don't we simply register multiple frontends during 

I created a cx88 patch last night to try this and the only questionable 
result is that you end up with a solution like this:

/dev/dvb/adapter0/fe0   .. cx24123 DVB-S on a HVR3000
/dev/dvb/adapter1/fe0   .. cx22702 DVB-T on the same HVR3000
/dev/dvb/adapter2/fe0   .. dvico ATSC LG demod I also had installed.

The simple thing about a solution like this is that:
a. a/t/szap -a <fenum> worked with zero changes.
b. The recent cx88 bus arbitration patches ensured that only one of 
adapter0/fe0 or adapter1/fe could be opened at any one time. (As expected).

I don't see solution #2 as a replacement for solution #1, but the 
patches are pretty trivial and localised within a single framework.

A few consideration:

How will new or existing applications deal with solution#2?
Do any existing drivers deliver adapter0/fe0 and adapter0/fe1 and which 
applications support that?
How do other products with multiple transport paths and frontends expose 
their features in /dev/dvb?



More information about the linux-dvb mailing list