[linux-dvb] [RFC] Should a DVB frontend report the board name?
mkrufky at linuxtv.org
Tue Feb 6 23:26:26 CET 2007
Manu Abraham wrote:
> On 2/7/07, Hartmut Hackmann <hartmut.hackmann at t-online.de> wrote:
>> Manu Abraham schrieb:
>> > On 2/6/07, Christophe Thommeret <hftom at free.fr> wrote:
>> >> Le mardi 06 février 2007 01:34, Markus Rechberger a écrit:
>> >> > > The name of a frontend should be that of the frontend itself
>> and not
>> >> > > the board, if it reports the board name then it is wrong, since
>> >> > > board is not the frontend.
>> >> >
>> >> > not that this is very important but I've seen that some people were
>> >> > confused because of displaying the name of the demodulator, they
>> >> > stated out that they own product xy and not a ZL10353, MT352, etc.
>> >> Indeed, i think that for a user
>> >> "TerraTec/qanu USB2.0 Highspeed DVB-T Receiver"
>> >> makes more sense than
>> >> "ST STV0299 DVB-S"
>> >> but in the latter case, the board name
>> >> "Philips Semiconductors SAA7146 (rev 01)"
>> >> is also somewhat "mysterious" when the user would expect
>> >> "WinTV Nova CI"
>> >> ;)
>> > The issue is that the board name shouldn't be the name of the frontend.
>> > I did have the issue taht which you mentioned, but that i did have a
>> > fix to it by using the adapter device that i mentioned sometime back
>> > in another thread on a mantis bridge.
>> > With this it gives the bridge name, Generic name and the frontend
>> > name, all in it's own relevant place and not in the frontend. it will
>> > be just messing up the frontend to a state where it will be hopeless.
>> > for example:
>> > bridge name = "Mantis PCI rev 1.0"
>> > Generic name = "VP-1034"
>> > frontend name = "MB86A16 DVB-S/DSS DC receiver"
>> > It additionally fixes some other issues as well, such as handling
>> > bridge reset 's etc.
>> > Will post the changes after i have cleaned it up, most probably will
>> > push it along with the multiproto/stb0899 tree.
>> > Manu
>> Hm, we technical guys tend to associate "frontend" with the channel
>> decoder / tuner combination but the average user can can easily assume
>> that the frontend is the entire card. He has no idea what the functions
>> of the chips are.
> frontend = demod name (that's what we have currently), Tuner is
> unimportant in this case as it doesn't have much of ops.
> for the average person, frontend = RF module, inclusive of the demod
> the problem comes when you have 2 different frontends on one bridge.
> The user get's even more confused. Tune to board frontend 0 /1 ? which
> is frontend 0 which is frontend 1 ?
> There needs to be clear distinction when multiple devices exists.
> So in your case you are always tuning to your board name, irrespective
> of the number of frontends. IMHO, in the case where you had one
> frontend (with demod as name) is not as confusing compared to this
> Assuming that a board has multiple demods.
>> But ack, we should be as precise as possible.
>> So the next question is: If we have the entries you propose, how do these
>> get reported to user space? Currently, the API only reports the frontend
> In multiproto, there is DVBFE_GET_INFO, working with that as a base.
> It is extendable to the adapter object.
> Currrently playing around with a bit with some devices on the same in
> that aspect
I don't think that Hartmut is talking about multiple frontends per adapter, as
you are describing.
Hartmut is trying to establish a means in telling the difference between the
frontends installed on the multiple devices in a single given system.
For instance, I have a mythtv backend server with five PCI cards inside... each
of which use the LG DT3303 ATSC demod.
Given that each of these frontends identify themselves as an LG Electronics DT
3303, how does the user know which frontend is associated to the FusionHDTV 5
Gold? Which one is the AirStar HD5000? Which one is the FusionHDTV5 USB Gold?
Does this explain the question any better?
More information about the linux-dvb