Re: [linux-dvb] [PATCH] Userspace tuner
Hi, On 9/13/07, Dâniel Fraga <[EMAIL PROTECTED]> wrote: > Well, I'd like to see Linus' opinion about this, because while > programmers keep discussing this, users are waiting forever... so if > Markus has a concrete and better solution, why don't use it? > > And as far as I know, Markus is the programmer who is most > interested in this code. I didn't see anybody else in the world doing > his work... > > And I always had a impression that if most of things could be > done in user space, than it will be better (for example, devfs -> udev). > Why do everything in kernel space? Lets put *less* code in the kernel, > not more code. And besides that, code in user space can be changed > easily. Code in kernel has to wait a long time for Linus to accept (*if* > he accepts). > It's not only about userspace here, some hardware needs newer features discussing those requirements (as I did with Mauro a while ago through Mail) end up nowhere. It was just about Analogue Audio standards. There are a few ways to solve that problem but in the end nothing came up which would have met that issue, although the solution I proposed didn't seem to be good enough either for him. Regarding binary drivers just read: http://www.linuxtv.org/v4lwiki/index.php/Avermedia it has been like that for years and I expect Avermedia to finally just remove their modules. I don't even see that Avermedia is the evil company by releasing the binary modules here. They are just at a bad position since the tunercode in that driver which comes from another company puts these restrictions onto everything. We currently have an implementation that works, although it works by downloading several firmwares for several devices or even several countries. This is not what I want to have in future since it's not needed and it's also hard to manage for distributors. All those differences could be adjusted by software even without module parameter hacks. The basic idea behind the Userspace drivers is since there's another project which should add a userspace library infront of video4linux devicenodes this library could directly reuse for example the userspace tuning, demodulator or videodecoder code by using for example the i2c-dev infrastructure. This would lateron make the kernelstub which I'm integrating for the em28xx obsolete (which I'm fine with), although such a library could directly reuse the userspace code without any code changes. However the others want to manage their devices I don't want to force anyone to do something although I aim at getting the devices which I received by several vendors last year integrated properly. Those companies are not only focussed in selling their devices in european or american countries only. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem about the video_mux function.
On 9/13/07, kevin liu <[EMAIL PROTECTED]> wrote: > Dear Markus: > I am studying the em28xx source code. > But I am puzzled by the function video_mux. > It seems that the function does nothing there. > Could you explain it ? > video_mux is a video input selector in the em28xx. The value usually gets passed forward to the tvp5150 or saa7115. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
Well, I'd like to see Linus' opinion about this, because while programmers keep discussing this, users are waiting forever... so if Markus has a concrete and better solution, why don't use it? And as far as I know, Markus is the programmer who is most interested in this code. I didn't see anybody else in the world doing his work... And I always had a impression that if most of things could be done in user space, than it will be better (for example, devfs -> udev). Why do everything in kernel space? Lets put *less* code in the kernel, not more code. And besides that, code in user space can be changed easily. Code in kernel has to wait a long time for Linus to accept (*if* he accepts). Linus could put an end to this discussion, since he will say the final word. On Thu, 13 Sep 2007 01:10:55 +0200 "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > Let's add the LKML to this. > > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > Markus, > > > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > > Following patch adds the possibility to implement tuner drivers in > > > > userspace. > > > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > > give you my feedback about it. > > > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > > means that, once a newer API is created, this should remain supported > > > for all future versions. So, such APIs should be carefully analyzed and > > > accepted by the community, before going to mainstream. > > > > > > > The V4L and DVB API is stable at the moment because it's at a stage > > which is sufficient for older devices but not sufficient for newer > > devices anymore. > > To support newer device it needs a change. > > > > > I don't see any technical reason why tuner drivers should be moved to > > > userspace. Looking at xc3028 device, the driver is very simple and > > > doesn't require any special treatment that it isn't possible to be done > > > at kernel. There are already some implementations on kernelspace that > > > works fine. > > > > > > > As from my side to support the xceive driver properly it needs a > > rewrite and a proper API description. Since it's not possible to > > discuss any API changes I will work around at least for those devices > > which I can support for. > > > > > On the other hand, a TV driver without a tuner is a broken driver. With > > > parts of the driver being at userspace, this means to add undesired > > > complexity at the drivers architecture, while not bringing any benefit. > > > > > > If you look at V4L history, the first drivers started at userspace, > > > being migrated to kernelspace, where we have the proper scenario for > > > managing those devices. > > > > > > Another aspect that should be analyzed is what is desired by the > > > community: > > > > don't get me wrong but the existing community is rather small and > > kicking off people who are interested in changing things. > > I recently had a talk with someone and I've been told that I'm kicking > > off people. > > Guess why I kick off people? -> because they do not contribute in a > > productive way which also means submitting patches. Optical useless > > changes don't make any difference at the functionality in the end. And > > my requirements are ignored constantly here. > > > > > kernelspace tuners or userspace tuners. Keeping support for > > > both at long term doesn't seem reasonable. The Linux community should > > > decide what is the better way. Currently, only you are pushing for > > > userspace tuners, mainly due to non-technical reasons. > > > > read the project site and you will see the reasons. > > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > > Another advantage is that I have cygwin based code here which I can > > easily reuse with all that work I'm not going to reinvent the wheel > > even for newer devices which I work on. > > > > > Almost all the > > > other developers are comfortable with kernelspace tuners. So, creating > > > an userspace interface just to make you happy is not the way we should > > > go. > > > > > > > I'm afraid of giving the people which are against what I submitted the > > responsibility over the project. Initially there was an RFC which > > didn't get commented either (well there was one useless comment, I > > tried to discuss it on IRC before with the same guy) after I > > implemented exactly what I proposed there I got the first non > > technical comments - also keep in mind that working on something costs > > alot of time and talking about something unknown is rather cheap. > > > > > A final aspect is that having an userspace driver for tuner will mean > > > that the kernel driver will depend on an userspace counterpart in order > > > to work. This will allow a vendor with bad intentions to release a > > > partially broken userspace dr
[linux-dvb] Problem about the video_mux function.
Dear Markus: I am studying the em28xx source code. But I am puzzled by the function video_mux. It seems that the function does nothing there. Could you explain it ? Thank you. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Dazzle* TV Stick supported?
En Thu, 13 Sep 2007 00:47:19 +0200, Markus Rechberger <[EMAIL PROTECTED]> escribió: > Hi, > > On 9/12/07, Pepe <[EMAIL PROTECTED]> wrote: >> I've just bought a dvb-t usb stick (Dazzle* TV Stick, identified in >> windows as Pinnacle PCTV 71e). >> >> Is this device supported on linux? I can't find anything about it. >> > > what does lsusb and usbview (just copy the content of the window) show > up? > > Markus # lsusb Bus 005 Device 003: ID 2304:022b Pinnacle Systems, Inc. [hex] Bus 005 Device 002: ID 05e3:0710 Genesys Logic, Inc. Bus 005 Device 001: ID : Bus 004 Device 001: ID : Bus 003 Device 001: ID : Bus 002 Device 001: ID : Bus 001 Device 001: ID : usbview: PCTV 71e Manufacturer: Pinnacle Systems Serial Number: 01010101061 Speed: 480Mb/s (high) USB Version: 2.00 Device Class: 00(>ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: 2304 Product Id: 022b Revision Number: 2.00 Config Number: 1 Number of Interfaces: 1 Attributes: 80 MaxPower Needed: 500mA Interface Number: 0 Name: (none) Alternate Number: 0 Class: ff(vend.) Sub Class: 0 Protocol: 0 Number of Endpoints: 4 Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 84 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 85 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms -- Pepe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Markus, > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > Following patch adds the possibility to implement tuner drivers in > > > userspace. > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > give you my feedback about it. > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > means that, once a newer API is created, this should remain supported > > for all future versions. So, such APIs should be carefully analyzed and > > accepted by the community, before going to mainstream. > > > > The V4L and DVB API is stable at the moment because it's at a stage > which is sufficient for older devices but not sufficient for newer > devices anymore. > To support newer device it needs a change. > > > I don't see any technical reason why tuner drivers should be moved to > > userspace. Looking at xc3028 device, the driver is very simple and > > doesn't require any special treatment that it isn't possible to be done > > at kernel. There are already some implementations on kernelspace that > > works fine. > > > > As from my side to support the xceive driver properly it needs a > rewrite and a proper API description. Since it's not possible to > discuss any API changes I will work around at least for those devices > which I can support for. > > > On the other hand, a TV driver without a tuner is a broken driver. With > > parts of the driver being at userspace, this means to add undesired > > complexity at the drivers architecture, while not bringing any benefit. > > > > If you look at V4L history, the first drivers started at userspace, > > being migrated to kernelspace, where we have the proper scenario for > > managing those devices. > > > > Another aspect that should be analyzed is what is desired by the > > community: > > don't get me wrong but the existing community is rather small and > kicking off people who are interested in changing things. > I recently had a talk with someone and I've been told that I'm kicking > off people. > Guess why I kick off people? -> because they do not contribute in a > productive way which also means submitting patches. Optical useless > changes don't make any difference at the functionality in the end. And > my requirements are ignored constantly here. > > > kernelspace tuners or userspace tuners. Keeping support for > > both at long term doesn't seem reasonable. The Linux community should > > decide what is the better way. Currently, only you are pushing for > > userspace tuners, mainly due to non-technical reasons. > > read the project site and you will see the reasons. > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > Another advantage is that I have cygwin based code here which I can > easily reuse with all that work I'm not going to reinvent the wheel > even for newer devices which I work on. > > > Almost all the > > other developers are comfortable with kernelspace tuners. So, creating > > an userspace interface just to make you happy is not the way we should > > go. > > > > I'm afraid of giving the people which are against what I submitted the > responsibility over the project. Initially there was an RFC which > didn't get commented either (well there was one useless comment, I > tried to discuss it on IRC before with the same guy) after I > implemented exactly what I proposed there I got the first non > technical comments - also keep in mind that working on something costs > alot of time and talking about something unknown is rather cheap. > > > A final aspect is that having an userspace driver for tuner will mean > > that the kernel driver will depend on an userspace counterpart in order > > to work. This will allow a vendor with bad intentions to release a > > partially broken userspace driver, with limited capabilities, and a > > closed source driver for full support. This model is likely to occur, if > > you take a look at the past. For example: ATI and Nvidia closed source > > drivers, several soft modem drivers, some network drivers, ... > > > > Please go forward and discuss the UIO driver with Greg Kroah Hartmann > and the fuse driver with the other people. If companies want to > release binary drivers they can easily use the existing code put it > into an RPM or DEB package and Ubuntu will pick it up. > > > With all those issues, I'm against to add an userspace interface for > > tuners. > > > > I'm against how the project works out at the moment and how it worked > out in history. Exactly this way will kick off companies to be > interested in future like Avermedia. A driver can easily be written > within a few weeks and I've been struggling with it for 2 years(!!!) > now just for nothing finally telling me that some guys want to steal > my code and move it to kernelspace although it would raise more > complications with u
Re: [linux-dvb] Dazzle* TV Stick supported?
Hi, On 9/12/07, Pepe <[EMAIL PROTECTED]> wrote: > I've just bought a dvb-t usb stick (Dazzle* TV Stick, identified in > windows as Pinnacle PCTV 71e). > > Is this device supported on linux? I can't find anything about it. > what does lsusb and usbview (just copy the content of the window) show up? Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Markus, > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > Following patch adds the possibility to implement tuner drivers in > > userspace. > > As you asked me about userspace driver, at Linux Conf Europe, let me > give you my feedback about it. > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > means that, once a newer API is created, this should remain supported > for all future versions. So, such APIs should be carefully analyzed and > accepted by the community, before going to mainstream. > The V4L and DVB API is stable at the moment because it's at a stage which is sufficient for older devices but not sufficient for newer devices anymore. To support newer device it needs a change. > I don't see any technical reason why tuner drivers should be moved to > userspace. Looking at xc3028 device, the driver is very simple and > doesn't require any special treatment that it isn't possible to be done > at kernel. There are already some implementations on kernelspace that > works fine. > As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes I will work around at least for those devices which I can support for. > On the other hand, a TV driver without a tuner is a broken driver. With > parts of the driver being at userspace, this means to add undesired > complexity at the drivers architecture, while not bringing any benefit. > > If you look at V4L history, the first drivers started at userspace, > being migrated to kernelspace, where we have the proper scenario for > managing those devices. > > Another aspect that should be analyzed is what is desired by the > community: don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. I recently had a talk with someone and I've been told that I'm kicking off people. Guess why I kick off people? -> because they do not contribute in a productive way which also means submitting patches. Optical useless changes don't make any difference at the functionality in the end. And my requirements are ignored constantly here. > kernelspace tuners or userspace tuners. Keeping support for > both at long term doesn't seem reasonable. The Linux community should > decide what is the better way. Currently, only you are pushing for > userspace tuners, mainly due to non-technical reasons. read the project site and you will see the reasons. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages Another advantage is that I have cygwin based code here which I can easily reuse with all that work I'm not going to reinvent the wheel even for newer devices which I work on. > Almost all the > other developers are comfortable with kernelspace tuners. So, creating > an userspace interface just to make you happy is not the way we should > go. > I'm afraid of giving the people which are against what I submitted the responsibility over the project. Initially there was an RFC which didn't get commented either (well there was one useless comment, I tried to discuss it on IRC before with the same guy) after I implemented exactly what I proposed there I got the first non technical comments - also keep in mind that working on something costs alot of time and talking about something unknown is rather cheap. > A final aspect is that having an userspace driver for tuner will mean > that the kernel driver will depend on an userspace counterpart in order > to work. This will allow a vendor with bad intentions to release a > partially broken userspace driver, with limited capabilities, and a > closed source driver for full support. This model is likely to occur, if > you take a look at the past. For example: ATI and Nvidia closed source > drivers, several soft modem drivers, some network drivers, ... > Please go forward and discuss the UIO driver with Greg Kroah Hartmann and the fuse driver with the other people. If companies want to release binary drivers they can easily use the existing code put it into an RPM or DEB package and Ubuntu will pick it up. > With all those issues, I'm against to add an userspace interface for > tuners. > I'm against how the project works out at the moment and how it worked out in history. Exactly this way will kick off companies to be interested in future like Avermedia. A driver can easily be written within a few weeks and I've been struggling with it for 2 years(!!!) now just for nothing finally telling me that some guys want to steal my code and move it to kernelspace although it would raise more complications with upcoming and current devices which have even more requirements. I spent more time in rewriting and discussing everything than to get any of those requirements done. Look at the dvb hotplug patch which came from my side, also look at device node locking where the Hauppauge guy sub
[linux-dvb] Dazzle* TV Stick supported?
I've just bought a dvb-t usb stick (Dazzle* TV Stick, identified in windows as Pinnacle PCTV 71e). Is this device supported on linux? I can't find anything about it. -- Pepe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
Markus, Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > Following patch adds the possibility to implement tuner drivers in > userspace. As you asked me about userspace driver, at Linux Conf Europe, let me give you my feedback about it. On Linux, userspace-to-kernelspace APIs are meant to be forever. This means that, once a newer API is created, this should remain supported for all future versions. So, such APIs should be carefully analyzed and accepted by the community, before going to mainstream. I don't see any technical reason why tuner drivers should be moved to userspace. Looking at xc3028 device, the driver is very simple and doesn't require any special treatment that it isn't possible to be done at kernel. There are already some implementations on kernelspace that works fine. On the other hand, a TV driver without a tuner is a broken driver. With parts of the driver being at userspace, this means to add undesired complexity at the drivers architecture, while not bringing any benefit. If you look at V4L history, the first drivers started at userspace, being migrated to kernelspace, where we have the proper scenario for managing those devices. Another aspect that should be analyzed is what is desired by the community: kernelspace tuners or userspace tuners. Keeping support for both at long term doesn't seem reasonable. The Linux community should decide what is the better way. Currently, only you are pushing for userspace tuners, mainly due to non-technical reasons. Almost all the other developers are comfortable with kernelspace tuners. So, creating an userspace interface just to make you happy is not the way we should go. A final aspect is that having an userspace driver for tuner will mean that the kernel driver will depend on an userspace counterpart in order to work. This will allow a vendor with bad intentions to release a partially broken userspace driver, with limited capabilities, and a closed source driver for full support. This model is likely to occur, if you take a look at the past. For example: ATI and Nvidia closed source drivers, several soft modem drivers, some network drivers, ... With all those issues, I'm against to add an userspace interface for tuners. Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Twinhan 1034 question
Hi I have installed FC6(2.6.18-1.2798.fc6-i686), downloaded the AZLinux driver from the Twinhan site, the problem I got an error when running "make": /home/stefan/Desktop/AZLinux_v1.4.2_CI_FC6/linuxdriver/v4l/mantis_common.h:39:23: error: mantis_ca.h: No such file or directory is mantis_ca.h missing or can it be that I use the i686 platform instead of the i586? FYI I have compiled the drivers in OpenSuSE(without errors) and been able to watch the free channels in mythTV, but I want to get the CI working and the only way to be able to do that is with FC6 (so I thought..) Regards Stefan ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] autoconf for dvb-apps
On Tuesday 11 September 2007, Christoph Pfister wrote: > Hi, > > Am Dienstag 11 September 2007 schrieb gxk: > > To someone responsible for dvb-apps project > > > > Will you accept patch to add autoconf for dvb-apps? > > From my side (I'm theoretically only responsible for the scan files, > practically I'm applying other patches as well if nobody else cares) I > wouldn't accept / deal with it ... dunno about the other people. > > In general you should provide some reasoning, as the advantages have to be > bigger in some kind than the disadvantages (in this case: different syntax, > additional dependencies). But my own position is unlikely to change with > regards to this. > > Christoph > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > hi, autofoo stuff can cause a lot of brain damage. if we would perform a change in the Makefile generation i would recommend cmake. it's at least easy to understand and works out quite well. regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 firmware - next try
On Wed, 2007-09-12 at 15:31 +0200, Maillist wrote: > I have problems to load this new firmware. > - I have added the file in /lib/firmware and removed the previous one. > - Shutdown, halt the system > - Boot the system > - Checks the dmesg and it shows that it tries to load the previous > firmware > (which are deleted) > > How can I solve this to run the latest FW? >> > Don't forget to either change the referring firmware filename in >> > dib0700_devices.c or rename the file to the current name. Nico ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Watching TV now with PCTV 200e driver
Hello, I have a pctv 60e. How do I test with the new driver to help you ? http://freeznet.ath.cx:81/files/pctv200e-update1.zip Thanks, Regards, Vincent___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 firmware - next try
> On Mon, 10 Sep 2007, Maillist wrote: > >> > Hi all, >> > >> > Some time has gone by and there have been some fixes. >> > >> > Can everyone please try the latest firmware from >> > >> > http://www.wi-bw.tfh-wildau.de/~pboettch/home/linux-dvb-firmware/dvb-usb-dib0700-1.10.fw >> > >> > ? >> > >> > Don't forget to either change the referring firmware filename in >> > dib0700_devices.c or rename the file to the current name. >> > >> > Please report whether it works better, the same or less good. >> > >> > best regards, >> > Patrick. >> >> Great... >> - Will that replace dvb-usb-dib0700-03-prel.fw ?? > > If it works better, yes. > >> - Will it require the latest v4l-dvb source ?? > > Yes it is better. > > Patrick. I have problems to load this new firmware. - I have added the file in /lib/firmware and removed the previous one. - Shutdown, halt the system - Boot the system - Checks the dmesg and it shows that it tries to load the previous firmware (which are deleted) How can I solve this to run the latest FW? // Joacim ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Initial tuning data for Hastings, UK, transmitter
Am Mittwoch 12 September 2007 schrieb [EMAIL PROTECTED]: > Quoting Christoph Pfister <[EMAIL PROTECTED]>: > > Hi, > > > > Am Dienstag 04 September 2007 schrieb [EMAIL PROTECTED]: > > > Hello, > > > > > > I created the below initial tuning data file for the Hastings, UK, > > > transmitter. I used information from this web-page > > > http://www.ukfree.tv/txdetail.php?a=TQ806100 > > > > > > It works ok for me. Can / should someone add this file to the main > > > repository? > > > > Adding it, thanks :) > > > > Note: according to > > http://www.ofcom.org.uk/static/reception_advice/digital_trans_guide/show_tr >ansmitter.asp-siteID=71.html > > > some of the frequencies use a negative offset (-167khz) - can you please > > check whether the corrected version still works as expected? > > Would this explain why the output of scan lists most channels twice? Yes ... > A difference of -166.670khz. > > How does scan know to check 55380 when only 55400 is in the initial > tuning data file? I have also noticed that if I only specify one frequency > in the initial tuning data file scan finds all the other frequencies and > all the channels, is this by the same method? The stream contains information where to find the other transponders (just that you can't really rely on it as it's sometimes wrong). So 554 comes from the initial scan file and 553.833 from the network information tables in the stream. > Furthermore both > $ dvbstream -f 554000 600 601 > and > $ dvbstream -f 553833 600 601 > Work for BBC ONE. > > So now that I have two frequencies I can use for most channels I wonder > which I should use? Is there any advantage of one over the other? Why > broadcast the same stream twice? It's only broadcasted once (on 553.833). But many cards / drivers (unfortunately not all, that's why I committed a corrected version) can still find the transponder if the supplied frequency is somewhat near the real frequency. > Regards, > > Nigel Christoph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 firmware - next try
Le mercredi 12 septembre 2007 08:46, Nicolas Will a écrit : > And we are getting into the second day ! > > I still have the odd read failure in the logs, and this time I got this > one, a write failure. > > mt2060 I2C write failed (len=2) > > But the signal is still there, I can change channels, as if I had a > nicely working piece of equipment working as it should. :o) > > What are the others experiencing ? Seems to work as good as the previous one with wintv-nova-t (2040:7050). -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Status of TT3200 driver development? Sharing might be the answer
Mario Smit wrote: > Yes, if you go against their wishes you will certainly have problems > later getting help from them. > > Unfortunately this creates the situation that only selected people have > a little bit information that they are not allowed to share. So, we can > only test the results of their works (reactive) and not work together > (proactive) creating the best driver possible. More than that STM wants to see the best driver. Currently it is not yet complete (complete in the sense, some bugs do remain in the driver. Other than that when you say a third party hardware, it is a mix of stuff from different vendors, so it is just not the demodulator driver alone that always matter) as you might be aware (WIP). The release what i had was based on a Satelco (KNC1 OEM) card using the STB0899. There have been a couple of folks who put a lot of effort, as well as to get additional hardware supported such as the TT S2 3200. These are just coarse patches, not even applied to the tree. Crying out frustration after applying these patches do not help anyone, but just a waste of time for everyone. Such patches are meant only for the brave, not for the people who just keep crying around. Also i saw from one of the users I/O errors. This are due to I2C probes which are crappy, due to a SAA7113 getting attached. (The SAA7113 doesn't have any video function at all but is used for a very different reason) The demodulator will not respond after that utter crap. Basically V4L drivers try to do I2C probing which is something like you are being called suddenly by a lot of people suddenly, you get confused, the same happens to the hardware. Additionally STM has provided lot of support as well for getting a very good driver. In fact it is a very complex device, because it doesn't hide it's internals in any firmware. For the same reason due to many patents and IP involved, they would like to keep the information far from prying eyes. Just with the specifications/datasheets alone (supposing you had them) it is far from reality, that you can make anything out of it, due to the complexity. Hardware these days are getting complex and even more complex, not simpler. In fact, i had to get back to STM at various stages for help, which they really helped by putting me in touch with the relevant people involved in the development of the various stages. Not to mention about missing registers in the datasheets etc. So even if you get the datasheets, it is quite pointless, unless you understand the innards of the device. On top of this, you will need to have a really good idea how a DVB-S2 demodulator will work to understand the same. So it is quite a lot of effort to get a driver for such a beast going from basic bare register specifications with around 800 registers with thousands of bitfields. (In contrast you can take a look at drivers were specifications are generally available and how they behave, you can see the complaints from the users if you just see the posts on the ML.) If you look at drivers generally, even if you have the specs, the drivers aren't normally great unless it is well tested and certified by the vendors. For the same reason, once it is complete STM wishes to take the driver a do certification program for selected hardware. This is the best that can ever happen. You get completely certified well written OSS drivers. User tests can of course make things better. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
