Hi! Am Mittwoch, den 07.02.2007, 04:31 +0400 schrieb Manu Abraham: > On 2/7/07, Hartmut Hackmann <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Michael Krufky schrieb: > > > Manu Abraham wrote: > > >> On 2/7/07, Hartmut Hackmann <[EMAIL PROTECTED]> wrote: > > >>> > > >>> Manu Abraham schrieb: > > >>>> On 2/6/07, Christophe Thommeret <[EMAIL PROTECTED]> 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 _______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
