Hi,
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
demod.
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
dvb_register?
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?
Regards,
Steve
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
