[linux-dvb] [RFC] Should a DVB frontend report the board name?

Manu Abraham abraham.manu at gmail.com
Wed Feb 7 01:31:53 CET 2007


On 2/7/07, Hartmut Hackmann <hartmut.hackmann at t-online.de> wrote:
> Hi,
>
> Michael Krufky schrieb:
> > 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
> >>> the
> >>>>>>> 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
> >> scenario.
> >>
> >> 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
> >>> type.
> >>
> >> 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
> >
> > Manu,
> >
> > 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?
> >
>
> I must say: I missed the multiple frontend point.
>
> Let me chage my question a bit:
> Should a DVB FE_GET_INFO call report a name defined in the board layer driver?
>
> I assume that each frontend needs to be attached to the host bridge. In this
> code sequence, a unique name can be assigned to each frontend.
> In this case, we should define naming conventions which are useful for the
> average user on application layer.
>
> We can of corse get this (probably better) with a new API call. But this is a
> API change and when will this be supported by the APPs?
>

Just adding API calls makes matters worser only , everytime there's a
problem, applications will need to change, because of API changes.
(A very clear example of such flat call's can be seen in the V4L1/2
API, which is it's drawback)

That's why i went working on a hierarchial method where the adapter
does device abstraction. This has various advantages as mentioned,
moreover the change required is once, that's why i mentioned alongwith
multiproto, since with multiproto anyway applications need to change
to work in a nice way.

manu



More information about the linux-dvb mailing list