Re: [linux-dvb] HVR-1250, Suse 10.3, scan hangs, taints kernel.
Hi, Am Montag, den 17.03.2008, 14:05 -0500 schrieb Mark A Jenks: SUCCESS! Built 2.6.24-3 and installed it. Recompiled CVS, and installed it. Now it doesn't hang when it finds a signal. -Mark Steve, the noise was not without reason. You might see, that all your drivers within and out of the kernel have been broken. Not to make any noise then, seems to me not a good idea. Also, on LKML was some stuff, that there is a general problem initializing PCI devices multiple times and eventually have problems on shutdown/suspend then. But to late for the recent -rc. So, as it stands, given that we are not that backward compatible as have been previously anymore, to know that this change to 2.6.24 did anything usefull, what I doubt, would be not bad to have in details. Cheers, Hermann -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark A Jenks Sent: Monday, March 17, 2008 1:28 PM To: Steven Toth; linux-dvb Subject: Re: [linux-dvb] HVR-1250, Suse 10.3, scan hangs, taints kernel. I'm compiling 2.4.24 right now to test it. I've been running this box for over a year with a TV2000 card without issues. I was just trying to upgrade into DTV. So, I really don't think it's a memory issue. The TV2000 was a pci, this is my first pcie card I'm using in this box. -Mark -Original Message- From: Steven Toth [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 1:18 PM To: Mark A Jenks; linux-dvb Subject: Re: [linux-dvb] HVR-1250, Suse 10.3, scan hangs, taints kernel. CC'ing the mailing list back in. Mark A Jenks wrote: Do you think I should push the kernel to 2.6.25? I maintain the driver on ubuntu 7.10, which I think has is 2.6.22-14 - or close to. I have another AMD system at home that the driver completely freezes on, no idea why, total system lockup. I don't trust the PCIe chipset on it, it's an early chipset and a little flakey. Other than that the driver's been pretty reliable. Lots of noise recently on the mailing lists about video_buf related issues and potential race conditions. Try running the system with a single cpu core and report back, also, just for the hell of it, run memtest also. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] CX88 (HVR-3000) -- strange errors in dmesg
Hi, Am Sonntag, den 16.03.2008, 11:02 + schrieb Philip Pemberton: Hi, I've just noticed an absolute ton of these messages in dmesg, can anyone tell me what's going on, or what they mean? [ 123.404000] cx88[0]: irq pci [0x1000] brdg_err* [ 123.404000] cx88[0]: irq pci [0x1000] brdg_err* [ 123.412000] cx88[0]: irq pci [0x1000] brdg_err* [ 123.412000] cx88[0]: irq pci [0x1000] brdg_err* (repeat ad nauseum) Kernel 2.6.22-14-generic, Hg 11fdae6654e8 with HVR-3000 patches from dev.kewl.org/hauppauge merged in manually. looks like you need the last patches from Guennadi. http://marc.info/?l=linux-videor=1b=200803w=2 Most important is that one in the middle. [PATCH] Fix left-overs from the videobuf-dma-sg.c conversion to generic DMA As a workaround there was also a patch from Mauro previously, reverting videobuf-dma-sg back to PCI DMA until the bug is discovered. http://www.spinics.net/lists/vfl/msg36025.html Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR-1250: v4l-dvb need help compiling
Hi, Am Freitag, den 07.03.2008, 09:21 -0500 schrieb Raphael: Hello folks, I'm new to the list, and I subscribed mainly because I'm having a problem compiling the v4l-dvb drivers. I have a pinnacle PCTV HD Pro Stick and that is working fine using the em28xx drivers from mcentral.de. Currently, I'm trying to get a Hauppage HVR-1250 working. At first when I tried compiling v4l-dvb, I got errors about tea575x-tuner.c, and so using make menuconfig, I disabled all AM/FM tuners. Howver, after that I still get an error during make, this time in videodev.c. The first error is unknown field 'dev_attrs' specified in initializer on line 491. Has anyone seen this, or could I be doing something wrong when I removed the webcam drivers? this looks like you are using an older kernel for which we don't have compatibility glue for sysfs currently. Likely from 2.6.19 on, for sure with at least 2.6.20, you should be able to overcome this. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] saa7134: Asus Tiger revision 1.0, subsys 1043:4857 improvements
Am Donnerstag, den 06.03.2008, 22:40 +0100 schrieb Hartmut Hackmann: Hi, Hermann hermann pitton schrieb: Hi, Harmut, was able to purchase such a device recently. For me it looks like they have been on OEM stuff only previously. The panel for the internal connectors is soldered, the analog audio out is there too and fine. For all what I could look up, it had never support for the PC-39 remote we added for revision 2.0, since all seen so far comes up with gpio init 0, the remote IRQ to sample from is never active. Folks, please report if it comes with that RC5 style remote too. It has a firmware eeprom. It turns out, and some previous reports pointed to it without to become speficic, but contradictions on what the ms driver does on antenna input switching, that this one has only a male FM connector and a female RF connector. So, currently we force people with that card to put the DVB-T antenna input on the male FM-connector, which might be quit inconvenient ... indeed ;-) If nobody disagrees, and also my thesis of the not ever delivered remote is right, we should change the auto detection to use card=81, the Philips Tiger reference design you developed on. Cheers, Hermann Stuff currently in that machine. We have also one byte different in the eeprom here. Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded saa7133[0]: found at :01:07.0, rev: 208, irq: 17, latency: 32, mmio: 0xe800 saa7133[0]: subsystem: 1043:4857, board: Philips Tiger reference design [card=81,insmod option] saa7133[0]: board init: gpio is 0 saa7133[0]: i2c eeprom 00: 43 10 57 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 01 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 cb ff ff ff ff ^^ snip tuner' 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7133[1]: found at :01:08.0, rev: 208, irq: 19, latency: 32, mmio: 0xe8001000 saa7133[1]: subsystem: 1043:4862, board: ASUSTeK P7131 Dual [card=78,autodetected] saa7133[1]: board init: gpio is 0 -- remote sensor is broken, else 0x4 input: saa7134 IR (ASUSTeK P7131 Dual) as /class/input/input6 tuner' 3-004b: chip found @ 0x96 (saa7133[1]) tda829x 3-004b: setting tuner address to 61 tda829x 3-004b: type set to tda8290+75a saa7133[1]: i2c eeprom 00: 43 10 62 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[1]: i2c eeprom 10: 00 01 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 d6 ff ff ff ff ^^ snip I guess you checked the entire eepron content ;-) According to the documentation i have, there is no config byte describing the assignment of antenna sockets. The document says that this byte is a checksum!!! I will try to get some information. I found one discrepancy: The Tiger uses LINE1 for the audio baseband inputs while the ASUS uses LINE2. Can you cross check this? Best regards Hartmut Hi Hartmut, that was just some fallout in between and I`m sure to have the proper testings already. That checksum game is interesting, but whatsoever is such hidden something good for, except to cheat. What gives me more to worry about recently is, that it is hard for me to illuminate some last working status of the saa7134-empress in some variant I have currently. (I'm down to bit specific operations) If pioneers like Geert, Greg or Mans could provide me with some saa7134_i2c debug on _start_ last known state and setting the fmt successfully, might help. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] saa7134: Asus Tiger revision 1.0, subsys 1043:4857 improvements
Hi, Harmut, was able to purchase such a device recently. For me it looks like they have been on OEM stuff only previously. The panel for the internal connectors is soldered, the analog audio out is there too and fine. For all what I could look up, it had never support for the PC-39 remote we added for revision 2.0, since all seen so far comes up with gpio init 0, the remote IRQ to sample from is never active. Folks, please report if it comes with that RC5 style remote too. It has a firmware eeprom. It turns out, and some previous reports pointed to it without to become speficic, but contradictions on what the ms driver does on antenna input switching, that this one has only a male FM connector and a female RF connector. So, currently we force people with that card to put the DVB-T antenna input on the male FM-connector, which might be quit inconvenient ... If nobody disagrees, and also my thesis of the not ever delivered remote is right, we should change the auto detection to use card=81, the Philips Tiger reference design you developed on. Cheers, Hermann Stuff currently in that machine. We have also one byte different in the eeprom here. Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded saa7133[0]: found at :01:07.0, rev: 208, irq: 17, latency: 32, mmio: 0xe800 saa7133[0]: subsystem: 1043:4857, board: Philips Tiger reference design [card=81,insmod option] saa7133[0]: board init: gpio is 0 saa7133[0]: i2c eeprom 00: 43 10 57 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 01 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 cb ff ff ff ff ^^ saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15 00 ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner' 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7133[1]: found at :01:08.0, rev: 208, irq: 19, latency: 32, mmio: 0xe8001000 saa7133[1]: subsystem: 1043:4862, board: ASUSTeK P7131 Dual [card=78,autodetected] saa7133[1]: board init: gpio is 0 -- remote sensor is broken, else 0x4 input: saa7134 IR (ASUSTeK P7131 Dual) as /class/input/input6 tuner' 3-004b: chip found @ 0x96 (saa7133[1]) tda829x 3-004b: setting tuner address to 61 tda829x 3-004b: type set to tda8290+75a saa7133[1]: i2c eeprom 00: 43 10 62 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[1]: i2c eeprom 10: 00 01 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 d6 ff ff ff ff ^^ saa7133[1]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15 00 ff ff ff ff ff ff saa7133[1]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: registered device video1 [v4l2] saa7133[1]: registered device vbi1 saa7133[1]: registered device radio1 saa7133[2]: found at :01:09.0, rev: 209, irq: 20, latency: 32, mmio: 0xe8002000 saa7133[2]: subsystem: 16be:0010, board: Medion/Creatix CTX953 Hybrid [card=134,autodetected] saa7133[2]: board
Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?
Am Montag, den 03.03.2008, 22:13 +0100 schrieb Christoph Pfister: Am Montag 03 März 2008 schrieb Florian Lohoff: snip I have no problem with beeing able to query stats - I have a problem that a GET call changes in kernel state, and the SET calls options get ignored where it should be the other way round. Probably you can tell me the reason the delivery option in the dvbfe_params gets ignored on a DVBFE_SET_PARAMS ? I dont see the rational behind this... The option is there - correctly filled and gets ignored or better overriden by previous ioctls - Every other parameter for the delivery mode is in that struct. Please tell me why the GET_INFO delsys/delivery option gets set as the next to use delivery mode. Even if i want to have stats just dont fill them when the delsys does not match the currently set delsys as that would be the right thing - Querying DVB-S2 stats when tuned to DVB-S should return nothing as there are no stats - but setting the delsys to DVB-S is BROKEN as i asked for stats not to change the delsys. Additionally, this was quite discussed in a long discussion a while back. You might like to read through those as well. I did partially of it ... and i found the same corners of this API to be broken by design. Maybe DVBFE_GET_INFO can probably be renamed to DVBFE_INFO if it really itches so much. No - its much more fundamental problem ... Options belonging together are passed in seperate ioctls in non obvious (read: strange) ways into the kernel (delivery system via GET_INFO and delivery options via SET_PARAMS). Options which are together in the same struct are not used together e.g. delivery mode and parameters are in the same struct which get passed by an ioctl but get partially ignored or better overridden by previous ioctls in non obvious ways... As i said - incoherent mess from the user api ... +1 Flo Christoph I can't let it, something totally OT ... The AIRBUS claimed nearly crashed in Hamburg recently, during EMMA, was in totally normal flight operation. At least the pilots don't have any guilt. The reason for it was, some might think it is not normal, that the expense per lost passenger is restricted to some 14000 old german marks, IIRC:) Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] auto detection of Flytv duo/hybrid and pci/cardbus confusion
Hi, Am Samstag, den 23.02.2008, 00:11 +1100 schrieb Peter D.: On Wednesday 20 February 2008, hermann pitton wrote: Am Sonntag, den 17.02.2008, 21:53 +0100 schrieb Peter Missel: Greetings all! Let me clear things up a bit. First clarification, duo versus hybrid. Are duo cards equipped with two independent tuners that can both be used at the same time? Are hybrid cards necessarily equipped with digital and analogue tuners? Can a two tuner card be both a duo and a hybrid, if one tuner is digital the other is analogue and they can both be used at the same time? LifeView are using two vendor IDs - 4E42h for all (!) their OEMs, and their own one for LifeView branded cards. Hence we need two PCI ID entries for everything, each pair pointing back to the same card data. Then, card types. The analog-only and hybrid have one single tuner, for DVB-T or analog. The Duo cards have two tuner frontends, one for DVB-T and the other for analog. Trio cards add a DVB-S frontend, which cannot be used at the same time as the DVB-T frontend. Like the Duo, these can run one digital and one analog stream in parallel. Finally, card shapes. Each card type comes in CardBus, PCI, and MiniPCI shape. The flavors are compatible, so that again, the PCI ID data point back to the same card entry for e.g. the PCI and CardBus Duo. The card type/shape combinations are distinctly identified by their subsystem ID. No need to guesstimate anything. That's the plan at least. regards, Peter Hi Peter! Your plan is fine so far. We might add some more comments to group devices obviously together, since those looking first time at it are a bit lost. For such i2c IR limits, we have your and Eddi's comments. Since we can't help it easily, Peter D. should suggest the older version of the MSI A/D for auto detection. It won't make anything more worse on that not fully clear Vivanco stuff, except Hartmut might have ideas. Cheers, Hermann I think that you just suggested something. I'm going to stand at the side and nod my head. ;-) What should I do to make it an official suggestion? the usual ;) Create a patch against the current v4l-dvb master repo. Try README.patches. Send it and add the Signed-off-by line. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
Hi. Am Samstag, den 23.02.2008, 03:35 +0400 schrieb Manu Abraham: CityK wrote: Manu Abraham wrote: CityK wrote: ... For V4L to work with devices that way, it will need to copy more from the other subsystems such as Video, DVB and ALSA since V4L alone is not any specific real subsystem pertaining to something in real life. V4L just originated as a means to tune Analog TV cards under Linux, which later went in a different tangent. While the move to multi-purpose, single IC devices is inevitable, the processing stages for the varying applications which the IC will perform (i.e. demodulation, encoding, ADC, etc) remain the same ... I don't see how V4L would be cut out of the block ... unless, of course, that means DVB means to expand its capabilities and/or absorbing some of those currently handled by V4L The in between stages will be masked out by larger stages which will wrap around them, thereby you don't see those small basic controls. As you see compared to the old days, you don't have that micro level controls anymore these days. Those are getting phased out at a reasonable pace, with more hardware doing those functionality of manual control. (features getting packed in to make look like something different) For example, When there is so much integration at such a stage, you feel silly including something gigantic for something too silly. In such a case for example of a TV output, you might not even need something that complex, for such a small feature. (to cite as a crude example, maybe a bad example, but i hope you get the idea) Maybe some facts in between, instead of pure advertising. If you have that, sold per every single device painfully. http://search.ebay.de/ws/search/SaleSearch?sofocus=bssatitle=dvb+cisacat=-1%26catref%3DC5fbd=1catref=C6fscl=1sorefinesearch=1flt=9from=R14nojspr=ypfid=0fswc=1few=saprclo=saprchi=fss=1saslop=1sasl=b.e.t.t.e.r.s.h.o.p.p.i.n.gfls=4%26floc%3D1sargn=-1%26saslc%3D0salic=77saatc=77sadis=200fpos=fsct=sacur=0sacqyop=gesacqy=sabfmts=0fobfmt=1saobfmts=insifga10244=10425saslt=2ftrt=1ftrv=1sabdlo=sabdhi=saaff=afdefaultafan=afmp=fsop=1%26fsoo%3D1fcl=3frpp=50 You still need something like this. http://cgi.ebay.de/Neu-CAM-CI-MODUL-AlphaCrypt-Light-mit-Software-1-12_W0QQitemZ37642816QQihZ024QQcategoryZ77740QQssPageNameZWDVWQQrdZ1QQcmdZViewItem And still have exactly nothing. If it stays like that, this will likely have some new owners soon, but teach me better. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
Am Samstag, den 23.02.2008, 11:09 +0400 schrieb Manu Abraham: hermann pitton wrote: Hi. If it stays like that, this will likely have some new owners soon, but teach me better. Unfortunately, i updated my mail filters which had tagged all your mails as junk, to spam status. Unencrypted HD currently has the sole function to sell subscriptions. Not to say it, _is_ spam. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] auto detection of Flytv duo/hybrid and pci/cardbus confusion
Am Mittwoch, den 20.02.2008, 23:41 +0100 schrieb Werner Braun: Am Sonntag, den 17.02.2008, 21:53 +0100 schrieb Peter Missel: Greetings all! Let me clear things up a bit. First clarification, duo versus hybrid. Are duo cards equipped with two independent tuners that can both be used at the same time? Are hybrid cards necessarily equipped with digital and analogue tuners? Can a two tuner card be both a duo and a hybrid, if one tuner is digital the other is analogue and they can both be used at the same time? LifeView are using two vendor IDs - 4E42h for all (!) their OEMs, and their own one for LifeView branded cards. Hence we need two PCI ID entries for everything, each pair pointing back to the same card data. Then, card types. The analog-only and hybrid have one single tuner, for DVB-T or analog. The Duo cards have two tuner frontends, one for DVB-T and the other for analog. Trio cards add a DVB-S frontend, which cannot be used at the same time as the DVB-T frontend. Like the Duo, these can run one digital and one analog stream in parallel. Finally, card shapes. Each card type comes in CardBus, PCI, and MiniPCI shape. The flavors are compatible, so that again, the PCI ID data point back to the same card entry for e.g. the PCI and CardBus Duo. The card type/shape combinations are distinctly identified by their subsystem ID. No need to guesstimate anything. That's the plan at least. regards, Peter Hi Peter! Your plan is fine so far. We might add some more comments to group devices obviously together, since those looking first time at it are a bit lost. For such i2c IR limits, we have your and Eddi's comments. Since we can't help it easily, Peter D. should suggest the older version of the MSI A/D for auto detection. It won't make anything more worse on that not fully clear Vivanco stuff, except Hartmut might have ideas. Cheers, Hermann Hermann and Peter, I guess it was me with the Vivanco card in May/June last year. I took a time out from the mailing list due to time constraints, but am back and willing to help you sorting out the open issues, as far as my limited competences allow for it. The current status with my Vivanco 21057 card (4e42:3306) is: - DVB-T works with the patches you suggested last year - Analog not (but did not bother anyway) - FM: did not try - Remote: dto. (I'm sitting in front of the computer anyway) Funny thing: since Kernel 2.6.22, firmware upload does not work any longer. I have to boot XP before and do a warm reboot, then DVB-T under Linux works. Best regards Werner Hi, Werner, yes it was your device coming back in mind. We know now about the new A/D version V1.1, saw only a fuzzy picture so far, but looks like a KS003 something for the remote and not that PIC on the prior, different addresses, IIRC. That one also has the supposed LNA in the tuner area visible. Must look it up again, but for what I remember I did not find a difference between your Vivanco card and what Peter D. has. We also have regspy output from a recent cardbus A/D NB, but Mauro can't test any DVB-T currently and analog is fine on that one with card=94. However, maybe the differences of the gpio settings in DVB-T mode visible there may help us to figure out a pattern we miss. analog SAA7134_GPIO_GPMODE: 8078e700 (1000 0000 11100111 ) SAA7134_GPIO_GPSTATUS: 08218000 (1000 0011 1000 ) composite SAA7134_GPIO_GPSTATUS: 08218000 (1000 0011 1000 ) s-video SAA7134_GPIO_GPSTATUS: 08218000 (1000 0011 1000 ) radio SAA7134_GPIO_GPSTATUS: 08018000 (1000 0001 1000 ) dvb-t SAA7134_GPIO_GPSTATUS: 08e08000 (1000 1110 1000 ) - board init: gpio is 821 1000 0011 Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Very quiet around Nova-T 500
Hi Nico, Am Mittwoch, den 20.02.2008, 07:12 + schrieb Nicolas Will: On Wed, 2008-02-20 at 01:12 +0100, hermann pitton wrote: Now stop that logging madness and get back to work! ... ;o) This is a rather comical situation, though... The debugging tool is providing a rather unexpected and unwelcomed fix. Nico Hi, no, it is not. It is well known! Timings are very critical on almost all drivers. We hold breath on almost everything coming down from above, nobody has the ability, or whom should ever want it, to test all possible side effects on all supported devices ... That something breaks is very common, and that others have to give the plumbers, is nothing new. To stay fair, it mostly has a good reason, and if there are some remaining ticks left, you might get it adjusted, but ... On the other side it is the same ... May post may have sounded offensive, apparently. Sorry about that, my intentions were on the lighter sides of life. Nico nothing offending at all, did enjoy your above comment :) and like your active support for others. It is just not totally unexpected that high debug levels can have some spin-off and I'm curious about it. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] support for key repeat with dib0700 ir receiver
Am Dienstag, den 19.02.2008, 23:29 +0100 schrieb Patrick Boettcher: Hi, On Tue, 19 Feb 2008, Nicolas Will wrote: I would suggest creating a netlink device which lircd (or similar) can read from. Be ready to discount my opinion, I'm not too good at those things. Wouldn't going away from an event interface kill a possible direct link between the remote and X? The way I see it, LIRC is an additional layer that may be one too many in most cases. From my point of view, it is a relative pain I could do without. But I may have tunnel vision by lack of knowledge. I agree with you. I'm more looking for a solution with existing things. LIRC is not in kernel. I don't think we should do something specific, new. If there is nothing which can be done with the event system I think we should either extend it or just drop this idea. What about HID? Patrick. Hi, for what we have ir-common then already? Did not look in any details, but we have a hook there, also for RC5 remotes. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] auto detection of Flytv duo/hybrid and pci/cardbus confusion
Am Sonntag, den 17.02.2008, 21:53 +0100 schrieb Peter Missel: Greetings all! Let me clear things up a bit. First clarification, duo versus hybrid. Are duo cards equipped with two independent tuners that can both be used at the same time? Are hybrid cards necessarily equipped with digital and analogue tuners? Can a two tuner card be both a duo and a hybrid, if one tuner is digital the other is analogue and they can both be used at the same time? LifeView are using two vendor IDs - 4E42h for all (!) their OEMs, and their own one for LifeView branded cards. Hence we need two PCI ID entries for everything, each pair pointing back to the same card data. Then, card types. The analog-only and hybrid have one single tuner, for DVB-T or analog. The Duo cards have two tuner frontends, one for DVB-T and the other for analog. Trio cards add a DVB-S frontend, which cannot be used at the same time as the DVB-T frontend. Like the Duo, these can run one digital and one analog stream in parallel. Finally, card shapes. Each card type comes in CardBus, PCI, and MiniPCI shape. The flavors are compatible, so that again, the PCI ID data point back to the same card entry for e.g. the PCI and CardBus Duo. The card type/shape combinations are distinctly identified by their subsystem ID. No need to guesstimate anything. That's the plan at least. regards, Peter Hi Peter! Your plan is fine so far. We might add some more comments to group devices obviously together, since those looking first time at it are a bit lost. For such i2c IR limits, we have your and Eddi's comments. Since we can't help it easily, Peter D. should suggest the older version of the MSI A/D for auto detection. It won't make anything more worse on that not fully clear Vivanco stuff, except Hartmut might have ideas. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] auto detection of Flytv duo/hybrid and pci/cardbus confusion
Hi Peter, Am Sonntag, den 17.02.2008, 14:28 +1100 schrieb Peter D.: Hi, I've finally gotten around to reading the code and trying to get my PCI MSI [EMAIL PROTECTED] A/D card auto detected. First clarification, duo versus hybrid. Are duo cards equipped with two independent tuners that can both be used at the same time? Are hybrid cards necessarily equipped with digital and analogue tuners? Can a two tuner card be both a duo and a hybrid, if one tuner is digital the other is analogue and they can both be used at the same time? for that all I give some examples further below. Second clarification, PCI versus cardbus. They don't look anything like each other, but can they be logically interchangeable? If the code for a cardbus tuner happens to work for a PCI tuner is there anything wrong with referring to the PCI tuner as a cardbus device? No, we do such and vice versa, but then we add a comment PCI or cardbus version usually and another important compatible category is Mini PCI. You should also add LR306 as the board type. Looking at http://www.linuxtv.org/wiki/index.php/DVB-T_PCMCIA_Cards there does not appear to be any such thing as a SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS, despite the entry (number 94) in saa7134.h. Looking at http://www.linuxtv.org/wiki/index.php/DVB-T_PCI_Cards#LifeView there is a PCI version - but there is no PCI version in saa7134.h. They do exist, see bttv-gallery.de, also Mauro has already a MSI OEM version. They are special for DVB-T, since they switch the mode by a gpio pin and have the silent i2c connection to the tuner open and don't use the i2c gate of the tda8290 analog demod inside the saa7131e for DVB-T tuning. Should SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS be changed to SAA7134_BOARD_FLYDVBT_HYBRID? No. Just also add PCI and LR306 to your comments. The gpio 21 is used for the TV/radio switch. The gpio 22 = 0 in the mask is used to switch the tuner AGC to the analog demod. On some cardbus version, which have the gpio 27 high, switching it to 0 turns the fan on, on yours it does nothing, since it is 0 anyway. It appears that both PCI and cardbus versions of the Flytv duo exist and are listed in saa7134.h - despite slightly inconsistent punctuation; SAA7134_BOARD_FLYDVBTDUO versus SAA7134_BOARD_FLYDVBT_DUO_CARDBUS. Should SAA7134_BOARD_FLYDVBTDUO be changed to SAA7134_BOARD_FLYDVBT_DUO? Not related to your device. Subdevice is 0x0306 and you have 0x3306, but yes, these are in a different family of devices too. I have an MSI [EMAIL PROTECTED] A/D PCI card that works with the option card=94 There appears to not be an entry in struct pci_device_id saa7134_pci_tbl[] in saa7134-cards.c for my card. There is a reference to a [EMAIL PROTECTED] DUO which I guess is a valid entry for a different card. Yes it is. Peter Missel bought some and added the entry. Duo in LifeView terminology means two separate tuners. One for analog TV/FM and one for DVB-T. On the older Duo versions those two tuners were _not hybrid_ and different for analog TV and DVB-T. Only the newer Duo variants with tda8275A use two identical such tuners, but not in hybrid mode. One is always in analog and the other always in digital mode. The older types are out of production and using two still allows to have DVB-T and analog TV from the tuners at once. This is not possible with one single hybrid tuner. DVB-T and analog video from an external input, VCR tuner or something, is possible at once, but needs also to use packed video formats for analog during that due to limitations of the dma engines with planar formats. Then the Trio has even one more tuner for DVB-S, but there is only _one_ saa713x PCI bridge on all such and only one channel decoder/demodulator for each mode. Since the single saa713x chip has only one TS/mpeg/host interface, either usable in parallel or serial mode, DVB-S and DVB-T can not be used at the same time. (also not an mpeg encoder) This is only possible with two saa713x bridges, like the md7134 in the CTX925 version has them and when we enable DVB-S support on the second bridge hopefully soon. Else functionality is like on the Trio. (BTW, the md7134 represents lots of different cards through eeprom detection) Next category is the Medion md8800 Quad(ro) with two saa7131e, two fully usable tda8275ac1 hybrid (2 analog + 2 DVB-T demods, no FM) and two tda8263 DVB-S tuners plus two tda10086 channel decoders plus an isl6405 dual LNB controller, where we just have support of the first SAT connector now, diseqc for multiswitches is not fully tested yet. There is RF loopthrough, in and out, respectively to the other. So it should be already possible to view and record from both DVB-S devices at once, within that tunable spectrum the active one limits for the passive by controlling tone and LNB voltage. That loopthrough can be switched off, for example when we have active control for the second SAT
Re: [linux-dvb] Mdeion / Creatix CTX948 DVB-S driver is ready for testing
Hi, Hartmut, Am Freitag, den 15.02.2008, 01:32 +0100 schrieb Hartmut Hackmann: Hi, again snip So this one works as well, great! But which one is it? Please tell me the minor device id. I need to use it to separate the 2 sections. i will need to control the other one in a very different way. Seems default is some RF loopthrough. I'll need to measure too against loopthrough conditions, but for sure voltage is only on the upper connector and previously with the RF feed from the external receiver the lower connector was fine enough. No voltage in any previous testing and the 12Volts were always connected. Both slightly different Quads from different fabs work as well as the CTX948. In my case it is the 16be:0007 and to the 16be:0008 I have no access. Perfect, that's what i needed to know. snip We might be already through here and you might like to commit first ;) Indeed. I should also announce this status for the md8800... What's your opinion on this: According to the hints i got, the isl6405 is visible only on one section of the md8800. The other section has control over the voltage through a GPIO port. So unless i do something very dirty, there will either be the restriction - that the DVB-S decoder of the 16be:0007 section needs to be selected first. Otherwise the other DVB-S part will not work - or i will need to always fire up the LNB supply of the 0008 section as soon as DVB is initialized. The second approach has the advantage that it has little effect for the end user while the first needs to be explained. But i am not sure whether the isl6405 is fully short circuit proof. I will read the datasheet again... if the second approach is safe and the API says nothing different, according to the MD8800 manual, it seems to be closer to the behavior of the other OS, but I can't test it. In opposite to what is stated for the switchable RF loopthrough on the two hybrid tuners, the manual claims that the DVB-S inputs are separate and not connected and nothing to switch there ... Andrew has loopthrough enabled by default and that is what I even see from the unused second DVB-S tuner to the first one I can use. We might want to set has_loopthrough = 0 then too. Funny stuff again. The latest revision of the manual _seems_ to be clear for possible tuner/demod/bridge combinations, also states nothing about concurrent usage of the other analog inputs. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] MSI [EMAIL PROTECTED] A/D v1.1 patch
Hi, Am Freitag, den 15.02.2008, 23:53 +0100 schrieb Hartmut Hackmann: Hi, Russell Russell Kliese schrieb: Hi, I've created a patch to support the MSI [EMAIL PROTECTED] A/D v1.1 card. This card previously had firmware upload issues when using card=109. With this patch, it's auto-detected and I haven't experienced any firmware upload problems (although my testing hasn't been exhaustive, but I have tried a couple of cold boots). I've tested both analog and digital TV. I haven't yet tested S-Video or composite inputs, so these might need to be tweaked. It would be great if this patch could be merged into the main repository. If there are any special requirements to allow this to be done, please let me know. Cheers, Russell Kliese You were able to help yourself, good! Few questions / commments: - Does the board support FM Radio? - Can you test the composite / S-Video inputs somehow? We already have boards with wrong configurations here but i would like to minimize the number ;-) - The code fragment in saa7134-cards.c from line 5479 on should not be necessary. Can you please cross check? please also drop the duplicate code in saa7134-dvb and just use philips_tiger_s_config. When i integrate the patch, i would like to mention you as the patch author. For this, i will need a signature from you: Signed-off-by: Your Name your email address Thanks, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mdeion / Creatix CTX948 DVB-S driver is ready for testing
Am Donnerstag, den 14.02.2008, 02:00 +0100 schrieb Hartmut Hackmann: Hi, folks In my personal repository: http://linuxtv.org/hg/~hhackmann/v4l-dvb-experimental/ you will find a driver that supports this card, DVB-T and DVB-S It might also work for - one section of the MD8800 - similar boards based on saa713x, tda10086, tda826x, isl6405 The board will show up as MD8800. According to Hermann, the configurations for analog TV and DVB-T are identical. If you want to use the board with DVB-S, you will need to load the saa7134-dvb module with the option use_frontend=1. The default 0 is DVB-T. For those who got the board from a second source: don't forget to connect the 12v (the floppy supply) connector. I don't have a dish, so i depend on your reports. To get the MD8800 running, i need a volunteer who does the testing for me. He should be able to apply patches, compile the driver and read kernel logs. Good luck Hartmut Hartmut, great job, thank you very much! Can't wait, result of a first voltage measurement on the md8800 Quad. The upper LNB connector associated to the second saa7134 16be:0008 device has correct voltage. Since my stuff is not in the original green PCI slot and I have only the first 16be:0007 device active, can't test much more for now here. People with the card in the original Medion PC could set options saa7134-dvb use_frontend=1 debug=1 in /etc/modprobe.conf and then do depmod -a. The Syntek v4l usb stkwebcam still produces a compilation error and needs to be disabled in make xconfig or something else. After make it is best to do make rmmod on top of your v4l-dvb-experimental first. Those new to the v4l-dvb development stuff might do also make rminstall and then check that no *.ko is left in /lib/modules/kernel_in_use/kernel/drivers/media/* Especially the old video_buf.ko in the video dir needs to be removed. Check with ls -R |grep .ko and then make install. Now I suggest to modprobe saa7134 card=117,96 In that case DVB-T is supported on the lower antenna connector and first adapter and DVB-S on the upper LNB connector and second adapter. Or to have it simple, it is safe to make rmmod and modprobe saa7134 card=5,96 tuner=54,54 This way on the first device is only analog TV enabled, don't forget to use it first to have good DVB-T reception later anyway, and the only frontend is the DVB-S one in question for testing. On the CTX948 voltage is OK AND Tuning to: Camera Deputati / autocount: 22 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 11804000 v 2750 inv:2 fecH:2 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 373 ms pipe opened xine pipe opened /root/.kaxtv.ts Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: Dubai Sports-1 / autocount: 23 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 11747000 h 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 18V, hiband (index 3) DiSEqC: e0 10 38 f3 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 374 ms xine pipe opened /root/.kaxtv1.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: ARD Das Erste / autocount: 24 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 11604000 h 2750 inv:2 fecH:5 DiSEqC: switch pos 0, 18V, loband (index 1) DiSEqC: e0 10 38 f2 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 379 ms xine pipe opened /root/.kaxtv.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: Abu Dhabi Sport / autocount: 25 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 12577000 h 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 18V, hiband (index 3) DiSEqC: e0 10 38 f3 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 379 ms xine pipe opened /root/.kaxtv1.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: BBC World / autocount: 26 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 12596000 v 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 ... LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 560 ms pipe opened xine pipe opened /root/.kaxtv.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: All Music / autocount: 38 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 10949000 v 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 13V, loband (index 0) DiSEqC: e0 10 38 f0 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 378 ms xine pipe opened /root/.kaxtv.ts pipe opened Congratulations! Cheers, Hermann ___ linux-dvb
Re: [linux-dvb] Mdeion / Creatix CTX948 DVB-S driver is ready for testing
Hi, Am Donnerstag, den 14.02.2008, 12:01 +0100 schrieb hermann pitton: Am Donnerstag, den 14.02.2008, 02:00 +0100 schrieb Hartmut Hackmann: Hi, folks In my personal repository: http://linuxtv.org/hg/~hhackmann/v4l-dvb-experimental/ you will find a driver that supports this card, DVB-T and DVB-S It might also work for - one section of the MD8800 - similar boards based on saa713x, tda10086, tda826x, isl6405 The board will show up as MD8800. According to Hermann, the configurations for analog TV and DVB-T are identical. If you want to use the board with DVB-S, you will need to load the saa7134-dvb module with the option use_frontend=1. The default 0 is DVB-T. For those who got the board from a second source: don't forget to connect the 12v (the floppy supply) connector. I don't have a dish, so i depend on your reports. To get the MD8800 running, i need a volunteer who does the testing for me. He should be able to apply patches, compile the driver and read kernel logs. Good luck Hartmut Hartmut, great job, thank you very much! Can't wait, result of a first voltage measurement on the md8800 Quad. The upper LNB connector associated to the second saa7134 16be:0008 device has correct voltage. Since my stuff is not in the original green PCI slot and I have only the first 16be:0007 device active, can't test much more for now here. back on the machine and thinking about it twice ... The Quad works for me as well on the upper LNB connector, despite of that I previously used the lower one successfully with RF loopthrough from an external receiver. So, in case of the Quad, just let it be autodetected and try on the first adapter and upper LNB connector. Even more fun :) Cheers, Hermann People with the card in the original Medion PC could set options saa7134-dvb use_frontend=1 debug=1 in /etc/modprobe.conf and then do depmod -a. The Syntek v4l usb stkwebcam still produces a compilation error and needs to be disabled in make xconfig or something else. After make it is best to do make rmmod on top of your v4l-dvb-experimental first. Those new to the v4l-dvb development stuff might do also make rminstall and then check that no *.ko is left in /lib/modules/kernel_in_use/kernel/drivers/media/* Especially the old video_buf.ko in the video dir needs to be removed. Check with ls -R |grep .ko and then make install. Now I suggest to modprobe saa7134 card=117,96 In that case DVB-T is supported on the lower antenna connector and first adapter and DVB-S on the upper LNB connector and second adapter. Or to have it simple, it is safe to make rmmod and modprobe saa7134 card=5,96 tuner=54,54 This way on the first device is only analog TV enabled, don't forget to use it first to have good DVB-T reception later anyway, and the only frontend is the DVB-S one in question for testing. On the CTX948 voltage is OK AND Tuning to: Camera Deputati / autocount: 22 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 11804000 v 2750 inv:2 fecH:2 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 373 ms pipe opened xine pipe opened /root/.kaxtv.ts Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: Dubai Sports-1 / autocount: 23 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 11747000 h 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 18V, hiband (index 3) DiSEqC: e0 10 38 f3 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 374 ms xine pipe opened /root/.kaxtv1.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: ARD Das Erste / autocount: 24 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 11604000 h 2750 inv:2 fecH:5 DiSEqC: switch pos 0, 18V, loband (index 1) DiSEqC: e0 10 38 f2 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 379 ms xine pipe opened /root/.kaxtv.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: Abu Dhabi Sport / autocount: 25 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 12577000 h 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 18V, hiband (index 3) DiSEqC: e0 10 38 f3 00 00 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 379 ms xine pipe opened /root/.kaxtv1.ts pipe opened Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Tuning to: BBC World / autocount: 26 Using DVB device 0:0 Philips TDA10086 DVB-S tuning DVB-S to 12596000 v 2750 inv:2 fecH:3 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 ... LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 560 ms pipe opened
Re: [linux-dvb] Mdeion / Creatix CTX948 DVB-S driver is ready for testing
Hi Hartmut, Am Donnerstag, den 14.02.2008, 22:59 +0100 schrieb Hartmut Hackmann: Hi, Hermann I am a bit confused hermann pitton schrieb: Hi, Am Donnerstag, den 14.02.2008, 12:01 +0100 schrieb hermann pitton: Am Donnerstag, den 14.02.2008, 02:00 +0100 schrieb Hartmut Hackmann: Hi, folks In my personal repository: http://linuxtv.org/hg/~hhackmann/v4l-dvb-experimental/ you will find a driver that supports this card, DVB-T and DVB-S It might also work for - one section of the MD8800 - similar boards based on saa713x, tda10086, tda826x, isl6405 The board will show up as MD8800. According to Hermann, the configurations for analog TV and DVB-T are identical. If you want to use the board with DVB-S, you will need to load the saa7134-dvb module with the option use_frontend=1. The default 0 is DVB-T. For those who got the board from a second source: don't forget to connect the 12v (the floppy supply) connector. I don't have a dish, so i depend on your reports. To get the MD8800 running, i need a volunteer who does the testing for me. He should be able to apply patches, compile the driver and read kernel logs. Good luck Hartmut Hartmut, great job, thank you very much! Can't wait, result of a first voltage measurement on the md8800 Quad. The upper LNB connector associated to the second saa7134 16be:0008 device has correct voltage. Since my stuff is not in the original green PCI slot and I have only the first 16be:0007 device active, can't test much more for now here. back on the machine and thinking about it twice ... The Quad works for me as well on the upper LNB connector, despite of that I previously used the lower one successfully with RF loopthrough from an external receiver. So, in case of the Quad, just let it be autodetected and try on the first adapter and upper LNB connector. So this one works as well, great! But which one is it? Please tell me the minor device id. I need to use it to separate the 2 sections. i will need to control the other one in a very different way. Seems default is some RF loopthrough. I'll need to measure too against loopthrough conditions, but for sure voltage is only on the upper connector and previously with the RF feed from the external receiver the lower connector was fine enough. No voltage in any previous testing and the 12Volts were always connected. Both slightly different Quads from different fabs work as well as the CTX948. In my case it is the 16be:0007 and to the 16be:0008 I have no access. Even more fun :) Cheers, Hermann People with the card in the original Medion PC could set options saa7134-dvb use_frontend=1 debug=1 in /etc/modprobe.conf and then do depmod -a. The Syntek v4l usb stkwebcam still produces a compilation error and needs to be disabled in make xconfig or something else. Hm, i didn't have any compile problems ... This happens on an almost given up FC5 with some 2.6.20 ... After make it is best to do make rmmod on top of your v4l-dvb-experimental first. Those new to the v4l-dvb development stuff might do also make rminstall and then check that no *.ko is left in /lib/modules/kernel_in_use/kernel/drivers/media/* Especially the old video_buf.ko in the video dir needs to be removed. Check with ls -R |grep .ko and then make install. Now I suggest to modprobe saa7134 card=117,96 In that case DVB-T is supported on the lower antenna connector and first adapter and DVB-S on the upper LNB connector and second adapter. Or to have it simple, it is safe to make rmmod and modprobe saa7134 card=5,96 tuner=54,54 This way on the first device is only analog TV enabled, don't forget to use it first to have good DVB-T reception later anyway, and the only frontend is the DVB-S one in question for testing. Why? the cards should be autodetected. Or is there a variant of the 948 with a device id different from 16be:000d? It should be possible to give a list to the use_frontend=xx option. Something like use_frontend=0,1,0 which should select DVB-S only for the 2nd instance. Am i wrong? Of corse you will need to select the right frontend which is not easy with some applications. snip This was all about first ideas on the Quads. On the CTX948 there is no problem _at all_! For the Quad I took my first idea back and said, just let it be auto detected and take the first frontend then and the upper LNB connector. Sorry for confusion, but it is still a little ... But thank you for your fast reporting! Another issue: You have some patches waiting for integration. We can use my other repository for this. We might be already through here and you might like to commit first ;) Best regards Hartmut Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Help! I cant view video. BUT I can scan!!
Hi! Am Sonntag, den 10.02.2008, 23:37 +0100 schrieb Per Blomqvist: Thanx! Now it works!! Watching some Danish (Dansk) channel, about Napoleon. Thanx again, for mocking me up.. It was the channel.conf, that was wrong The channel.conf -file that I used before, was 6 month old and from my previous computer. (Now dvbscan doesn't detect anything on that bandwidth. And that TV6 was on that.. If I run dvdscan against the closest mayor city (Malmö in my case, here in south Sweden), it only tunedin encrypted channels. BUT, against all of Denmark (file dk-All) I get a some.. Its strange though.. I CAN SEE TV6 unencrypted, but in Windows XP. But there with A program called PowerCinema is used (in XP OS). (tuning is a fuzz there also, I believe PowerCinema download channels and guides and what, from the internet. It would maybe be a point to retrieve its (channel) configure file. I have looked, but found none. Another question now, how is all these initial-tuning-data created?? Either the broadcasters provide them or people try as good they can. Since different channel decoders vary in the tolerance for having something wrong there, and also broadcasters often change something, with the tda10046 better try as recommended. redeb:~/.tzap# cat dk-All # Denmark, whole country # Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 48200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 50600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 55400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 60200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 68200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 69000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 71400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 73800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 82600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 83400 8MHz 2/3 NONE QAM64 8k 1/4 NONE redeb:~/.tzap# cat se-Malmo # Sweden - Malmö # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 48200 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 50600 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 61800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 81800 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 85000 8MHz 3/4 NONE QAM64 8k 1/4 NONE Can I compose one, of these by myself (from other nearby citys), or how? There are a lot of Swedish channels.conf in dvb-apps now. In kaffeine you just select the transmitters in the dvb configuration. You also can combine multiple transmitters or try with w_scan. http://wirbel.htpc-forum.de/w_scan/index2.html http://edafe.org/vdr/wscan.html hermann pitton wrote: Hi, Am Sonntag, den 10.02.2008, 15:28 +0100 schrieb Per Blomqvist: Hello Jonas Andren. (Kom inte o säg att Anden är dansk) The Harware I have, I have said. Its the media-card, is this: http://www.linuxtv.org/wiki/index.php/Asus_My_Cinema-P7131_Hybrid (running on a amd64, mother-board m2a-vm.. Inköpt på KjellCo byggsats för 2 veckor sedan... I also said that the same Media-card did function (somewhat) on my old computer (a PII330MHz, though with terrible video result). And it works in Windows XP. So, the Media-card function. I downloadedinstalled linuxtv-dvb-apps-1.1.1.tar.bz2 http://www.linuxtv.org/downloads/linuxtv-dvb-apps-1.1.1.tar.bz2 (and all so called utils: dvbdate dvbtrafick scan and zap worked. BUT, nothing under the test) you should prefer dvb-apps from mercurial, but that is not so important. There is a deb-package called mercurial. (I suspect it doesnt have anything, todo with this, no?) http://www.linuxtv.org/repo You will find recent initial tuning and channels.conf files in dvb-apps. First of all I would like to see relevant dmesg stuff for the card and tuner to see if it is still likely the same card, auto detected and eeprom content unchanged and all chips alive. If you enable i2c_scan=1 you look first for the devices found. I used the linux-kernels-source. in its documents for this. Downloaded the firmware.. (I include dmesg output in the end of this email, anyway. The revision is 20, and not a LifeView fabrication.. Thanks. It is the known card with LNA. According to Asus, Philips/NXP firmware prior to revision 26 had problems with missing channels. Also we never saw, if your firmware upload is successful and if you use preferably revision 29 with such a card with Low Noise Amplifier. If not, download it from LifeView with the script in /Documentation/dvb and do a cold boot. (recent stuff is in a v4l-dvb mercurial snapshot) All the older P7131 Dual cards have a firmware eeprom and only the oldest revision needed an upgrade. Since you have no firmware on eeprom ./get_dvb_firmware tda10046lifeview. Antenna input for DVB-T is FM/RF input. Can you point
Re: [linux-dvb] Help! I cant view video. BUT I can scan!!
Hi, Am Sonntag, den 10.02.2008, 15:28 +0100 schrieb Per Blomqvist: Hello Jonas Andren. (Kom inte o säg att Anden är dansk) The Harware I have, I have said. Its the media-card, is this: http://www.linuxtv.org/wiki/index.php/Asus_My_Cinema-P7131_Hybrid (running on a amd64, mother-board m2a-vm.. Inköpt på KjellCo byggsats för 2 veckor sedan... I also said that the same Media-card did function (somewhat) on my old computer (a PII330MHz, though with terrible video result). And it works in Windows XP. So, the Media-card function. I downloadedinstalled linuxtv-dvb-apps-1.1.1.tar.bz2 http://www.linuxtv.org/downloads/linuxtv-dvb-apps-1.1.1.tar.bz2 (and all so called utils: dvbdate dvbtrafick scan and zap worked. BUT, nothing under the test) you should prefer dvb-apps from mercurial, but that is not so important. First of all I would like to see relevant dmesg stuff for the card and tuner to see if it is still likely the same card, auto detected and eeprom content unchanged and all chips alive. If you enable i2c_scan=1 you look first for the devices found. Also we never saw, if your firmware upload is successful and if you use preferably revision 29 with such a card with Low Noise Amplifier. If not, download it from LifeView with the script in /Documentation/dvb and do a cold boot. (recent stuff is in a v4l-dvb mercurial snapshot) Antenna input for DVB-T is FM/RF input. Can you point to the initial tuning file you are using or to what you believe is a valid channels.conf file for you? It is always worth a try to set all to AUTO in the initial tuning file, except frequency to tune and bandwidth and then use scan to create a channels.conf. If still not, we install the recent v4l-dvb, remove all old modules and might try to debug from there. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] TDA10086 with Pinnacle 400e tuning broken
Am Mittwoch, den 06.02.2008, 09:17 +0100 schrieb André Weidemann: Hartmut Hackmann wrote: Are you sure that it is a lnbp21 on your board? What kind of satellite equipment do you have? - a single LNB, so the 22kHz tone is enough. - a Multiswitch? if yes, which commands does it need / understand? - nothing but the tone? - a tone burst to switch between satellites and the tone? - full diseqc (2?) serial messages? I got a board with tda10086 and lnbp21 let and started measuring. voltage switching and static tone work fine with the current configuration. Hi Hartmut, I got the same tuning problems as Patrick. After your patch the Pinnacle 400e is not working anymore. I can get a signal, but no lock at all. I took a look at the PCB and there is definitely an LNBP21PD soldered onto it. Your patch disables the modulation of the 22kHz signal inside the demod as fas as I understood, but then the LNBP21PD was supposed to generate it. Unfortunately this is not possible with the Pinnacle 400e. I took a look at the LNBP21PD datasheet which states, that DSQIN is supposed to be connected to GND if you don't want the 22kHz signal to be generated by the LNBP21 itself. Guess what?! Pin 14(DSQIN) is connected to GND. For the time being I reverted your patch on my local system and the Pinnacle 400e is working flawlessly again. André Hi, we should try to get this sorted. With the prior state, working for Andre and others, it does not work on the LifeView Trio (PCI and cardbus) and the saa7134 driver. Three guys I think reported it and Hartmut did wait with the patch for long and allowed about half a year for testing ... So, if we can't fix it soon, prior state of course counts and those later will have to use the patches further. Such a fix can always be committed prior to 2.6.25 release. Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Patch for analog part for Avermedia A700 fails to apply
Am Dienstag, den 29.01.2008, 14:07 +0100 schrieb Matthias Schwarzott: On Dienstag, 29. Januar 2008, Eduard Huguet wrote: Hi, I'm just trying to apply the first patch mentioned on the wiki for this cardad I'm getting the following result: From http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_DVB-S_Pro_%28A700%29 http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_DVB-S_Pro_%2528A700% 2529 # patch -p1 ../1_avertv_A700_analog_part.diff patching file linux/drivers/media/video/saa7134/saa7134-cards.c Hunk #1 succeeded at 3992 with fuzz 2 (offset 41 lines). Hunk #2 succeeded at 4243 (offset 41 lines). Hunk #3 succeeded at 5233 (offset 59 lines). patching file linux/drivers/media/video/saa7134/saa7134.h Hunk #1 FAILED at 260. 1 out of 1 hunk FAILED -- saving rejects to file linux/drivers/media/video/saa7134/saa7134.h.rej patching file linux/Documentation/video4linux/CARDLIST.saa7134 Hunk #1 FAILED at 129. 1 out of 1 hunk FAILED -- saving rejects to file linux/Documentation/video4linux/CARDLIST.saa7134.rej linux/drivers/media/video/saa7134/saa7134.h.rej: *** *** 260,265 #define SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM 128 #define SAA7134_BOARD_BEHOLD_607_9FM 129 #define SAA7134_BOARD_BEHOLD_M6 130 #define SAA7134_MAXBOARDS 8 #define SAA7134_INPUT_MAX 8 --- 260,266 #define SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM 128 #define SAA7134_BOARD_BEHOLD_607_9FM 129 #define SAA7134_BOARD_BEHOLD_M6 130 + #define SAA7134_BOARD_AVERMEDIA_A700 131 #define SAA7134_MAXBOARDS 8 #define SAA7134_INPUT_MAX 8 Sure the patch is too old. There was added a new card to saa7134 driver. So I needed to update the patch. You can now get the patch from my last mail (it was attached). http://thread.gmane.org/gmane.linux.drivers.dvb/38943/focus=38952 Or you re-download the file linked from the wiki. I uploaded the new version. Greetings Matthias Hi Matthias, sorry for breaking your lines in between. Else, you have done such good spotting already. You are very welcome! Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] unable to compile latest HG
Hi, Am Montag, den 28.01.2008, 15:06 + schrieb Stephen Rowles: Hi, I am trying to build the latest HG to get the fixes for my Nova-T-Stick that were added a couple of days ago. However I the following problem with the stk-webcam modiles: Is there something I'm missing? Do I need a later kernel than the 2.6.21 that I currently have or is there some other problem? As I don't need this device, is there an easy way to stop it being built? Cheers. Steve Make Error: [EMAIL PROTECTED] v4l-dvb]# make make -C /home/root/dvb/latest-hg/v4l-dvb/v4l make[1]: Entering directory `/home/root/dvb/latest-hg/v4l-dvb/v4l' creating symbolic links... Kernel build directory is /lib/modules/2.6.21-1.3194.fc7/build make -C /lib/modules/2.6.21-1.3194.fc7/build SUBDIRS=/home/root/dvb/latest-hg/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/kernels/2.6.21-1.3194.fc7-i686' CC [M] /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.o /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c: In function 'stk_isoc_handler': /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:400: warning: implicit declaration of function 'list_first_entry' /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:401: error: expected expression before 'struct' /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:401: warning: assignment makes pointer from integer without a cast /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:448: error: expected expression before 'struct' /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:448: warning: assignment makes pointer from integer without a cast /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c: In function 'v4l_stk_read': /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:778: error: expected expression before 'struct' /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:778: warning: assignment makes pointer from integer without a cast /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c: In function 'stk_vidioc_dqbuf': /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:1251: error: expected expression before 'struct' /home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.c:1251: warning: assignment makes pointer from integer without a cast make[3]: *** [/home/root/dvb/latest-hg/v4l-dvb/v4l/stk-webcam.o] Error 1 make[2]: *** [_module_/home/root/dvb/latest-hg/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.21-1.3194.fc7-i686' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/root/dvb/latest-hg/v4l-dvb/v4l' make: *** [all] Error 2 Darren Salt last night posted a compat fix for it to the video4linux-list. It works at least down to 2.6.20 and on 2.6.22 and higher it is not needed. Else you can simply disable the syntek webcam in make xconfig or similar for the moment. Mauro, if you should get any time for such these days, please have a look at Darren's patches. Thanks, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] saa7134 TUN 900 card remote driver
Hello, Am Samstag, den 26.01.2008, 13:39 +1100 schrieb Peter D.: I think that you are asking in the correct place BUT you are addressing a bunch of volunteers working on their hobby. no, wrong place. No dvb on it. Things get done when someone feels inspired to do something. There probably isn't a HOWTO. If you find one let me know. I have an MSI without remote support and a Kworld with remote support that I haven't managed to get working. :-( We have a HOWTO for simple gpio remotes on the v4l wiki. For this one the TODO list can be found in the mail archives. http://marc.info/?l=linux-videow=2r=1s=Tun900q=b You are, of course, welcome to do any work that you are up to doing yourself. ;-) Mike pulled that one in and I had to defend the auto detection for a prior card they did try to steel ;) Separate Composite1 is missing, it is on vmux = 3. Test composite over s-video, likely this is on vmux = 0. S-Video is likely wrong, the other Yuan card has it on vmux = 7 The amux for radio is likely wrong. Try amux = TV too. The gpiomask and the radio switch look suspicious. Most other cards switch to radio on gpio21, 0x020. The card could need eeprom detection, since it has the same subsystem IDs than the UPMOST_PURPLE_TV. With that one it shares also a device at 0xf4. (0x7a seven bit) On the Upmost it is the i2c remote controller for which Wang-Chan Chen added support in ir-kbd-i2c. You can try on that one. Here is some eeprom dump from his card. You can pick something for detection, maybe the c2 byte on yours. saa7133[0]: found at :00:0d.0, rev: 16, irq: 10, latency: 64, mmio: 0xd000 saa7133[0]: subsystem: 12ab:0800, board: UPMOST PURPLE TV [card=36,autodetected] saa7133[0]: board init: gpio is 0 saa7133[0]: dsp access wait timeout [bit=WRR] saa7133[0]: dsp access wait timeout [bit=WRR] saa7133[0]: i2c eeprom 00: ab 12 00 08 00 00 00 00 00 00 00 00 00 00 00 00 saa7133[0]: i2c eeprom 10: 00 00 00 00 15 00 05 01 0b c0 d1 ff ff ff ff ff saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 0-0060: chip found @ 0xc0 (saa7133[0]) tuner 0-0060: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) tda9885/6/7: chip found @ 0x86 saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 ir-kbd-i2c: i2c IR (Purple TV) detected at i2c-0/0-007a/ir0 [saa7133[0]] Please send further posts and patches only to the video4linux-list. Cheers, Hermann Peter D. On Saturday 26 January 2008, Timothy E. Krantz wrote: Hmmm, no response yet. Am I asking in the wrong place? _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy E. Krantz Sent: Thursday, January 24, 2008 2:48 PM To: linux-dvb@linuxtv.org Subject: [linux-dvb] saa7134 TUN 900 card remote driver Hi, looking at the code for the TUN 900 (card 66) part of the saa7134 driver I see that it says that the remote control is not implemented. Can someone point me in the direction of a FAQ or HOWTO that would get me started on fixing that? Thanks in Advance. Tim ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suse Linux 10.2
Am Dienstag, den 22.01.2008, 08:16 +0100 schrieb thomas schorpp: hermann pitton wrote: Hi, Am Montag, den 21.01.2008, 16:41 +0100 schrieb thomas schorpp: Dr. Michael Schaale wrote: Hi, I tried to re-compile the driver staff after a kernel update and ended in an error message that I cannot understand ... anybody able to help me ?? Thanks !! Kindest regards, Michael /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'stk_isoc_handler': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:400: error: implicit declaration of function 'list_first_entry' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:401: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:401: warning: assignment makes pointer from integer without a cast /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:448: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:448: warning: assignment makes pointer from integer without a cast /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'stk_prepare_iso': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:534: warning: assignment from incompatible pointer type /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'v4l_stk_read': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:775: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:775: warning: assignment makes pointer from integer without a cast /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'stk_vidioc_dqbuf': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:1225: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:1225: warning: assignment makes pointer from integer without a cast make[5]: *** [/tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.o] Error 1 make[4]: *** [_module_/tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l] Error 2 make[3]: *** [modules] Error 2 make[2]: *** [modules] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.18.8-0.7-obj/i386/default' make[1]: *** [default] Error 2 make[1]: Leaving directory `/tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l' make: *** [all] Error 2 which version? pls do a ~$hg -pull -u header errors, kernel maintainer's fault or Your v4l-dvb sandbox is out of sync. anyway, it is not recommended and not really supported to build v4l-dvb hg against such old kernels, pls use latest linux release kernel. y tom that should not be necessary. The new synthek stk-webcam driver needs to be fixed for compat. Until then, if Michael don't need it, just disable in make xconfig or menuconfig/config. Cheers, Hermann well! so lets have this list flooded by users accusing v4l-dvb for not always distro patched-up ancient kernels or gcc versions binary incompats. and do You've got a list for all drivers not compatible for each and every older kernel release = 2.6.12 version? http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers#Solution_for_old_kernels_.282.4.x.29 fine CM/QA-practice. y tom Hi Tom, you might remember that I did not like when some people did not stop to ask, how they could have v4l2 version 1 up to date for their obscure interests. The case here is a little different. People like Mauro, Mike and Trent are spending a lot of work, Trent especially during all the last time, that we have some reasonable compatibility and likely one of the best build systems around ever. So, we don't send people into deserts, if not needed. This counts especially for those working on university projects, they likely have own software in use, which might need to be updated too, but to do this is in most cases _not_ the subject of their studies ... Cheers, Hermann -- FB11 ;) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] saa7134-dvb: add missing dvb_attach call (for tda10046_attach)
Am Samstag, den 26.01.2008, 00:13 +0100 schrieb Hartmut Hackmann: Hi, Matthias Schwarzott schrieb: Hi there! The attached small patch adds a missing dvb_attach wrapping around tda10046_attach. So it removes the hard dependency of saa7134-dvb on tda1004x module. I have only tested compiling as I don not have the hardware. Greetings Matthias I don't have this hardware either but your patch is right. Can you please resend it with your signature like Signed-off-by: Hartmut Hackmann [EMAIL PROTECTED] Reviewed-by: Hermann Pitton [EMAIL PROTECTED] (of corse with your name and e-mail address) Please do this soon otherwise it will not make it into the next kernel release. Best regards Hartmut Hi all, quality control is a nice thing. To have a two weeks merge window too ... ;) On checkpatch.pl and other stuff one can easily triple the total amount of patches for nothing. On missing SOBs the amount of mails too. We should carefully watch this. It will end up in that only those buying new cards endlessly, hundreds are already on the way, are trusted for patches. Hm, that was not the plan for /me. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suse Linux 10.2
Hi, Am Montag, den 21.01.2008, 16:41 +0100 schrieb thomas schorpp: Dr. Michael Schaale wrote: Hi, I tried to re-compile the driver staff after a kernel update and ended in an error message that I cannot understand ... anybody able to help me ?? Thanks !! Kindest regards, Michael /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'stk_isoc_handler': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:400: error: implicit declaration of function 'list_first_entry' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:401: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:401: warning: assignment makes pointer from integer without a cast /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:448: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:448: warning: assignment makes pointer from integer without a cast /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'stk_prepare_iso': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:534: warning: assignment from incompatible pointer type /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'v4l_stk_read': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:775: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:775: warning: assignment makes pointer from integer without a cast /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c: In function 'stk_vidioc_dqbuf': /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:1225: error: expected expression before 'struct' /tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.c:1225: warning: assignment makes pointer from integer without a cast make[5]: *** [/tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l/stk-webcam.o] Error 1 make[4]: *** [_module_/tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l] Error 2 make[3]: *** [modules] Error 2 make[2]: *** [modules] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.18.8-0.7-obj/i386/default' make[1]: *** [default] Error 2 make[1]: Leaving directory `/tmp3/downloaded_stuff/post-install-10.2/Software/DONE/FIRMWARE/v4l-dvb/v4l' make: *** [all] Error 2 which version? pls do a ~$hg -pull -u header errors, kernel maintainer's fault or Your v4l-dvb sandbox is out of sync. anyway, it is not recommended and not really supported to build v4l-dvb hg against such old kernels, pls use latest linux release kernel. y tom that should not be necessary. The new synthek stk-webcam driver needs to be fixed for compat. Until then, if Michael don't need it, just disable in make xconfig or menuconfig/config. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Need suggestions for TV card
Am Dienstag, den 22.01.2008, 10:01 +1100 schrieb Robin Rainton: Carsten Aulbert wrote: Look at the linux-dvb Wiki and look if the card of your choise is listed there. Although be aware that this is no guarantee. I recently purchased an MSI TV @ Anywhere which was listed in the Wiki, only to find MSI had changed a few things and the card was now V1.1. Eventually I've managed to get this working (see mails on this list about that) but it's not stable as yet. Cheers, Rob Hi Rob, to your new card version Hartmut or me should try to come back for further investigations. Do you have any analog TV broadcast left and can eventually also test and report on that? We have to test if there is really a LowNoiseAmplyfier on it, seems so. Also Hartmut predicted already 9 months back, that we likely will see a change to use the tda8290 i2c gate to the tuner on this stuff, like most others do. This you have confirmed already with your recent testing. Thanks, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [Patch 3/4] saa7134: add initial support for the Creatix CTX948_V1
We might add it to the name string as well, when the Quadro
might be duplicate for the LNB control.
- start here
From: Hermann Pitton [EMAIL PROTECTED]
This adds support for analog inputs and DVB-T.
Good sensitivity for DVB-T currently needs to use analog TV first.
DVB-S support is not yet completed, but is on the way.
Signed-off-by: Hermann Pitton [EMAIL PROTECTED]
diff -r 99b8ada1f4b6 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jan 18 22:55:05
2008 +0100
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jan 18 23:08:32
2008 +0100
@@ -4601,6 +4601,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0x0008,
.driver_data = SAA7134_BOARD_MEDION_MD8800_QUADRO,
},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x16be,
+ .subdevice= 0x000d, /* triple CTX948_V1.1.1 */
+ .driver_data = SAA7134_BOARD_MEDION_MD8800_QUADRO,
+ }, {
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x1461,
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [Patch 4/4] saa7134: detect the LifeView FlyDVB-T Hybrid Mini PCI
saa7134: detect the LifeView FlyDVB-T Hybrid Mini PCI
From: Hermann Pitton [EMAIL PROTECTED]
Thanks to Angelo Lisco for his initial patch we missed and to
Ahmet Dogan Ugurel confirming such a device functional.
Signed-off-by: Hermann Pitton [EMAIL PROTECTED]
diff -r ca55fe14f3e1 -r 4d71d8ea3835
linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 Fri Jan 18 23:22:10
2008 +0100
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Sat Jan 19 00:38:27
2008 +0100
@@ -92,7 +92,7 @@
91 - AVerMedia A169 B [1461:7360]
92 - AVerMedia A169 B1[1461:6360]
93 - Medion 7134 Bridge #2[16be:0005]
- 94 - LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB
[5168:3306,5168:3502,4e42:3502]
+ 94 - LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB
[5168:3306,5168:3502,5168:3307,4e42:3502]
95 - LifeView FlyVIDEO3000 (NTSC) [5169:0138]
96 - Medion Md8800 Quadro [16be:0007,16be:0008,16be:000d]
97 - LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300]
diff -r ca55fe14f3e1 -r 4d71d8ea3835
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jan 18 23:22:10
2008 +0100
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Jan 19 00:38:27
2008 +0100
@@ -4589,6 +4589,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0x3502, /* whats the difference to 0x3306 ?*/
.driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS,
},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5168,
+ .subdevice= 0x3307, /* FlyDVB-T Hybrid Mini PCI */
+ .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS,
+ }, {
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x16be,
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [Patch 1/4] saa7134: support for Twinhan Hybrid DTV-DVB 3056 PCI
Hi,
here are four patches which should be ready for review.
Maybe Hartmut can have a look at them too.
Thanks,
Hermann
--
saa7134: support for Twinhan Hybrid DTV-DVB 3056 PCI
From: Hermann Pitton [EMAIL PROTECTED]
S-Video is unconfirmed, but likely correct.
The remote is not yet investigated.
Thanks go to Sioux for providing code and asking to fix the auto
detection.
Signed-off-by: sioux [EMAIL PROTECTED]
Signed-off-by: Hermann Pitton [EMAIL PROTECTED]
diff -r 2ae5c2995730 linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 Sun Jan 13 13:02:20
2008 -0200
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Sun Jan 13 22:39:26
2008 +0100
@@ -129,3 +129,4 @@ 128 - Beholder BeholdTV Columbus TVFM
128 - Beholder BeholdTV Columbus TVFM [:5201]
129 - Beholder BeholdTV 607 / BeholdTV 609
[5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093]
130 - Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193]
+131 - Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
diff -r 2ae5c2995730 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 13 13:02:20
2008 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 13 22:42:58
2008 +0100
@@ -3951,6 +3951,36 @@ struct saa7134_board saa7134_boards[] =
},
.mpeg = SAA7134_MPEG_EMPRESS,
},
+ [SAA7134_BOARD_TWINHAN_DTV_DVB_3056] = {
+ .name = Twinhan Hybrid DTV-DVB 3056 PCI,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 2,
+ .mpeg = SAA7134_MPEG_DVB,
+ .gpiomask = 0x020,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,/* untested */
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x020,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -4882,7 +4912,13 @@ struct pci_device_id saa7134_pci_tbl[] =
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x4e42,
.subdevice= 0x3502,
- .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS
+ .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1822, /*Twinhan Technology Co. Ltd*/
+ .subdevice= 0x0022,
+ .driver_data = SAA7134_BOARD_TWINHAN_DTV_DVB_3056,
},{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
@@ -5308,7 +5344,8 @@ int saa7134_board_init2(struct saa7134_d
case SAA7134_BOARD_ASUSTeK_P7131_DUAL:
case SAA7134_BOARD_ASUSTeK_P7131_HYBRID_LNA:
case SAA7134_BOARD_MEDION_MD8800_QUADRO:
- case SAA7134_BOARD_AVERMEDIA_SUPER_007:
+ case SAA7134_BOARD_AVERMEDIA_SUPER_007:
+ case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
/* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
*/
diff -r 2ae5c2995730 linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Sun Jan 13 13:02:20
2008 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Sun Jan 13 21:38:58
2008 +0100
@@ -779,6 +779,21 @@ static struct tda1004x_config avermedia_
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config twinhan_dtv_dvb_3056_config = {
+ .demod_address = 0x08,
+ .invert= 1,
+ .invert_oclk = 0,
+ .xtal_freq = TDA10046_XTAL_16M,
+ .agc_config= TDA10046_AGC_TDA827X,
+ .gpio_config = TDA10046_GP01_I,
+ .if_freq = TDA10046_FREQ_045,
+ .i2c_gate = 0x42,
+ .tuner_address = 0x61,
+ .tuner_config = 2,
+ .antenna_switch = 1,
+ .request_firmware = philips_tda1004x_request_firmware
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
Hi, Am Donnerstag, den 10.01.2008, 13:47 + schrieb John Pilkington: hermann pitton wrote: Am Donnerstag, den 10.01.2008, 01:13 +0200 schrieb Axel Thimm: Hi, On Wed, Jan 09, 2008 at 11:42:19PM +0100, hermann pitton wrote: video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) Guess this is the root of the problem. Axel's modules might fail to eliminate it. Mauro has converted the old single videobuf.ko to different types to be more flexible. Looks like you have an upgrade to the new types without that the old videobuf.ko is removed from your /lib/modules.../media stuff. Try to remove/delete it manually and depmod -a. is there a way to somehow blacklist videobuf.ko w/o having to remove it? The reason is that packagewise this belongs to the kernel rpm which is managed by the upstream vendor (e.g. Red Hat, Fedora) and I wouldn't want to nuke it - it would return anyway with the next kernel update. Instead maybe some dummy alias or some remapping could be made to effectively remove it from module-utils' radar w/o actually removing the file? That would be much cleaner from a packaging POV. Thanks! Hi Axel, here it is de facto gone, if not anymore in the next kernel release. What you do in between is up to you. If you like to stay in sync as close as possible, of course v4l-dvb counts and not the delayed kernel stuff. Greetings, Hermann I'm not sure what ideas people have about this after a spate of messages yesterday. The dmesg extracts that I posted were from a forced reboot after an improper shutdown and might not be 'typical', so I just risked a normal reboot from cold. This did not hang and has delivered a system that seems to be working properly, but during the udev phase and twice afterwards it reported on-screen that the video-buf.ko module was malformed. This is not recorded in dmesg. I then did an auto shutdown/reboot sequence, again without hanging but with the same malformed-module message. dmesg does still include repeated complaints about the duplicate symbol, as above, but there is no module videobuf.ko in the relevant directory. $ cd /lib/modules/2.6.18-53.1.4.el5/updates/drivers/media/video/ $ ls -l videobuf*.ko -rw-r--r-- 1 root root 23232 Dec 27 11:21 videobuf-core.ko -rw-r--r-- 1 root root 18120 Dec 27 11:21 videobuf-dma-sg.ko -rw-r--r-- 1 root root 11616 Dec 27 11:21 videobuf-dvb.ko -rw-r--r-- 1 root root 11616 Dec 27 11:21 videobuf-vmalloc.ko and the 'malformed' module is not there $ ls -l video-buf*.ko ls: video-buf*.ko: No such file or directory the old 2.6.18 video-buf.ko is not in Axel's /updates, but in the original .../drivers/media/video. Hope this helps. Else we clean everything ... (modprobe -v and less modules.symbols |grep video-buf) The two dvb cards are saa7133[0]: subsystem: 1461:f01d, board: Avermedia Super 007 [card=117,autodetected] Thanks to all for your interest. I hope this helps. John Pilkington Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] MSI TV Anywhere A/D V1.1 Almost Works :(
Am Sonntag, den 13.01.2008, 09:11 +1100 schrieb Robin Rainton: Robin Rainton wrote: Think I'm almost there but just can't seem to get this card to work with Linux. Hardware: no-name PCI box Tuner: MSI [EMAIL PROTECTED] A/D (MSI TV Anywhere A/D) v1.1 (I think the v1.1 is crucial!). Looking at the card it has the SAA7131 (?? hard to make out) and TDA10046A chips. kernel: latest (2.6.23.13) with all relevant modules (I think!) built which seem to load. Further to this I have managed to find version 29 of the firmware which still seems not to make a difference. Also enabled debug on the tda1004x module and tried tuning, below is the output. Really hoping someone can make sense of this 'cos I sure can't ;) DVB: registering new adapter (saa7133[0]) DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: tda10046_init tda1004x: tda10046_fwupload: 16MHz Xtal, reducing I2C speed tda1004x: tda1004x_write_byteI: reg=0x7, data=0x80 tda1004x: tda1004x_write_byteI: success reg=0x7, data=0x80, ret=1 tda1004x: tda1004x_write_mask: reg=0x3b, mask=0x1, data=0x0 tda1004x: tda1004x_read_byte: reg=0x3b tda1004x: tda1004x_read_byte: success reg=0x3b, data=0xff, ret=2 tda1004x: tda1004x_write_byteI: reg=0x3b, data=0xfe tda1004x: tda1004x_write_byteI: success reg=0x3b, data=0xfe, ret=1 tda1004x: tda1004x_write_byteI: reg=0x3c, data=0x33 tda1004x: tda1004x_write_byteI: success reg=0x3c, data=0x33, ret=1 tda1004x: tda1004x_write_mask: reg=0x3d, mask=0xf, data=0x0 tda1004x: tda1004x_read_byte: reg=0x3d tda1004x: tda1004x_read_byte: success reg=0x3d, data=0x6a, ret=2 tda1004x: tda1004x_write_byteI: reg=0x3d, data=0x60 tda1004x: tda1004x_write_byteI: success reg=0x3d, data=0x60, ret=1 tda1004x: tda1004x_write_byteI: reg=0x2d, data=0xf0 tda1004x: tda1004x_write_byteI: success reg=0x2d, data=0xf0, ret=1 tda1004x: setting up plls for 48MHz sampling clock tda1004x: tda1004x_write_byteI: reg=0x2f, data=0x3 tda1004x: tda1004x_write_byteI: success reg=0x2f, data=0x3, ret=1 tda1004x: tda10046_init_plls: setting up PLLs for a 16 MHz Xtal tda1004x: tda1004x_write_byteI: reg=0x30, data=0x3 tda1004x: tda1004x_write_byteI: success reg=0x30, data=0x3, ret=1 tda1004x: tda1004x_write_byteI: reg=0x3e, data=0x72 tda1004x: tda1004x_write_byteI: success reg=0x3e, data=0x72, ret=1 tda1004x: tda1004x_write_byteI: reg=0x4d, data=0xc tda1004x: tda1004x_write_byteI: success reg=0x4d, data=0xc, ret=1 tda1004x: tda1004x_write_byteI: reg=0x4e, data=0x0 tda1004x: tda1004x_write_byteI: success reg=0x4e, data=0x0, ret=1 tda1004x: tda1004x_write_buf: reg=0x31, len=0x5 tda1004x: tda1004x_write_byteI: reg=0x31, data=0x54 tda1004x: tda1004x_write_byteI: success reg=0x31, data=0x54, ret=1 tda1004x: tda1004x_write_byteI: reg=0x32, data=0x3 tda1004x: tda1004x_write_byteI: success reg=0x32, data=0x3, ret=1 tda1004x: tda1004x_write_byteI: reg=0x33, data=0xc tda1004x: tda1004x_write_byteI: success reg=0x33, data=0xc, ret=1 tda1004x: tda1004x_write_byteI: reg=0x34, data=0x30 tda1004x: tda1004x_write_byteI: success reg=0x34, data=0x30, ret=1 tda1004x: tda1004x_write_byteI: reg=0x35, data=0xc3 tda1004x: tda1004x_write_byteI: success reg=0x35, data=0xc3, ret=1 tda1004x: tda1004x_write_byteI: reg=0x4d, data=0xd tda1004x: tda1004x_write_byteI: success reg=0x4d, data=0xd, ret=1 tda1004x: tda1004x_write_byteI: reg=0x4e, data=0x55 tda1004x: tda1004x_write_byteI: success reg=0x4e, data=0x55, ret=1 tda1004x: tda1004x_write_mask: reg=0x37, mask=0xc0, data=0x0 tda1004x: tda1004x_read_byte: reg=0x37 tda1004x: tda1004x_read_byte: success reg=0x37, data=0xf8, ret=2 tda1004x: tda1004x_write_byteI: reg=0x37, data=0x38 tda1004x: tda1004x_write_byteI: success reg=0x37, data=0x38, ret=1 tda1004x: tda1004x_read_byte: reg=0x6 tda1004x: tda1004x_read_byte: success reg=0x6, data=0xb0, ret=2 tda1004x: tda1004x_write_mask: reg=0x7, mask=0x10, data=0x0 tda1004x: tda1004x_read_byte: reg=0x7 tda1004x: tda1004x_read_byte: success reg=0x7, data=0x80, ret=2 tda1004x: tda1004x_write_byteI: reg=0x7, data=0x80 tda1004x: tda1004x_write_byteI: success reg=0x7, data=0x80, ret=1 tda1004x: tda1004x_write_byteI: reg=0x11, data=0x67 tda1004x: tda1004x_write_byteI: success reg=0x11, data=0x67, ret=1 tda1004x: tda1004x_read_byte: reg=0x13 tda1004x: tda1004x_read_byte: success reg=0x13, data=0x67, ret=2 tda1004x: tda1004x_read_byte: reg=0x14 tda1004x: tda1004x_read_byte: success reg=0x14, data=0x29, ret=2 tda1004x: found firmware revision 29 -- ok tda1004x: tda1004x_write_mask: reg=0x7, mask=0x20, data=0x0 tda1004x: tda1004x_read_byte: reg=0x7 tda1004x: tda1004x_read_byte: success reg=0x7, data=0x80, ret=2 tda1004x: tda1004x_write_byteI: reg=0x7, data=0x80 tda1004x: tda1004x_write_byteI: success reg=0x7, data=0x80, ret=1 tda1004x: tda1004x_write_byteI: reg=0x1, data=0x87 tda1004x: tda1004x_write_byteI: success reg=0x1, data=0x87, ret=1 tda1004x: tda1004x_write_byteI: reg=0x16, data=0x88
Re: [linux-dvb] MSI TV Anywhere A/D V1.1 Almost Works :(
Am Sonntag, den 13.01.2008, 10:37 +1100 schrieb Robin Rainton:
hermann pitton wrote:
Maybe somebody from Sydney can help, don't know it offhand, but try to add
a positive offset of 167000Hz to the initial scan file.
I know the frequencies in this file work, as for the other card I have
they are fine. Or are you saying that the hardware won't be mapping
frequencies it's given properly and therefore needs that offset adding?
Yes, hardware capabilities are different.
That's why I said give it at least a try.
Do so,
Hermann
Actually - I notice in the code that .info reads:
.info = {
.name = Philips TDA10046H DVB-T,
.type = FE_OFDM,
.frequency_min = 5100,
.frequency_max = 85800,
.frequency_stepsize = 17,
.caps =
FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO
},
But as previously noted, the chip is a TDA10046A and on the box the
specs say, TV Tuner: Digital TV: 45MHz to 863MHz
Do you think this could cause problems?
BTW, when I use the scan utility where my other card finds channels,
this one reports 'filter timeout', like this:
tune to:
57150:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE
WARNING: filter timeout pid 0x0011
WARNING: filter timeout pid 0x
WARNING: filter timeout pid 0x0010
Which beats a plain, 'tuning failed!!!' I guess... are these clues helping?
Rob
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
Am Samstag, den 05.01.2008, 09:17 + schrieb John Pilkington: Hi: I'm running MythTV 0.21 under CentOS 5, all updated from ATrpms etc. The DVB-T card is 'AVerTV DVB-T Super 007', which worked out-of-the-box after I had used the get_dvb_fimware script packaged in kernel-docs. Manual extraction, as mentioned in the wiki, didn't give a usable file. I have a second identical card which I would like to add, but with it in place booting stops with a blank screen soon after the udev stage. That reports a malformed kmdl, but with one card this is presumably corrected after the firmware load. I don't see any jumpers on the card. I also have a Medion 7134 card in place; I intend to use its SVHS input but at present it isn't much used. I mention it because all the devices include an saa7134. My apologies if this is a well-known effect, but I don't recollect seeing it mentioned and would like to get it fixed. Thanks in advance. John Pilkington Hi John, still no solution? Put in /etc/modprobe.conf options saa7134 card=118,118 tuner=54,54 gbuffers=32 latency=64 Do a depmod -a Power down, remove all power and the md7134, especially if not in the original blue PCI slot. Are you able to come up now? If so, modprobe -vr saa7134-dvb tuner tda827x and modprobe -v saa7134 several times. Have a look in dmesg if the eeprom readout is always the same. There seems to be a potential issue, if multiple cards with eeprom detection are in the same machine, the readout is sometimes corrupted. This must not be related to your issue, but please test. Anyway, the card is unnecessarily in the Philips' reference boards eeprom detection if auto detected. I'll provide a patch to remove it from there. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
Am Mittwoch, den 09.01.2008, 23:45 + schrieb John Pilkington: hermann pitton wrote: video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) Guess this is the root of the problem. Axel's modules might fail to eliminate it. Mauro has converted the old single videobuf.ko to different types to be more flexible. Looks like you have an upgrade to the new types without that the old videobuf.ko is removed from your /lib/modules.../media stuff. Try to remove/delete it manually and depmod -a. I come back to you, if I should find more to test. Greetings and Thanks, Hermann $ ls -l videobuf*.ko -rw-r--r-- 1 root root 23232 Dec 27 11:21 videobuf-core.ko -rw-r--r-- 1 root root 18120 Dec 27 11:21 videobuf-dma-sg.ko -rw-r--r-- 1 root root 11616 Dec 27 11:21 videobuf-dvb.ko -rw-r--r-- 1 root root 11616 Dec 27 11:21 videobuf-vmalloc.ko Should I look for something else? Thanks again, John P Seems to be complete now. Don't know how you managed it ;) Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
Am Donnerstag, den 10.01.2008, 01:13 +0200 schrieb Axel Thimm: Hi, On Wed, Jan 09, 2008 at 11:42:19PM +0100, hermann pitton wrote: video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) Guess this is the root of the problem. Axel's modules might fail to eliminate it. Mauro has converted the old single videobuf.ko to different types to be more flexible. Looks like you have an upgrade to the new types without that the old videobuf.ko is removed from your /lib/modules.../media stuff. Try to remove/delete it manually and depmod -a. is there a way to somehow blacklist videobuf.ko w/o having to remove it? The reason is that packagewise this belongs to the kernel rpm which is managed by the upstream vendor (e.g. Red Hat, Fedora) and I wouldn't want to nuke it - it would return anyway with the next kernel update. Instead maybe some dummy alias or some remapping could be made to effectively remove it from module-utils' radar w/o actually removing the file? That would be much cleaner from a packaging POV. Thanks! Hi Axel, here it is de facto gone, if not anymore in the next kernel release. What you do in between is up to you. If you like to stay in sync as close as possible, of course v4l-dvb counts and not the delayed kernel stuff. Greetings, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with concurrent recording of ANALOG and DVB-T on saa7134 Based card
Am Sonntag, den 06.01.2008, 16:18 +0100 schrieb Eddi De Pieri: Hi, I've a FlyDVB TRio, and I've found a problem with viewing or recording of Analog stream while recording a DVB-T stream on my Debian Etch system with driver included in packaged kernel. The issue is that analog stream is with poor quality and distorced colors. It seems that some data sent by dvb-t part of driver affect the analog one. Please can other owner of this card and/or other lifeview Hybrid cards to test recording? The test can be due using 2 session of mencoder. Regards Eddi Hi Eddi, since you don't mention it, it is very important to use packed formats and not the default planar format when doing analog at once with DVB-T! Otherwise you get memory or even file corruption. According to Hartmut it is due to a limitation of the dma engines. Other testers please take care. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Nova-S-Plus Locking Issues
Hi, Am Freitag, den 04.01.2008, 10:09 -0500 schrieb Dwaine Garden: Maybe this patch? http://linuxtv.org/hg/v4l-dvb/rev/38287d40ff25 out of interest, does it mean you have excluded already this one http://linuxtv.org/hg/v4l-dvb/rev/cf687ab6b0ab and you get 13V and 18V properly set on the older Geniatech, since the not yet reviewed error on SEC_VOLTAGE_OFF you still have? Cheers, Hermann CityK [EMAIL PROTECTED] wrote: Dark Dragon wrote: Is there any way to track what changes to the driver where made to make the card imoperative? (Sorry DD, you'll likely be getting a second copy of this message -- I meant to reply to the list (via reply all, but accidently just sent the original reply to you (via reply) ... also I changed the url slightly, from a specific revision to the general tip ). Yes -- find the relevant files in http://linuxtv.org/hg/v4l-dvb/file/tip/ and then review the revision changes of the files ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Digiwave 108G/GeniaTech TVStar Card - Adding it to the CX88 Driver
: cx24123_read_snr: read S/N index = 0 Jan 3 06:21:29 mythtv kernel: cx24123_read_signal_strength: Signal strength = 1280 Jan 3 06:21:29 mythtv kernel: cx24123_read_snr: read S/N index = 0 Jan 3 06:21:30 mythtv kernel: cx24123_read_signal_strength: Signal strength = 1280 Jan 3 06:21:30 mythtv kernel: cx24123_read_snr: read S/N index = 0 Jan 3 06:21:31 mythtv kernel: cx24123_read_signal_strength: Signal strength = 1024 Jan 3 06:21:31 mythtv kernel: cx24123_read_snr: read S/N index = 0 Jan 3 06:21:32 mythtv kernel: cx24123_read_signal_strength: Signal strength = 1024 Jan 3 06:21:32 mythtv kernel: cx24123_read_snr: read S/N index = 0 Jan 3 06:21:33 mythtv kernel: cx24123_read_signal_strength: Signal strength = 1024 Jan 3 06:21:33 mythtv kernel: cx24123_read_snr: read S/N index = 0 hermann pitton [EMAIL PROTECTED] wrote: Am Mittwoch, den 02.01.2008, 23:21 -0500 schrieb Dwaine Garden: Looking at the chip which is right beside the Analog TV input. It says TBA2028E3. Is that the Xceive 2028 tuner chip? Dwaine 2028 looks suspicious, but as far as I remember, they have been marked differently previously. I'll try to come back to it ASAP. There is so much out in the wilderness, others already seem to care for ;) Likely, we'll have already people knowing better ... Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Digiwave 108G/GeniaTech TVStar Card - Adding it to the CX88 Driver
Hi Dwaine,
Am Mittwoch, den 02.01.2008, 18:03 -0500 schrieb Dwaine Garden:
I have added the following code to cx88-cards.c and it seemed to activate the
card. I can now here the regulator for the LNB switch on. Also, I'm getting
both signal and SNR values that look better than before. I also get locks on
radio channels when scanning.
Is there a way to confirm the actual analog TV tuner for the device? I think
this is the code that is missing.
the FQ1216ME with tda9887 is the most doubtfully analog tuner in it's
current shape I know about. There are some old multi standard PAL/SECAM
tuners in a similar uncertain condition, but at least they don't claim
suddenly to be compatible with more recent MK3/4/5 tuners too.
For the two physically existing devices I imagine, none of them has a
tda9887. For the more recent FQ1216ME H-3 (MK3) it is a tda9886, means
no analog radio support on that analog TV tuner. It would need an extra
radio tuner chip for that then.
Those are all still huge tin/can tuners, but from the fuzzy picture I
saw, you definitely seem to have some sort of silicon behind the analog
antenna connectors.
Likely it is worth to have a closer look at these chips again.
For what is confused currently with FQ1216ME, you should be either far
away from it or you are close to shed some light on it, how it could
come into this stage.
Interesting enough, that you seem to get no errors on analog tuning
attempts.
Cheers,
Hermann
[CX88_BOARD_DIGIWAVE_108G] = {
.name = Digiwave 108G,
.tuner_type = TUNER_PHILIPS_FQ1216ME,
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT,
.input = {{
.type = CX88_VMUX_TELEVISION,
.vmux = 0,
.gpio0 = 0x00ff,
.gpio1 = 0xf39d,
}},
.radio = {
.type = CX88_RADIO,
.gpio0 = 0x00ff,
.gpio1 = 0xf39d,
},
.dvb= 1,
}
},{
.subvendor = 0x14f1,
.subdevice = 0x2319,
.card = CX88_BOARD_DIGIWAVE_108G,
},
void cx88_card_setup(struct cx88_core *core)
{
static u8 eeprom[256];
if (0 == core-i2c_rc) {
core-i2c_client.addr = 0xa0 1;
tveeprom_read(core-i2c_client,eeprom,sizeof(eeprom));
}
switch (core-board) {
case CX88_BOARD_DIGIWAVE_108G:
cx_write(MO_GP0_IO, 0x00ff);
cx_write(MO_GP1_IO, 0xf39d);
break;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Digiwave 108G/GeniaTech TVStar Card - Adding it to the CX88 Driver
Am Mittwoch, den 02.01.2008, 23:21 -0500 schrieb Dwaine Garden: Looking at the chip which is right beside the Analog TV input. It says TBA2028E3. Is that the Xceive 2028 tuner chip? Dwaine 2028 looks suspicious, but as far as I remember, they have been marked differently previously. I'll try to come back to it ASAP. There is so much out in the wilderness, others already seem to care for ;) Likely, we'll have already people knowing better ... Hermann hermann pitton [EMAIL PROTECTED] wrote: Hi Dwaine, Am Mittwoch, den 02.01.2008, 18:03 -0500 schrieb Dwaine Garden: I have added the following code to cx88-cards.c and it seemed to activate the card. I can now here the regulator for the LNB switch on. Also, I'm getting both signal and SNR values that look better than before. I also get locks on radio channels when scanning. Is there a way to confirm the actual analog TV tuner for the device? I think this is the code that is missing. the FQ1216ME with tda9887 is the most doubtfully analog tuner in it's current shape I know about. There are some old multi standard PAL/SECAM tuners in a similar uncertain condition, but at least they don't claim suddenly to be compatible with more recent MK3/4/5 tuners too. For the two physically existing devices I imagine, none of them has a tda9887. For the more recent FQ1216ME H-3 (MK3) it is a tda9886, means no analog radio support on that analog TV tuner. It would need an extra radio tuner chip for that then. Those are all still huge tin/can tuners, but from the fuzzy picture I saw, you definitely seem to have some sort of silicon behind the analog antenna connectors. Likely it is worth to have a closer look at these chips again. For what is confused currently with FQ1216ME, you should be either far away from it or you are close to shed some light on it, how it could come into this stage. Interesting enough, that you seem to get no errors on analog tuning attempts. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AverTV Hybrid Volar HX
Am Dienstag, den 01.01.2008, 20:33 +0400 schrieb Manu Abraham: Zdenek Kabelac wrote: 2008/1/1, Manu Abraham [EMAIL PROTECTED]: Zdenek Kabelac wrote: Hi Manu There is a OSS driver upcoming, supported by the chip manufacturer themselves (AFA Technologies.) I have been a bit involved in that process. Yep - looks nice - and do you have any idea about the release date? I don't have a date, but the chip manufacturer as well as everybody involved is under pressure, due to the large usage of the chip by different peripheral manufacturers. It has to come out soon, looking at the list of supported device configurations by now, nothing less than 33 configurations documented list as i have now, just PC based configurations alone, CE equipments excluded. The current state is that there are some tests going on in the AFA labs on the driver for the chip (currently, 2nd round) due to all the Hardware hacks on the chip to handle Maybe I could help with testing and reporting bugs ? As I can see it would be probably useless to try hacking any code for this device myself. The current state of testing is that, one needs to understand the chip internals and the testing happens in the Labs alone (lot of undocumented things in there, documentation being really crap), with some basic tests we have going on. As soon as it get's past this stage, there is something for users to test. I have redone the driver a few times by now, trying to handle the different aspects. There have been some discussions on this ML also, on the same a while back. Regards, Manu Manu, where do you have your mission from? As far as I can see, _excactly Nobody_ asked you to do it. If you have a GO for this by Linus and Andrew, and that I seriuously doubt, I stay away for ever ... Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Hi, can someone of you test the S-Video input? That is what is still untested. Am Sonntag, den 23.12.2007, 13:20 +0100 schrieb sioux: Hi Terry, Fedora 8... dependency list I don't know, I use UBUNTU... it loads by default all the saa7134 modules Listen FM while DVB-T is running, yes that's right! No. One single hybrid tuner at 0x60 behind the very same i2c bridge for analog and digital. Merry Christmas and happy new year to you and all members on this lists. Sioux. Yes! Cheers, Hermann _ Terry Barnaby ha scritto: Hi Sioux, Thanks for the info, I now have FM radio. I had to load the saa7134_alsa module as well to get the ALSA device, my Fedora 8 system had not loaded it by default. I this a minor bug in the module dependency lists ? I presume it is not possible to listen to stream FM radio while streaming DVB TV with this card ? Cheers Terry sioux wrote: Hi, I am happy to see my patch is ok. For audio stream you have to use sox... here is an example: sox -r 32000 -w -t alsa hw:1,0 -t alsa hw:0,0 Ciao Sioux. __ Terry Barnaby ha scritto: Hi, I have tried the sioux.patch on my AzureWave AD-TP500 3056 PCI board. With the dvb-fe-tda10045.fw and dvb-fe-tda10046.fw firmware files installed in /lib/firmware for Fedora 8. It seems to work fine in DVB mode. I now want to try the FM Tuner but am at a loss on how to capture a stream from this. Eventually I want to stream the FM audio across the network. Any info on: 1. How can I stream the FM Tuners output using VLC or something else ? 2. I can see how to tune set the FM Tuners frequency, but how can I get a raw data stream from the card using the V4L/DVB API ? Some initial pointers would be appreciated. Cheers Terry ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Conceptronic CTVCOMBOi
Hi Miguel Angel, Am Donnerstag, den 20.12.2007, 16:32 +0100 schrieb Miguel Ángel Fernández: I'm sorry, I had sent this message directly to Hermann's e-mail instead of to the list. I forward it again, I ask for excuses for this mistake. sorry too, I have a cold currently and did not even notice it. From: hermann Date: Tue, 18 Dec 2007 02:10:29 +0100 Holla, Hello! do you have to do anything actively? No I don't. It's automatically detected. Fine! It is a dual tuner device and what about the remote so far? It has a digital tuner and an analogue tuner. You can watch 1 dvb-t channel + 1 analogue channel at the same time. But it is not posible to see 2 dvb-t channels at the same time or 2 analogue channels. Sorry, about the remote I can't tell you anything because I don't know how to configure it. It should have a KS700 i2c remote controller then. There is a patch around from Dwaine Garden for the Kworld ATSC110 based on a patch by Henry Wong for the MSI [EMAIL PROTECTED] with KS300. Please send us dmesg for the saa713x and tuner stuff. [ 24.468000] saa7130/34: v4l2 driver version 0.2.14 loaded [ 24.468000] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [ 24.468000] ACPI: PCI Interrupt :00:0d.0[A] - Link [LNKC] - GSI 11 (level, low) - IRQ 11 [ 24.468000] saa7133[0]: found at :00:0d.0, rev: 209, irq: 11, latency: 32, mmio: 0xde001000 [ 24.468000] saa7133[0]: subsystem: 17de:7201, board: Tevion/KWorld DVB-T 220RF [card=88,autodetected] [ 24.468000] saa7133[0]: board init: gpio is 100 [ 24.604000] saa7133[0]: i2c eeprom 00: de 17 01 72 ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 24.604000] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.212000] tuner 1-004b: chip found @ 0x96 (saa7133[0]) [ 25.26] tuner 1-004b: setting tuner address to 61 [ 25.308000] tuner 1-004b: type set to tda8290+75a [ 25.592000] parport_pc 00:0a: reported by Plug and Play ACPI [ 25.592000] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] [ 25.804000] pnp: Device 01:01.02 activated. [ 25.824000] gameport: NS558 PnP Gameport is pnp01:01.02/gameport0, io 0x200, speed 438kHz [ 27.092000] tuner 1-004b: setting tuner address to 61 [ 27.132000] tuner 1-004b: type set to tda8290+75a [ 28.452000] saa7133[0]: registered device video0 [v4l2] [ 28.456000] saa7133[0]: registered device vbi0 [ 28.456000] saa7133[0]: registered device radio0 [ 28.544000] ACPI: PCI Interrupt :00:0f.0[A] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 [ 28.744000] saa7134 ALSA driver for DMA sound loaded [ 28.744000] saa7133[0]/alsa: saa7133[0] at 0xde001000 irq 11 registered as card -2 [ 28.812000] DVB: registering new adapter (saa7133[0]). [ 28.812000] DVB: registering frontend 0 (Philips TDA10046H DVB-T)... [ 28.92] tda1004x: setting up plls for 48MHz sampling clock [ 29.204000] tda1004x: found firmware revision 29 -- ok [ 30.968000] lp0: using parport0 (interrupt-driven). [ 31.068000] Adding 939792k swap on /dev/hda3. Priority:-1 extents:1 across:939792k [ 31.708000] EXT3 FS on hda2, internal journal [ 33.06] NET: Registered protocol family 10 [ 33.06] lo: Disabled Privacy Extensions [ 43.608000] eth0: no IPv6 routers present [ 47.308000] No dock devices found. [ 47.556000] input: Power Button (FF) as /class/input/input4 [ 47.556000] ACPI: Power Button (FF) [PWRF] [ 47.604000] input: Power Button (CM) as /class/input/input5 [ 47.604000] ACPI: Power Button (CM) [PWRB] [ 47.628000] input: Sleep Button (CM) as /class/input/input6 [ 47.628000] ACPI: Sleep Button (CM) [SLPB] [ 61.244000] ppdev: user-space parallel port driver [ 71.412000] audit(1198074711.646:3): type=1503 operation=inode_permission requested_mask=a denied_mask=a name=/dev/tty pid=4753 profile=/usr/sbin/cupsd [ 88.308000] tda1004x: setting up plls for 48MHz sampling clock [ 88.592000] tda1004x: found firmware revision 29 -- ok Seems all fine, will have a closer look after Christmas. Thanks for your report! It is the minimal thing that I can do for the community Thanks again, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] VHF tuning broken for TDA8275A cards?
Hi Nico, Am Donnerstag, den 20.12.2007, 12:01 +0100 schrieb Nico Sabbi: Hi, in recent kernels (up to 2.6.23xxx) my Lifeview Trio can't tune anymore VHF channels, that used to work in previous kernels (after a patch by Hartmutt that IIRC was integrated in several months ago). I haven't tried an hg snapshot yet, but I'd like to know if other users have my problem. you asked the other way round, but at least I can confirm that my tda8275a cards and also such with the FMD1216ME and tda10046ht/a still tune the single VHF transponder we have here. I'm using about ten to four days old v4l-dvb mercurial master on some 2.6.23 and an old 2.6.20 currently. You likely noticed some reports, that on VHF some transmitters changed from FEC 3/4 to 2/3 recently. If not already done, it might be worth a try creating a new channels.conf. Let me know, if you like to see some mplayer or other logs. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Conceptronic CTVCOMBOi
Am Montag, den 17.12.2007, 15:19 +0100 schrieb Miguel Ángel Fernández: Hello! My name is Miguel Ángel, I'm from Oviedo (Spain) and this is my first message to the list. I've just bought a Conceptronic CTVCOMBOi DVB-T + Analog PCI card and it works fine. But it's unlisted in the DVB-T PCI wiki so I'm going to give you some information to add to the wiki. Web: http://www.conceptronic.net/site/desktopdefault.aspx?tabindex=0tabid=200Cat=20grp=2010ar=360Prod_ID=1365Prod=CTVCOMBOi Model:Conceptronic CTVCOMBOi Price: 61 € Supports: DVB-T, Analogue, Tuner/Chips: Philips SAA7131E, Philips TDA10046A Connectors: S-Video, composite, TV DVB-T antenna in, TV analogue antenna in, FM antenna in, Remonte in Notes:Supports HDTV. Works with Ubuntu 7.10: Kaffeine and MythTV. Package contents: Audio/Video Cable, remote control, infrared receiver, DVB-T antenna, FM Antenna I hope the information can be useful for you. If I find more information I'll send it to the list. Bye! Holla, do you have to do anything actively? It is a dual tuner device and what about the remote so far? Please send us dmesg for the saa713x and tuner stuff. Thanks for your report! Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Am Montag, den 17.12.2007, 00:34 +0100 schrieb sioux: Hi herman, sorry but I did not understand what you said. My goal is, please, add to next v4l-dvb releases this board in order to avoid me to manually set it up. Hi Sioux, there is nothing left than to confirm the s-video vmux. If you don't have a device to test it, doesn't matter much, since it is almost untested/unconfirmed on many other cards. It will still be right with a probability of around 97 ;) %. We should regenerate the patch, taking into account some minor recent changes, to manifest what we have so far and give a hint for the untested s-video stuff. That should be all. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Hi Sioux,
Am Mittwoch, den 12.12.2007, 22:16 +0100 schrieb sioux:
Hi Hermann,
I have been a little busy... but I did the test as you said.
Before to procede with the test and install the patch I have cleared
my sys as follow:
1. Cleared all previous files under /src/usr/v4l-dvb following:
sudo make clean
sudo make distclean
2. Cleared aliases with sudo gedit /etc/modprobe.d/aliases to the
origin as:
alias char-major-81 * videodev
alias char-major-81-* saa7134
3. Cleared the modprobe option with sudo gedit /etc/modprobe.d/options
to the origin as:
# Enable double-buffering so gstreamer et. al. work
options quickcam compatible=2
# Default hostap to managed mode
options hostap_pci iw_mode=2
options hostap_cs iw_mode=2
4. Cleared the previous saa7134 script under /etc/modprobe.d with sudo
rm saa*
5. Cleared all the dir V4l-dvb and v4l-app under /usr/src
6. Rebooted the sys...
and this is the virgin dmesg of my Twinhan:
[EMAIL PROTECTED]:~$ dmesg | grep saa
[ 37.551793] saa7130/34: v4l2 driver version 0.2.14 loaded
[ 37.553908] saa7133[0]: found at :02:09.0, rev: 209, irq: 18,
latency: 32, mmio: 0xed00
[ 37.553917] saa7133[0]: subsystem: 1822:0022, board:
UNKNOWN/GENERIC [card=0,autodetected]
[ 37.553934] saa7133[0]: board init: gpio is 4
[ 37.751425] saa7133[0]: i2c eeprom 00: 22 18 22 00 54 20 1c 00 43
43 a9 1c 55 d2 b2 92
[ 37.751443] saa7133[0]: i2c eeprom 10: 00 01 fb 00 ff 20 ff ff ff
ff ff ff ff ff ff ff
[ 37.751458] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08
ff 00 10 ff ff ff ff
[ 37.751472] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751486] saa7133[0]: i2c eeprom 40: ff 21 00 c2 84 10 03 32 15
50 ff ff ff ff ff ff
[ 37.751501] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751515] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751530] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751544] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751558] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751573] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751587] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751602] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751616] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.751645] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[ 37.753643] saa7133[0]: registered device video0 [v4l2]
[ 37.753880] saa7133[0]: registered device vbi0
[ 38.044982] saa7134 ALSA driver for DMA sound loaded
[ 38.045031] saa7133[0]/alsa: saa7133[0] at 0xed00 irq 18
registered as card -2
[EMAIL PROTECTED]:~$
Fine,
soon after I tested the Hermann-Sioux collaboration patch as follow:
1. Reinstalled virgin v4l-dvb and dvb-app with HG clone
2. copied the patch in /usr/src/v4l-dvb and renamed it as sioux.patch
3. launched the command: sudo patch --dry-run -p1 sioux.patch (see
below the rsults)
[EMAIL PROTECTED]:/usr/src/v4l-dvb$ sudo patch --dry-run -p1
sioux.patch
patching file linux/drivers/media/video/saa7134/saa7134-cards.c
Hunk #1 succeeded at 3601 (offset 1 line).
Hunk #2 succeeded at 4400 (offset 1 line).
Hunk #3 succeeded at 4820 (offset 2 lines).
patching file linux/drivers/media/video/saa7134/saa7134-dvb.c
Hunk #1 succeeded at 779 (offset 1 line).
Hunk #2 succeeded at 1059 (offset 1 line).
patching file linux/drivers/media/video/saa7134/saa7134.h
[EMAIL PROTECTED]:/usr/src/v4l-dvb$
Ok, I diden't see errors... than I made this command: sudo patch -p1
sioux.patch (see below the rsults)
[EMAIL PROTECTED]:/usr/src/v4l-dvb$ sudo patch -p1 sioux.patch
patching file linux/drivers/media/video/saa7134/saa7134-cards.c
Hunk #1 succeeded at 3601 (offset 1 line).
Hunk #2 succeeded at 4400 (offset 1 line).
Hunk #3 succeeded at 4820 (offset 2 lines).
patching file linux/drivers/media/video/saa7134/saa7134-dvb.c
Hunk #1 succeeded at 779 (offset 1 line).
Hunk #2 succeeded at 1059 (offset 1 line).
patching file linux/drivers/media/video/saa7134/saa7134.h
[EMAIL PROTECTED]:/usr/src/v4l-dvb$
I made some check in saa7134.h, saa7134-cards.c, saa7134-dvb.c with
gedit and searching for 3056... and this is what I sow:
saa7134.h
starting row 250
#define SAA7134_BOARD_TWINHAN_DTV_DVB_3056 118
_
saa7134-cards.c
starting row 3604
[SAA7134_BOARD_TWINHAN_DTV_DVB_3056] = {
.name = Twinhan Hybrid DTV-DVB 3056 PCI,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_PHILIPS_TDA8290,
Re: [linux-dvb] updated DVB-T tuning data file for de-Frankfurt
Hi Christoph, Am Montag, den 10.12.2007, 12:57 +0100 schrieb Christoph Mockenhaupt: Hi Hermann, Am Freitag Dezember 7 2007 00:53:39 schrieben Sie: What hardware and demod are you using, that it makes such a difference? I'm using a Terratec Cinergy DT XS Diversity USB with the latest driver from v4l-linux-hg (modul dvb-usb-dib0700) and kernel 2.6.22. Right now I'm using firmware dvb-usb-dib0700-01.fw (the driver requests v1.10) because the new version is unstable on my system. So far I didn't had time to investigate further on this matter. I'm afraid I don't know what you mean by demod. But I have not set anything special, so I assume that it is set to standard :) from a mail by me back in November 2005 when the tda8275a tuner started working with the tda10046a demodulator/channel decoder. Simplest is in dvb-apps/util/scan changed accordingly to your provider. ./dvbscan -n -o zap -p dvb-t/de-Frankfurt channels.conf It produces this channels.conf for me. Das Erste:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:101:102:1 arte:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:201:202:2 PHOENIX:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:301:302:3 ARD-MHP-Data:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:16 This did work for me that time. scan from dvb-apps-1.1.1 until the recent mercurial dvb-apps produces valid channels, even with the wrong FEC in the initial tuning file. (in dvb-apps-1.1.1 de-Frankfurt is not there yet, too old) ./scan dvb-t/de-Frankfurt-orig scanning dvb-t/de-Frankfurt-orig using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 19850 1 3 9 1 1 3 0 initial transponder 48200 0 2 9 1 1 3 0 initial transponder 57800 0 2 9 1 1 3 0 initial transponder 73800 0 2 9 1 1 3 0 initial transponder 76200 0 2 9 1 1 3 0 initial transponder 81800 0 2 9 1 1 3 0 tune to: 19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE 0x 0x0003: pmt_pid 0x012c ARD -- PHOENIX (running) 0x 0x0021: pmt_pid 0x01f4 ARD -- Bayerisches FS (running) 0x 0x00e2: pmt_pid 0x0258 ARD -- SWR Fernsehen RP (running) Network Name 'HR-RM' tune to: 48200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMIS PHOENIX:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:301:302:3 Bayerisches FS:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:501:502:33 SWR Fernsehen RP:19850:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:601:602:226 Guess I missed that change, since I had most set to AUTO in my channels.conf files and scan produced valid channels even with the now wrong FEC in the initial tuning file on the previously also changed 7MHz VHF transponder ... All your fixes are fine. Thanks, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Hi Sioux! Am Samstag, den 08.12.2007, 22:16 +0100 schrieb sioux: All :-) Sioux is back :-) I see my email has generate a big work... Thanks guys Not much work to set up some lines and you had all ready so far. It takes more time to look up the latest known status on the lists. In this case, we had to start also to look for coding style issues running seven years old code against a script and I was not sure if I have to fix all what comes up over all places, when submitting some new lines ... (then I ask also, who took it previously?) I am happy... even if I hope none of you will get money for that becouse otherwise I want some cents for me too. :-) and also I hope no RIAA or SIAE or any yellow finace police in futures days will ring to my door for have done only few stupid testing and report on this mail list :-) No money and totally legal. So, Hermann give me instruction what I have to do for test the patch you sent me like: It's your patch suggestion with the fix for the auto detection you asked for and taking Egidio's previous test report into account. 1. what I have to type on my keyboard to test the file you sent (how I install that)? If you have a recent v4l-dvb snapshot from the master repository at linuxtv.org, put it into it and name it, say, sioux.patch. patch --dry-run -p1 sioux.patch If no error. patch -p1 sioux.patch make make rmmod make rmmod make install modprobe -v saa7134 Check if the auto detection does work and test all you can, analog TV, digital TV, radio and the other inputs. Report what you can't test and what goes wrong and maybe needs further fixes. 2. what you need for my signed-off? You have the link to read about it. No fake allowed. Just a line Signed-off-by: your_name your.e-mail.somewhere I told you I am not a developer... just a crazy sioux... Before start the test I must clean some alias. Ciao. P.S. I don't like give you my signed-off with my real name :-) if ok I can do it with my nick name.. that's ok for you? I don't make the rules, not even Linus, some gambling in the markets force us to take care to document our code. For just adding a new card it might be a bit too much currently ... See above and read. It is up to you. If you don't like it, you get at least credit as Sioux. Happy testing, that is the work now. Thanks, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] initial tuning file for Astra 23.5E
Am Freitag, den 07.12.2007, 21:41 +0100 schrieb hermann pitton: Hi, Am Freitag, den 07.12.2007, 08:22 +0100 schrieb Mike: Hi There, is ther eany initial tuning file available for scanning the Astra 1E on 23.5E ? here is stated that the 1E was replaced by the new 1L. http://de.wikipedia.org/wiki/Astra_%28Satellit%29 However, SES-Astra still provides freq. tables for it together with the 3A at 23,5°East. http://www.ses-astra.com/consumer/de/programs/program-lists/index.php You might try with something like that. # SES-GLOBAL, Astra-1E 23.5E # freq pol sr fec S 11635000 H 2850 AUTO S 11739000 V 2750 3/4 S 11817000 V 2750 AUTO S 11914000 H 2750 3/4 S 11992000 H 2750 3/4 S 12032000 H 2750 3/4 S 10758000 V 2200 7/8 S 10842000 V 1000 7/8 -- reading against Igor's link, is 3/4 here. S 10862000 H 2200 5/6 Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] initial tuning file for Astra 23.5E
Hi, Am Freitag, den 07.12.2007, 08:22 +0100 schrieb Mike: Hi There, is ther eany initial tuning file available for scanning the Astra 1E on 23.5E ? here is stated that the 1E was replaced by the new 1L. http://de.wikipedia.org/wiki/Astra_%28Satellit%29 However, SES-Astra still provides freq. tables for it together with the 3A at 23,5°East. http://www.ses-astra.com/consumer/de/programs/program-lists/index.php You might try with something like that. # SES-GLOBAL, Astra-1E 23.5E # freq pol sr fec S 11635000 H 2850 AUTO S 11739000 V 2750 3/4 S 11817000 V 2750 AUTO S 11914000 H 2750 3/4 S 11992000 H 2750 3/4 S 12032000 H 2750 3/4 S 10758000 V 2200 7/8 S 10842000 V 1000 7/8 S 10862000 H 2200 5/6 Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] updated DVB-T tuning data file for de-Frankfurt
Hi Christoph, Am Donnerstag, den 06.12.2007, 14:20 +0100 schrieb Christoph Mockenhaupt: Hi, I updated the de-Frankfurt tuning data file. Since 3.12.2007 ARD Multiplex 2 has been moved from channel 57 to channel 37. I confirm that this change has happened. I also corrected the entry for ARD Multiplex 1, which has never worked for me as the coderate_HP has to be set to 2/3 That's interesting, it always worked for me, but I had to increase the tuning delay on it for the tda10046a. see also: http://www.hr-online.de/website/static/derhr/dvb-t/_dvbt_rheinmain_2007.pdf Yes, they have FEC 2/3 for the single VHF one too. What hardware and demod are you using, that it makes such a difference? Always thought it is caused by that this one is first in the row to scan. On the tda1046a, with already increased timeouts, seems I get more fails as previously, but overall it seems not to make much a difference. Might have to come back to it. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Am Dienstag, den 04.12.2007, 01:23 +0100 schrieb hermann pitton:
Am Dienstag, den 04.12.2007, 00:23 +0100 schrieb hermann pitton:
[...]
Since it is more than six months back, that the card could have been
added, guess I'll try this next pointing at the state of affairs we have
here now.
Missing commas tend to spread ... ;)
diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Nov 30
18:27:26 2007 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Dec 04
00:06:19 2007 +0100
@@ -3600,6 +3600,36 @@ struct saa7134_board saa7134_boards[] =
.tv = 1,
Broken lines, not compatible editors and mail clients ...
I'm back to Mike Isely and will ignore all other stuff not officially
documented, ... until it works.
Hi,
OK, seems we have enough rules and documentation now.
Based on what I seem to know about the card and is prior in this thread
on the linux-dvb ML, the patch is correct. Some spaces, also between
braces, are introduced by checkpatch.pl. Please review.
Sioux, please test and check and Sign-off with me or take at least some
credit for your work on it.
Cheers,
Hermann
- saa7134: add Twinhan Hybrid DTV-DVB 3056 PCI
- Thanks go to Sioux for providing code and asking to fix the auto
detection.
- S-Video seems to be untested and likely a Composite over S-Video
input is also there. The remote is not yet investigated.
Signed-off-by: Hermann Pitton [EMAIL PROTECTED]
diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Nov 30 18:27:26
2007 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Dec 04 00:06:19
2007 +0100
@@ -3600,6 +3600,36 @@ struct saa7134_board saa7134_boards[] =
.tv = 1,
}},
},
+ [SAA7134_BOARD_TWINHAN_DTV_DVB_3056] = {
+ .name = Twinhan Hybrid DTV-DVB 3056 PCI,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 2,
+ .mpeg = SAA7134_MPEG_DVB,
+ .gpiomask = 0x020,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x020,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -4369,7 +4399,13 @@ struct pci_device_id saa7134_pci_tbl[] =
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x4e42,
.subdevice= 0x3502,
- .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS
+ .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1822, /*Twinhan Technology Co. Ltd*/
+ .subdevice= 0x0022,
+ .driver_data = SAA7134_BOARD_TWINHAN_DTV_DVB_3056,
},{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
@@ -4782,6 +4818,7 @@ int saa7134_board_init2(struct saa7134_d
case SAA7134_BOARD_ASUSTeK_P7131_DUAL:
case SAA7134_BOARD_ASUSTeK_P7131_HYBRID_LNA:
case SAA7134_BOARD_MEDION_MD8800_QUADRO:
+ case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
/* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
*/
diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Fri Nov 30 18:27:26
2007 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon Dec 03 19:05:39
2007 +0100
@@ -778,6 +778,21 @@ static struct tda1004x_config avermedia_
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config twinhan_dtv_dvb_3056_config = {
+ .demod_address = 0x08,
+ .invert= 1,
+ .invert_oclk = 0,
+ .xtal_freq = TDA10046_XTAL_16M,
+ .agc_config
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Hi Sioux,
Am Sonntag, den 02.12.2007, 01:08 +0100 schrieb sioux:
Hey guys... I am feed up to stay compile each time when a new kernel
upgrades cames up.
Please I need your help to complite my stupid work (my prefered distro
is a ubuntu... please at least for my distro can you redistribute this
driver?)
The works that needs to be complited is about PCI kernel automatic loads
of this video card and probably some other.
This is the card:
have a look at what we had back in May for the card.
http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017946.html
It is trashed with some top-postings, but finally Egidio reported
everything working by forcing the TIGER_S.
The remote is not yet investigated.
[EMAIL PROTECTED]:~$ sudo lspci -s 02:09.0 -vv -
02:09.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135
Video Broadcast Decoder (rev d1)
Subsystem: Twinhan Technology Co. Ltd Unknown device 0022
[...]
And here is my driver Signed off for this card that is: Twinhan Hybrid
DTV-DVB 3056 PCI [1822:0022]
well
In cardlist.saa7134 please add:
118 - Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
A script will do this automatically when make commit is called.
In saa7134.h please add:
#define SAA7134_BOARD_TWINHAN_DTV_DVB_3056 118
_
In saa7134.card.c add:
[SAA7134_BOARD_TWINHAN_DTV_DVB_3056] = {
/* sioux signed-off [EMAIL PROTECTED] :-) */
.name = Twinhan Hybrid DTV-DVB 3056 PCI,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_PHILIPS_TDA8290,
.radio_type = UNSET,
.tuner_addr= ADDR_UNSET,
.radio_addr= ADDR_UNSET,
.tuner_config = 2,
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x040,
.inputs = {{
.name = name_tv,
.vmux = 1,
.amux = TV,
.tv = 1,
},{
.name = name_comp1,
.vmux = 3,
.amux = LINE1,
},{
.name = name_svideo,
.vmux = 8,
.amux = LINE1,
}},
.radio = {
.name = name_radio,
.amux = TV,
},
},
Unless you teach me better, I'll keep this like the TIGER_S has it and
what Egidio tested.
...
case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
/* I don't know why I have to do this, but this cards was ok as
tiger_s. In case fix me */
/* No other different ways could I found. Signed OFF by sioux */
{
u8 data[] = { 0x3c, 0x33, 0x60};
struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len =
sizeof(data)};
if(dev-autodetected (dev-eedata[0x49] == 0x50)) {
This breaks it for you and you don't need any eeprom detection at all.
But your card is sharp here,
dev-board = SAA7134_BOARD_TWINHAN_DTV_DVB_3056;
printk(KERN_INFO %s: Reconfigured board as %s\n,
dev-name, saa7134_boards[dev-board].name);
}
if(dev-board == SAA7134_BOARD_TWINHAN_DTV_DVB_3056) {
tun_setup.mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
tun_setup.type = TUNER_PHILIPS_TDA8290;
tun_setup.addr = 0x4b;
and then the TDA8290 is forced to an wrong address. You have it at 0x42.
tun_setup.config = 2;
saa7134_i2c_call_clients (dev, TUNER_SET_TYPE_ADDR,tun_setup);
data[2] = 0x68;
}
i2c_transfer(dev-i2c_adap, msg, 1);
}
This is one problem... if in saa7134.card.c I add this code for
automatic driver load:
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x1822, /*Twinhan Technology Co. Ltd*/
.subdevice= 0x0022,
.driver_data = SAA7134_BOARD_TWINHAN_DTV_DVB_3056
The card is loaded but only: DVB-T and radio works fine, the analog
tuner no; gives no audio e not all channels are correctly scanned and
the pictures are unstable. I don't know why some more works around need
to be done.
If autodetected, the analog demodulator is forced to a wrong address by
the eeprom detection. The radio is demodulated by the saa7131e.
So:
sudo modprobe saa7134 card=118
it's ok and than all works fine.
If _not_ autodetected, the tda8290 is not forced to a wrong address by
the successful eeprom detection and works fine at 0x42.
__
This is the code to add in saa7134-dvb.c
case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
configure_tda827x_fe(dev, twinhan_dtv_dvb_3056_config);
static struct tda1004x_config twinhan_dtv_dvb_3056_config = {
/* sioux signed-off [EMAIL
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
[...]
Since it is more than six months back, that the card could have been
added, guess I'll try this next pointing at the state of affairs we have
here now.
Missing commas tend to spread ... ;)
diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Nov 30
18:27:26 2007 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Dec 04
00:06:19 2007 +0100
@@ -3600,6 +3600,36 @@ struct saa7134_board saa7134_boards[] =
.tv = 1,
}},
},
+ [SAA7134_BOARD_TWINHAN_DTV_DVB_3056] = {
+ .name = Twinhan Hybrid DTV-DVB 3056 PCI,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 2,
+ .mpeg = SAA7134_MPEG_DVB,
+ .gpiomask = 0x020,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x020,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -4369,7 +4399,13 @@ struct pci_device_id saa7134_pci_tbl[] =
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x4e42,
.subdevice= 0x3502,
- .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS
+ .driver_data = SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1822, /*Twinhan Technology Co. Ltd*/
+ .subdevice= 0x0022,
+ .driver_data = SAA7134_BOARD_TWINHAN_DTV_DVB_3056,
},{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
@@ -4782,6 +4818,7 @@ int saa7134_board_init2(struct saa7134_d
case SAA7134_BOARD_ASUSTeK_P7131_DUAL:
case SAA7134_BOARD_ASUSTeK_P7131_HYBRID_LNA:
case SAA7134_BOARD_MEDION_MD8800_QUADRO:
+ case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
/* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
*/
diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Fri Nov 30
18:27:26 2007 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon Dec 03
19:05:39 2007 +0100
@@ -778,6 +778,21 @@ static struct tda1004x_config avermedia_
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config twinhan_dtv_dvb_3056_config = {
+ .demod_address = 0x08,
+ .invert= 1,
+ .invert_oclk = 0,
+ .xtal_freq = TDA10046_XTAL_16M,
+ .agc_config= TDA10046_AGC_TDA827X,
+ .gpio_config = TDA10046_GP01_I,
+ .if_freq = TDA10046_FREQ_045,
+ .i2c_gate = 0x42,
+ .tuner_address = 0x61,
+ .tuner_config = 2,
+ .antenna_switch = 1,
+ .request_firmware = philips_tda1004x_request_firmware
+};
+
/* --
* special case: this card uses saa713x GPIO22 for the mode switch
*/
@@ -1043,6 +1058,8 @@ static int dvb_init(struct saa7134_dev *
case SAA7134_BOARD_AVERMEDIA_SUPER_007:
configure_tda827x_fe(dev, avermedia_super_007_config);
break;
+ case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
+ configure_tda827x_fe(dev, twinhan_dtv_dvb_3056_config);
default:
wprintk(Huh? unknown DVB card?\n);
break;
diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h Fri Nov 30 18:27:26
2007 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134.h Mon Dec 03 18:16:32
2007 +0100
@@ -247,6 +247,7 @@ struct saa7134_format {
#define SAA7134_BOARD_SABRENT_TV_PCB05 115
#define SAA7134_BOARD_10MOONSTVMASTER3 116
#define SAA7134_BOARD_AVERMEDIA_SUPER_007 117
+#define SAA7134_BOARD_TWINHAN_DTV_DVB_3056 118
#define SAA7134_MAXBOARDS 8
#define SAA7134_INPUT_MAX 8
Re: [linux-dvb] new driver for: Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] as card=118 in cardlist.saa7134
Am Dienstag, den 04.12.2007, 00:23 +0100 schrieb hermann pitton: [...] Since it is more than six months back, that the card could have been added, guess I'll try this next pointing at the state of affairs we have here now. Missing commas tend to spread ... ;) diff -r 27b2c6a80826 linux/drivers/media/video/saa7134/saa7134-cards.c --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Nov 30 18:27:26 2007 +0200 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Dec 04 00:06:19 2007 +0100 @@ -3600,6 +3600,36 @@ struct saa7134_board saa7134_boards[] = .tv = 1, Broken lines, not compatible editors and mail clients ... I'm back to Mike Isely and will ignore all other stuff not officially documented, ... until it works. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asus p7131Hybrid: help me using an internal patch cable?
Am Donnerstag, den 22.11.2007, 06:06 +0100 schrieb Soeren Sonnenburg: On Mon, 2007-11-19 at 04:28 +0100, hermann pitton wrote: Hi Paolo, [...] From the driver's side, if it is connected, I'm not aware of anything that could stop it, since the from analog derived digital sound works. It is now exactly two years back, that we have support for such Asus cards. Exactly _one_ user had a disappointing experience with _one_ such card on _his_ PC, as far I know. :) And this is the result _on top_ of the DVB-T v4l-wiki currently. http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards#Asus I'm not related to Asus in anyway, they simply had one of the first those cards. They have never been bothered about it. So, I can't even say if they would have been willing to help or not. What is stated there currently is all, but for sure not the truth. Since I have been involved in getting those cards to work, I won't give the wiki censor, it is right that users tell what they found thereafter, but it also shows the whole stupidity of any wiki-mania, even the pictures are wrong and show a different device. Well as I am that one such user with one such card I can only tell that I know have a TT-1500 in the exact same machine in the exact same slot and I don't see random memory corruptions to happen and the machine has including 3 dvb cards an uptime of 1 month now. With the asus it was usually crashing after 4 days of continuous usage. So either the driver is buggy, the card's hardware is or it is triggering a bug on my hardware that no other card triggers. And well it could of course be that no one uses the asus p7131 in a long term setup. I mean the dibcom dongles all work fine if you just don't want to use them for more then just a flick. A way to tell the truth could be to record exactly what works under which circumstances / hardware / how long things were tested. I bought the asus back then because it was said to be fully working/supported in the above wiki page ... so your mileage may vary. Soeren. Hi Soeren, good to know, it was you then. You did spend at least a lot of time on it and seriously tried to track it down. Unfortunately we still know exactly nothing, could be something BIOS/PSU/hardware, saa7134 driver, tuner code, even the IRQ remote. Or some nice combination of it. As said, nothing is perfect, and I never did exclude a potential driver bug, some are hard to get, but to blame it all to the card manufacturer is most likely very, very wrong. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Determining chipsets (was Artec T14BR DVB-T)
Am Mittwoch, den 21.11.2007, 07:37 +0100 schrieb hermann pitton: Am Mittwoch, den 21.11.2007, 10:43 +1000 schrieb Lindsay Mathieson: Yousef Lamlum wrote: Hi, Being the impatient so and so that I am, I cracked open my Artec T14BR to have proper look inside. Turns out it uses the same chipset combo that DiBcomm's STK7070-P reference design uses. Is there anyway to id the chips without taking a USB device to pieces? I have a DigitalNow TinyTwin USB (Dual Tuner) that I'm pretty sure is an AF9015 design but I'm not sure what the tuner is. I have it recognised using the af9015 module from v4l development but the tuner is not recognised. I popped the plastic shell of but all the chips are hidden under soldered metal plates and I'm not game to remove them :) Thanks - Lindsay Hi, that is the current situation on almost all new devices since the last two years and still improves. In most cases you can see something such simple as the chips being used only by the risk to destroy the device. And as said, that still improves. Ah, I forgot to add, some already wash out the printings on the chips. That such stuff is distributed by ASUS makes me grumpy. Others simply get their drivers done from the chip manufactures and their customers and Bill and friends collect for doing nothing than just rule the market ... Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] video capture is broken
Am Montag, den 19.11.2007, 22:46 +0100 schrieb Halim Sahin: Hi, Hmm where can I get the patch? Regards Halim Hi, Mauro pulled it already into v4l-dvb master 4 hours back. Cheers, Hermann On Mo, Nov 19, 2007 at 08:02:32 +0100, e9hack wrote: Brandon Philips schrieb: I am guessing this a saa7136 based device. The card is saa7146 based. I think you mean the saa7146. Could you please test this patch? If it is in fact not a saa7136, what driver is it? The patch does fix the problem, thanks! - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asus p7131Hybrid: help me using an internal patch cable?
Hi Paolo, Am Samstag, den 17.11.2007, 14:27 +0100 schrieb Paolo Dell'Aquila: I'm really enjoining my Asus P7131 Hybrid: everything it's working fine, analog TV, DVB-T, radio. the remote should work perfectly as well. The only problem is that, excluding mplayer and kaffeine, I've alwyas to use sox or aplay for hearing audio. So I took an internal patch cable and I tried to use it... but I've no luck with it. No way to let it work. I connected it to my motherboard (ASUS P5AD2-E Premium) internal connector and to the internal connector of my P7131Hybrid Can someone help me? Your card is derived from the Asus P7131 Dual and adjusted for the missing firmware eeprom and the new LNA on it. All reports I remember after that are just, that it works fine. Also, after testing a whole bunch of other cards in this league recently, it has a exceptional reception performance compared to others. There was one more report I remember, that analog from the on board 4pin connector doesn't work, either all others did never test and/or it is true. The lines on the PCB seem to talk a different language, but after looking around on current merchants, nobody announces the support for analog sound explicitly, but to keep the connector should be a waste of money else ... On the previous P7131 Dual, where all started, the two pins in the middle are ground and analog sound support works flawlessly. From the drivers side, using saa7134-alsa sets the two mute off bits for digital and analog audio at once, if digital sound works, there is no known escape that analog sound should not work too. I don't have the slightest idea about, how well your recent sound card/chip is supported, but switching 5.1 and higher all to output might be an issue not to get input. Dunno. So, since no one else with that variant of the card gave a comment yet, connecting a appropriate cable to the on-board analog audio out and testing with some headphones left/right to ground stuff may be something to do. From the driver's side, if it is connected, I'm not aware of anything that could stop it, since the from analog derived digital sound works. It is now exactly two years back, that we have support for such Asus cards. Exactly _one_ user had a disappointing experience with _one_ such card on _his_ PC, as far I know. :) And this is the result _on top_ of the DVB-T v4l-wiki currently. http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards#Asus I'm not related to Asus in anyway, they simply had one of the first those cards. They have never been bothered about it. So, I can't even say if they would have been willing to help or not. What is stated there currently is all, but for sure not the truth. Since I have been involved in getting those cards to work, I won't give the wiki censor, it is right that users tell what they found thereafter, but it also shows the whole stupidity of any wiki-mania, even the pictures are wrong and show a different device. Cheers, Hermann Thank You in advance. Paolo My system: ** Linux Ubuntu 7.10 (gutsy Gibbon) Kernel: 2.3.22-14-generic Motherboard: ASUS P5AD2-E Premium lsmod (relavant modules): * saa7134_dvb18188 0 dvb_pll15492 1 saa7134_dvb saa7134_alsa 15392 1 video_buf_dvb 7812 1 saa7134_dvb tda1004x 17028 2 saa7134_dvb snd_pcm80388 3 saa7134_alsa,snd_hda_intel,snd_pcm_oss saa7134 129100 3 saa7134_dvb,saa7134_alsa video_buf 26244 4 saa7134_dvb,saa7134_alsa,video_buf_dvb,saa7134 compat_ioctl32 2304 1 saa7134 ir_kbd_i2c 9872 1 saa7134 ir_common 35460 2 saa7134,ir_kbd_i2c videodev 29312 2 saa7134 v4l2_common18432 3 tuner,saa7134,videodev v4l1_compat15364 2 saa7134,videodev i2c_core 26112 10 w83627ehf,i2c_isa,tda827x,saa7134_dvb,dvb_pll,tda1004x,tuner,saa7134,ir_kbd_i2c,nvidia snd54660 13 saa7134_alsa,snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device snd_rtctimer4384 1 snd_hda_intel 263712 3 snd_pcm_oss44672 2 snd_mixer_oss 17664 2 snd_pcm_oss snd_seq_dummy 4740 0 snd_seq_oss33152 0 snd_seq_midi9600 0 snd_rawmidi25728 1 snd_seq_midi snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi snd_seq53232 7 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 24324 3 snd_rtctimer,snd_pcm,snd_seq snd_seq_device 9228 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq snd54660 13 saa7134_alsa,snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 8800 4 snd snd_page_alloc
[linux-dvb] small hardware news: recent Medion/Aldi PCs with Creatix CTX_948
Hi, the CTX_948 is a low profile triple PCI card. It is compatible with the saa7134 Medion Quad card=96, but in truth else a very different card. Known pitfall one: analog TV must be used first to get good results on DVB-T. Known pitfall two: the ISL6405EZR doesn't get sharp, needs currently a external receiver with RF/IF loopthrough to get voltage and tone for DVB-S, same like on the Quad ... Someone interested, Hartmut? Might take a while with me... Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] never do symbol_put(tunerfoo_attach);
Am Freitag, den 16.11.2007, 19:10 -0500 schrieb [EMAIL PROTECTED]:
Michel Ludwig wrote:
On Fri 16 Nov 2007, you wrote:
We like to make linuxtv drivers modular and forward compatible. There
_are_ devices out there that use other tuners, and if you hardcode
xc3028 into this driver, it prevents future developers from adding
support for other devices without having to change existing code.
Sure, but no one said that tm6000-dvb is ready to go into the main tree...
I saw an issue and I felt it was appropriate for me to point it out
immediately.
Better to fix a problem when it is noticed, no?
But anyway, how would dvb_frontend_detach(fe) release the xc3028_attach
symbol, which is requested by dvb_attach?
The answer is self-explanatory. Take a look at the other drivers, and
take a look at dvb_frontend_detach. (dvb_frontend.c , lines 1204 thru
1221)
Of course, I have done that, but it is still not clear to me. Here are the
two
macros:
#define dvb_attach(FUNCTION, ARGS...) ({ \
void *__r = NULL; \
typeof(FUNCTION) __a = symbol_request(FUNCTION); \
if (__a) { \
__r = (void *) __a(ARGS); \
if (__r == NULL) \
symbol_put(FUNCTION); \
} else { \
printk(KERN_ERR DVB: Unable to find symbol
#FUNCTION()\n); \
} \
__r; \
})
void dvb_frontend_detach(struct dvb_frontend* fe)
{
void *ptr;
if (fe-ops.release_sec) {
fe-ops.release_sec(fe);
symbol_put_addr(fe-ops.release_sec);
}
if (fe-ops.tuner_ops.release) {
fe-ops.tuner_ops.release(fe);
symbol_put_addr(fe-ops.tuner_ops.release);
}
ptr = (void*)fe-ops.release;
if (ptr) {
fe-ops.release(fe);
symbol_put_addr(ptr);
}
}
dvb_attach is called with xc2028_attach, hence it will request
xc2028_attach.
But dvb_frontend_detach will release xc2028_dvb_release.
It's the same module.
I can try this out tomorrow, but if I have to reboot my machine after that
to
unload tuner-xc2028, then there is definitely a flaw in this approach...
:-)
This is the accepted and proven method used across the entire dvb tree.
If it doesnt work for you, then something is wrong in your code. I
don't think it will cause any problem.
Hey, I was just trying to point out a flaw in your patch -- Nobody is an
expert, and there is always something to be learned.
-Mike
P.S. Why are you guys dropping cc's? I cc'd linux-dvb mailing list
because this is a development issue. It is important for such
discussions to be documented, because it is the only way for future
developers to learn from our mistakes. To conduct all emails in private
will not lead to any progression. This is a community, and we should
all be willing to give and accept advice from each other.
Mike,
I still fully under scribe that.
But we should also not create illusions for those coming later and have
to crawl through.
Sometimes it is a damned ratrace, maybe always!
With that NDA stuff not in some GNU/Linux library as fall back, it can
always start again.
I said it previously and repeat it, it comes from above and gets wild by
will.
We are only the idiots ...
Cheers,
Hermann
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Lifeview PCI TRIO DVB-S problems: can not tune half transponders, low SS and SNR
Hi Vangelis! Am Donnerstag, den 15.11.2007, 21:00 + schrieb Vangelis Nonas: Hello Hermann, Your suggestion helped a lot indeed. I can now get about 2000 services on Hotbird using scan from dvb-apps. Moreover the reception is better, SNR is about 90%, SS is around 50% or more and I dont often get high error rates. I also tested viewing channels and I can now see channels that didn't exist before. One minor negative side effect is that channelscan on vdr crashes. However, I still can not tume to 12 transponders on hotbird (out of 94 in total). These are the failing transponders: tune to: 11334:h:S0.0W:27500: (tuning failed) tune to: 11373:h:S0.0W:27500: (tuning failed) tune to: 11432:v:S0.0W:27500: (tuning failed) tune to: 12264:v:S13.0E:27500: (tuning failed) tune to: 11954:h:S19.2E:27500: (tuning failed) tune to: 11597:v:S19.2E:22000: (tuning failed) tune to: 12480:v:S19.2E:27500: (tuning failed) tune to: 12500:v:S13.0E:27500: (tuning failed) tune to: 11533:v:S13.0E:27500: (tuning failed) tune to: 11996:v:S13.0E:27500: (tuning failed) tune to: 12722:h:S68.5E:26657: (tuning failed) tune to: 11344:h:S8.0W:27500: (tuning failed) Although the DVB-S part of the card is now much more usable. I feel there is still room for improvement of the Linux driver. Any suggestions on how to improve the reception further? I have to mention here that I have a single LNB on my installation, no disecq, however the patch helped a lot. Thank you Vagelis I'm a bloody beginner on DVB-S and have a simple dish just since a few days. The reason for that is, that we have the code from Andrew since long for the newer silicon stuff, also saa7134 triple devices, which should support DVB-S as well since for over two years, but we don't make much progress, since only the Trio seems to be supported and on others not even testing happens. For sure I can see, that whole fleets of such triple stuff are coming in from all seas. For now, I'm only on a device, hard enough to barely hold it in a not triple capable PCI slot, and likely not fully initialized for the ISL stuff. I'm looking forward to get something normal next and then maybe I can contribute to your questions in the future. For now, try to exchange with people on the same hardware than you and hope for hints of the DVB guys. BTW, that outstanding patch is committed since 7 days to v4l-dvb master. For what I can see the patchlet from me, attaching the ISL6421 for the ISL6405 on the Medion Quad should not do any harm, quite the same for the first LNB. If somebody recognizes any possible risks to the hardware, please say so. I don't. Cheers, Hermann hermann pitton wrote: Hi, Am Mittwoch, den 14.11.2007, 21:36 + schrieb Vangelis Nonas: Hello, I have been trying to use the DVB-S frontend of lifeview pci trio to scan and watch channels from Hotbird. I have the following two problems: please try again with that patch applied and report again. http://linuxtv.org/pipermail/linux-dvb/2007-June/018741.html I don't get a Medion Quad, not in the original triple bus master PCI slot, to behave well on supplying voltage and tone on a ISL6405ER, but with the RF loop through from an external receiver providing the missing I have more than thousand broadcasts available from Hotbird-13.OE. Cheers, Hermann A) When I scan (using the scan utility from the hg tree, or the scan utility of my distribution) almost half of the transponders can not be tuned. I get the error tuning failed and of course almost half of Hotbitd's channels are not found. My transponders file is correct because it comes from my set top box which also runs linux :) or from hg dvb-apps or from other dvb software (e.g. prog dvb). I have also tried scanning with channelscan plugin of vdr with the same results. When I use kaffeine to scan for channels I get an Oops. I am attaching the output of my scan command using the scan util from dvb-apps fresh hg pull. (scan.log.gz) B) When I use ready made channel lists downloaded from the internet I get low SNR and SS on almost half of the transponders and in some cases high error rate. When I use szap on those transponders I can not get a lock. My kernel is: Linux vagoshome 2.6.22-gentoo-r9 #1 SMP Tue Oct 30 16:02:08 UTC 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux with a fresh hg mercurial pull and installation. I attach also my dmesg as dmesg.log.gz I also attach my lsmod as lsmod.log.gz In case you need more info about the Oops I get when I scan from Kaffeine, I can reproduce it and send you the output. The card works correctly under windows on the same machine, sat cable, dish. Thank you Vagelis ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin
Re: [linux-dvb] Lifeview PCI TRIO DVB-S problems: can not tune half transponders, low SS and SNR
Hi, Am Mittwoch, den 14.11.2007, 21:36 + schrieb Vangelis Nonas: Hello, I have been trying to use the DVB-S frontend of lifeview pci trio to scan and watch channels from Hotbird. I have the following two problems: please try again with that patch applied and report again. http://linuxtv.org/pipermail/linux-dvb/2007-June/018741.html I don't get a Medion Quad, not in the original triple bus master PCI slot, to behave well on supplying voltage and tone on a ISL6405ER, but with the RF loop through from an external receiver providing the missing I have more than thousand broadcasts available from Hotbird-13.OE. Cheers, Hermann A) When I scan (using the scan utility from the hg tree, or the scan utility of my distribution) almost half of the transponders can not be tuned. I get the error tuning failed and of course almost half of Hotbitd's channels are not found. My transponders file is correct because it comes from my set top box which also runs linux :) or from hg dvb-apps or from other dvb software (e.g. prog dvb). I have also tried scanning with channelscan plugin of vdr with the same results. When I use kaffeine to scan for channels I get an Oops. I am attaching the output of my scan command using the scan util from dvb-apps fresh hg pull. (scan.log.gz) B) When I use ready made channel lists downloaded from the internet I get low SNR and SS on almost half of the transponders and in some cases high error rate. When I use szap on those transponders I can not get a lock. My kernel is: Linux vagoshome 2.6.22-gentoo-r9 #1 SMP Tue Oct 30 16:02:08 UTC 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux with a fresh hg mercurial pull and installation. I attach also my dmesg as dmesg.log.gz I also attach my lsmod as lsmod.log.gz In case you need more info about the Oops I get when I scan from Kaffeine, I can reproduce it and send you the output. The card works correctly under windows on the same machine, sat cable, dish. Thank you Vagelis ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How could I play my composite tv using mplayer???
Am Dienstag, den 13.11.2007, 15:49 +0800 schrieb kevin liu: Dear everyone: How could I use mplayer to play my composite tv program. I use this command mplayer tv:// -tv driver=v4l2:device=/dev/video0:norm=NTSC:noaudio Seems no result. :-( Hi, look at what mplayer prints after querying the device about analog inputs and doing input enumeration. Default is input=0, depends on the hardware, but something could also be done on the drivers to get it more homogeneously. In most cases that first input will not be composite. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PULL] minor videobuf fixes http://ifup.org/hg/v4l-dvb
Hi! Am Dienstag, den 13.11.2007, 15:44 -0800 schrieb Brandon Philips: Hello Mauro, Please review and pull from http://ifup.org/hg/v4l-dvb for: Brandon, that above link is dead for me. Likely not related to all what you try to fix currently, maybe I have to read the recent patch policy again, but stuff coming in off lists is bad anyway. I'm against that possible major changes happen without being visible to the public. That goes also for more complex down ports from kernel. Finally someone with restricted abilities, like me, for global testing nobody is able to do it alone, should confirm that such changes are functional in the end after they already happened or are assumed to be harmless. Since next _improvements_ will for sure come soon, there are already complaints for example that NICAM stereo on PAL_DK is broken on the saa7134 driver, which I happily ignore too, since it is only one voice. But fact is, that we mostly have only _one_ voice over a _very long_ time period and others can't test ... I don't understand, why patches have no equivalent on the public lists anymore, yeah, for a finally payed distro it looks better, but to have them public is also very important for to get new interested people in the long run. To make it short, not caused by you at all, _all_ patches have to be on the lists again and nothing else is acceptable, that I vote for. To claim it is enough to review them when they arrive at kernel, is proved to be wrong. Adrian and others will do their best, but the bang always still comes thereafter. That means also that major patch bombs should be send again at least every three months, to face against that it is politics to deny them, when in truth it are only the limited resources to review them. Cheers, Hermann - V4L: videobuf: don't chew up namespace STATE_.*, convert to VIDEOBUF_ - V4L: videobuf: convert streaming and reading to bitfields - V4L: videobuf-core locking fixes and comments - V4L: Convert videobuf drivers to videobuf_stop b/linux/drivers/media/common/saa7146_fops.c |8 b/linux/drivers/media/common/saa7146_vbi.c| 10 b/linux/drivers/media/common/saa7146_video.c |8 b/linux/drivers/media/video/bt8xx/bttv-driver.c | 26 - b/linux/drivers/media/video/bt8xx/bttv-risc.c | 14 b/linux/drivers/media/video/bt8xx/bttv-vbi.c |6 b/linux/drivers/media/video/cx23885/cx23885-core.c| 18 b/linux/drivers/media/video/cx88/cx88-alsa.c |2 b/linux/drivers/media/video/cx88/cx88-blackbird.c |5 b/linux/drivers/media/video/cx88/cx88-core.c |4 b/linux/drivers/media/video/cx88/cx88-mpeg.c | 14 b/linux/drivers/media/video/cx88/cx88-vbi.c | 10 b/linux/drivers/media/video/cx88/cx88-video.c | 22 b/linux/drivers/media/video/saa7134/saa7134-core.c|8 b/linux/drivers/media/video/saa7134/saa7134-empress.c |5 b/linux/drivers/media/video/saa7134/saa7134-ts.c |8 b/linux/drivers/media/video/saa7134/saa7134-vbi.c |8 b/linux/drivers/media/video/saa7134/saa7134-video.c | 12 b/linux/drivers/media/video/videobuf-core.c | 50 +- b/linux/drivers/media/video/videobuf-dvb.c|2 b/linux/drivers/media/video/vivi.c| 24 b/linux/include/media/videobuf-core.h | 14 linux/drivers/media/common/saa7146_video.c|5 linux/drivers/media/video/bt8xx/bttv-driver.c |5 linux/drivers/media/video/cx88/cx88-video.c |5 linux/drivers/media/video/saa7134/saa7134-video.c |5 linux/drivers/media/video/videobuf-core.c | 249 ++ linux/drivers/media/video/vivi.c |1 linux/include/media/videobuf-core.h |6 29 files changed, 304 insertions(+), 250 deletions(-) Thanks, Brandon ___ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PULL] minor videobuf fixes http://ifup.org/hg/v4l-dvb
Am Dienstag, den 13.11.2007, 21:31 -0800 schrieb Brandon Philips: On 05:27 Wed 14 Nov 2007, hermann pitton wrote: Am Dienstag, den 13.11.2007, 15:44 -0800 schrieb Brandon Philips: Please review and pull from http://ifup.org/hg/v4l-dvb for: Brandon, that above link is dead for me. My host had some trouble earlier, a small DOS attack. It should be up again. Likely not related to all what you try to fix currently, maybe I have to read the recent patch policy again, but stuff coming in off lists is bad anyway. I like the idea of sending PULL requests to Mauro/v4l-dvb-maintainer and broken out patches to video4linux-list or linux-dvb. I will do that for this patch set after I figure out how to do that with hg :) Does that seem reasonable? That means also that major patch bombs should be send again at least every three months, to face against that it is politics to deny them, when in truth it are only the limited resources to review them. Major patch bombs where? You talk like we don't have anything out of tree currently. The rest is of course to your fun something. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PULL] minor videobuf fixes http://ifup.org/hg/v4l-dvb
Am Mittwoch, den 14.11.2007, 07:27 +0100 schrieb hermann pitton: Am Dienstag, den 13.11.2007, 21:31 -0800 schrieb Brandon Philips: On 05:27 Wed 14 Nov 2007, hermann pitton wrote: Am Dienstag, den 13.11.2007, 15:44 -0800 schrieb Brandon Philips: Please review and pull from http://ifup.org/hg/v4l-dvb for: Brandon, that above link is dead for me. My host had some trouble earlier, a small DOS attack. It should be up again. Likely not related to all what you try to fix currently, maybe I have to read the recent patch policy again, but stuff coming in off lists is bad anyway. I like the idea of sending PULL requests to Mauro/v4l-dvb-maintainer and broken out patches to video4linux-list or linux-dvb. I will do that for this patch set after I figure out how to do that with hg :) Does that seem reasonable? That means also that major patch bombs should be send again at least every three months, to face against that it is politics to deny them, when in truth it are only the limited resources to review them. Major patch bombs where? You talk like we don't have anything out of tree currently. The rest is of course to your fun something. Ermmh, sorry, you might miss on what I thought to have made noise enough. The whole misery is of course caused by the current official kernel policy. Take whatever you can get, run for NDAs ..., let's have lot of code nobody knows about exactly ... It comes from above. And I don't like it. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Need help in setting up my kworld nb 220 card on ubuntu 7.10
Am Sonntag, den 11.11.2007, 20:56 -0600 schrieb ying lcs: On Nov 11, 2007 8:19 PM, hermann pitton [EMAIL PROTECTED] wrote: ... We have some how to add a new card stuff on the v4l-wiki then. Nevertheless, to try card=88. modprobe -vr saa7134-dvb saa7134-alsa tuner tda827x modprobe -v saa7134 i2c_scan=1 My, modprobe -v saa7134 card=88 i2c_scan=1 Hermann Thanks for the help. I tried your suggestion: # modprobe -v saa7134 card=88 i2c_scan=1 # dmesg | grep dvb # dmesg | grep dvb # ls -l /dev/dvb/adapter* ls: /dev/dvb/adapter*: No such file or directory But there is still nothing in /dev/dvb/adapter* Thanks for any more pointers. Hi, if you are not on recent v4l-dvb from linux-tv.org or on some latest kernels, you need to modprobe saa7134-dvb debug=1 manually. This goes for saa7134-alsa too until today. See the v4l-wiki for that. Still interested in your dmesg for saa7134 card=88 and detection of tuner and other chips with i2c_scan=1. As said, a Kworld NB 220 PCI card is unknown to me. Try google, there are only this new NB-TV 220 pcmcia/cardbus. Here are good details of the hardware on that one. http://www.ixbt.com/monitor/kworld-nb-tv220.shtml This one _could eventually_ work with card=88. To try FlyDVB-T Duo with different audio clock, we can override with with audio_clock=N seems not to have any advantage against card=88 on a device without analog radio and remote. If you can't verify that you have almost the same on a PCI variant, as listed previously for chips, xtals and i2c addresses, we need all details. There is not much left for try and error luck on such recent devices. That you have a new Kworld card with new subdevice ID is all we have so far. Also nothing else in the eeprom and no patterns on gpio pins. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Need help in setting up my kworld nb 220 card on ubuntu 7.10
Am Montag, den 12.11.2007, 17:41 -0600 schrieb ying lcs: On Nov 12, 2007 5:36 PM, hermann pitton [EMAIL PROTECTED] wrote: Am Sonntag, den 11.11.2007, 20:56 -0600 schrieb ying lcs: On Nov 11, 2007 8:19 PM, hermann pitton [EMAIL PROTECTED] wrote: ... We have some how to add a new card stuff on the v4l-wiki then. Nevertheless, to try card=88. modprobe -vr saa7134-dvb saa7134-alsa tuner tda827x modprobe -v saa7134 i2c_scan=1 My, modprobe -v saa7134 card=88 i2c_scan=1 Hermann Thanks for the help. I tried your suggestion: # modprobe -v saa7134 card=88 i2c_scan=1 # dmesg | grep dvb # dmesg | grep dvb # ls -l /dev/dvb/adapter* ls: /dev/dvb/adapter*: No such file or directory But there is still nothing in /dev/dvb/adapter* Thanks for any more pointers. Hi, if you are not on recent v4l-dvb from linux-tv.org or on some latest kernels, you need to modprobe saa7134-dvb debug=1 manually. This goes for saa7134-alsa too until today. See the v4l-wiki for that. I am runnning ubuntu 7.10. And I just tried # modprobe saa7134-dvb debug=1 # dmesg | grep dvb # And I still get nothing dmesg. See above, you must unload all related modules previously with modprobe -vr Can't believe that you have a custom kernel with all statically compiled in. Then modprobe saa7134 i2c_scan=1. Then modprobe saa7134-dvb or set options saa7134 ..., options saa7134-dvb ... amd whatsoever in /etc/modprobe.conf or what ever Ubuntu uses for it and depmod -a. Use modinfo module_name to know more. What says uname -a? Where can one buy this card? Cheers, Hermann Still interested in your dmesg for saa7134 card=88 and detection of tuner and other chips with i2c_scan=1. As said, a Kworld NB 220 PCI card is unknown to me. Try google, there are only this new NB-TV 220 pcmcia/cardbus. Here are good details of the hardware on that one. http://www.ixbt.com/monitor/kworld-nb-tv220.shtml This one _could eventually_ work with card=88. To try FlyDVB-T Duo with different audio clock, we can override with with audio_clock=N seems not to have any advantage against card=88 on a device without analog radio and remote. If you can't verify that you have almost the same on a PCI variant, as listed previously for chips, xtals and i2c addresses, we need all details. There is not much left for try and error luck on such recent devices. That you have a new Kworld card with new subdevice ID is all we have so far. Also nothing else in the eeprom and no patterns on gpio pins. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Need help in setting up my kworld nb 220 card on ubuntu 7.10
Hi, Am Samstag, den 10.11.2007, 13:45 -0600 schrieb ying lcs: Hi, I am trying to setup my kworld nb 220 tv card in ubuntu 7.10. I have read http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers But I find out that my /dev/dvb/adapter* is empty. Here is the result of the command 'lsmod', 'dmesg', 'lspci -v'. Please advice what should I do to setup my video card to watch TV under ubuntu 7.10. for what I seem to know so far, it has a saa7135 with 32.110MHz audioclock. The digital demod is tda10046 at 0x08 with firmware eeprom. The 16MHz clock comes from a tda8275ac1 used for DVB-T tuning at 0x60. A second tda8275ac1 at 0x61, also 16MHz clock, has a tda8290 analog demod at 0x4b also used as i2c gate for analog tuning. You could give the Tevion/KWorld DVB-T 220RF card=88 a try. Is not completely the same design. That one uses a saa7131e, has radio and a KS700 remote controller, which yours seems to miss. Does it have a fan for cooling? Hopefully not. It is likely that external analog audio-in is on amux Line2 and not on LINE1 like on card=88 currently, not sure about it. Don't use overlay preview mode with the fglrx. Also, depending on that binary driver, I can't say if you can have multiple VideoOverlays for DVB-T and analog TV at once, which the card itself does provide. In case you should ever get something at all ;) to work, if DVB is running you can't use/record analog TV with planar formats at once, like mencoder will use them by default. That might end up in corrupted files on the disk, due to dma limitations. You need to force packed formats for such analog operations simultaneously. Some shots in the dark. All related stuff reloaded with the saa7134 option i2c_scan=1 (modinfo saa7134) might help to find out, how dark it really is. Good Luck, Hermann 15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller Subsystem: Lenovo ThinkPad T60/R60 series Flags: bus master, medium devsel, latency 168, IRQ 16 Memory at e430 (32-bit, non-prefetchable) [size=4K] Bus: primary=15, secondary=16, subordinate=17, sec-latency=176 Memory window 0: e000-e3fff000 (prefetchable) Memory window 1: c400-c7fff000 I/O window 0: a000-a0ff I/O window 1: a400-a4ff 16-bit legacy interface ports at 0001 16:00.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev f0) Subsystem: KWorld Computer Co. Ltd. Unknown device 7203 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at c400 (32-bit, non-prefetchable) [size=2K] Capabilities: access denied [...] [ 19.412000] Linux video capture interface: v2.00 [ 19.544000] saa7130/34: v4l2 driver version 0.2.14 loaded [ 19.548000] PCI: Enabling device :16:00.0 ( - 0002) [ 19.548000] ACPI: PCI Interrupt :16:00.0[A] - GSI 16 (level, low) - IRQ 16 [ 19.548000] saa7133[0]: found at :16:00.0, rev: 240, irq: 16, latency: 0, mmio: 0xc400 [ 19.548000] PCI: Setting latency timer of device :16:00.0 to 64 [ 19.548000] saa7133[0]: subsystem: 17de:7203, board: UNKNOWN/GENERIC [card=0,autodetected] [ 19.548000] saa7133[0]: board init: gpio is 0 [ 19.684000] saa7133[0]: i2c eeprom 00: de 17 03 72 ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: registered device video0 [v4l2] [ 19.684000] saa7133[0]: registered device vbi0 [ 19.696000] saa7134 ALSA driver for DMA sound loaded [ 19.696000] saa7133[0]/alsa: saa7133[0] at 0xc400 irq 16 registered as card -2 [ 30.432000] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 30.436000] [fglrx] Maximum main memory to use for locked dma buffers: 2896 MBytes. [ 30.436000] [fglrx] module loaded - fglrx 8.37.6 [May 25 2007] on minor 0 [ 30.64] ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 [ 31.388000] eth0: no IPv6 routers present [ 32.344000] thinkpad_acpi: ThinkPad ACPI Extras v0.14 [ 32.344000] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 32.344000] thinkpad_acpi: ThinkPad EC firmware 79HT50WW-1.07 [ 32.716000] [fglrx] total GART = 130023424 [ 32.716000] [fglrx] free GART =
Re: [linux-dvb] Need help in setting up my kworld nb 220 card on ubuntu 7.10
Hi Ying lcs, Am Sonntag, den 11.11.2007, 19:28 -0600 schrieb ying lcs: On Nov 11, 2007 6:54 PM, hermann pitton [EMAIL PROTECTED] wrote: Hi, Am Samstag, den 10.11.2007, 13:45 -0600 schrieb ying lcs: Hi, I am trying to setup my kworld nb 220 tv card in ubuntu 7.10. I have read http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers But I find out that my /dev/dvb/adapter* is empty. Here is the result of the command 'lsmod', 'dmesg', 'lspci -v'. Please advice what should I do to setup my video card to watch TV under ubuntu 7.10. for what I seem to know so far, it has a saa7135 with 32.110MHz audioclock. The digital demod is tda10046 at 0x08 with firmware eeprom. The 16MHz clock comes from a tda8275ac1 used for DVB-T tuning at 0x60. A second tda8275ac1 at 0x61, also 16MHz clock, has a tda8290 analog demod at 0x4b also used as i2c gate for analog tuning. You could give the Tevion/KWorld DVB-T 220RF card=88 a try. Thank you, Hermann. How can I try Tevion/KWorld DVB-T 220RF card=88? Yes, my card does not have any remote controller and it does not has a fan for cooling. It is a PCI card. I appreciate if you can tell me how can I try 'Tevion/KWorld DVB-T 220RF card=88'? Thank you again. so then, I don't know about which card we are actually talking. The eeprom has nothing and gpio init is 0x0. I just assumed the last from Kworld I have seen for now, the NB-TV 220 cardbus. On kworld.com.tw it is not even listed until today, but was seen in the UK some weeks back first time. We have some how to add a new card stuff on the v4l-wiki then. Nevertheless, to try card=88. modprobe -vr saa7134-dvb saa7134-alsa tuner tda827x modprobe -v saa7134 i2c_scan=1 And depending on your kernel version and depending on your analog sound out connectors saa7134-alsa. Else, all chips, all xtals, all connectors and high resolution pics ;) Cheers, Hermann Is not completely the same design. That one uses a saa7131e, has radio and a KS700 remote controller, which yours seems to miss. Does it have a fan for cooling? Hopefully not. It is likely that external analog audio-in is on amux Line2 and not on LINE1 like on card=88 currently, not sure about it. Don't use overlay preview mode with the fglrx. Also, depending on that binary driver, I can't say if you can have multiple VideoOverlays for DVB-T and analog TV at once, which the card itself does provide. In case you should ever get something at all ;) to work, if DVB is running you can't use/record analog TV with planar formats at once, like mencoder will use them by default. That might end up in corrupted files on the disk, due to dma limitations. You need to force packed formats for such analog operations simultaneously. Some shots in the dark. All related stuff reloaded with the saa7134 option i2c_scan=1 (modinfo saa7134) might help to find out, how dark it really is. Good Luck, Hermann 15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller Subsystem: Lenovo ThinkPad T60/R60 series Flags: bus master, medium devsel, latency 168, IRQ 16 Memory at e430 (32-bit, non-prefetchable) [size=4K] Bus: primary=15, secondary=16, subordinate=17, sec-latency=176 Memory window 0: e000-e3fff000 (prefetchable) Memory window 1: c400-c7fff000 I/O window 0: a000-a0ff I/O window 1: a400-a4ff 16-bit legacy interface ports at 0001 16:00.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev f0) Subsystem: KWorld Computer Co. Ltd. Unknown device 7203 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at c400 (32-bit, non-prefetchable) [size=2K] Capabilities: access denied [...] [ 19.412000] Linux video capture interface: v2.00 [ 19.544000] saa7130/34: v4l2 driver version 0.2.14 loaded [ 19.548000] PCI: Enabling device :16:00.0 ( - 0002) [ 19.548000] ACPI: PCI Interrupt :16:00.0[A] - GSI 16 (level, low) - IRQ 16 [ 19.548000] saa7133[0]: found at :16:00.0, rev: 240, irq: 16, latency: 0, mmio: 0xc400 [ 19.548000] PCI: Setting latency timer of device :16:00.0 to 64 [ 19.548000] saa7133[0]: subsystem: 17de:7203, board: UNKNOWN/GENERIC [card=0,autodetected] [ 19.548000] saa7133[0]: board init: gpio is 0 [ 19.684000] saa7133[0]: i2c eeprom 00: de 17 03 72 ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.684000] saa7133[0]: i2c eeprom 40: ff ff ff
Re: [linux-dvb] Need help in setting up my kworld nb 220 card on ubuntu 7.10
... We have some how to add a new card stuff on the v4l-wiki then. Nevertheless, to try card=88. modprobe -vr saa7134-dvb saa7134-alsa tuner tda827x modprobe -v saa7134 i2c_scan=1 My, modprobe -v saa7134 card=88 i2c_scan=1 Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Am Samstag, den 03.11.2007, 00:56 +0100 schrieb rjkm: Manu Abraham writes: If you have had crack, then you will see cracks everywhere . :) I don't understand Ralph's involvement in your Linux projects, and why the alternative direction mattered to him. If you see the initial proposal, there were so many people involved, Ralph too, he used to hang out on IRC along with us. Please see the original post when the STB0899 driver was made public. There were reasons why it mattered to him. He was also involved in an STB0899 based project, which he can disclose if he is interested. There is a nice little PCIe dual STB0899 reference platform I wrote drivers for. But I don't know if it will ever be built by anybody. Ralph Ralph, thanks for your comment, and you never did let a beginner hang into something, when it starts to become serious, iirc. I ask frankly now. Was there really something going that wrong, that Manu still feels he is right intercepting all from v4l, because Mauro did also some harm to you, likely without any chance to avoid it, simply not knowing what it could be all about, since we were on blank bones after Gerd got it sick? That is what I got told from him when it became, hmm, _quite strange_ previously over a long amount of time and tried to ask ... He told me that Mauro crossed your ways somehow too, but it was that abstract still, that I did not understood where the point of it should ever be and after fair and fully understandable explanations, what he has to face too, it ended up within hours then that we are all idiots ... , because I said Mauro is none. Greetings, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hg v4l-dvb broken with kernel 2.6.18.dfsg.1-13etch4 (Debian)
Am Samstag, den 20.10.2007, 00:41 +0200 schrieb hermann pitton:
Am Samstag, den 20.10.2007, 00:04 +0200 schrieb Hans-Georg Friedmann:
Hans-Georg Friedmann schrieb:
Hi folks :-)
Yesterday I upgraded the kernel of my c't-VDR 6 to 2.6.18.dfsg.1-13etch3,
then
to 2.6.18.dfsg.1-13etch4 and had the same problem with both of them when
building the latest v4l-dvb from hg.
Unfortunately I hadn't tried compiling with the before working
hg-release, so I
had quite a hard time finding the error.
The error was (compiling with linux-source-2.6.18 2.6.18.dfsg.1-13etch4
on hg
release ea93c93f1547 as of Oct 11th):
CC [M] src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.o
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c: In function
'pvr2_sysfs_add_debugifc':
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:626: warning: assignment from
incompatible pointer type
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:627: warning: assignment from
incompatible pointer type
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:630: warning: assignment from
incompatible pointer type
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c: In function
'pvr2_sysfs_class_create':
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:925: error: 'struct class' has
no member named 'dev_release'
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:930: error: 'struct class' has
no member named 'dev_uevent'
make[4]: ***
[src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.o] Error 1
[..]
The problem persisted even after deactivating pvrusb2-support and looked
like that:
make[2]: Entering directory
`src/usr_src_vdr6/linux-headers-2.6.18-5-686'
CC [M] src/dvb/v4l-dvb/v4l/videodev.o
src/dvb/v4l-dvb/v4l/videodev.c:126: error: unknown field 'dev_attrs'
specified in initializer
src/dvb/v4l-dvb/v4l/videodev.c:126: warning: initialization from
incompatible pointer type
src/dvb/v4l-dvb/v4l/videodev.c:127: error: unknown field 'dev_release'
specified in initializer
src/dvb/v4l-dvb/v4l/videodev.c:127: warning: missing braces around
initializer
src/dvb/v4l-dvb/v4l/videodev.c:127: warning: (near initialization for
'video_class.subsys')
src/dvb/v4l-dvb/v4l/videodev.c:127: warning: initialization from
incompatible pointer type
make[4]: *** [src/dvb/v4l-dvb/v4l/videodev.o]
[..]
Finally looking in the Mercurial changelog at
http://www.linuxtv.org/hg/v4l-dvb
and trying to compile different revisions I found out that revision
d54a009062d3
worked, but a3583b377d71 not anymore:
Mauro Carvalho Chehab V4L: convert struct class_device to struct
device
a3583b377d71 ## - doesn't work
Mauro Carvalho Chehab videobuf_core init always require callback
implementationd54a009062d3## - still works
An example of the problematic section in dvb/v4l-dvb/v4l/videodev.c[118]:
static struct class video_class = {
.name= VIDEO_NAME,
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,13)
.release = video_release,
#else
.dev_attrs = video_device_attrs,
.dev_release = video_release,
#endif
};
It seems for me like the new struct isn't in the debian-version of 2.6.18
yet.
But maybe the test for version 2.6.13 in the code is simply wrong and the
change
in the struct was even later? I'm not so good at kernel-level, so this is
only a
guess.
So for now I'm running on rev. d54a009062d3 (accomplished by
hg revert -r d54a009062d3).
Hi again,
[EMAIL PROTECTED] [EMAIL PROTECTED] and
[EMAIL PROTECTED] [EMAIL PROTECTED] seem to have similar problems.
I tried again with changeset 6358...
authorMike Isely [EMAIL PROTECTED]
Sun Oct 14 16:20:34 2007 -0500 (5 days ago)
changeset 6358pvrusb2: Fix broken build for 2.6.18 kernel
... and got this error, obviously coming from some earlier changeset
including
freezer.h, which isn't in 2.6.18:
CC [M] src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-ts.o
CC [M] src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-tvaudio.o
src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-tvaudio.c:30:27: error:
linux/freezer.h: No such file or directory
make[3]: ***
[src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-tvaudio.o] Error 1
make[2]: *** [_module_src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l] Error 2
make[2]: Leaving directory `src/usr_src_vdr6/linux-headers-2.6.18-5-686'
make[1]: *** [default] Fehler 2
make[1]: Leaving directory `src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l'
make: *** [all] Fehler 2
The compilation of current changeset 6383 exits with exactly the same error,
btw. Would be nice if 2.6.18 would still be supported in the hg tree since
this
still seems to be the official Kernel of Debian stable.
greetz,
hgf
We can't take much care of _official_ Debian kernels
Re: [linux-dvb] OT: Re: linuxtv.org fell in the blacklists trap
Am Mittwoch, den 31.10.2007, 02:44 +0100 schrieb thomas schorpp: Luca Olivetti wrote: En/na Jim Barber ha escrit: Sorbs will remove you from their list once you contact them and prove you have a static IP address though. Yes, they did, *twice*, since they wrongly listed my address *twice* (though I thought I already stated that) but I shouldn't go through all of this. Besides, one shouldn't have more or less rights to have an own mail server depending on the fact that the address is static or dynamic. And others blacklists don't even listen to you (and, again, even if they would, it's tiresome and shouldn't be necessary). The net result is that spammers simply hop from network to network and can send their shit with no problem, while non-spam is blocked. Good job. Bye I'm with Luca. in general blacklisting is an unprofessional, trivial security concept and completely sucks, especially sorbs: Netblock: 91.89.4.0/24 (91.89.4.0-91.89.4.255) Last Seen:Thu Feb 15 15:15:12 2007 GMT Additional Information: ad-online.biz. A 91.89.4.92 [TTL=1800] Job Scam Spammers they still block my mail server on .246 cause some spamfucks were once in my assigned netblock??? great. and blocking Luca against their own(!) whitelist policy is really scandalous. I and many people can't simply afford the horrific costs of static and NIC registered IPs. this is social discrimination of internet users and glorifying the few big mailprovider's monopoly all in the name of a protection system that has been long proven of complete failure by spamgangs. Jim, so how to prove ownership of a IP? thats actually a crap requirement, cause only the ISP can certify. NIC registry can't, too. I can register every fake data in there. spamgangs do so. CA signed server certificates can't prove ownership of an IP, too, cause I could use any proxy and fake certify ownership of its IP that way. so practically you never get delisted from sorbs, once listed. they don't do blacklisting, actually they do whitelisting in their big sponsors preferences(?) in fact. besides this is a violation of accepted civilized international law principles. pre-convicted for having done nothing. BTW law: in most countries courts take denied mails *as delivered*(!) to evidence whatever the reason for denial! so companies be very careful using blocklists... sorbs: Fighting spam by finding and listing Exploitable Servers.. real great policy. Which administrator can assure that his systems are 100% unexploitable all the time? this is pure SCI-FI and not a accepted all day practioneer's requirement. as Luca said, spam-gangs avoid it easily. Johannes, PLS use a bayesian filter / greylisting combination. or use spamhaus at least. they have a much kinder not ordinary dynamic IP internet mail user discriminating delisting policy :) with private house community wlan-routers, wifi-hotspots, inetcafes, anonymizers further upcoming, blacklisting has become complete idiocracy. sorbs go on, blacklist them all! spamgangs laugh at You. y tom I also fully agree. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] XC5000/XC3028 tuner dvb support? (an apology)
Am Mittwoch, den 24.10.2007, 10:00 -0400 schrieb James Klaas: I apologize, Markus, for making that rather rude comment. But, from a user's perspective the split between you and the rest of the v4l/dvb community is extrordinarily frustrating and my comment reflects that. I think both sides are responsible for the split to varying degrees. Your work has been invaluable to many people including myself, but I think pulling your code down so abruptly has caused a pretty big loss in goodwill and respect, even from some of your supporters. I have also become a little uneasy with some aspects of this split. It appears to my untrained eye, Markus, that you still depend quite a bit on the dvb/v4l community to provide a working structure for your code and for users to provide information on various hardware. This is not to belittle your amazing work, but it seems odd that (it appears) you depend so much on the community you've so roundly criticised. In all, it wouldn't be so frustrating for the users who depend on both projects if they got along in the kernel at the same time. Obviously, I'm not sure this is practicable, or even possible, but that would alleviate some of the tension. James On 10/24/07, Markus Rechberger [EMAIL PROTECTED] wrote: since Marcus has taken his toys and gone home so to speak if anything important is missing there let me know. several repositories have been made available before I went for a trip to sweden. Markus James, I know you as a strong GNU/Linux supporter since many years. Markus did a great job, not the slightest doubt! But to say it would have been easy somehow, maybe some other ways round, is also not true. He did run in some stuff not caused by him at all. So he decided to break out, take it over, oh well, finally needs some others still in the long run. Can't point to anyone specifically, but we can't continue to hold the v4l maintainer responsible for it. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)
Am Freitag, den 19.10.2007, 20:34 +0100 schrieb Mauro Carvalho Chehab: Wait! Please clarify whether you think that your problem is caused by the _saa7134_ driver or the _saa7146_ driver. You wrote 'that memory corruption is caused by the saa7146 driver,' Is this a typo? Did you mean saa7134? You are right my statement is wrong. To get it right, my asus has the • tda10046a • saa7131e and not the saa7146 (which my brain generated using the numbers 7131 / 10046). On saa7131 board, the memory corruptions may be caused by V4L overlay interface. On overlay mode, the driver sets the device to do a PCI2PCI memory transfer. This is known to cause troubles with some VIA and SIS motherboards. If you load saa7134 with no_overlay=1, overlay mode will be disabled. Could you please test if this solves the issue? AFAIK, some newer motherboards that had this problem can be corrected by upgrading its bios. That was what I told Soeren in the very beginning, but he does not even use any analog TV. The only case that I know of, that can cause menmory or file system corruption on that driver, is using DVB-T at once with planar video formats from other external inputs. Needs packed formats, because of some dma engines limitation here, according to Hartmut. Since we have other users of this later revision of that card, maybe not hardcored enough to run it over weeks, we should have at least one more to confirm that problem. I do not deny, that there can be an undiscovered issue. We had something similar with signal detection flaws previously on analog. Some apps did show it within 20 minutes, others only after two weeks ... Have not seen it myself until today, but was true. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hg v4l-dvb broken with kernel 2.6.18.dfsg.1-13etch4 (Debian)
Am Samstag, den 20.10.2007, 00:04 +0200 schrieb Hans-Georg Friedmann:
Hans-Georg Friedmann schrieb:
Hi folks :-)
Yesterday I upgraded the kernel of my c't-VDR 6 to 2.6.18.dfsg.1-13etch3,
then
to 2.6.18.dfsg.1-13etch4 and had the same problem with both of them when
building the latest v4l-dvb from hg.
Unfortunately I hadn't tried compiling with the before working hg-release,
so I
had quite a hard time finding the error.
The error was (compiling with linux-source-2.6.18 2.6.18.dfsg.1-13etch4 on
hg
release ea93c93f1547 as of Oct 11th):
CC [M] src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.o
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c: In function
'pvr2_sysfs_add_debugifc':
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:626: warning: assignment from
incompatible pointer type
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:627: warning: assignment from
incompatible pointer type
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:630: warning: assignment from
incompatible pointer type
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c: In function
'pvr2_sysfs_class_create':
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:925: error: 'struct class' has no
member named 'dev_release'
src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.c:930: error: 'struct class' has no
member named 'dev_uevent'
make[4]: ***
[src/dvb/v4l-dvb_test/v4l/pvrusb2-sysfs.o] Error 1
[..]
The problem persisted even after deactivating pvrusb2-support and looked
like that:
make[2]: Entering directory
`src/usr_src_vdr6/linux-headers-2.6.18-5-686'
CC [M] src/dvb/v4l-dvb/v4l/videodev.o
src/dvb/v4l-dvb/v4l/videodev.c:126: error: unknown field 'dev_attrs'
specified in initializer
src/dvb/v4l-dvb/v4l/videodev.c:126: warning: initialization from
incompatible pointer type
src/dvb/v4l-dvb/v4l/videodev.c:127: error: unknown field 'dev_release'
specified in initializer
src/dvb/v4l-dvb/v4l/videodev.c:127: warning: missing braces around
initializer
src/dvb/v4l-dvb/v4l/videodev.c:127: warning: (near initialization for
'video_class.subsys')
src/dvb/v4l-dvb/v4l/videodev.c:127: warning: initialization from
incompatible pointer type
make[4]: *** [src/dvb/v4l-dvb/v4l/videodev.o]
[..]
Finally looking in the Mercurial changelog at
http://www.linuxtv.org/hg/v4l-dvb
and trying to compile different revisions I found out that revision
d54a009062d3
worked, but a3583b377d71 not anymore:
Mauro Carvalho Chehab V4L: convert struct class_device to struct
device
a3583b377d71## - doesn't work
Mauro Carvalho Chehab videobuf_core init always require callback
implementation d54a009062d3## - still works
An example of the problematic section in dvb/v4l-dvb/v4l/videodev.c[118]:
static struct class video_class = {
.name= VIDEO_NAME,
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,13)
.release = video_release,
#else
.dev_attrs = video_device_attrs,
.dev_release = video_release,
#endif
};
It seems for me like the new struct isn't in the debian-version of 2.6.18
yet.
But maybe the test for version 2.6.13 in the code is simply wrong and the
change
in the struct was even later? I'm not so good at kernel-level, so this is
only a
guess.
So for now I'm running on rev. d54a009062d3 (accomplished by
hg revert -r d54a009062d3).
Hi again,
[EMAIL PROTECTED] [EMAIL PROTECTED] and
[EMAIL PROTECTED] [EMAIL PROTECTED] seem to have similar problems.
I tried again with changeset 6358...
author Mike Isely [EMAIL PROTECTED]
Sun Oct 14 16:20:34 2007 -0500 (5 days ago)
changeset 6358 pvrusb2: Fix broken build for 2.6.18 kernel
... and got this error, obviously coming from some earlier changeset including
freezer.h, which isn't in 2.6.18:
CC [M] src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-ts.o
CC [M] src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-tvaudio.o
src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-tvaudio.c:30:27: error:
linux/freezer.h: No such file or directory
make[3]: *** [src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l/saa7134-tvaudio.o]
Error 1
make[2]: *** [_module_src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l] Error 2
make[2]: Leaving directory `src/usr_src_vdr6/linux-headers-2.6.18-5-686'
make[1]: *** [default] Fehler 2
make[1]: Leaving directory `src/dvb/v4l-dvb_test_2.6.18_fix/v4l-dvb/v4l'
make: *** [all] Fehler 2
The compilation of current changeset 6383 exits with exactly the same error,
btw. Would be nice if 2.6.18 would still be supported in the hg tree since
this
still seems to be the official Kernel of Debian stable.
greetz,
hgf
We can't take much care of _official_ Debian kernels :)
But the problem is at least known.
Cheers,
Hermann
___
linux-dvb mailing list
linux-dvb@linuxtv.org
Re: [linux-dvb] Strage SkyStar HD modprobe
Am Samstag, den 20.10.2007, 00:11 +0200 schrieb Reinhard Nissl: Hi, Manu Abraham schrieb: Can someone verify whether the STB6100 has component values as in this image ? http://abraham.manu.googlepages.com/snapshot9.png in the problematic case ? Am I right that these components are covered by the metal housing near the F connector, so it needs to be removed to have a look at them? Reinhard, did not follow this closely, but if you need to remove that shielding, likely the welding stuff used was prepared for higher temperatures, than for the SMD components for sure close around it. To avoid to get too high temperature, and likely other SMD stuff gets unsoldered during that, I recommend to carefully fix the card and use some also fixed mechanical toy to remove the shielding. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)
Am Mittwoch, den 17.10.2007, 02:34 +0200 schrieb Oliver Endriss: Soeren Sonnenburg wrote: On Sun, 2007-10-14 at 19:47 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: I am unfortunately 100% sure that it is caused by the saa7146 driver, as I have an uptime of over a week now that it is not loaded (but the card is still in the slot, yeah and I did memory tests for 18 passes - nothing). Could you please try the patch posted in http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html and report whether it fixes your problem? Hmmhh, reading what it changes Two fixes for the 'saa7146_wait_for_debi_done' code: (a) Timeout did not work when the routine was called with interrupts disabled. (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done. Seems to be very important on fast machines! I am not sure why this could fix the problems I am seeing. I can give it a try if you are quite confident that it could help High load on the PCI bus might trigger a bug somewhere else. Btw, I'm not aware of any reports that the saa7146 driver caused memory corruption or something like that. Well it could be a bug in the asus p7131 firmware and the card just randomly doing weird things... and if this can be seen only after a few days of vdr/continuous use not many people may be affected and you may just not get reports. , but I get - gcc compile failures - filesystem corruptions - database corruptions Hm. Very often these symptoms are caused by broken hardware. I know. But as this machine has uptimes of months without this card (even with several pci slots in use and worked for long long times with very different cards in these slots) and it does not work when I just use the card instead of a win-tv or so I am sure that it is the the asus card which is not working correctly. Anyway I am now replacing that card with a tt-1500-t lets see whether strange things will happen or not. when the card's driver is loaded and is in use for a few days (and then finally a hang/crash+reboot). I have the *feeling* that the situation improved slightly by improving reception via F-connectors, so I thing there is some kind of buffer overflow or so occurring... Anyway thanks for your work, I will happily try it if you think it may fix this problem. I would try. ;-) Well :-) If the tt-1500 turns out to work OK I can just once give the asus + your isolated patch a last chance before trashing it... Wait! Please clarify whether you think that your problem is caused by the _saa7134_ driver or the _saa7146_ driver. You wrote 'that memory corruption is caused by the saa7146 driver,' Is this a typo? Did you mean saa7134? (My patch is pointless if you do not run a saa7146-based card.) As I understand he has both. Single work each, but not together and in that case always the saa713x is the culprit. Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [saa7134] Fwd: [PATCH] Spezial Lifeview DVB-S Card without eeprom
Am Mittwoch, den 17.10.2007, 02:50 +0200 schrieb Oliver Endriss: Hi, since there was no reply on the DVB ML: Is anyone maintaining the DVB part of the saa7134 driver? Can this patch be accepted? CU Oliver Oliver, de facto there is no saa713x maintainer anymore since half a year. We all hope Hartmut will find some time to come back, especially for the DVB part. Some sort of joke, but Ralph's code for the analog part ;) Reviewed-by Hermann Pitton [EMAIL PROTECTED] If Ralph wants to have it in, maybe Mike can have a look for the inittab stuff there after latest tuner conversions, else as always, there most likely is nothing wrong ... Cheers, Hermann -- Forwarded Message -- Subject: [linux-dvb] [PATCH] Spezial Lifeview DVB-S Card without eeprom Date: Sunday 14 October 2007 22:12 From: Martin Dauskardt [EMAIL PROTECTED] To: linux-dvb@linuxtv.org The patch has already been posted in May by Michael Möhle without getting attention: http://linuxtv.org/pipermail/linux-dvb/2007-May/018007.html Several users in the german vdrportal forum use this card, therefore the patch is included in my LinVDR kernel package since months. To patch should really be included into the hg. I attach a diff against hg from today. It is still the same patch originally written by Ralph Metzler. Greets, Martin Dauskardt --- ___ 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] Tuner not detected on second Kworld card
Am Sonntag, den 14.10.2007, 15:34 -0400 schrieb CityK: David Engel wrote: The minor problem I mentioned earlier has to do with using the saa7134-alsa module to capture sound directly from the card. A quick glance at the driver source code looks like it shold support 32 and 48 kHz sampling rates. I've only been able to get 32 kHz working well so far with MythTV. Trying 48 kHz results in some sort of rate mismatch. Is 48 kHz supposed to work? ... I tried using mplayer with 48 kHz audio and got the same results. Regardless of the requested audio rate, the cx88-alsa driver or hardware only supplies 32 kHz audio. The result is audio underruns and chipmunk audio because the samples that are received are being played too fast. Can anyone confirm the Kworld card can only do 32 kHz? I could have sworn I just wrote about this -- email? wiki? But alas, I can't find a thing. In any regard ... Yes, you can only use 32KHz from the tuner with the saa713x. This is a hardware limitation of the chip in regards to handling of SIF sources. For further information, search through the V4L achieves using various saa7134 or saa713x and 32KHz and alsa combinations. There should be plenty of good info. (Example: http://marc.info/?l=linux-videow=2r=1s=32KHz+saa7134q=b) However, that said, I'm just thinking aloud here about this case, as this actually presents a curious question. Here goes: The NIM on these boards (TUV1236D) contains a TDA9887, which is capable of SIF demodulation, and hence, if utilised, would be feeding the saa713x a baseband audio signal for ADC. Yet, given that in field testing shows the 32KHz limitation, it would seem to indicate that the SIF capability of the TDA9887 is being ignored and that, instead, the broadcast audio is being sent straight to the saa713x for processing (ie. tuner - saa713x for SIF demod then ADC). I'm wondering if this is a case of: (1) hard wiring from the TUV1236D module (broadcast audio output) to the saa713x or (2) if there exist alternate pathways/routes in the TUV1236D for the audio signal i.e.: (i) tuner - TDA9887 for SIF demodulation - baseband audio to saa713x for ADC (ii) tuner - saa713x for SIF demod then ADC If it is a case of 2), then it is obvious that the later route (ii) is being utilized ... and, if it is a case of 2), then the obvious follow up question is: How do you enable the more desirable pathway (i) ? ... i.e. make use of the TDA9887 for SIF demodulation and feed the resultant baseband signal to the saa713x, which, consequently, would allow for the selection of sampling rates other then 32KHz during the ADC phase. Limitation is, that there is no direct stereo TV sound output from those tuners. The saa7130 chip uses always baseband audio from the tuner and has no audio ADCs. That,s why no dma sound is supported and always a loopthrough connection to the sound card is needed and why it has only mono TV sound. Radio and other analog inputs can be stereo. DVB just gets pumped through the TS interface and the dma engines. The saa7134 chip has no stereo audio support for System M and the saa7133 has no support for dual FM (A2) stereo. Currently only saa7135 and saa7131e support all kind of TV sound. The two others could utilize additional SIF/MPX sound decoding chips, then your scenario would become true. Suggested as a solution in such case, but not yet seen. How to make use of which audio coming from the tuner also depends of the audio system in use. For example think about mono on the first sound carrier and NICAM on the second. You will need the saa713x NICAM decoder to get stereo sound. On the Philips MultiEurope MK3s with tda9887 only radio comes stereo separated by the tda7040 to either the LINE1 or LINE2 pair of analog inputs. If switched back to TV mode, you get from those two lines equal TV mono audio, also about 6 db lower as otherwise, IIRC. Some cards still use a TV mono section with vmux TV and same amux than used for radio exactly for that reason, as workaround for having problems with stereo sound in the beginnings. That is also what you see on the saa7130 chips. If needed, we might continue on the video4linux-list ... The other issue sounds a bit weired or my poor English fails. Multiple identical cards should be auto detected like they are found walking down the PCI devices and lining up minors. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] false accusations - was Re: Future of Multiproto
Hi, Am Freitag, den 12.10.2007, 03:07 +0400 schrieb Manu Abraham: Hi Hartmut, Hartmut Hackmann wrote: Hi, Manu Manu Abraham schrieb: Hi Hartmut, I do know you are busy, but i would like to have a small clarification, which thus will help in clearing of some false accusations put up on me. If i am the cause of your disappearance, i do apologize for the same. hermann pitton wrote: Example 3. You claimed to have all NDAs/docs to provide support for recent NXP/Philips stuff and since then our second saa7134 maintainer was not seen anymore. He did a lot! Is it anyway related, that what's stated above is true with regards to the SAA716x linux driver/support and your disappearance ? Thanks, Manu Definitely not. Thanks for the clarification. I did not disappear completely, i still try to read the list. But for personal reasons, i am currently not able to do a significant amount of work. Regarding SAA716x: Some aspects of this chip are very difficult to handle and up to now, i was not able to help Manu a lot. Tracy said she will help what she can, she said is working on it as well and can provide whatever help she can. It was a bit of struggle, but got it going finally. But still it looks a bit hard nut to crack. I must appreciate the help what you put into it. Thanks for that. If there is something you urgently need my help with: may i ask you or Hermann to point me explictly to it? Never mind. Nothing pretty much. Sorry to have woken you up. Manu, sorry and please excuse for that one. Simply tried to find out, what might have happened and suspected there might have been a change in direction to open source during the transition from Philips to NXP and your mew NDAs might be related. We might try to continue as good we can for now until Hartmut has more time again. Thanks, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)
Hi, Am Freitag, den 12.10.2007, 02:24 +0200 schrieb Oliver Endriss: Soeren Sonnenburg wrote: I am unfortunately 100% sure that it is caused by the saa7146 driver, as I have an uptime of over a week now that it is not loaded (but the card is still in the slot, yeah and I did memory tests for 18 passes - nothing). Could you please try the patch posted in http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html and report whether it fixes your problem? CU Oliver Mauro also discovered a problem with SMP machines and the saa7134 driver i did never hit on UP stuff. Soeren, in case of dual processors or hyperthreading you might try what Mauro used to come around it, not sure if it is in latest v4l-dvb. Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Am Mittwoch, den 10.10.2007, 23:44 +0400 schrieb Manu Abraham: Steven Toth wrote: If there is a defined workflow, this moaning will stop. With the moaning on there will be problems and blindly writing mails based on that, just adds in to the problems at large. Thanks for the feedback. I had some difficulties understanding parts of your email, so I may come back to those pieces later today. One thing that was obvious... I don't understand what you mean about workflow, or why it's a problem, or why defining the workflow will help you, or resolve your concerns/frustrations. Clearly you are referring to how we collect and manage trees under linuxtv.org, but you haven't suggested an alternative method. I did. Maybe you missed it, anyway that is not significant. Will readdress it in a more clear manner Two questions: How do you suggest improve 'workflow'? Let me tell you how problems arise. @ the problem User sends a patch the person who was write access to linuxtv.org/hg/v4l-dvb, takes the patch and applies it. (Please note, this is not personal, this issue results for anyone doing the same job) Now the person who has write access is neither the author/maintainer of the driver/code and has little clue. (it is the nature of any human being), he thinks that i have been doing this, who are you to tell me. In either case whether the patch is good or bad (not talking about the quality of the patch, but that which results in the unnecessary discussions and or talks) Now the actual author/maintainer has issues with the patch whatever it is. Now the argument goes on for a while. In most cases the person who has write access to the repository get's it right (since others tend to shy away for some reason) This is a bad situation where the people who do the real work in fact do get demoralized, also not to mention the long unnecessary discussions. That is the bad side of things and this is what exactly what we are facing Situations like this can be avoided. There is more than one possible way, but there are two possible ways this can work @ Improving the situation Say whoever maintains some code he can be called the maintainer for the same. Well this shouldn't be verbal, as this has proved many times that what's considered verbal, behind the back there are many discussions and we have seen practically how this works. So there needs to be well defined who maintains what, and mainline kernel folks also need to know about it, lest someone should have a doubt and the problematic case is revisited. i would suggest it the same place where the rest of the kernel goes, we shouldn't be doing things in a different way (doing things different attracts different problems from the kernel style development methods, then the situation is different) That said about the thought. Practically it might look like this 1) a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies the (modified or unmodified) patch to the tree (this assumes that the maintainers do have write access to the project base tree) d) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree 2) steps a - b are the same a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies it to the tree that which is meant specific for the code/module that which the patch is sent for. d) he asks whoever is sending patches to apply changes from this tree to the project base tree e) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree The application of changes from the base tree to the patches sent to Linus must be atomic. ie , there shouldn't be any shady deals in between. (The reason being the condition of cherrypicking also doesn't come into the picture as the changes have already been discussed/acknowledged, otherwise it wouldn't exist in that tree in the first place) Now, in either of these cases there will be common code NOTE! * In the case of the common code, the relevant maintainers all must agree for that specific change, without which it might be hard to have that change in. There is one significant advantage to this method, this
Re: [linux-dvb] [RFC-final] videobuf tree
Am Sonntag, den 07.10.2007, 14:03 -0700 schrieb Trent Piepho:
On Sun, 7 Oct 2007, Mauro Carvalho Chehab wrote:
I took a look at cx23885 code. It seems that there's a serious error on
the way you're using cx23885_buffer there:
cx23885-dvb.c: return cx23885_buf_prepare(q, port, (struct
cx23885_buffer*)vb, field);
cx23885-dvb.c: cx23885_buf_queue(port, (struct cx23885_buffer*)vb);
cx23885-dvb.c: cx23885_free_buffer(q, (struct cx23885_buffer*)vb);
It seems that you are forcing videobuf_buffer to be cx23885_buffer. This
is not right!
This is what is defined on cx23885.h:
struct cx23885_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
I'm not sure that it is competely wrong. Say one has a cx23885_buffer that
contains a videobuf_buffer. Now suppose you have a pointer to the
videobuf_buffer, and you want to get a pointer to the cx23885_buffer that
contains it. What you should write is:
struct videobuf_buffer *vb = ...;
struct cx23885_buffer *buf = container_of(vb, struct cx23885_buffer, vb);
But since vb is the first field of the cx23885_buffer struct, the container_of
will turn into just '(struct cx23885_buffer *)(vb)'
This code in videobuf-dma-sg.c looks odd to me:
/* Allocated area consists on 3 parts:
struct video_buffer
struct driver_buffer (cx88_buffer, saa7134_buf, ...)
struct videobuf_pci_sg_memory
static void *__videobuf_alloc(size_t size)
{
struct videbuf_pci_sg_memory *mem;
struct videobuf_buffer *vb;
vb = kzalloc(size+sizeof(*mem),GFP_KERNEL);
mem = vb-priv = ((char *)vb)+size;
What is 'size', is that the size of the driver buffer? Shouldn't you be
allocating size + sizeof(*vb) + sizeof(*mem)?
Is there documentation for videobuf anywhere? It doesn't look like any of
the videobuf functions have descriptions of that they do or what the
parameters are.
As far as I know, there is no further documentation, except the little
what is on the list.
It is work done by Gerd, and we almost always had fun.
Hermann
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Medion Quad(ro) - first tries on DVB-S
Folks,
since yesterday I got my dirty ;) fingers on a used double saa7131e
Medion Quadro and got it up for the first PCI bridge in an MSI orange
PCI slot on some nforce3 AMD stuff.
Analog TV, noticeable worse than on my prior Asus P7131e Dual, works.
DVB-T too, also with significant loss compared to the Asus.
One can enable _some sort_ of radio, but obviously the 5.5MHz filter is
missing to get it through sound IF processing on the saa7131e.
All three known LNA configs don't improve any reception.
Now, the hybrid analog/DVB-T tda8275a tuner at 0x60 is behind the bridge
of the tda8290 analog IF demodulator, which is at 0x96 within the
saa7131e on that device(s).
I'm currently using the attached patch, since tests revealed, that the
DVB-S driver can't find anything, except on 0x60 too, for the tda826x
behind the i2c bridge of the tda10086.
I don't have _any_ DVB-S equipment, nada, also far away from caring
about any diseqc stuff right now.
The card should be able to support analog TV and DVB-S at once.
Of course DVB-T and DVB-S can only be used at once on either of the two
PCI bridges, have only one visible ...
The following happens.
DVB-S seems to be fine.
If I start an analog TV app like xawtv-3.95, I can switch analog
channels during szap is running. With szap I also seem to be able to
change DVB-S to anything at the same time.
If I quit xawtv analog during szap is running and restart it then, the
tda8290 and tda8275a get doomed/lost and only a cold reboot brings them
back.
On tvtime, even only analog channel changes have the same result within
short time, also the picture is affected on every refresh of szap.
Without any sat equipment, what is going on and why no errors
previously ...
Cheers,
Hermann
xawtv analog restart during szap running and tvtime switching channels
then also attached.
diff -r b0a3a9b43d60 linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Wed Oct 03 11:23:01 2007 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Wed Oct 03 19:32:06 2007 +0200
@@ -973,7 +973,21 @@ static int dvb_init(struct saa7134_dev *
configure_tda827x_fe(dev, tevion_dvbt220rf_config);
break;
case SAA7134_BOARD_MEDION_MD8800_QUADRO:
- configure_tda827x_fe(dev, md8800_dvbt_config);
+ if(! use_frontend) { //terrestrial
+ configure_tda827x_fe(dev, md8800_dvbt_config);
+ } else { //satellite
+ dev-dvb.frontend = dvb_attach(tda10086_attach, flydvbs, dev-i2c_adap);
+ if (dev-dvb.frontend) {
+if (dvb_attach(tda826x_attach, dev-dvb.frontend, 0x60,
+ dev-i2c_adap, 0) == NULL) {
+ wprintk(%s: Medion Quadro, No tda826x found!\n, __FUNCTION__);
+}
+if (dvb_attach(isl6421_attach, dev-dvb.frontend, dev-i2c_adap,
+ 0x08, 0, 0) == NULL) {
+ wprintk(%s: Medion Quadro, No ISL6421 found!\n, __FUNCTION__);
+}
+ }
+ }
break;
case SAA7134_BOARD_AVERMEDIA_AVERTVHD_A180:
dev-dvb.frontend = dvb_attach(nxt200x_attach, avertvhda180,
binclHp5EqZgF.bin
Description: application/compressed-tar
binbdeNDGebuJ.bin
Description: application/compressed-tar
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] compiling is broken
Am Mittwoch, den 03.10.2007, 22:59 +0200 schrieb e9hack: Hi, this changset: Fix Kconfig dependency authorMauro Carvalho Chehab [EMAIL PROTECTED] Tue Oct 02 11:16:16 2007 -0300 (30 hours ago) changeset 626048badb1df2ed manifest 48badb1df2ed parent 6259 6129aac33d3e child 62618e7bc314eb82 Fix Kconfig dependency breaks compiling. I get the following error: make -C /lib/modules/2.6.23-rc8-up-64-test/build SUBDIRS=/usr/src/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-2.6.23-rc8' CC [M] /usr/src/v4l-dvb/v4l/saa7134-dvb.o /usr/src/v4l-dvb/v4l/saa7134-dvb.c: In function 'philips_europa_demod_sleep': /usr/src/v4l-dvb/v4l/saa7134-dvb.c:415: error: 'struct saa7134_dev' has no member named 'original_demod_sleep' /usr/src/v4l-dvb/v4l/saa7134-dvb.c:416: error: 'struct saa7134_dev' has no member named 'original_demod_sleep' /usr/src/v4l-dvb/v4l/saa7134-dvb.c: In function 'configure_tda827x_fe': /usr/src/v4l-dvb/v4l/saa7134-dvb.c:557: error: 'struct saa7134_dev' has no member named 'dvb' ... make[3]: *** [/usr/src/v4l-dvb/v4l/saa7134-dvb.o] Error 1 make[2]: *** [_module_/usr/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.23-rc8' make[1]: *** [default] Fehler 2 make[1]: Leaving directory `/usr/src/v4l-dvb/v4l' make: *** [all] Fehler 2 - Hartmut What a sad story. ;) Any fixes? Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] compiling is broken
Am Donnerstag, den 04.10.2007, 03:16 +0200 schrieb hermann pitton: Am Mittwoch, den 03.10.2007, 22:59 +0200 schrieb e9hack: Hi, this changset: Fix Kconfig dependency author Mauro Carvalho Chehab [EMAIL PROTECTED] Tue Oct 02 11:16:16 2007 -0300 (30 hours ago) changeset 6260 48badb1df2ed manifest48badb1df2ed parent 6259 6129aac33d3e child 6261 8e7bc314eb82 Fix Kconfig dependency breaks compiling. I get the following error: make -C /lib/modules/2.6.23-rc8-up-64-test/build SUBDIRS=/usr/src/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-2.6.23-rc8' CC [M] /usr/src/v4l-dvb/v4l/saa7134-dvb.o /usr/src/v4l-dvb/v4l/saa7134-dvb.c: In function 'philips_europa_demod_sleep': /usr/src/v4l-dvb/v4l/saa7134-dvb.c:415: error: 'struct saa7134_dev' has no member named 'original_demod_sleep' /usr/src/v4l-dvb/v4l/saa7134-dvb.c:416: error: 'struct saa7134_dev' has no member named 'original_demod_sleep' /usr/src/v4l-dvb/v4l/saa7134-dvb.c: In function 'configure_tda827x_fe': /usr/src/v4l-dvb/v4l/saa7134-dvb.c:557: error: 'struct saa7134_dev' has no member named 'dvb' ... make[3]: *** [/usr/src/v4l-dvb/v4l/saa7134-dvb.o] Error 1 make[2]: *** [_module_/usr/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.23-rc8' make[1]: *** [default] Fehler 2 make[1]: Leaving directory `/usr/src/v4l-dvb/v4l' make: *** [all] Fehler 2 - Hartmut What a sad story. ;) Any fixes? without jokes now, the _current_ v4l-dvb master repo builds without problems here. 2.6.23-rc6-git3 #1 PREEMPT Fri Sep 14 20:44:27 CEST 2007 i686 athlon i386 GNU/Linux gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13) Can't be much left in between. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] video-buf redesign
Hi, Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb [EMAIL PROTECTED]: Mauro Carvalho Chehab wrote: Unfortunately, I see the same broken behavior in the videobuf tree and the tm6000-new tree. Only the master branch v4l-dvb tree is functioning properly. Unfortunately, there's nothing I can do without the logs. So, _please_ send the logs also. Every test I did here (and also Hermann reports) didn't produce the issues you're showing. All I get here is clean mpeg streams, with videobuf-dvb and cx88-dvb. There is, however, a known issue with IRQ and SMP machines that might be influencing. So, I need you to do also cat /proc/cpuinfo. If the machine you're using to test has more than one CPU core, you may also need to run irqbalance. Another valuable test would be to disable the second core, and see what's happening. I also conducted the tests only on UP machines on the saa7134 driver. Mauro, It is a dual-core CPU. This should be irrelevant to the issue, since multi-core CPU's have no problem when using the videobuf code in the master branch -- why would your new videobuf code be dependent on a single core when the original videobuf code was not? I had previously sent you logs of this problem while using read() , but you said this was not good enough -- You told me that the logs did not indicate any errors. The only way to test this without using read() would be to use xawtv4, which I am not able to build on my Ubuntu Feisty system. Otherwise, I could try to test by installing mythtv-backend, but that will take a lot of time to setup -- I'll be happy to do it after I've settled in the new apartment, if need be. I understand that neither you nor Hermann were able to reproduce this problem, but I assure you, this is indeed a regression, and it's a show-stopper for 2.6.24 -- it absolutely must be fixed prior to a merge. Yes, I agree then. We should be careful with this small testing base we have and Mike obviously noticed issues. I will not be able to conduct any more tests until after I unpack into my new apartment (next week) -- I will take down this test machine tonight and pack it up in boxes. If you still would like to see logs while using read() , then I can do this tonight before I pack up the test machine. If you want these logs, please let me know asap. Unfortunately I have not even a DVB-T card currently ... The Medion Quad I ordered isn't here yet, also unsure if I can get DVB-T running on it, don't have the original green PCI Slot for it. Else I considered to get the Asus P7131 Hybrid LNA, since Soeren still reports issues on it, also memory corruption with the old stuff. http://linuxtv.org/pipermail/linux-dvb/2007-September/020748.html This is still the only such report within the last two years. The only case I know from Hartmut that this could happen, also tested myself, is if someone uses DVB-T and anlog video at once from external inputs with planar formats, like mplayer/mencoder does by default and not packed formats as advised in such case. Why this happens on his machine with VDR and an additional saa7146 device, I still don't know. We have also no reports for the new video_buf design from saa7146 users. Just installed the tm6000-new tree on two machines again and xawtv4 seems to be fine on both, UP, no DVB-T currently, no HD streams. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Freecom rev 4 DVB-T USB 2.0 tuner usb id 14aa:0160
Am Donnerstag, den 20.09.2007, 11:08 +0200 schrieb [EMAIL PROTECTED]: Hi linuxtv.org, Mr. Kleiminger wrote in the linux-dvb mailinglist (found in September 2007 Archives) that he is interested in the progress of the driver development of the Freecom dvb-t stick rev.4 (id 14aa:0160). I own the same model. I had a Freecom dvb-t stick rev.3 (USB ID (before firmware): 14aa:0225) till yesterday. Now it's defective and yesterday I went to Conrad Electronics Megastore in Graz/Austria and they made a rma and gave me a new one - rev.4 . As you write there is no driver yet available and I can't watch tv :o( . I want to know, if there is a schedule for developing a driver. Can I help? I'm UNIX/LINUX Sysadmin, wrote some c++ programs (must say it was in the windows world, but that doesn't matter (o:) and am really interested in hardware. Maybe I can help with testing or possibly some minor development. I already used mercurial for compiling the modules for my kernel. cheers, Holger Fischer Hi Holger, is it that one? http://www1.conrad.de/scripts/wgate/zcop_b2c/?~template=pcat_product_details_documentobject_guid=F884D044998C7F45E1000A010220master_guid=master_typ=no_brotkrumennavi=ownrow=6p_load_area=0417021p_artikelbilder_mode=Einp_sortopt=object_descriptionpage=1p_catalog_max_results=20cachedetail= And if you download the datasheet from there on page 2 it says Art.No.EU 27442 ? Mauro is currently in Germany for work, not GNU/Linux related, and I know every free minutes, he hardly has some, he is working on a driver and got PAL-BG working now too, seems there are some issues with the buffering left, but good progress so far. It is _assumed_ that this device can be supported by that driver too. When he is back in Brazil, he probably will enjoy to have further feedback from PAL testers. You might have a first try with card=6 ... http://linuxtv.org/hg/~mchehab/tm6000-new Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Missing channels on FlyDVB-S LR300 (saa7134-dvb)
Am Donnerstag, den 20.09.2007, 14:51 +0200 schrieb Héctor Cordobés: On Thu, 20 Sep 2007 12:04:50 +0100, James Le Cuirot [EMAIL PROTECTED] wrote: I'm afraid I haven't had any luck. I filed a bug but the only response I've had didn't help. http://bugzilla.kernel.org/show_bug.cgi?id=8824 I've just seen this and I think it's worth a try. I am not sure if it's going to make any difference as I am using a community installation and I don't see why should I bother for current limits, but definitely I'll give it a try: http://www.linuxtv.org/pipermail/linux-dvb/2006-November/014567.html Regards, --Héctor Hi, if the chips are unchanged, that I don't know, at least I had a report from a guy with a FlyDVB Trio cardbus recently and the same ISL, tuner and channeldecoder and he seemed to fine with it after applying a diseqc patch for the tda10086 submitted to the list over Hartmut. http://www.linuxtv.org/pipermail/linux-dvb/2007-July/019307.html Patch is here. http://www.linuxtv.org/pipermail/linux-dvb/2007-June/018741.html Good luck, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Missing channels on FlyDVB-S LR300 (saa7134-dvb)
Am Donnerstag, den 20.09.2007, 10:13 -0400 schrieb CityK: hermann pitton wrote: Philips semiconductors is outsourced to NXP Philips semiconductors does not exist any more. Philips sold the controlling interest in its subsidiary to a private equity group. The new semiconductor company is now known as NXP. A noteworthy point is that Philips retained a large stake in NXP, which is perhaps reflected in the founded by Philips portion of NXP 's logo: http://www.nxp.com So, saying Philips semiconductors is outsourced to NXP is technically incorrect. Yet, at the same time, there is large element of truth in Hermann's comment. To make it short, likely no time soon again. I don't know what happened to Philips semiconductors Hamburg Germany, from where we got all the support from Hartmut there in his free time. I totally underestimated, what he still has to hack to provide that all for us, but I now have a better picture. Then Manu announced, please don't take it as an attack or something in that direction, that he has all NDAs for the recent PCIe bridges with dual/quadro multiple/mixed frontend support. Might not yet have been sufficient enough. We have our own analog experiences too. We know what it means to get the right datasheet! And struggled for years for example on the tda9887 and related. If you have it once, it is nothing anymore, and you have tears in your eyes for all the pain you had ... Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Am Mittwoch, den 19.09.2007, 10:24 +0200 schrieb Markus Rechberger: On 9/19/07, hermann pitton [EMAIL PROTECTED] wrote: Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu: Mauro Carvalho Chehab wrote: I'm just interested on see things moving forward. Please stop with your flame wars. If you are not interested on serious discussions, you shouldn't have started the thread. (bla, bla, bla) If you can't technically argue about DVB API, but just want to play politics, you don't deserve any attention on that thread. Missing context: You don't have to try for that. See the userspace thread as well, where you were misappropriating credits. So my case was not an isolated case. My, my, you and Markus would have exactly _nothing_ without the prior work done by others. If you don't feel referenced enough by some lines from you currently, likely only by running on NDAs first, just make it clear and you get _your_ credit! there should be another thread called Ongoing internal flamewars and the first line of that mail should be idiots who cannot work together and disagree whenever it's possible. Markus If it would be such simple, it would be still reasonable. Unfortunately Manu behaves much worse behind the lines on private notes he is sending around. When you try to calm him down, and don't agree with him, he becomes really dirty. I don't know to what extend he does it ... If there is anything left with code not fairly honored, just point to it, that Mauro can get it in the desired shape. For all my experience, he will always try do that. Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Missing channels on FlyDVB-S LR300 (saa7134-dvb)
Am Donnerstag, den 20.09.2007, 03:09 +0200 schrieb Héctor: Hi there. I bought a FlyDVB-S LR300 a few weeks ago. I set it up for use with MythTV but I have been unable to get more than a few channels and the ones I can get are pretty bad. No BBC besides radio. No ITV. No Film4. The only remotely interesting one is Sky News UK. Hi, I have seen the same results on mine (LR300 with silicon tuner). If you have managed to make it work, please advice (thanks!, I have made a search on the list and I have not seen any result about this issue). If not, I can add some more info to the description. First of all, I have a working and tested installation from the LNB to the F-connector just up to the card. It is an universal LNB, although I only use the Lo-Band, V pol. With the card I can tune 11038MHz (badly), 10979MHz (fine), 11156MHz (fine), but not 11097MHz, 10876MHz, 10818, 10778... There is some overlap, although the cutting frequency should be arounf 11700MHz. With the original Windows drivers, the provided version did not work (same failures!). But the updated version does work! So it seems that they had to make an update on the sw for some component or something like that. Nevertheless, I have tried both latest stable version from linuxtv (in July), and vanilla 2.6.21-5 drivers, with same failing results. So, if this clarifies the landscape, fine. If you feel like you need more info or some tests, please advice. Thanks, and regards, --Héctor Hi, Philips semiconductors is outsourced to NXP, and the only contacts we had so far came from some guys in India. To be honest, I didn't had the impression that they already know on what they are sitting now. Happy camping, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu: Mauro Carvalho Chehab wrote: I'm just interested on see things moving forward. Please stop with your flame wars. If you are not interested on serious discussions, you shouldn't have started the thread. (bla, bla, bla) If you can't technically argue about DVB API, but just want to play politics, you don't deserve any attention on that thread. Missing context: You don't have to try for that. See the userspace thread as well, where you were misappropriating credits. So my case was not an isolated case. My, my, you and Markus would have exactly _nothing_ without the prior work done by others. If you don't feel referenced enough by some lines from you currently, likely only by running on NDAs first, just make it clear and you get _your_ credit! Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
