Re: [linux-dvb] dtt200u crashing with smp
Hi, do you use the drivers which are included in the kernel or did you use the latest sources from linuxtv.org? Markus On 5/12/07, ben handley [EMAIL PROTECTED] wrote: Hi, I have a freecom usb dvt-t device, which works fine with a non-smp kernel (using the dvb-usb-dtt200u driver). But with an smp kernel, on my dual core athlon cpu (i386 mode, haven't tried a 64 bit install yet), I get frequent problems. Usually I just lose all reception, and can only get it back by rebooting. Sometimes stranger things happen, like the keyboard stopping working. The problems only ever occur while using the device. Is the dvb-usb-dtt200u driver known to not be smp safe? Here's a sample of what tends to get dumped to the console around the time things go wrong. Anythink else I can provide to help diagnose? Thanks a lot, Ben dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully deinitialized and disconnected. BUG: unable to handle kernel paging request at virtual address f8a580c0 printing eip: f8a580c0 *pde = 02912067 *pte = Oops: [#1] SMP Modules linked in: usbhid dvb_usb dvb_core firmware_class dvb_pll i2c_core radeon drm snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep usblp 8139too amd64_agp agpgart snd bitrev crc32 CPU:0 EIP:0060:[f8a580c0]Not tainted VLI EFLAGS: 00010246 (2.6.20.4.noold #1) EIP is at 0xf8a580c0 eax: ea6ae000 ebx: ea6ae000 ecx: c294df48 edx: c294df4c esi: c28eb380 edi: ea6af00c ebp: 0292 esp: c294df40 ds: 007b es: 007b ss: 0068 Process events/0 (pid: 6, ti=c294c000 task=c292ea70 task.ti=c294c000) Stack: f8a52738 c28125a0 c2813160 ea6af010 c012fb2c c28eb394 c294df9c c28125e8 c28eb38c c28eb3a0 f8a52710 c28eb380 c28eb38c c28eb394 c294df9c c012fd9f 0001 0001 Call Trace: [f8a52738] dvb_usb_read_remote_control+0x28/0xe0 [dvb_usb] [c012fb2c] run_workqueue+0x7c/0x150 [f8a52710] dvb_usb_read_remote_control+0x0/0xe0 [dvb_usb] [c012fd9f] worker_thread+0xff/0x160 [c011b7c0] default_wake_function+0x0/0x10 [c012fca0] worker_thread+0x0/0x160 [c01331bc] kthread+0xec/0xf0 [c01330d0] kthread+0x0/0xf0 [c0103b7f] kernel_thread_helper+0x7/0x18 === Code: Bad EIP value. EIP: [f8a580c0] 0xf8a580c0 SS:ESP 0068:c294df40 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Markus Rechberger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
Markus Rechberger wrote: to be more accurate where all the changes happened: b/linux/drivers/media/tuners/Kconfig| 14 b/linux/drivers/media/tuners/Makefile |7 b/linux/drivers/media/tuners/xc3028-tuner.c | 601 b/linux/drivers/media/tuners/xc3028-tuner.h | 20 b/linux/drivers/media/video/em28xx/em2880-dvb.c | 748 b/linux/drivers/media/video/em28xx/em28xx-audio.c | 439 ++ b/linux/drivers/media/video/em28xx/em28xx-webcam.c | 365 ++ b/linux/include/media/v4l_dvb_tuner.h | 131 linux/Documentation/video4linux/CARDLIST.cx88 |3 linux/Documentation/video4linux/CARDLIST.em28xx | 69 linux/Documentation/video4linux/CARDLIST.tuner |1 linux/drivers/media/Kconfig |2 linux/drivers/media/Makefile|1 linux/drivers/media/common/ir-keymaps.c | 221 + linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c | 21 linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c | 34 linux/drivers/media/dvb/dvb-core/dmxdev.c |6 linux/drivers/media/dvb/dvb-core/dmxdev.h |1 linux/drivers/media/dvb/dvb-core/dvb_demux.c|3 linux/drivers/media/dvb/dvb-core/dvb_demux.h|3 linux/drivers/media/dvb/dvb-core/dvb_frontend.c | 29 linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 64 linux/drivers/media/dvb/dvb-core/dvb_net.c | 29 linux/drivers/media/dvb/dvb-core/dvb_net.h |1 linux/drivers/media/dvb/dvb-usb/af9005-fe.c | 12 linux/drivers/media/dvb/dvb-usb/au6610.c|3 linux/drivers/media/dvb/dvb-usb/cxusb.c | 150 linux/drivers/media/dvb/dvb-usb/cxusb.h |2 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c |7 linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6 linux/drivers/media/dvb/dvb-usb/dibusb-mb.c | 17 linux/drivers/media/dvb/dvb-usb/digitv.c|7 linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c | 11 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h |2 linux/drivers/media/dvb/dvb-usb/dvb-usb.h |8 linux/drivers/media/dvb/dvb-usb/gl861.c |3 linux/drivers/media/dvb/dvb-usb/m920x.c | 14 linux/drivers/media/dvb/dvb-usb/opera1.c|3 linux/drivers/media/dvb/dvb-usb/ttusb2.c|3 linux/drivers/media/dvb/dvb-usb/umt-010.c |3 linux/drivers/media/dvb/frontends/at76c651.c|2 linux/drivers/media/dvb/frontends/bsbe1.h |3 linux/drivers/media/dvb/frontends/bsru6.h |3 linux/drivers/media/dvb/frontends/cx22700.c |2 linux/drivers/media/dvb/frontends/cx22702.c |2 linux/drivers/media/dvb/frontends/cx24110.c |2 linux/drivers/media/dvb/frontends/dib3000mb.c |2 linux/drivers/media/dvb/frontends/dib3000mc.c |2 linux/drivers/media/dvb/frontends/dib7000m.c|2 linux/drivers/media/dvb/frontends/dib7000p.c|2 linux/drivers/media/dvb/frontends/dvb-pll.c | 65 linux/drivers/media/dvb/frontends/dvb-pll.h | 19 linux/drivers/media/dvb/frontends/dvb_dummy_fe.c|2 linux/drivers/media/dvb/frontends/l64781.c |2 linux/drivers/media/dvb/frontends/lgdt330x.c|6 linux/drivers/media/dvb/frontends/mt2060.c | 43 linux/drivers/media/dvb/frontends/mt2060.h |6 linux/drivers/media/dvb/frontends/mt312.c |2 linux/drivers/media/dvb/frontends/mt352.c | 15 linux/drivers/media/dvb/frontends/mt352.h |3 linux/drivers/media/dvb/frontends/nxt200x.c |2 linux/drivers/media/dvb/frontends/nxt6000.c |2 linux/drivers/media/dvb/frontends/or51132.c |2 linux/drivers/media/dvb/frontends/qt1010.c | 59 linux/drivers/media/dvb/frontends/qt1010.h |4 linux/drivers/media/dvb/frontends/s5h1420.c |6 linux/drivers/media/dvb/frontends/sp8870.c |2 linux/drivers/media/dvb/frontends/sp887x.c |4 linux/drivers/media/dvb/frontends/stv0297.c |2 linux/drivers/media/dvb/frontends/stv0299.c |4 linux/drivers/media/dvb/frontends/tda10021.c|2 linux/drivers/media/dvb/frontends/tda10023.c|2 linux/drivers/media/dvb/frontends/tda1004x.c|2 linux/drivers/media/dvb/frontends/tda10086.c|4 linux/drivers/media/dvb/frontends/tda8083.c |2
Re: [linux-dvb] [Patch TT-Budget S-1401 (TDA10086/TDA8262)]
Rudy Zijlstra wrote: Oliver Endriss wrote: With Helmut's help I've prepared a new patch which solved all tuning problems for him. Basically the same as the previous patch, except for: - TDA8262: set baseband gain to 9db (maximum value) - TDA10086: toggle register 0x02 between 0x35 (tuning) and 0x00 (locked) - STR and SNR values are inverted now. Helmut already confirmed that it works for him. @all TT-budget S-1401 Pinnacle 400e DVB-S users: Please test the attached patch. If nobody objects I'll commit this patch on Thursday. ... I have 2 1400's, and stopped using them as i had consistent problems switching between two satellites. My suspicion was (and is) not- trustworthy diseqc implementation. Any reason to test? Well, it's up to you, whether you'd like to contribute or not. ;-) Afaik DiSEqC has been fixed here: http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=7151f5a5582b;style=gitweb Oliver -- VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: cx878_41 ?...help needed with Mercurial
Mike, If I remember quite well your card has a cx24106 tuner / frontend. That means: 1. Even if bttv recognizes it, it will be unsupported, as a new frontend driver would be necessary to be written, and Conexant is not very helpful in those cases. A. Its a cx24110 there already is a driver. 2. Even if it is recognized by bttv, neither the pure Mercurial tree would help, nor the Mercurial tree with the implemented cx878 tree. A how do you know? 3. As I told you already, the cx878 driver runs, but it is not finished yet. So it does not help at all to fiddle around with it. You won't neither get a picture nor sound even if you were running a supported card. A how do you know? 4. I already asked you to send in a dmesg, but you simply ignored that request. Why please? Cheers Uwe Dmesg and lspci follow. dmesg journald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on hda2, internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Adding 262136k swap on /mnt/hda2/swapfile. Priority:-1 extents:119 across:428048k Linux video capture interface: v2.00 bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). PCI: setting IRQ 5 as level-triggered PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:09.1 bttv0: Bt878 (rev 17) at :00:09.0, irq: 5, latency: 64, mmio: 0xcddfe000 bttv0: detected: Avermedia M109 [card=199], PCI subsystem ID is 1461:0199 bttv0: using: Avermedia M109 [card=199,autodetected] bttv0: gpio: en=, out= in=004f00df [init] bttv0: using tuner=-1 bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 = 35468950 .. ok bttv0: add subdevice dvb0 bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). PCI: Found IRQ 5 for device :00:09.1 PCI: Sharing IRQ 5 with :00:09.0 bt878_probe: card id=[0x1991461],[ Avermedia M109 ] has DVB functions. bt878(0): Bt878 (rev 17) at 00:09.1, irq: 5, latency: 64, memory: 0xcddff000 DVB: registering new adapter (bttv0). DVB: registering frontend 0 (Conexant CX24110 DVB-S)... eth0: link down eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 [EMAIL PROTECTED]:/home/mike/build-v4l/v4l-dvb# lspci -v 00:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: Avermedia Technologies Inc Unknown device 0199 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cddfe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: Avermedia Technologies Inc Unknown device 0199 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cddff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Uwe all i really want is some help with Mercurial to merge the driver , or whatever , as it exists. I'm doing it purely for interests sake and as far as I am aware I am still able to decide what to do with my own time. I have no intention of interfering, demanding support or anything else. Rgds Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
On 5/15/07, Oliver Endriss [EMAIL PROTECTED] wrote: Markus Rechberger wrote: to be more accurate where all the changes happened: b/linux/drivers/media/tuners/Kconfig| 14 b/linux/drivers/media/tuners/Makefile |7 b/linux/drivers/media/tuners/xc3028-tuner.c | 601 b/linux/drivers/media/tuners/xc3028-tuner.h | 20 b/linux/drivers/media/video/em28xx/em2880-dvb.c | 748 b/linux/drivers/media/video/em28xx/em28xx-audio.c | 439 ++ b/linux/drivers/media/video/em28xx/em28xx-webcam.c | 365 ++ b/linux/include/media/v4l_dvb_tuner.h | 131 linux/Documentation/video4linux/CARDLIST.cx88 |3 linux/Documentation/video4linux/CARDLIST.em28xx | 69 linux/Documentation/video4linux/CARDLIST.tuner |1 linux/drivers/media/Kconfig |2 linux/drivers/media/Makefile|1 linux/drivers/media/common/ir-keymaps.c | 221 + linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c | 21 linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c | 34 linux/drivers/media/dvb/dvb-core/dmxdev.c |6 linux/drivers/media/dvb/dvb-core/dmxdev.h |1 linux/drivers/media/dvb/dvb-core/dvb_demux.c|3 linux/drivers/media/dvb/dvb-core/dvb_demux.h|3 linux/drivers/media/dvb/dvb-core/dvb_frontend.c | 29 linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 64 linux/drivers/media/dvb/dvb-core/dvb_net.c | 29 linux/drivers/media/dvb/dvb-core/dvb_net.h |1 linux/drivers/media/dvb/dvb-usb/af9005-fe.c | 12 linux/drivers/media/dvb/dvb-usb/au6610.c|3 linux/drivers/media/dvb/dvb-usb/cxusb.c | 150 linux/drivers/media/dvb/dvb-usb/cxusb.h |2 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c |7 linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6 linux/drivers/media/dvb/dvb-usb/dibusb-mb.c | 17 linux/drivers/media/dvb/dvb-usb/digitv.c|7 linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c | 11 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h |2 linux/drivers/media/dvb/dvb-usb/dvb-usb.h |8 linux/drivers/media/dvb/dvb-usb/gl861.c |3 linux/drivers/media/dvb/dvb-usb/m920x.c | 14 linux/drivers/media/dvb/dvb-usb/opera1.c|3 linux/drivers/media/dvb/dvb-usb/ttusb2.c|3 linux/drivers/media/dvb/dvb-usb/umt-010.c |3 linux/drivers/media/dvb/frontends/at76c651.c|2 linux/drivers/media/dvb/frontends/bsbe1.h |3 linux/drivers/media/dvb/frontends/bsru6.h |3 linux/drivers/media/dvb/frontends/cx22700.c |2 linux/drivers/media/dvb/frontends/cx22702.c |2 linux/drivers/media/dvb/frontends/cx24110.c |2 linux/drivers/media/dvb/frontends/dib3000mb.c |2 linux/drivers/media/dvb/frontends/dib3000mc.c |2 linux/drivers/media/dvb/frontends/dib7000m.c|2 linux/drivers/media/dvb/frontends/dib7000p.c|2 linux/drivers/media/dvb/frontends/dvb-pll.c | 65 linux/drivers/media/dvb/frontends/dvb-pll.h | 19 linux/drivers/media/dvb/frontends/dvb_dummy_fe.c|2 linux/drivers/media/dvb/frontends/l64781.c |2 linux/drivers/media/dvb/frontends/lgdt330x.c|6 linux/drivers/media/dvb/frontends/mt2060.c | 43 linux/drivers/media/dvb/frontends/mt2060.h |6 linux/drivers/media/dvb/frontends/mt312.c |2 linux/drivers/media/dvb/frontends/mt352.c | 15 linux/drivers/media/dvb/frontends/mt352.h |3 linux/drivers/media/dvb/frontends/nxt200x.c |2 linux/drivers/media/dvb/frontends/nxt6000.c |2 linux/drivers/media/dvb/frontends/or51132.c |2 linux/drivers/media/dvb/frontends/qt1010.c | 59 linux/drivers/media/dvb/frontends/qt1010.h |4 linux/drivers/media/dvb/frontends/s5h1420.c |6 linux/drivers/media/dvb/frontends/sp8870.c |2 linux/drivers/media/dvb/frontends/sp887x.c |4 linux/drivers/media/dvb/frontends/stv0297.c |2 linux/drivers/media/dvb/frontends/stv0299.c |4 linux/drivers/media/dvb/frontends/tda10021.c|2 linux/drivers/media/dvb/frontends/tda10023.c|2 linux/drivers/media/dvb/frontends/tda1004x.c|2 linux/drivers/media/dvb/frontends/tda10086.c|4
Re: [linux-dvb] How to read from /dev/dvb/adapter0/dvr0 ???
Le mardi 15 mai 2007 02:05, Jorge Canas a écrit : I have tried using fopen() and open() to open /dev/dvb/adapter0/dvr0 but it always returns NULL or -1, respectively. How exactly is it that I am supposed to read from /dev/dvb/adapter0/dvr0 ?? I have already successfully tuned the device by using azap prior to the fopen() or open() calls. Did you give azap option -r ? -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: cx878_41 ?...help needed with Mercurial
Am Dienstag, 15. Mai 2007 10:29 schrieb Mike Booth: Mike, If I remember quite well your card has a cx24106 tuner / frontend. That means: 1. Even if bttv recognizes it, it will be unsupported, as a new frontend driver would be necessary to be written, and Conexant is not very helpful in those cases. A. Its a cx24110 there already is a driver. Yes, for your sight, after fiddling around doing stupid changes in some places like changing Pinnacle into Aver or so. There are cx24108 tuners / frontends which are supported by cx24110. But every other card / tuner / frontend containing a cx24106 tuner / frontend is a completely different issue: A developer like Manu or Michael has to (well, if they are interested tot do so): a. sign a paper at the conexant company to get some info on the frontend b. modify cx24110.c to imply some support for your card c. modify dvb-bt8xx.c to imply some support for the card d. modify bttv cardlist . Both steps need a whole lot of time, especially the second one. 2. Even if it is recognized by bttv, neither the pure Mercurial tree would help, nor the Mercurial tree with the implemented cx878 tree. A how do you know? I know that as I already told you for 2 times now that your card is an UNSUPPORTED one. Moreover I did not find your card in the bttv gallery - the M109 simply does not appear there: And this says very clear: It is NOT supported! You can try with kernel 2.4 if you may wish, but there won't be no success either I guess. 3. As I told you already, the cx878 driver runs, but it is not finished yet. So it does not help at all to fiddle around with it. You won't neither get a picture nor sound even if you were running a supported card. A how do you know? I know as I did already the whole testing for cx878 and am aware of all the problems to be solved. 4. I already asked you to send in a dmesg, but you simply ignored that request. Why please? Cheers Uwe Dmesg and lspci follow. dmesg journald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on hda2, internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Adding 262136k swap on /mnt/hda2/swapfile. Priority:-1 extents:119 across:428048k Linux video capture interface: v2.00 bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). PCI: setting IRQ 5 as level-triggered PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:09.1 bttv0: Bt878 (rev 17) at :00:09.0, irq: 5, latency: 64, mmio: 0xcddfe000 bttv0: detected: Avermedia M109 [card=199], PCI subsystem ID is 1461:0199 bttv0: using: Avermedia M109 [card=199,autodetected] bttv0: gpio: en=, out= in=004f00df [init] bttv0: using tuner=-1 bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 = 35468950 .. ok bttv0: add subdevice dvb0 bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). PCI: Found IRQ 5 for device :00:09.1 PCI: Sharing IRQ 5 with :00:09.0 bt878_probe: card id=[0x1991461],[ Avermedia M109 ] has DVB functions. bt878(0): Bt878 (rev 17) at 00:09.1, irq: 5, latency: 64, memory: 0xcddff000 DVB: registering new adapter (bttv0). DVB: registering frontend 0 (Conexant CX24110 DVB-S)... eth0: link down eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 [EMAIL PROTECTED]:/home/mike/build-v4l/v4l-dvb# lspci -v 00:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: Avermedia Technologies Inc Unknown device 0199 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cddfe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: Avermedia Technologies Inc Unknown device 0199 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cddff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Uwe all i really want is some help with Mercurial to merge the driver , or whatever , as it exists. Wrong! You start to nerve me now, really! I'm doing it purely for interests sake and as far as I am aware I am still able to decide what to do with my own time. I have no intention of interfering, demanding support or anything else. Rgds Mike Two suggestions for now: 1. Return this card to your dealer as soon as possible or sell it or do whatever with it (BEST CHOICE!) 2. Try to find some developer to get this card supported doing the necessary changes in the relevant places (cx24110, dvb-bt8xx..). 3. Stop bugging me
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Markus Rechberger wrote: Hi, TUNER_SET_TYPE_ADDR, seems to break with that approach, it's possible to change the tuner type on the fly with it. There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part. Normally, a tuner/PLL (note that a tuner is not exactly the same as a PLL) is behind a DVB demodulator in most cases ~90% of the times. The demod of course does control access to it, also this control is private to the demod a control which is exported to the dvb-core such that DVB-CORE might use that control to do various operations with regards to the devices that are behind the demodulator. Now, there are few devices, that do not use the bus behind the demodulator. But these devices are comparatively lesser in number, say the remaining ~10%. The statement that V4L cannot set tuner address is baseless, as V4L is not supposed to do that since what the DVB subsystem controls, that alone should handle. http://article.gmane.org/gmane.comp.video.video4linux/32821/match=multi+std+silicon+tuners+analog If you have read through the code that i posted you see this comment +/* NOTE! + * Almost all tuners are behind a secondary bus behind a digital demodulator. + * Access to this bus is controlled by the demodulator itself by the means of a + * control with the demodulator. viz, i2c_gate_ctrl. A hybrid device (in Analog + * mode) should never try to enable/disable the i2c_gate_ctrl, ie the gate + * control is private to the demodulator. Since the demodulator only has access + * to this secondary bus, initialization is handled in a better manner by the + * digital mode. ie, dvb-core + */ The reason being manufacturers are more oriented to making DVB devices with Analog as a small add on feature, not that Analog is the main feature on it. moreover if you think that a hybrid tuner which has a major feature such as DVB stating things like: There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part. is absurd. If you think that V4L should handle this, then your thoughts (logic) itself is fundamentally flawed to a very great extend. Additionally, if you take a look, the proposed method doesn't require *all* the DVB drivers to be modified to make the XC3028 to work. Only the XC3028 need to be modified, which IMHO is much easier and cleaner approach that will work with other hybrid devices too in a nice and clean way, rather than messing up with the entire DVB tree. It is not that i do want to see my code being accepted or anything like that, but i do prefer to not have changes that do have a negative impact going into the DVB tree. I just wrote that as a means for people to look at it such that better drivers can be written, rather than wasting time again and again on long discussions that lead to nowhere. Also if you think that the code that which i have pasted doesn't work for you, with regards to personality issues: You can as an alternate use an approach handled by Michael which has been proven to work as well. http://www.linuxtv.org/~mkrufky/xc-bluebird.patch This will save you a lot of time too, as he is offering to spend some of his time to have a better approach. You should probably additionally test that tree whether it breaks things for you. Additionally for one driver, if the entire DVB driver tree has to be changed, don't you think that there is something wrong with your patches/driver ? I doubt that i will be able write any further on this thread, time being very much limited. HTH Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
On 5/15/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: Hi, TUNER_SET_TYPE_ADDR, seems to break with that approach, it's possible to change the tuner type on the fly with it. There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part. Normally, a tuner/PLL (note that a tuner is not exactly the same as a PLL) is behind a DVB demodulator in most cases ~90% of the times. The demod of course does control access to it, also this control is private to the demod a control which is exported to the dvb-core such that DVB-CORE might use that control to do various operations with regards to the devices that are behind the demodulator. Now, there are few devices, that do not use the bus behind the demodulator. But these devices are comparatively lesser in number, say the remaining ~10%. The statement that V4L cannot set tuner address is baseless, as V4L is not supposed to do that since what the DVB subsystem controls, that alone should handle. that your current approach breaks the TUNER_SET_TYPE_ADDR approach is not baseless. Look up where it's used at the moment and how it is used. This was the only point of what I wrote there. http://article.gmane.org/gmane.comp.video.video4linux/32821/match=multi+std+silicon+tuners+analog If you have read through the code that i posted you see this comment +/* NOTE! + * Almost all tuners are behind a secondary bus behind a digital demodulator. + * Access to this bus is controlled by the demodulator itself by the means of a + * control with the demodulator. viz, i2c_gate_ctrl. A hybrid device (in Analog + * mode) should never try to enable/disable the i2c_gate_ctrl, ie the gate + * control is private to the demodulator. Since the demodulator only has access + * to this secondary bus, initialization is handled in a better manner by the + * digital mode. ie, dvb-core + */ The reason being manufacturers are more oriented to making DVB devices with Analog as a small add on feature, not that Analog is the main feature on it. moreover if you think that a hybrid tuner which has a major feature such as DVB stating things like: There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part. is absurd. If you think that V4L should handle this, then your thoughts (logic) itself is fundamentally flawed to a very great extend. I think you have the wrong idea about what I wrote. V4L should only deal with analogue/radio mode of a tuner, dvb only the digital part. Additionally, if you take a look, the proposed method doesn't require *all* the DVB drivers to be modified to make the XC3028 to work. Only the XC3028 need to be modified, which IMHO is much easier and cleaner approach that will work with other hybrid devices too in a nice and clean way, rather than messing up with the entire DVB tree. Remember there was a proposal which didn't touch that many drivers, it got discussed till there was nothing to discuss anymore and that approach just died, I encourage everyone to participate at both projects and I don't insist on keeping the old structures as they are because they were ok for the first devices which were available but the framework simply doesn't fit for current devices anymore. It is not that i do want to see my code being accepted or anything like that, but i do prefer to not have changes that do have a negative impact going into the DVB tree. I just wrote that as a means for people to look at it such that better drivers can be written, rather than wasting time again and again on long discussions that lead to nowhere. Also if you think that the code that which i have pasted doesn't work for you, with regards to personality issues: You can as an alternate use an approach handled by Michael which has been proven to work as well. http://www.linuxtv.org/~mkrufky/xc-bluebird.patch This will save you a lot of time too, as he is offering to spend some of his time to have a better approach. You should probably additionally test that tree whether it breaks things for you. Additionally for one driver, if the entire DVB driver tree has to be changed, don't you think that there is something wrong with your patches/driver ? This bluebird patch makes a DVB tuner out of the v4l tuner so this is no solution for the problem, my change introduces a new way for handling these hybrid tuners which aren't directly handled by the dvb demodulator (eg. which are not behind a demod bus) dvb_tuner_ops was designed to split out the tuner functionality in DVB, this is where the V4L approach connects. The only change that I've done there is to unify the function parameters that v4l doesn't need initialized dvb structures (for example dvb_frontend). If you look at the mt2060 it's
Re: [linux-dvb] DVICO's FusionHDTV 5 RT Lite...
On Thu, 03 May 2007 Michael Krufky wrote : Suresh S wrote: Hi, The dvb card which i am using is DVICO's FusionHDTV 5 RT Lite and I m using Linux DVB version 3 API. Is there any API provision to access the video decoder memory for accessing the decoded frame buffer. Your reply is appriciated. The video decoder of this device is the bt878. Access to the decoded video is provided through the v4l1/2 API, via the bttv driver. Please note: If you are looking for the decoded mpeg video frames, that is not possible with this card -- There is no mpeg TS decoder on this card. The bt878 video decoder is only useful for dealing with analog video. Digital video is provided by the lgdt3303 demod, and is passed over to the pci bus, untouched. It is up to software to handle PID filtering and MPEG decoding, etc. Regards, Michael Krufky Suresh S wrote: Thanks Michael Krufky. what about Dvico FusionHDTV 5 RT gold card. Because we are looking for digital video decoder not analog, so it is possible to get a copy of the decoder memory having decoded frames if we use this gold card. Just we want to make a copy and we will not modify the buffer anymore. Thanks Regards, Suresh.S Suresh S wrote: Hi, If I am using FusionHDTV 5 RT gold card as a DVB card, then what are the decoders available (what decoders generally the peoples are using nowadays). Could you please tell me is there any possiblity like any kernel source to fetch(accessing) the decoder's memory if I am using any decoder. I requirement is I want to make a copy (or accessing) the decoded memory(frames). For this I want to know what are the decoders could have these kind of facilities. Please give your comments. -SSmadurai. Suresh S wrote: Hi, The dvb card which i am using is DVICO's FusionHDTV 5 RT gold. I want to know where(which memory) the decoded frames are storing. Is it possible that we can make a copy of that memory(having decoded frames).? -SSMadurai. Suresh, The kernel driver delivers the mpeg TS over the PCI bus untouched. There is no decoding in hardware nor kernelspace. The application handles the decoding in userland. For information about the mpeg decoding, look into mplayer, libmpeg2 or ffmpeg. Side note: I would appreciate it if you would stop sending the same question to me in private over and over again. There is a mailing list for these questions (cc added) ... Asking the same question multiple times is not going to change the answer -- there is no hardware decoder on these pci boards, and we do not decode the stream in kernelspace -- it all happens in userland. I hope this helps. Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
Hi Michael and others, I know we've been over this, but I need to state my feelings on the matter, otherwise I would have to simply keep quiet, and that doesn't help the situation for anybody. I _strongly_ feel that the core changes being proposed here will hurt the integrity of the dvb subsystem. I don't think they will hurt the integrity of the subsystem, but a large amount of changes can really affect the driver stability, even being trivial changes. Such patch series, if applied, will need acks for the active driver maintainers that should make sure this won't break any other driver. I would, instead, use a different approach, without losing the required functionalities for xc3028. To give my $2 cents of contribution, I've sent a modified version of dvb integration for xc3028 sometime ago to Markus, as a sugestion. It should be noticed that I didn't tested the patchset (as currently I don't have em288x+xc3028 DVB hardware). If someone wants to take a look, the patch series it is available (at quilt format) at: http://linuxtv.org/~mchehab/mrec2/ The required changes on DVB are minimal (just adding a few newer fields at frontend core). Also, there's no need to change any stuff on dvb or v4l drivers. So, it wouln't break any existing drivers. The diffstat for the core changes is: linux/drivers/media/Kconfig |2 linux/drivers/media/Makefile|1 linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 29 ++ linux/drivers/media/video/tuner-core.c | 156 ++- linux/include/media/tuner.h |6 linux/include/media/v4l2-common.h |2 v4l/Makefile|4 v4l/scripts/gentree.pl |1 All API changes on DVB are at the first patch: http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch It should be noticed that the comments at the patches may not be correct anymore, since I've folded some patches, and modified some API calls on Markus original series to be compatible with the way I did the integration on DVB frontend. If we go to this path, some work is still required. I do frown upon code duplication, however, in this case it is a safer alternative to the one currently on the table. Earlier versions of the xc3028 tuner driver were bound to the video4linux tuner.ko module, for the sake of tuning analog television stations. There was a wrapper present inside the em2880-dvb driver that allowed the dvb subsystem to access the xc3028 via tuner.ko. I am not a big fan of this solution, however, it does not touch any core subsystem code. DVB-only devices can use a separate module in order to access the xc3028 without imposing dependencies on the v4l core. Duplicating a driver is not a solution, just a terrible hack. We should focus on a way to use the same tuner driver for both Analog and Digital TV. -- Cheers, Mauro Carvalho Chehab http://linuxtv.org [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Problem with virtual ethernet driver
I need to perform a virtual ethernet driver in c code and I've not found any clear solution in the web. Thanks to everyone to help me! Hakim. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Mantis (vp-1034) and CI (linux driver from Twinhan) question?
Manu, You can probably answer this one. If not maybe someone else. The linux driver which can be downloaded from the Twinhan website for the Mantis family (AZLinux_v1.4.2_CI_FC6), And in my case the vp-1034, is only suitable for the first FC6 kernel. Is has precompiled module binaries. I tried to compile the driver myself but found the dvb sources are missing a directory linux/drivers/media/dvb/cimodule which should contain the file mantis_ca.h I tried it in a xen domain with the specified kernel version but it is offcourse a xen kernel version which is not compatible with the inlcuded precompiled non-xen modules. Why is this part missing? Can we get it from somewhere? I would like to test the ci part of my vp-1034 but I do not want to downgrade my installation to the 2.6.18 kernel of FC6. Regards, Michel. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Hi Michael and others, I know we've been over this, but I need to state my feelings on the matter, otherwise I would have to simply keep quiet, and that doesn't help the situation for anybody. I _strongly_ feel that the core changes being proposed here will hurt the integrity of the dvb subsystem. I don't think they will hurt the integrity of the subsystem, but a large amount of changes can really affect the driver stability, even being trivial changes. Such patch series, if applied, will need acks for the active driver maintainers that should make sure this won't break any other driver. I would, instead, use a different approach, without losing the required functionalities for xc3028. To give my $2 cents of contribution, I've sent a modified version of dvb integration for xc3028 sometime ago to Markus, as a sugestion. It should be noticed that I didn't tested the patchset (as currently I don't have em288x+xc3028 DVB hardware). If someone wants to take a look, the patch series it is available (at quilt format) at: http://linuxtv.org/~mchehab/mrec2/ The required changes on DVB are minimal (just adding a few newer fields at frontend core). Also, there's no need to change any stuff on dvb or v4l drivers. So, it wouln't break any existing drivers. The diffstat for the core changes is: linux/drivers/media/Kconfig |2 linux/drivers/media/Makefile|1 linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 29 ++ linux/drivers/media/video/tuner-core.c | 156 ++- linux/include/media/tuner.h |6 linux/include/media/v4l2-common.h |2 v4l/Makefile|4 v4l/scripts/gentree.pl |1 All API changes on DVB are at the first patch: http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch It should be noticed that the comments at the patches may not be correct anymore, since I've folded some patches, and modified some API calls on Markus original series to be compatible with the way I did the integration on DVB frontend. If we go to this path, some work is still required. I do frown upon code duplication, however, in this case it is a safer alternative to the one currently on the table. Earlier versions of the xc3028 tuner driver were bound to the video4linux tuner.ko module, for the sake of tuning analog television stations. There was a wrapper present inside the em2880-dvb driver that allowed the dvb subsystem to access the xc3028 via tuner.ko. I am not a big fan of this solution, however, it does not touch any core subsystem code. DVB-only devices can use a separate module in order to access the xc3028 without imposing dependencies on the v4l core. Duplicating a driver is not a solution, just a terrible hack. We should focus on a way to use the same tuner driver for both Analog and Digital TV. If I compare that solution with the solution I provided your one is only half way done, you add a dependency for a structure which will never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will be used). If you look at v4l_dvb_tuner_ops it's clear what it intends to be and in no way it adds extra struct definitions which do not belong there, if you look at dvb_frontend in tuner-core.c it has nothing to do with the tuner, it also contains the callbacks for the digital demod. It also requires all the dvb headers. #include dvb_frontend.h #include linux/dvb/frontend.h #include dvbdev.h dvbdev.h is not needed at all either, even if gcc might wipe out the defined functions because they're not used. We shouldn't care about hacks to keep the noise on the ML low, put the technical aspect (which includes a solution for all the requirements) infront of everything then I might agree with your patch. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis (vp-1034) and CI (linux driver from Twinhan) question?
Michel Verbraak wrote: Manu, You can probably answer this one. If not maybe someone else. The linux driver which can be downloaded from the Twinhan website for the Mantis family (AZLinux_v1.4.2_CI_FC6), And in my case the vp-1034, is only suitable for the first FC6 kernel. Is has precompiled module binaries. I tried to compile the driver myself but found the dvb sources are missing a directory linux/drivers/media/dvb/cimodule which should contain the file mantis_ca.h I tried it in a xen domain with the specified kernel version but it is offcourse a xen kernel version which is not compatible with the inlcuded precompiled non-xen modules. Why is this part missing? Can we get it from somewhere? I would like to test the ci part of my vp-1034 but I do not want to downgrade my installation to the 2.6.18 kernel of FC6. There will be a driver for the CI part soon. There are some issues to be sorted out, before anything else. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
If I compare that solution with the solution I provided your one is only half way done, you add a dependency for a structure which will never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will be used). As I said, this is a sugestion. For sure, improvements can be done. The main point is not risking breaking other drivers. If you look at v4l_dvb_tuner_ops it's clear what it intends to be and in no way it adds extra struct definitions which do not belong there, if you look at dvb_frontend in tuner-core.c it has nothing to do with the tuner, it also contains the callbacks for the digital demod. It also requires all the dvb headers. #include dvb_frontend.h #include linux/dvb/frontend.h #include dvbdev.h dvbdev.h is not needed at all either, even if gcc might wipe out the defined functions because they're not used. I can't see any troubles including those headers, except for a slower compilation. Later, somebody may write a patch reorganizing the includes. We shouldn't care about hacks to keep the noise on the ML low, put the technical aspect (which includes a solution for all the requirements) infront of everything then I might agree with your patch. It is not a matter of keeping noise low, but, instead, avoid breaking existing drivers. This is a technical issue: smaller changes means less lines to check, and more unlikely to break an existing driver. Cheers, Mauro Carvalho Chehab http://linuxtv.org [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88 - cx878 project
Am Dienstag, 15. Mai 2007 17:55 schrieb Markus Rechberger: On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Hi Michael and others, I know we've been over this, but I need to state my feelings on the matter, otherwise I would have to simply keep quiet, and that doesn't help the situation for anybody. I _strongly_ feel that the core changes being proposed here will hurt the integrity of the dvb subsystem. I don't think they will hurt the integrity of the subsystem, but a large amount of changes can really affect the driver stability, even being trivial changes. Such patch series, if applied, will need acks for the active driver maintainers that should make sure this won't break any other driver. I would, instead, use a different approach, without losing the required functionalities for xc3028. To give my $2 cents of contribution, I've sent a modified version of dvb integration for xc3028 sometime ago to Markus, as a sugestion. It should be noticed that I didn't tested the patchset (as currently I don't have em288x+xc3028 DVB hardware). If someone wants to take a look, the patch series it is available (at quilt format) at: http://linuxtv.org/~mchehab/mrec2/ The required changes on DVB are minimal (just adding a few newer fields at frontend core). Also, there's no need to change any stuff on dvb or v4l drivers. So, it wouln't break any existing drivers. The diffstat for the core changes is: linux/drivers/media/Kconfig |2 linux/drivers/media/Makefile|1 linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 29 ++ linux/drivers/media/video/tuner-core.c | 156 ++- linux/include/media/tuner.h |6 linux/include/media/v4l2-common.h |2 v4l/Makefile|4 v4l/scripts/gentree.pl |1 All API changes on DVB are at the first patch: http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch It should be noticed that the comments at the patches may not be correct anymore, since I've folded some patches, and modified some API calls on Markus original series to be compatible with the way I did the integration on DVB frontend. If we go to this path, some work is still required. I do frown upon code duplication, however, in this case it is a safer alternative to the one currently on the table. Earlier versions of the xc3028 tuner driver were bound to the video4linux tuner.ko module, for the sake of tuning analog television stations. There was a wrapper present inside the em2880-dvb driver that allowed the dvb subsystem to access the xc3028 via tuner.ko. I am not a big fan of this solution, however, it does not touch any core subsystem code. DVB-only devices can use a separate module in order to access the xc3028 without imposing dependencies on the v4l core. Duplicating a driver is not a solution, just a terrible hack. We should focus on a way to use the same tuner driver for both Analog and Digital TV. If I compare that solution with the solution I provided your one is only half way done, you add a dependency for a structure which will never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will be used). If you look at v4l_dvb_tuner_ops it's clear what it intends to be and in no way it adds extra struct definitions which do not belong there, if you look at dvb_frontend in tuner-core.c it has nothing to do with the tuner, it also contains the callbacks for the digital demod. It also requires all the dvb headers. #include dvb_frontend.h #include linux/dvb/frontend.h #include dvbdev.h dvbdev.h is not needed at all either, even if gcc might wipe out the defined functions because they're not used. We shouldn't care about hacks to keep the noise on the ML low, put the technical aspect (which includes a solution for all the requirements) infront of everything then I might agree with your patch. Markus Hi everybody, This is what I found at http://www.bttv-gallery.de. Perhaps this helps to clear up misunderstandings and helps to finish that discussion / thread – original author of the german text is Peter Hettkamp: Point 4: „Data transfer from QSPK-Chip into the PC-Random Access Memory. All further processings are done by relevant software. To enable that the data must be transferred into RAM over the PCI bus. Within the PCTV SAT this is done by the CN878 chip over its audio DMA.“ Well, and now comes the misleading part: „The whole video part of the chip rests functionless during the DVB capture, and can on the contrary be used parallely for recording analog video (SVHS and Composite input) under Linux. The bttv driver is loaded anyhow... Done by my driver, API does not exist on that.“ Markus Rechberger said on Monday, May 16th, 16:23: „* full
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: If I compare that solution with the solution I provided your one is only half way done, you add a dependency for a structure which will never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will be used). As I said, this is a sugestion. For sure, improvements can be done. The main point is not risking breaking other drivers. If you look at v4l_dvb_tuner_ops it's clear what it intends to be and in no way it adds extra struct definitions which do not belong there, if you look at dvb_frontend in tuner-core.c it has nothing to do with the tuner, it also contains the callbacks for the digital demod. It also requires all the dvb headers. #include dvb_frontend.h #include linux/dvb/frontend.h #include dvbdev.h dvbdev.h is not needed at all either, even if gcc might wipe out the defined functions because they're not used. I can't see any troubles including those headers, except for a slower compilation. Later, somebody may write a patch reorganizing the includes. We shouldn't care about hacks to keep the noise on the ML low, put the technical aspect (which includes a solution for all the requirements) infront of everything then I might agree with your patch. It is not a matter of keeping noise low, but, instead, avoid breaking existing drivers. This is a technical issue: smaller changes means less lines to check, and more unlikely to break an existing driver. I really understand that issue I just want to point to the saa7114 changes which broke the em28xx MSI devices in the kernel, there was neither a revert or something else. If I'd have to rate the patch I sent to the v4l maintainer list I'd give it 3/10 pts. the driver is still broken even in the v4l-dvb-experimental repository since I haven't ported that change from the v4l-dvb-kernel repository to the experimental one yet. It's important to avoid breaking devices that for it should be tested and discussed. But again I see everyone here is writing around the whole issue. Oliver wrote that the patches are too big and that it will take alot time to review them (it was also alot time to write them, so telling me about a time factor is more than unfair). I suggest to get your hands dirty with it and start to test it and comment the outstanding points I wrote in the first email. thanks, Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Patch TT-Budget S-1401 (TDA10086/TDA8262)]
Hello Rudy, Rudy Zijlstra wrote: So in general i am willing to test patches, provided: 1 - i have the HW available to do so 2 - its a patch against the current kernel, or against a rc release. the mentioned patch is part of the official kernel since 2.6.21-rc6. Best regards, Andreas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] A correction on nasty stupid MRecs statements about hybrid tuners /em28xx-dvb
Hi, Markus Rechberger said on Monday, May 16th, 16:36: „TUNER_SET_TYPE_ADDR, seems to break with that approach, it's possible to change the tuner type on the fly with it. There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part. This is perfect nonsense! A small look at www.bttv-gallery.de says quite clear, that both the xc3028 and the qt1010 tuners / demodulators are BUT ANALOGUE ONES. NONE of those two is capable to offer DVB-T functions, proven by facts @bttv-gallery. Tuners / demodulators that offer DVB-T functions are for example the MT352 or the ZL10353. In so far (i. e. as the author called Mrechberger obviously does not know what he is saying or doing) I would suggest to throw his 9000 lines of code into the next available trash box without return ticket. What a waste of space giving such a team incapable man a personal repository for his nonsense experiments! No cent for this crap! No cent for this pig-headed politician! Regards Uwe -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
Am Dienstag, den 15.05.2007, 19:00 +0200 schrieb Markus Rechberger: On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: If I compare that solution with the solution I provided your one is only half way done, you add a dependency for a structure which will never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will be used). As I said, this is a sugestion. For sure, improvements can be done. The main point is not risking breaking other drivers. If you look at v4l_dvb_tuner_ops it's clear what it intends to be and in no way it adds extra struct definitions which do not belong there, if you look at dvb_frontend in tuner-core.c it has nothing to do with the tuner, it also contains the callbacks for the digital demod. It also requires all the dvb headers. #include dvb_frontend.h #include linux/dvb/frontend.h #include dvbdev.h dvbdev.h is not needed at all either, even if gcc might wipe out the defined functions because they're not used. I can't see any troubles including those headers, except for a slower compilation. Later, somebody may write a patch reorganizing the includes. We shouldn't care about hacks to keep the noise on the ML low, put the technical aspect (which includes a solution for all the requirements) infront of everything then I might agree with your patch. It is not a matter of keeping noise low, but, instead, avoid breaking existing drivers. This is a technical issue: smaller changes means less lines to check, and more unlikely to break an existing driver. I really understand that issue I just want to point to the saa7114 changes which broke the em28xx MSI devices in the kernel, there was neither a revert or something else. If I'd have to rate the patch I sent to the v4l maintainer list I'd give it 3/10 pts. the driver is still broken even in the v4l-dvb-experimental repository since I haven't ported that change from the v4l-dvb-kernel repository to the experimental one yet. It's important to avoid breaking devices that for it should be tested and discussed. But again I see everyone here is writing around the whole issue. Oliver wrote that the patches are too big and that it will take alot time to review them (it was also alot time to write them, so telling me about a time factor is more than unfair). I suggest to get your hands dirty with it and start to test it and comment the outstanding points I wrote in the first email. Manu, what do you think already could have a GO? Markus can't invade like that, but must have a next safe harbour to continue to work on it. The hybrid stuff will invade the planet for long, and then ... die. Do you think to share tuners between digital and analog is really impossible, or just wait until these zilliards are gone? Why, please? GNU/Linux is surely dead on this after it. Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to read from /dev/dvb/adapter0/dvr0 ???
From: Christophe Thommeret [EMAIL PROTECTED] Le mardi 15 mai 2007 02:05, Jorge Canas a écrit : I have tried using fopen() and open() to open /dev/dvb/adapter0/dvr0 but it always returns NULL or -1, respectively. How exactly is it that I am supposed to read from /dev/dvb/adapter0/dvr0 ?? I have already successfully tuned the device by using azap prior to the fopen() or open() calls. Did you give azap option -r ? Yes, I had specified the recording option (-r) to azap. I got it to work after a reboot. I am not sure what was wrong. Thanks for the help anyway! _ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_2G_0507 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] how to record entire TS?
Hi, I have looked at the azap.c code and I see how it creates PES filters to select specific video and audio PIDs. Then, when azap is used with -r, packets with those PIDs are available on the dvr device file. However, how would I go about making the entire transport stream (including PSI packets) available for recording? I assume there is a way to send the whole thing to the dvr device file, anyone know how? Thanks. _ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
