[linux-dvb] Re: dvb-kernel CVS branched for Linux 2.4
Am 20.04.2004 um 13:51 schrieb Michael Hunold: There haven't been many complaints in the past -- either because users still use the DVB tree from CVS for 2.4 or because the current dvb-kernel is good enough for them. The dvb-kernel thing (in my opinion) ist far away from the quality of the old 2.4 DVB driver (stability, liveview, diseqc). I found it very confusing what happens with the DVB driver lately. First i heard that the old (for me very stable) DVB tree is obsolete, what means that no further development is done for it. Further development is only done in the dvb-kernel (which contains now both, 2.4 and 2.6) tree. Now the things are changing again, dvb-kernel is now only 2.6 and... what does now happen with the DVB Tree? From my point of view (i'm not involved in the DVB development in any way) this is more then confusing. I've get the impression that most of the energy is wasted in strutural changes instead of making the hole thing more stable (which i think is the major thing to complain about the DVB driver). Tom. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: dvb-kernel CVS branched for Linux 2.4
Hello Michael, On Tue, Apr 20, 2004 at 01:51:25PM +0200, Michael Hunold wrote: ... There haven't been many complaints in the past -- either because users still use the DVB tree from CVS for 2.4 or because the current dvb-kernel is good enough for them. If you're satisfied with the current state of dvb-kernel in 2.4, then you're not switched off at all. I have been using dvb-kernel 2.4 for a while now, and it's working fine. Please bug the AVM DSL USB driver author to provide proper 2.6 support. ;-) I've already done that: they have decided that a 2.6 driver isn't ne- cessary as long as SuSe is not shipping a 2.6 kernel :-( See: http://www.avm.de/de/Service/AVM_Service_Portale/Linux/index.php3 - News und Ausblick Wolfgang -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] share /dev/dvb/adapter0/frontend0
Hi Nicolas I am sorry but I forgot to send you e second line to be patched in the av7110 driver. In the lines immediately following the previously applied patch you have to apply the same modification : original case VIDIOCSTUNER: { struct video_tuner *v =3D arg; dprintk(KERN_ERR dvb: VIDIOCSTUNER called\n); /* only channel 0 has a tuner */ if (!v-tuner) return -EINVAL; patched case VIDIOCSTUNER: { struct video_tuner *v =3D arg; dprintk(KERN_ERR dvb: VIDIOCSTUNER called\n); /* only channel 0 has a tuner */ if (v-tuner) return -EINVAL; Angelo On Tue, 20 Apr 2004, [EMAIL PROTECTED] wrote: Le 04/20/2004 01:03 PM, [EMAIL PROTECTED] a joliment =E9crit : Hi what is the exact DVB board you are using, Nexus S DVB card Hauppauge with a cam for crypted channels Do you use a Cam ? what is the exact command line your are running mplayer cut and past your command line Are you sure to have loaded the recompliled modules ? Yes beacause before vdr output didn't black. In my case too, vdr output go black for a while when mplayer start. Then it is in progress ;-) Nicolas. -- Powered .~. by Linux /V\ -- // \\ solutions for /( )\ smart penguins ^`~'^ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Gpioirq unknown
Hello, I have previously been using the linuxtv-dvb-1.1.1 drivers and a 2.6.5 kernel with my Nexus-S card. Today I decided to update to the latest CVS dvb-kernel and I am seeing this in my syslog: kernel: gpioirq unknown type=0 len=0 The DVB card seems to be functioning properly but I am curious why the 1.1.1 drivers did not have this message. Is this a bug? Thanks.. Cym P.S. I'm Sorry for sending this to the wrong mailing list. I meant to send it to linux-dvb not vdr. Please excuse me.
[linux-dvb] Re: dvb-kernel CVS branched for Linux 2.4
Wolfgang Thiel wrote: On Tue, Apr 20, 2004 at 01:51:25PM +0200, Michael Hunold wrote: Please bug the AVM DSL USB driver author to provide proper 2.6 support. ;-) I've already done that: they have decided that a 2.6 driver isn't ne- cessary as long as SuSe is not shipping a 2.6 kernel :-( AFAIK the upcoming SuSE 9.1 will be based on a 2.6 kernel. http://www.suse.com/us/private/products/suse_linux/preview/index.html Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Gpioirq unknown
cym wrote: I have previously been using the linuxtv-dvb-1.1.1 drivers and a 2.6.5 kernel with my Nexus-S card. Today I decided to update to the latest CVS dvb-kernel and I am seeing this in my syslog: kernel: gpioirq unknown type=0 len=0 The DVB card seems to be functioning properly but I am curious why the 1.1.1 drivers did not have this message. Is this a bug? When and how often does it happen? I get one of those after loading the firmware when querying for the firmware version. I think it is not a serious problem. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: dvb-kernel CVS branched for Linux 2.4
Thomas Koch wrote: The dvb-kernel thing (in my opinion) ist far away from the quality of the old 2.4 DVB driver (stability, liveview, diseqc). Could you please be more specific? If we don't know what your problems are with dvb-kernel, we cannot address them. AFAIK most of the stability problems are in the av7110 firmware, and I've spend quite some time searching for them (without success, though). Anyway, the dvb-kernel-1.1.1 release is a bit old, but current dvb-kernel CVS works way better for me than DVB ever did. I found it very confusing what happens with the DVB driver lately. First i heard that the old (for me very stable) DVB tree is obsolete, what means that no further development is done for it. Further development is only done in the dvb-kernel (which contains now both, 2.4 and 2.6) tree. Now the things are changing again, dvb-kernel is now only 2.6 and... what does now happen with the DVB Tree? From my point of view (i'm not involved in the DVB development in any way) this is more then confusing. I've get the impression that most of the energy is wasted in strutural changes instead of making the hole thing more stable (which i think is the major thing to complain about the DVB driver). With the integration of the DVB drivers into the mainline kernel we comitted ourselves to maintain the drivers. And that means that we need to adapt to changes in the kernel APIs and driver infrastructure. You are of course free to ignore our efforts, but saying that energy is wasted in strutural changes is quite offensive. Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] info visionplus usb-ter
hi, we bought this usb dvb-t visionplus dvb-t usb-ter http://www.visionplus.com.tw/visiontv-2.htm and it seems this usb device card isn't yet supported by the linux dvb driver. or at least i can't find any useful stuff on the linux-dvb ML! so, i'd like to try to raise some awareness about the meat inside, and only time will tell if this is just a warm generator for the linux world or a more useful device! actually, if i plug it in the other OS i can see it will load _two_ different drivers one after the other.. the first step, from cold to warm, is just a firmware loading and initialization of the controller inside.. the second step should be the recognition of the final device: the DVB-T tuner/demux.. on linux i can find two different USB footprint under the /proc/bus/usb/devices (see attached dump!) COLD: ... P: Vendor=1822 ProdID=3201 Rev= 0.01 ... WARM: ... P: Vendor=1822 ProdID=3202 Rev= 0.01 S: Manufacturer=TWINHAN S: Product=VP7041 ... (BTW, the shop told me this was a VP7042, don't know the difference between 7042 and 7041.. anyone?!) than i made some pictures about the inside of the box (BTW no seal to be broken :-) beware they are huge pictures! http://krusty.cineca.it/vpweb/temp/vp/ the demuxer is under a passive cooler so i don't know what it is; here someone say should be a conexant chip: http://www.golem.de/0402/29659.html (could someone deutch-speaking tell about useful info on that thread on macosx and linux support?!) the only other visible chip is a cypress AN2135SC: one of the AN2131 family: http://www.cypress.com/products/datasheet.cfm?partnum=AN2131 this is the controller (8051) i said above. it's a quite aged device used in many different purposes; it's called ez-usb and there's already a simple driver on sf.net: http://ezusb2131.sourceforge.net/ the main business is load any firmware available on the linux host to the chip. but i have not been able to recognize the firmware file in the driver directory of the MS OS driver package.. (maybe it's embedded in some of the .sys file there) BTW it's a pity this is not the EZ-USB FX2 running at full speed of a usb 2.0 bus (aka 480Mbps) but just the usb 1.1 version so it seems hardware pid filtering will be a must because a full mux bw should largely exceed the usb 1.1 real bw available!! :-( i believe both tuner (on a side there is a sticker telling something about a TD 7022..) and demux should be available on the i2c bus (driven from the cypress chip..) and maybe they answer some discovery query.. that's all for now. do you know if there's some activity on-going about this usb device for linux? thanx in advance andrea venturi T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.5 uhci_hcd S: Product=Intel Corp. 82801CA/CAM USB (Hub #3) S: SerialNumber=:00:1d.2 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.5 uhci_hcd S: Product=Intel Corp. 82801CA/CAM USB (Hub #2) S: SerialNumber=:00:1d.1 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.5 uhci_hcd S: Product=Intel Corp. 82801CA/CAM USB (Hub #1) S: SerialNumber=:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=1822 ProdID=3201 Rev= 0.01 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 0 Alt= 1 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=10ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=08(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=8a(I) Atr=01(Isoc)
[linux-dvb] Re: dvb-kernel CVS branched for Linux 2.4
If you can guarantee me that features and functionality worked on in 2.6 that are reasonably 2.4 compliant will get ported to the 2.4 tree then I'm ok with it but if you have features and bug fixes that are DVB related, but not architecture dependent, I.E. bootstrapping 2.6 stuff, then I have a real problem. Maintaining two separate code trees without dilligence means that whomever is NOT on HEAD branch ultimately loses. If the code before the split works both in 2.4 and 2.6, then why is that not satisfactory to include in mainline? What were the historical reasons for using a single tree for 2.4 and 2.6? What has changed since then philisophically to cause that decision to be revoked without warning? For many months, I thought dvb was for 2.4 and dvb-kernel was for 2.6. I was surprised to see that dvb-kernel was also for 2.4 and gleefully switched to it. I suspect people don't realize that dvb-kernel works in 2.4. Just because it isn't easy IMHO is not justification not to do it. Perhaps the CVS code could be marked up in some way such that when the code is exported to the kernel, an automated process could remove the unwanted segments I.E. 2.4 compatability. _J In the new year, Johannes Stezenbach wrote: Wolfgang Thiel wrote: On Mon, Apr 19, 2004 at 06:50:30PM +0200, Johannes Stezenbach wrote: ... Consequently, I've created a linux_2_4 branch in dvb-kernel CVS for the driver version for Linux 2.4. Main development in CVS HEAD will be for Linux 2.6 only, and all 2.4 compatibility stuff will soon be removed from HEAD. I would love to switch to 2.6, but I cannot because of missing 2.6 drivers. I don't think I'm the only one... For me, I don't have access to the internet with 2.6 because there is no driver for AVM DSL SL USB available yet. I don't like to be switched off from the main tree because of this. IMHO creating a CVS branch is the appropriate tool to work on two parallel lines of development. It does not mean anyone is cut off from main development. Also, I suspect that a good deal of work will be done on the 2.4 branch (not by me, of course :-), and will have to be forward ported... Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: info visionplus usb-ter
Andrea Venturi wrote: hi, we bought this usb dvb-t visionplus dvb-t usb-ter http://www.visionplus.com.tw/visiontv-2.htm and it seems this usb device card isn't yet supported by the linux dvb driver. or at least i can't find any useful stuff on the linux-dvb ML! [...] the demuxer is under a passive cooler so i don't know what it is; here someone say should be a conexant chip: http://www.golem.de/0402/29659.html (could someone deutch-speaking tell about useful info on that thread on macosx and linux support?!) [...] Sorry, no useful information inside. The only valueable info in the whole thread is found below (I added english summaries in brackets): Autor: Andreas B. Datum: 10.02.04 15:10 ich habe mir leider noch nicht den Spass gegeben, zu versuchen die Karte auch unter Linux mit 2.6.2 und den linux-tv.org dvb treibern fuer den cxt 878 [A] zu betreiben, [He has not yet done any tests with linux, but believes, that a Connexant 878[A] is built in the box.] vorsicht bei btb878 Treibern fuer die normalen TV-Karten, beim Laden dieses Moduls und Anwesenheit der V(+)-DTV friert der Rechner Resetwuerdig ein, hotplug laed das Modul automatisch, also wenn, dann den btb878 auf die hotplug Verbotsliste setzen, [If you load the normal btb878 driver module for linux with the box present, the system sometimes freezes unrecoverable. To avoid this, he suggests to put the btb878 to the block-list of the hotplug service.] -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: budget-ci CI interface testing
Andrew de Quincey wrote: On Tuesday 20 April 2004 00:40, Andrew de Quincey wrote: 1) When there is no CAM in the slot, no TS data is received. I think the DD1 port has to be switched, when no CAM is present. I'll have to check that. I'd assumed that the CI interface would pass the data through if a CAM is not present (it's _supposed_ to; EN50221 says so). Maybe thats incorrect for this hardware though. Or else I'm setting the passthrough bit wrongly. You're absolutely right; I just beeped that bit out again, and the CI interface is dumber than I thought. You have to manually switch the SAA7146 input ports when a CAM is removed. I'll work on that tomorrow. This is now fixed in CVS. Great!!! Now I'm getting the TS data from the card; that didn't work with the CI code before. So far I've only been able to test it without the CAM, but I hope to test the CAM later tonight... -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Gpioirq unknown
Yes, that is exactly what is happening to me as well. Once during boot up when it is loading the firmware. I just noticed that it was acting differently so I thought I would ask. I went through the gpioirq function in av7110.c and I did not see any changes to it so I couldn't figure out why it was behaving differently than before. Thank You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Stezenbach Sent: Wednesday, April 21, 2004 4:12 AM To: [EMAIL PROTECTED] Subject: [linux-dvb] Re: Gpioirq unknown cym wrote: I have previously been using the linuxtv-dvb-1.1.1 drivers and a 2.6.5 kernel with my Nexus-S card. Today I decided to update to the latest CVS dvb-kernel and I am seeing this in my syslog: kernel: gpioirq unknown type=0 len=0 The DVB card seems to be functioning properly but I am curious why the 1.1.1 drivers did not have this message. Is this a bug? When and how often does it happen? I get one of those after loading the firmware when querying for the firmware version. I think it is not a serious problem. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] scanning
is there a utility out there that if given a frequency, it will scan for any usable data? In otherwords will check all polarities and symbol rates etc for data. -Dan __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: scanning
From: D. Ratner [EMAIL PROTECTED] is there a utility out there that if given a frequency, it will scan for any usable data? In otherwords will check all polarities and symbol rates etc for data. All symbol rates? Let's see: The STV0299B has 20 bits for the symbol rate setting, that's 1,048,576 possible symbol rates. Even if you spend only 10ms checking each symbol rate, it'll take 3 hours to scan all symbol rates. Add polarity and it'll be 6 hours. Add the 5 possible Viterbi FEC rates and it'll take over a day... Also, for low symbol rates, you'll have to wait much longer for a signal lock, it can sometimes take several seconds to lock. If you wait 10 seconds on each possible combination of symbol rate, polarization and FEC rate, you'll spend over a thousand days, i.e. over three years scanning just a single frequency. I don't think you really want to do this. Better find the correct parameters out from the satellite operator - they know, for sure. Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.