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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>" > > 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 _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
