Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hello Marc, sorry for late response, had BIG problems this month... I can test the ubuntu, can you tell me where to find the ISO so that I can install and test it ? Cheers, Thierry Marc a écrit : Thierry MERLE schreef: Hello I did a last test: kernel 2.6.17.10+latest v4l-dvb tree. Works flawlessly... Marc, do you run FC6 and Ubuntu on the same PC ? Maybe a hardware problem... I've had both on a Amilo 1655G. AMD Turion 64 1.8 ghz, 1Gb RAM. Marc ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On Saturday 10 February 2007 11:07, Hartmut Hackmann wrote: [snip] I understand the give the component name in it's own relevant place and not in the frontend code but the point is: there is no such place! And we can't easily create one because this would mean a API change - IMHO this is not an option. And the information is useless if it isn't reported to the user space. [snip] Is there an official wish-list for future versions of the API? If so then put it on the list and if/when a change is forced, for this or any other reason, it should be added. -- sig goes here... Peter D. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hi I just read your thread. I have a bit different suggestion. This is a hierarcial naming scheme. I also suggest Tuner numbering with 1 and 2, instead of 0 and 1. How to separate different devices? The device drivers aren't supposed to know anything about other devices. Udev tries to handle device separation and name aliasing. Applications and libraries could do that separation also. How to do device frontend - RF component separation? Before I bought a PCI card, I wanted to know that how many RF components (or tuners) it had. It was important, because then I know that how many different channels I can see or record at a same time. Then I decided to buy a card with one tuner. Usually the RF input is same for both tuners on a card. There aren't more than one TV antenna or satellite dish. A single tuner or multiple tuners are always on one card (PCI/USB). Thus this is my naming suggestion: Card 1 (two RF components, hierarcial naming scheme): TerraTec/qanu USB2.0 Highspeed DVB-T Receiver / Tuner 1 TerraTec/qanu USB2.0 Highspeed DVB-T Receiver / Tuner 2 Card 2 (single RF component): TerraTec/qanu USB2.0 Highspeed DVB-T Receiver The hierarcial naming scheme would thus work with single and multiple frontends. Tuner separation is done only when it is necessary. The average user doesn't need technical numbering starting from zero. Unfortunately the separate technical (frontend 0) and user numbering scheme (Tuner 1 ) would cause confusion with user support. Those who don't need technical support, are less confused with Tuner 1 and Tuner 2. The application or udev would be responsible to make names look different if there are two exactly identical cards. Regards, Marko Ristola Manu Abraham wrote: 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 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/11/07, Marko Ristola [EMAIL PROTECTED] wrote: Hi I just read your thread. I have a bit different suggestion. This is a hierarcial naming scheme. I also suggest Tuner numbering with 1 and 2, instead of 0 and 1. How to separate different devices? The device drivers aren't supposed to know anything about other devices. Udev tries to handle device separation and name aliasing. Applications and libraries could do that separation also. How to do device frontend - RF component separation? Before I bought a PCI card, I wanted to know that how many RF components (or tuners) it had. It was important, because then I know that how many different channels I can see or record at a same time. Then I decided to buy a card with one tuner. Usually the RF input is same for both tuners on a card. There aren't more than one TV antenna or satellite dish. A single tuner or multiple tuners are always on one card (PCI/USB). Thus this is my naming suggestion: Card 1 (two RF components, hierarcial naming scheme): TerraTec/qanu USB2.0 Highspeed DVB-T Receiver / Tuner 1 TerraTec/qanu USB2.0 Highspeed DVB-T Receiver / Tuner 2 Card 2 (single RF component): TerraTec/qanu USB2.0 Highspeed DVB-T Receiver The hierarcial naming scheme would thus work with single and multiple frontends. Tuner separation is done only when it is necessary. I did work on something similarly .. It needs some more cleanups before i can present it out. In the crudest way, it looks something of this sort, a dump of all the information currently it looks like this, the device nodes .. /dev/dvb/adapter0/ /adapter0 /frontend0 /dvr0 /demux0 /dev/dvb/adapter1/ /adapter0 /frontend0 /dvr0 /demux0 Feb 8 14:18:40 testbox kernel: [17280831.736000] ACPI: PCI Interrupt :02:0a.0[A] - GSI 22 (level, low) - IRQ 18 Feb 8 14:18:40 testbox kernel: [17280831.736000] irq: 18, latency: 64 Feb 8 14:18:40 testbox kernel: [17280831.736000] memory: 0xefeff000, mmio: 0xe5908000 Feb 8 14:18:40 testbox kernel: [17280831.736000] found a VP-1041 PCI DVB-S/DSS/DVB-S2 Multistandard device on (02:0a.0), Feb 8 14:18:40 testbox kernel: [17280831.736000] Mantis Rev 1 [1822:0031], irq: 18, latency: 64 Feb 8 14:18:40 testbox kernel: [17280831.736000] memory: 0xefeff000, mmio: 0xe5908000 Feb 8 14:18:40 testbox kernel: [17280831.74] MAC Address=[00:00:00:00:00:00] Feb 8 14:18:40 testbox kernel: [17280831.74] mantis_alloc_buffers (0): DMA=0x1993 cpu=0xd993 size=65536 Feb 8 14:18:40 testbox kernel: [17280831.74] mantis_alloc_buffers (0): RISC=0x42c3000 cpu=0xc42c3000 size=1000 Feb 8 14:18:40 testbox kernel: [17280831.74] DVB: registering new adapter (Mantis dvb adapter). Feb 8 14:18:40 testbox kernel: [17280831.74] DVB: registering adaptor (0) (Mantis Rev 1 on a VP-1041) Feb 8 14:18:40 testbox kernel: [17280832.26] mantis_frontend_init (0): Probing for STB0899 (DVB-S/DSS/DVB-S2) Feb 8 14:18:40 testbox kernel: [17280832.264000] stb0899_read_reg: Reg=[0xf000], data=82 Feb 8 14:18:40 testbox kernel: [17280832.264000] stb0899_get_dev_id: Device ID=[8], Release=[2] Feb 8 14:18:40 testbox kernel: [17280832.276000] stb0899_get_dev_id: Demodulator Core ID=[DMD1], Version=[1] Feb 8 14:18:40 testbox kernel: [17280832.288000] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1] Feb 8 14:18:40 testbox kernel: [17280832.288000] stb0899_attach: Attaching STB0899 Feb 8 14:18:40 testbox kernel: [17280832.288000] mantis_frontend_init (0): found STB0899 DVB-S/DSS/DVB-S2 frontend @0x68 Feb 8 14:18:40 testbox kernel: [17280832.288000] mantis_frontend_init (0): Probing for STB6100 tuner Feb 8 14:18:40 testbox kernel: [17280832.288000] stb6100_attach: Attaching Feb 8 14:18:40 testbox kernel: [17280832.288000] mantis_frontend_init (0): found STB6100 tuner @0x60 Feb 8 14:18:40 testbox kernel: [17280832.288000] mantis_frontend_init (0): Probing for LNBP21 SEC Feb 8 14:18:40 testbox kernel: [17280832.292000] DVB: registering frontend 0 (STB0899 Multistandard)... The average user doesn't need technical numbering starting from zero. Unfortunately the separate technical (frontend 0) and user numbering scheme (Tuner 1 ) would cause confusion with user support. Those who don't need technical support, are less confused with Tuner 1 and Tuner 2. The application or udev would be responsible to make names look different if there are two exactly identical cards. Yep, true .. the overall idea was to have this information to sysfs, thus solving another issue of device ordering, which some people were getting very frustrated with as well. regards, manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Am Donnerstag, den 08.02.2007, 10:31 +0100 schrieb Andrea Venturi: hermann pitton wrote: Hi, Am Mittwoch, den 07.02.2007, 10:07 +0400 schrieb Manu Abraham: On 2/7/07, hermann pitton [EMAIL PROTECTED] wrote: Hi! and the the cinergyT2 seems not to have a maintainer anymore. Is it broken or something like that ? unfortunately i don't have any hardware to test the same. If there are some users out there, who can provide feedback on the status, most probably it can be fixed in case it is broken. Marc reported it non functional on Ubuntu 6.10 with its 2.6.17 kernel. On FedoraCore6 it worked for him. Thierry from the video4linux usbvision project seems to be the only one else on the lists currently with such a device. He confirmed it working on vanilla 2.6.17.13 and even tested on vanilla 2.6.17.10, works. The current v4l-dvb on this older kernels is not yet tested for it. After it seemed there was also some precompiled module involved, I thought we found it. Marc is now back with a clean install of v4l-dvb and still doesn't get it to work since three weeks now. hi, i don't know if i'm getting on the right track. i missed the beginning of this thread. i see you speak of the cynergy T2. i do have it, so i can test any v4l-dvb tree, provided with some time. for example, i just tested this tree: http://linuxtv.org/hg/v4l-dvb?ca=a8819e65be60;type=bz2 on my vanilla kernel 2.6.18 on debian/unstable (i can provide the kernel config, if useful) the cinergy T2, with this tree, works: usbcore: registered new driver cinergyT2 usb 5-5: USB disconnect, address 7 usb 5-2.1: new high speed USB device using ehci_hcd and address 8 usb 5-2.1: configuration #1 chosen from 1 choice DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver). let me know if i need to try something else.. Hi Andrea, thanks for your support. The cinergyT2 was meant here only to remember that Holger and Gerd once had a discussion if linux-dvb should implement kernel i2c or not. Later on it was a problem to get dvb-pll included and it looked like Gerd should write endless out of tree kernel patches forever to get hybrid stuff working. IIRC, he sent all mainline anyway. http://www.linuxtv.org/pipermail/linux-dvb/2005-February/33.html and followups for the interested. This time Manu is a step ahead with multiproto considering naming conventions and v4l2 needs API changes to cover all the new hardware and to sync with linux-dvb anyway. So Mauro has the hard part. http://www.linuxtv.org/pipermail/linux-dvb/2006-October/013729.html - For Marc and the cinergyT2 on Ubuntu 6.10 latest is here. http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015800.html We should return to the thread and Marc should report, if the LED is still never on. Out of list I find reports that the device works on Ubuntu 6.10, also several with the usual usb disconnect troubles, but none with not at all. There is also no open bug at Ubuntu and v4l-dvb compiles against the latest Ubuntu kernel without warnings and anything for the cinergyT2, but that is all I can test so far. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hello I did a last test: kernel 2.6.17.10+latest v4l-dvb tree. Works flawlessly... Marc, do you run FC6 and Ubuntu on the same PC ? Maybe a hardware problem... Thierry hermann pitton a écrit : Hi, Am Mittwoch, den 07.02.2007, 10:07 +0400 schrieb Manu Abraham: On 2/7/07, hermann pitton [EMAIL PROTECTED] wrote: Hi! and the the cinergyT2 seems not to have a maintainer anymore. Is it broken or something like that ? unfortunately i don't have any hardware to test the same. If there are some users out there, who can provide feedback on the status, most probably it can be fixed in case it is broken. Marc reported it non functional on Ubuntu 6.10 with its 2.6.17 kernel. On FedoraCore6 it worked for him. Thierry from the video4linux usbvision project seems to be the only one else on the lists currently with such a device. He confirmed it working on vanilla 2.6.17.13 and even tested on vanilla 2.6.17.10, works. The current v4l-dvb on this older kernels is not yet tested for it. After it seemed there was also some precompiled module involved, I thought we found it. Marc is now back with a clean install of v4l-dvb and still doesn't get it to work since three weeks now. I pointed already that we are not always fully compatible with older kernels and that compat to distribution kernels is a not guaranteed feature anyway. Why he can't use the Ubuntu 2.6.17, I don't know. Marc, add at least dmesg for modprobe -v cinergyT2 or what you can find on error messages for it to your new report in the old thread. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Thierry MERLE schreef: Hello I did a last test: kernel 2.6.17.10+latest v4l-dvb tree. Works flawlessly... Marc, do you run FC6 and Ubuntu on the same PC ? Maybe a hardware problem... I've had both on a Amilo 1655G. AMD Turion 64 1.8 ghz, 1Gb RAM. Marc ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hi, CityK schrieb: Hi Manu, Manu Abraham wrote: ..snip.. So the concept of a frontend /nim/dc receiver are all names which are used in different contexts for different categories of devices. But it is quite hard to draw a distinct line, in such a case. It could be argued either ways. (Just like painting the bikeshed green) True enough. frontend = demod name (that's what we have currently), And that would technically be wrong ... although if it works into the coding framework, then so be it. Tuner is unimportant in this case as it doesn't have much of ops. I'm not certain what you mean by ops, but I gather that its minor role is what has lead to the project's definition of frontend to equal demod The project has never stated that at any place. Or is there ? Not that I know of -- I was just surmising that by what you wrote i.e. frontend = demod name (that's what we have currently) But i don't understand what your argument is -- for example when i have a tuner module (tin can inclusive of the demod) say one based on a STV0299, what advantage do you get by telling the user that it uses a TSA5059 PLL in the RF stage ? My point, as I mentioned I at the very beginning, wasn't related to the central premise. I understand that your argument in the discussion proper is: give the component name in it's own relevant place and not in the frontend code. What I had interjected was a sidebar, based largely upon your words of frontend = demod name (that's what we have currently). I thought it might be prudent to address this secondary point. In particular, it sounded like the project's definition of what constituted a frontend was a little constrained or limited in scope. I thought perhaps some discussion was warranted. I'm satisfied by your explanation. Lastly, as some food for thought -- we're already starting to see the move towards multi-purpose IC's. Examples: - Xceive 3028 tuner and analog demod; - ATI theater 650 analog demod, A/V decoder mpeg encoder. It likely will be a few years yet, but pretty soon we WILL run into the case where the traditional frontend and backend components on the DTV devices merge into one IC. How then does one define the abstraction? even though the entire thing is in one chip, it is an abstraction, so it doesn't matter whether the MPEG decoder and the demodulator are on the same chip. Still they are separate functional blocks requiring separate control (You can't ask a MPEG decoder to do some job on a RF signal) At that point, the concept will only refer to the relevant processing stages carried out in that single IC. IC = Integrated Circuit. Integration doesn't mean that you loose control. Of course noise is added into the system. The greater the integration the greater the noise, in a constant environment. Yes, I agree of course. But I think you missed what I was driving at. This section, which wasn't expressed well, was also related to my sidebar point, and not to the discussion proper -- specifically, I was directing commentary as to what a frontend should be defined as, and how it should be treated. Will this solution account for a single, multifunctional IC, as I have just described? Why not ? look at the MB86A15/16 (tuner + demod in a single chip in that sense) Okay. In case it wasn't clear (and it really wasn't :) ! ) I had switched gears here and was expressing concern, just as Hartmut and a few others had, in regards to naming conventions which are useful for the average user. As I said, I completely understand your argument: give the component name in it's own relevant place and not in the frontend code. But as I also prefaced at the start of the message, I don't think everyone was on the same page. I believe that the other prevailing point of contention was not so much as to whether having the demod name listed in the frontend output, but rather whether information relevant to the average user is being conveyed as a whole. My hypothetical example of a multifunctional, single IC was meant to exemplify this point although I think I trailed off with my train of thought. Anyway, not to worry. Cheers I understand the give the component name in it's own relevant place and not in the frontend code but the point is: there is no such place! And we can't easily create one because this would mean a API change - IMHO this is not an option. And the information is useless if it isn't reported to the user space. Just my opinion... Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
hermann pitton wrote: Hi, Am Mittwoch, den 07.02.2007, 10:07 +0400 schrieb Manu Abraham: On 2/7/07, hermann pitton [EMAIL PROTECTED] wrote: Hi! and the the cinergyT2 seems not to have a maintainer anymore. Is it broken or something like that ? unfortunately i don't have any hardware to test the same. If there are some users out there, who can provide feedback on the status, most probably it can be fixed in case it is broken. Marc reported it non functional on Ubuntu 6.10 with its 2.6.17 kernel. On FedoraCore6 it worked for him. Thierry from the video4linux usbvision project seems to be the only one else on the lists currently with such a device. He confirmed it working on vanilla 2.6.17.13 and even tested on vanilla 2.6.17.10, works. The current v4l-dvb on this older kernels is not yet tested for it. After it seemed there was also some precompiled module involved, I thought we found it. Marc is now back with a clean install of v4l-dvb and still doesn't get it to work since three weeks now. hi, i don't know if i'm getting on the right track. i missed the beginning of this thread. i see you speak of the cynergy T2. i do have it, so i can test any v4l-dvb tree, provided with some time. for example, i just tested this tree: http://linuxtv.org/hg/v4l-dvb?ca=a8819e65be60;type=bz2 on my vanilla kernel 2.6.18 on debian/unstable (i can provide the kernel config, if useful) the cinergy T2, with this tree, works: usbcore: registered new driver cinergyT2 usb 5-5: USB disconnect, address 7 usb 5-2.1: new high speed USB device using ehci_hcd and address 8 usb 5-2.1: configuration #1 chosen from 1 choice DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver). let me know if i need to try something else.. bye andrea venturi ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hi, Am Mittwoch, den 07.02.2007, 10:07 +0400 schrieb Manu Abraham: On 2/7/07, hermann pitton [EMAIL PROTECTED] wrote: Hi! and the the cinergyT2 seems not to have a maintainer anymore. Is it broken or something like that ? unfortunately i don't have any hardware to test the same. If there are some users out there, who can provide feedback on the status, most probably it can be fixed in case it is broken. Marc reported it non functional on Ubuntu 6.10 with its 2.6.17 kernel. On FedoraCore6 it worked for him. Thierry from the video4linux usbvision project seems to be the only one else on the lists currently with such a device. He confirmed it working on vanilla 2.6.17.13 and even tested on vanilla 2.6.17.10, works. The current v4l-dvb on this older kernels is not yet tested for it. After it seemed there was also some precompiled module involved, I thought we found it. Marc is now back with a clean install of v4l-dvb and still doesn't get it to work since three weeks now. I pointed already that we are not always fully compatible with older kernels and that compat to distribution kernels is a not guaranteed feature anyway. Why he can't use the Ubuntu 2.6.17, I don't know. Marc, add at least dmesg for modprobe -v cinergyT2 or what you can find on error messages for it to your new report in the old thread. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hi Manu, Manu Abraham wrote: ..snip.. So the concept of a frontend /nim/dc receiver are all names which are used in different contexts for different categories of devices. But it is quite hard to draw a distinct line, in such a case. It could be argued either ways. (Just like painting the bikeshed green) True enough. frontend = demod name (that's what we have currently), And that would technically be wrong ... although if it works into the coding framework, then so be it. Tuner is unimportant in this case as it doesn't have much of ops. I'm not certain what you mean by ops, but I gather that its minor role is what has lead to the project's definition of frontend to equal demod The project has never stated that at any place. Or is there ? Not that I know of -- I was just surmising that by what you wrote i.e. frontend = demod name (that's what we have currently) But i don't understand what your argument is -- for example when i have a tuner module (tin can inclusive of the demod) say one based on a STV0299, what advantage do you get by telling the user that it uses a TSA5059 PLL in the RF stage ? My point, as I mentioned I at the very beginning, wasn't related to the central premise. I understand that your argument in the discussion proper is: give the component name in it's own relevant place and not in the frontend code. What I had interjected was a sidebar, based largely upon your words of frontend = demod name (that's what we have currently). I thought it might be prudent to address this secondary point. In particular, it sounded like the project's definition of what constituted a frontend was a little constrained or limited in scope. I thought perhaps some discussion was warranted. I'm satisfied by your explanation. Lastly, as some food for thought -- we're already starting to see the move towards multi-purpose IC's. Examples: - Xceive 3028 tuner and analog demod; - ATI theater 650 analog demod, A/V decoder mpeg encoder. It likely will be a few years yet, but pretty soon we WILL run into the case where the traditional frontend and backend components on the DTV devices merge into one IC. How then does one define the abstraction? even though the entire thing is in one chip, it is an abstraction, so it doesn't matter whether the MPEG decoder and the demodulator are on the same chip. Still they are separate functional blocks requiring separate control (You can't ask a MPEG decoder to do some job on a RF signal) At that point, the concept will only refer to the relevant processing stages carried out in that single IC. IC = Integrated Circuit. Integration doesn't mean that you loose control. Of course noise is added into the system. The greater the integration the greater the noise, in a constant environment. Yes, I agree of course. But I think you missed what I was driving at. This section, which wasn't expressed well, was also related to my sidebar point, and not to the discussion proper -- specifically, I was directing commentary as to what a frontend should be defined as, and how it should be treated. Will this solution account for a single, multifunctional IC, as I have just described? Why not ? look at the MB86A15/16 (tuner + demod in a single chip in that sense) Okay. In case it wasn't clear (and it really wasn't :) ! ) I had switched gears here and was expressing concern, just as Hartmut and a few others had, in regards to naming conventions which are useful for the average user. As I said, I completely understand your argument: give the component name in it's own relevant place and not in the frontend code. But as I also prefaced at the start of the message, I don't think everyone was on the same page. I believe that the other prevailing point of contention was not so much as to whether having the demod name listed in the frontend output, but rather whether information relevant to the average user is being conveyed as a whole. My hypothetical example of a multifunctional, single IC was meant to exemplify this point although I think I trailed off with my train of thought. Anyway, not to worry. Cheers ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hi, Markus Rechberger schrieb: On 2/6/07, Manu Abraham [EMAIL PROTECTED] wrote: On 2/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Hartmut Hackmann wrote: Hi, folks Currently most boards report the type of the channel decoder as the frontend name. This has the disadvantage that if you have multiple (hybrid) cards with the same channel decoder type, you will not be able to distinguish them in the applications. Especially if you want to use one of them for analog- and and the other one for digital TV, this becomes a problem. In my personal repository, i have a change that reports the board name instead in saa7134-dvb. Should i leave this in or remove it to stay consistent with other cards? In the past, cx88-dvb would report the board name, but I've changed it to report the frontend name in this changeset: http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=d1b4025b0ec8 --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Aug 23 15:58:06 2005 + +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Aug 25 06:06:52 2005 + @@ -412,11 +412,6 @@ static int dvb_register(struct cx8802_de dev-dvb.frontend-ops-info.frequency_max = dev-core-pll_desc-max; } - /* Copy the board name into the DVB structure */ - strlcpy(dev-dvb.frontend-ops-info.name, - cx88_boards[dev-core-board].name, - sizeof(dev-dvb.frontend-ops-info.name)); - /* register everything */ return videobuf_dvb_register(dev-dvb, THIS_MODULE, dev); } At the time, I thought it would be more consistent to report the name of the demodulator, since it is in fact the frontend driver that is being reported here. However, now I am aware that some other dvb drivers report the device name instead of the frontend driver's name For instance, any dvb-usb device will report the device's textual name instead of the actual frontend's name. In the case of dvb-usb, I do prefer that the device name is being shown, although I feel that we should be consistent across the board. Should I add those lines back to cx88-dvb so that the board's name will be displayed instead of the frontend driver's name? 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. Markus I would not call this unimportant and i agree, the channel decoder type tells nothing to the average user. And even the kernel log doesn't tell much more... Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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. 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. Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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? -- Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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? Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/7/07, Michael Krufky [EMAIL PROTECTED] wrote: 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 think you got a lot confused .. manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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. manu ___ linux-dvb mailing list linux-dvb@linuxtv.org
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
I don't want to derail the underlying discussion at hand (although it strikes me as not everyone talking about the same thing), but I do want to just pick up on a particular point: Manu Abraham wrote: for the average person, frontend = RF module, inclusive of the demod And if that is what the average person believes, then they would indeed be correct. (Although I have serious doubts that the average person knows what a frontend is ;) ) A Frontend is just an abstraction. In some cases a frontend can be described entirely by a NIM/RF module such as the LGH06xF (which is inclusive of the demodulator) or, in the case of older designs like the pcHDTV HD-2000 or DVICO FusionHDTV3 series, both the RF module AND the external demodulator comprise the frontend. frontend = demod name (that's what we have currently), And that would technically be wrong ... although if it works into the coding framework, then so be it. Tuner is unimportant in this case as it doesn't have much of ops. I'm not certain what you mean by ops, but I gather that its minor role is what has lead to the project's definition of frontend to equal demod Lastly, as some food for thought -- we're already starting to see the move towards multi-purpose IC's. Examples: - Xceive 3028 tuner and analog demod; - ATI theater 650 analog demod, A/V decoder mpeg encoder. It likely will be a few years yet, but pretty soon we WILL run into the case where the traditional frontend and backend components on the DTV devices merge into one IC. How then does one define the abstraction? At that point, the concept will only refer to the relevant processing stages carried out in that single IC. 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 this solution account for a single, multifunctional IC, as I have just described? Cheers. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On Wednesday 07 February 2007 09:15, 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. I feel qualified to comment for the ignorant user. ;-) My guess is that they would expect something like; MSI [EMAIL PROTECTED] A/D, using analogue tuner or MSI [EMAIL PROTECTED] A/D, using digital tuner. I would also guess that the the people reading this list would expect much more detailed information, such as, SAA7134 etc. 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 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- sig goes here... Peter D. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/7/07, CityK [EMAIL PROTECTED] wrote: I don't want to derail the underlying discussion at hand (although it strikes me as not everyone talking about the same thing), but I do want to just pick up on a particular point: Manu Abraham wrote: for the average person, frontend = RF module, inclusive of the demod And if that is what the average person believes, then they would indeed be correct. (Although I have serious doubts that the average person knows what a frontend is ;) ) A Frontend is just an abstraction. In some cases a frontend can be described entirely by a NIM/RF module such as the LGH06xF (which is inclusive of the demodulator) or, in the case of older designs like the pcHDTV HD-2000 or DVICO FusionHDTV3 series, both the RF module AND the external demodulator comprise the frontend. There are different cases, for example * a complete tuner is never in one chip, unless it is a silicon tuner * a silicon tuner and a demod is never in one chip, unless it is a Direct Conversion receiver, similar to the Superhet radio's, no Intermediate Frequencies in such a case. when you have a device implemented in silicon and the integration is high, similarly to your integration constant C the greater the integration, the greater the noise floor. when you have a demod, these days many demods are implemented on a FPGA . In such cases the operational noise is too high for the analog core to be very near the digital core. In any RF design, looking at the electrical side of it, we do have separate electrical grounds such as Analog RF ground and Digital RF ground separately, to avoid loops which create oscillations/intermodulate distortion. So the concept of a frontend /nim/dc receiver are all names which are used in different contexts for different categories of devices. But it is quite hard to draw a distinct line, in such a case. It could be argued either ways. (Just like painting the bikeshed green) frontend = demod name (that's what we have currently), And that would technically be wrong ... although if it works into the coding framework, then so be it. Tuner is unimportant in this case as it doesn't have much of ops. I'm not certain what you mean by ops, but I gather that its minor role is what has lead to the project's definition of frontend to equal demod The project has never stated that at any place. Or is there ? But i don't understand what your argument is -- for example when i have a tuner module (tin can inclusive of the demod) say one based on a STV0299, what advantage do you get by telling the user that it uses a TSA5059 PLL in the RF stage ? Lastly, as some food for thought -- we're already starting to see the move towards multi-purpose IC's. Examples: - Xceive 3028 tuner and analog demod; - ATI theater 650 analog demod, A/V decoder mpeg encoder. It likely will be a few years yet, but pretty soon we WILL run into the case where the traditional frontend and backend components on the DTV devices merge into one IC. How then does one define the abstraction? even though the entire thing is in one chip, it is an abstraction, so it doesn't matter whether the MPEG decoder and the demodulator are on the same chip. Still they are separate functional blocks requiring separate control (You can't ask a MPEG decoder to do some job on a RF signal) At that point, the concept will only refer to the relevant processing stages carried out in that single IC. IC = Integrated Circuit. Integration doesn't mean that you loose control. Of course noise is added into the system. The greater the integration the greater the noise, in a constant environment. 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 this solution account for a single, multifunctional IC, as I have just described? Why not ? look at the MB86A15/16 (tuner + demod in a single chip in that sense) manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/7/07, hermann pitton [EMAIL PROTECTED] wrote: Hi! and the the cinergyT2 seems not to have a maintainer anymore. Is it broken or something like that ? unfortunately i don't have any hardware to test the same. If there are some users out there, who can provide feedback on the status, most probably it can be fixed in case it is broken. regards, manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [RFC] Should a DVB frontend report the board name?
Hi, folks Currently most boards report the type of the channel decoder as the frontend name. This has the disadvantage that if you have multiple (hybrid) cards with the same channel decoder type, you will not be able to distinguish them in the applications. Especially if you want to use one of them for analog- and and the other one for digital TV, this becomes a problem. In my personal repository, i have a change that reports the board name instead in saa7134-dvb. Should i leave this in or remove it to stay consistent with other cards? Best regards Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/6/07, Hartmut Hackmann [EMAIL PROTECTED] wrote: Hi, folks Currently most boards report the type of the channel decoder as the frontend name. This has the disadvantage that if you have multiple (hybrid) cards with the same channel decoder type, you will not be able to distinguish them in the applications. Especially if you want to use one of them for analog- and and the other one for digital TV, this becomes a problem. Why do you need the board name ? If it is the second frontend, it shoud be just frontend 1 manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
Hartmut Hackmann wrote: Hi, folks Currently most boards report the type of the channel decoder as the frontend name. This has the disadvantage that if you have multiple (hybrid) cards with the same channel decoder type, you will not be able to distinguish them in the applications. Especially if you want to use one of them for analog- and and the other one for digital TV, this becomes a problem. In my personal repository, i have a change that reports the board name instead in saa7134-dvb. Should i leave this in or remove it to stay consistent with other cards? In the past, cx88-dvb would report the board name, but I've changed it to report the frontend name in this changeset: http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=d1b4025b0ec8 --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Aug 23 15:58:06 2005 + +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Aug 25 06:06:52 2005 + @@ -412,11 +412,6 @@ static int dvb_register(struct cx8802_de dev-dvb.frontend-ops-info.frequency_max = dev-core-pll_desc-max; } - /* Copy the board name into the DVB structure */ - strlcpy(dev-dvb.frontend-ops-info.name, - cx88_boards[dev-core-board].name, - sizeof(dev-dvb.frontend-ops-info.name)); - /* register everything */ return videobuf_dvb_register(dev-dvb, THIS_MODULE, dev); } At the time, I thought it would be more consistent to report the name of the demodulator, since it is in fact the frontend driver that is being reported here. However, now I am aware that some other dvb drivers report the device name instead of the frontend driver's name For instance, any dvb-usb device will report the device's textual name instead of the actual frontend's name. In the case of dvb-usb, I do prefer that the device name is being shown, although I feel that we should be consistent across the board. Should I add those lines back to cx88-dvb so that the board's name will be displayed instead of the frontend driver's name? I must say, almost all of *my* devices have a lgdt3303 inside them. Having the actual device's name being displayed might make it a bit easier to tell the difference between each of the them. What does everybody else think? -Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Hartmut Hackmann wrote: Hi, folks Currently most boards report the type of the channel decoder as the frontend name. This has the disadvantage that if you have multiple (hybrid) cards with the same channel decoder type, you will not be able to distinguish them in the applications. Especially if you want to use one of them for analog- and and the other one for digital TV, this becomes a problem. In my personal repository, i have a change that reports the board name instead in saa7134-dvb. Should i leave this in or remove it to stay consistent with other cards? In the past, cx88-dvb would report the board name, but I've changed it to report the frontend name in this changeset: http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=d1b4025b0ec8 --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Aug 23 15:58:06 2005 + +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Aug 25 06:06:52 2005 + @@ -412,11 +412,6 @@ static int dvb_register(struct cx8802_de dev-dvb.frontend-ops-info.frequency_max = dev-core-pll_desc-max; } - /* Copy the board name into the DVB structure */ - strlcpy(dev-dvb.frontend-ops-info.name, - cx88_boards[dev-core-board].name, - sizeof(dev-dvb.frontend-ops-info.name)); - /* register everything */ return videobuf_dvb_register(dev-dvb, THIS_MODULE, dev); } At the time, I thought it would be more consistent to report the name of the demodulator, since it is in fact the frontend driver that is being reported here. However, now I am aware that some other dvb drivers report the device name instead of the frontend driver's name For instance, any dvb-usb device will report the device's textual name instead of the actual frontend's name. In the case of dvb-usb, I do prefer that the device name is being shown, although I feel that we should be consistent across the board. Should I add those lines back to cx88-dvb so that the board's name will be displayed instead of the frontend driver's name? 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. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
On 2/6/07, Manu Abraham [EMAIL PROTECTED] wrote: On 2/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Hartmut Hackmann wrote: Hi, folks Currently most boards report the type of the channel decoder as the frontend name. This has the disadvantage that if you have multiple (hybrid) cards with the same channel decoder type, you will not be able to distinguish them in the applications. Especially if you want to use one of them for analog- and and the other one for digital TV, this becomes a problem. In my personal repository, i have a change that reports the board name instead in saa7134-dvb. Should i leave this in or remove it to stay consistent with other cards? In the past, cx88-dvb would report the board name, but I've changed it to report the frontend name in this changeset: http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=d1b4025b0ec8 --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Aug 23 15:58:06 2005 + +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Aug 25 06:06:52 2005 + @@ -412,11 +412,6 @@ static int dvb_register(struct cx8802_de dev-dvb.frontend-ops-info.frequency_max = dev-core-pll_desc-max; } - /* Copy the board name into the DVB structure */ - strlcpy(dev-dvb.frontend-ops-info.name, - cx88_boards[dev-core-board].name, - sizeof(dev-dvb.frontend-ops-info.name)); - /* register everything */ return videobuf_dvb_register(dev-dvb, THIS_MODULE, dev); } At the time, I thought it would be more consistent to report the name of the demodulator, since it is in fact the frontend driver that is being reported here. However, now I am aware that some other dvb drivers report the device name instead of the frontend driver's name For instance, any dvb-usb device will report the device's textual name instead of the actual frontend's name. In the case of dvb-usb, I do prefer that the device name is being shown, although I feel that we should be consistent across the board. Should I add those lines back to cx88-dvb so that the board's name will be displayed instead of the frontend driver's name? 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. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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 ;) -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Should a DVB frontend report the board name?
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 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
