[linux-dvb] DVB-S2 / Multiproto and future modulation support

Steven Toth stoth at linuxtv.org
Wed Sep 10 20:32:39 CEST 2008


Christophe Thommeret wrote:
> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
>>> Is this card able to deliver both S and T at the same time?
>> No, the hardware can do S/S2 or T.
> 
>> The driver in the S2API tree only has S/S2 enabled (for the time being).
> 
> So, maybe we have to think a bit about how to add support for this kind of 
> device.

This is already in progress, based on some work I did on the HVR3000 
bus-sharing changes a couple of years ago 
(http://linuxtv.org/hg/~stoth/hvr3000). People are interested in seeing 
this merged. Darron Board took the patches a long time ago and has been 
maintaining them. (Thank you)

What does this mean? Well, this is what it looks like to the applications:

/dev/dvb/adapter0/frontend0 DVB-S
/dev/dvb/adapter0/frontend1 DVB-T

I floated these patches in the linux-dvb mailing list a long time ago 
and the general feeling was of support for this approach.

I'm told myth already supports this. If anyone has experience running an 
HVR3000 with both DVB-T and DVB-T on Myth then I'd welcome their 
feedback here.


> I mean, if the driver provides different adapters/frontends (say 
> adapter0/frontend0 and adapter1/frontend0), a typical application will see 
> these as separate devices, and then when a user watch a S channel, the app 
> assumes that the T frontend is free while in fact it's not.
> For example, Kaffeine updates its channels list according to which channels 
> can be viewed (based on which frontends are free). So, if you are recording a 
> S channel, all channels on this freq are shown as available and all T 
> channels are also shown as available. But in the HVR4000 case, it's false, 
> since the T tuner isn't free.
> 
> Maybe a solution could be to have :
> - adapter0/frontend0 -> S/S2 tuner
> - adapter0/frontend1 -> T tuner

Correct, this : http://linuxtv.org/hg/~stoth/hvr3000/rev/3f78be7007f6

Quoting the original patch description:

"Multiple frontends on a single adapter support.

From: Steven Toth <stoth at hauppauge.com>

These patches are for review only.

The WinTV-HVR3000 has a single transport bus which is shared between
a DVB-T and DVB-S modulator. These patches build on the bus acquisition
cx88 work from a few weeks ago to add support for this.

So to applications the HVR3000 looks like this:
/dev/dvb/adapter0/fe0 (cx24123 DVB-S demod)
/dev/dvb/adapter0/fe1 (cx22702 DVB-T demod)

Additional boards continue as before, eg:
/dev/dvb/adapter1/fe0 (lgdt3302 ATSC demod)

The basic change is removing the single instance of the videobuf_dvb in
cx8802_dev and saa7134_dev(?) and replacing it with a list and some
supporting functions.

*NOTE* This branch was taken before v4l-dvb was closed for 2.6.19 so
two or three current cx88 patches appear to be reversed by this tree,
this will be cleaned up in the near future. The patches missing change
the mutex handing to core->lock, fix an enumeration problem.

For Review: The best place to start reviewing this patch
is videobuf_dvb. These core structures and functions are then implemented
in cx88 and (partially in) saa7134.

Signed-off-by: Steven Toth <stoth at hauppauge.com>"



> 
> So applications could know that these 2 frontends are exclusive.
> That would not require any API change, but would have to be a rule followed by 
> all drivers.
> 
> 

This would be a nice addition to the S2API tree. I'll collect the new 
patches and present another patchset for review.

S2API is shaping up nicely, we just have to make sure we don't overload 
the tree and lose sight of the basic goal.

- Steve





More information about the linux-dvb mailing list