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

hermann pitton hermann-pitton at arcor.de
Wed Feb 7 03:36:35 CET 2007


Hi!

Am Mittwoch, den 07.02.2007, 04:31 +0400 schrieb Manu Abraham:
> 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.

Fine, at least it is back again for the prize we lost Gerd and Johannes
and the the cinergyT2 seems not to have a maintainer anymore.

Hopefully we get it better in the next round.
Plenty of time seems to be there.

Cheers,
Hermann





More information about the linux-dvb mailing list