Re: [linux-dvb] Re: [PATCH] Re: More than 2Gb problem (dvb related) ?
Oliver Endriss wrote: After digging through the code, kernel DMA docs and the saa7146 datasheet, I think that we should remove the scatter-gatter voodoo from the budget and av7110 driver. ;-) What about the attached patch? - easy to understand and maintain - saves 1 page of memory (page table of the SAA7146 MMU) - saves PCI bandwidth (SAA7146 does not read page table anymore) Comments? pci_alloc_consistent() allocates uncached memory. This makes the demuxer very slow. The 'scatter-gatter voodoo' is a better solution. If exist a function, which can allocate cached continuous physical memory, you should replace pci_alloc_consistent() with this function. - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Fwd: Trouble with Hauppauge HVR 1300 ir remote
Hi Michael,
linux-dvb is the right place to ask such questions, I'm not into cx88 Ir stuff
-Markus
-- Forwarded message --
From: [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 18:25:06 +0200
Subject: Trouble with Hauppauge HVR 1300 ir remote
To: [EMAIL PROTECTED]
Hallo Markus,
while browsing the v4l-dvb mercurial I got the impresssion that you are taking
care of the current cx88 development. So I hope you are the right person to
direct my questions to. If not it would great if you could tell me whom to
contact regarding the following issue,
I'm having a hard time to get the ir remote of my Hauppauge HVR 1300 (non-MCE)
working. And I also noticed two other guys on the mailing list having the same
problem (HVR-1300 non MCE and ir remote from 2007/04/03). I tried with
different kernel and v4l versions but to no avail. Played with all the
different debug options of the v4l modules but still I'm clueless what might go
wrong. OTOH I'm sure that this is not a hardware issue as the card works fine
on windows.
I guess what I'm looking for is some sort of guidance on how to further track
down the problem. I already tried to add some more ir_dprintk to cx88-input.c
but there is not much I can gather from the additional output. The following
sequence of calls is logged
cx88_ir_init
cx88_ir_init - case CX88_BOARD_HAUPPAUGE_HVR1300
cx88_ir_start
cx88_ir_irq
cx88_ir_irq
where cx88_ir_irq is never seeing a complete sample (
Is there any specifc information I should provide or can you give me a hint
where to start this investigation?
Thanks for your time
Michael
Some details:
mythtv - ~ # uname -a
Linux mythtv 2.6.21 #1 SMP Sun Apr 29 17:12:44 CEST 2007 i686 GNU/Linux
mythtv - ~ # ls -al /dev/input/by-path/pci-\:04\:09.0--event-ir
lrwxrwxrwx 1 root root 12 Apr 29 17:58
/dev/input/by-path/pci-:04:09.0--event-ir - ../../event3
looking at device '/class/input/input3/event3':
KERNEL==event3
SUBSYSTEM==input
DRIVER==
ATTR{dev}==13:67
looking at parent device '/class/input/input3':
KERNELS==input3
SUBSYSTEMS==input
DRIVERS==
ATTRS{uniq}==
ATTRS{phys}==pci-:04:09.0/ir0
ATTRS{name}==cx88 IR _Hauppauge WinTV-HVR130
looking at parent device '/devices/pci:00/:00:10.0/:04:09.0':
KERNELS==:04:09.0
SUBSYSTEMS==pci
DRIVERS==cx8800
ATTRS{msi_bus}==
ATTRS{broken_parity_status}==0
ATTRS{enable}==1
ATTRS{modalias}==pci:v14F1d8800sv0070sd9601bc04sc00i00
ATTRS{local_cpus}==ff
ATTRS{irq}==21
ATTRS{class}==0x04
ATTRS{subsystem_device}==0x9601
ATTRS{subsystem_vendor}==0x0070
ATTRS{device}==0x8800
ATTRS{vendor}==0x14f1
mythtv - ~ # udevinfo -a -p $(udevinfo -q path -n /dev/event3)
looking at device '/class/input/input3/event3':
KERNEL==event3
SUBSYSTEM==input
DRIVER==
ATTR{dev}==13:67
looking at parent device '/class/input/input3':
KERNELS==input3
SUBSYSTEMS==input
DRIVERS==
ATTRS{uniq}==
ATTRS{phys}==pci-:04:09.0/ir0
ATTRS{name}==cx88 IR _Hauppauge WinTV-HVR130
looking at parent device '/devices/pci:00/:00:10.0/:04:09.0':
KERNELS==:04:09.0
SUBSYSTEMS==pci
DRIVERS==cx8800
ATTRS{msi_bus}==
ATTRS{broken_parity_status}==0
ATTRS{enable}==1
ATTRS{modalias}==pci:v14F1d8800sv0070sd9601bc04sc00i00
ATTRS{local_cpus}==ff
ATTRS{irq}==21
ATTRS{class}==0x04
ATTRS{subsystem_device}==0x9601
ATTRS{subsystem_vendor}==0x0070
ATTRS{device}==0x8800
ATTRS{vendor}==0x14f1
looking at parent device '/devices/pci:00/:00:10.0':
KERNELS==:00:10.0
SUBSYSTEMS==pci
DRIVERS==
ATTRS{msi_bus}==1
ATTRS{broken_parity_status}==0
ATTRS{enable}==1
ATTRS{modalias}==pci:v10DEd026Fsvsdbc06sc04i01
ATTRS{local_cpus}==ff
ATTRS{irq}==0
ATTRS{class}==0x060401
ATTRS{subsystem_device}==0x
ATTRS{subsystem_vendor}==0x
ATTRS{device}==0x026f
ATTRS{vendor}==0x10de
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
mythtv - ~ # lspci -v
04:09.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio
Decoder (rev 05)
Subsystem: Hauppauge computer works Inc. Unknown device 9601
Flags: bus master, medium devsel, latency 32, IRQ 21
Memory at fa00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
04:09.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio
Decoder [Audio Port] (rev 05)
Subsystem: Hauppauge computer works Inc. Unknown device 9601
Flags: bus master, medium devsel, latency 32, IRQ 21
Memory at f900 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
04:09.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio
Decoder [MPEG Port] (rev 05)
Subsystem:
[linux-dvb] No Frontend
I have a KWorld DVB-T 300U (identical to the ADSTech PTV-333) but when I plug it in I dont get a frontend registered. I was using Ubuntu Edgy and for 3 or 4 days it worked perfectly, just plugged it in and it worked. Then it stopped working and nothing seemed to help. I installed the V4L drivers and this didn't help. I have since done a clean install of Ubuntu Fiesty hoping that this may fix the problem but it hasn't. In dmesg I still get the following: [17289667.668000] usb 5-6: new high speed USB device using ehci_hcd and address 11 [17289667.80] usb 5-6: configuration #1 chosen from 1 choice [17289667.80] dvb-usb: found a 'KWorld Xpert DVB-T USB2.0' in cold state, will try to load a firmware [17289667.844000] dvb-usb: downloading firmware from file 'dvb-usb-adstech-usb2-02.fw' [17289667.932000] usb 5-6: USB disconnect, address 11 [17289667.932000] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [17289669.684000] usb 5-6: new high speed USB device using ehci_hcd and address 12 [17289669.816000] usb 5-6: configuration #1 chosen from 1 choice [17289669.816000] dvb-usb: found a 'KWorld/ADSTech Instant DVB-T USB2.0' in warm state. [17289669.816000] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [17289669.816000] DVB: registering new adapter (KWorld/ADSTech Instant DVB-T USB2.0). [17289669.816000] dvb-usb: no frontend was attached by 'KWorld/ADSTech Instant DVB-T USB2.0' [17289669.816000] input: IR-receiver inside an USB DVB receiver as /class/input/input6 [17289669.816000] dvb-usb: schedule remote query interval to 150 msecs. [17289669.816000] dvb-usb: KWorld/ADSTech Instant DVB-T USB2.0 successfully initialized and connected. Please can someone point me in the right direction! Thanks. Dom d o m / b r y a n t title:// Software.Developer location:// BAE.Systems / Christchurch tel:// 01202 / 404111 mob:// 07793 / 423201 Sent by BAE Systems plc or a member of the BAE Systems group of companies BAE Systems plc A company registered in England and Wales Company Number 1470151 Registered Office: 6 Carlton Gardens, London SW1Y 5AD, United Kingdom This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problems with KNC1 DVB-C
e9hack wrote: Oliver Endriss wrote: Apparently it works in polling mode, but not in interrupt mode. Why? Can someone else confirm problems with this card type (Terratec Cinergy 1200 DVB-C, sub-system 0x153b:0x1156)? Now I consider the following options: - Add a module parameter to disable irq mode. - Turn off irq mode for card type 0x153b:0x1156. - Turn off irq mode for the TDA10021 frontend. - Revert to polling mode for all cards. :-( Any opinions? The windows driver uses a reduced i2c bit rate. I've reduced the bit rate with the patch for the new DVB-C cards. Possible, it does solve the problem. - Hartmut Original start configuration: dual PIII with KNC-1, as well as 2 DVB-S cards, running 2.6.19.1 Was running with mild problems: the CAM on the KNC-1 was loosing sync. P4 with Terratec Synergy, mostly being used for TS recordings. No apparent problems, running older kernel. Then i got problems with the KNC-1, in that suddenly i could still tune but no longer got any data off the card. Action 1: swap KNC-1 and Terratec. Result 1: PIII system still giving same problems P4 system with KNC-1 doing well. Action2: thinking i was facing some weird application problem, i took an older Mythtv, build that on the P4 as a separate test system for DVB-C and slowly upgraded to most recent SVN head. Result2: no problem found Action3: upgrade the PIII to 2.6.21.1 Result3: The DVB-S cards work quit well (although diseqc seems to give intermitent problems), Terratec lost interupts, showing in i2c problems (see this thread). Action4: Implement patch from Oliver Endriss. Result4: On the dual PIII i2c works again, tuning works but i cannot get any data from the card.. Action5: upgrade the P4 to unpatched 2.6.21.1 Result5: The P4 with the KNC-1 works without problems. At request i am willing to swap the Terratec and the KNC-1 to double verify the terratec also behaves well in the P4 with unpatched 2.6.21.1 Provisional conclusion: The dual PIII is having interupt problems, most likely at least one PCI slot is no longer working correctly on interrupt level. I am saying at least one PCI as i suspect the intermittent diseqc problems can also be caused by missing interupts. Next action not yet known If anyone has a suggestion on how to test for problems on the other PCI slots, i'd be happy to know that. Cheers, Rudy ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Sun, 29 Apr 2007 18:37:00 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Linus Torvalds wrote: On Sun, 29 Apr 2007, Uwe Bugla wrote: BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab: You never explained what the problem even was, apart from compiling in some code that you didn't need to before. Didn't it work in the end? If it worked, I don't see what the big issue was. You are getting a _lot_ of other code in the kernel that you probably never use, you may not even have realized. I'd like to explain this a bit, for people seeing these messages who haven't been following this part of dvb development. dvb-pll is a simple driver for a number of I2C tuners, which are used in many many TV cards. These are simple devices, and drivers for host controllers (which usually support quite a few different models of tv card based on the same core chip) often didn't use dvb-pll. They would just re-implement an I2C tuner driver, sometimes more than once in the same file! The dvb tree ended up with over a dozen different re-implementations of the same basic tuner driver. Of course each implementation would have different bugs, quirks, and missing features. So we've been removing this code and using dvb-pll. If you look at some of my patches to do this: 14 files changed, 14 insertions(+), 199 deletions(-) 1 files changed, 4 insertions(+), 34 deletions(-) 4 files changed, 17 insertions(+), 204 deletions(-) These patches fixed bugs and added features, yet are very much net negative when if comes to lines of code in the kernel. any chance to deselect the compilation of the dvb-pll.c-module, as its deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1. dvb-pll has nothing to do with VIDEO_V4L1_COMPAT or VIDEO_V4L1. Uwe is just confused about what is causing what. Hi, I am NO WAY confused about what is causing what - I only wrote down what I say trying to compile 2.6.21-git2! Once again, and for the last time definitely, even if you do not want to perceive what goddamn crap you have produced, Mr. Piepho: If I want to compile drivers for a specific card ( let us call it Pinnacle PCTV SAT or TwinHan DST - just to mention two examples ) I a. need to say yes to VIEDO_V4L1 b. CANNOT deselect dvb-pll.c (Generic pll) exactly knowing that the PCTV SAT or the TwinHan DST DO NOT need dvb-pll.c. c. am trapped by still existing exported symbols like dvb_pll_lg_tdvs_h06xf in backend module dvb-bt8xx.c (line 614), which have never been a problem before this catastrophic rollback caused by you, Mr. Piepho! d. do not see any chance to get rid of static dependencies connected with dvb-pll.c because your work is reactionary and a regression, nothing else. Conclusion: Linus, I would appreciate you to rip this stuff out of git2, as long as there is no compromise solution that I can live with. This work, done by Mr. Piepho is very buggy, and buggy stuff like this does not belong into mainline. All the almost excellent work that Michael Krufky has offered for that issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber exactly) is being wiped out and rolled back with his acknowledgement! Uwe is probably talking about the dvb_attach() system, written mainly by Andrew de Quincey and myself, which went into 2.6.18. The basic concept is that a core driver uses symbol_request() to avoid any strong references to its helper drivers. This way only the helper drivers that are actually needed must be loaded. We want to make dvb-pll use this system too, but it doesn't fully work yet. I have several ideas about how to solve the problem, but it's not a high priority. YUP. And as long as this is not finished this stuff has absolutely no place in mainline vanilla. Basta! All you need is to offer a possibility to deselection for dvb-pll.c for cards that never neede it! As lang as you cannot offer this or do not want to offer this there is no place in mainline for that crap work. The dvb_attach() system worked almost perfectly optimized ( as far as RAM consommation is concerned) for me and a couple of other cards, until you Mr. Piepho, came up and offered this utmost regessive work. It is a shame that buggy stuff like this can reach the mainline. When I first saw it I could not trust my eyes. But seeing the complete personal situation @ linuxtv.org - well: Who wonders?? Anything is possible, even if its quality is horrible. Uwe -- Feel free - 10 GB Mailbox, 100
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure.
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure.
[linux-dvb] Problem with IR-Remote (black) Technotrend DVB-C 1500
Hello, i try to get the IR-remote control to run. The card is detected and the appropriate kernel modules are loaded (as far as i can see). The IR control is mapped to /dev/input/event4 (as can be seen in /proc/bus/input/devices). But a cat /dev/input/event4 does not print anything when i press keys on the remote control. Any hints ? Some data: Kernel version is 2.6.20 (in fact Gentoo 2.6.20-gentoo-r7) /var/log/messages says: cut --- saa7146: register extension 'budget_ci dvb'. ACPI: PCI Interrupt :00:0b.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 saa7146: found saa7146 @ mem e0856000 (revision 1, irq 10) (0x13c2,0x1010). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (TT-Budget-C-CI PCI). adapter has MAC addr = 00:d0:5c:67:c2:51 input: Budget-CI dvb ir receiver saa7146 (0) as /class/input/input4 DVB: registering frontend 0 (ST STV0297 DVB-C)... cut --- I have loaded the module with option ir_debug=1 to see whether the remote codes are detected: cut --- ... budget_ci: received command byte 0xc3 budget_ci: received device byte 0xb5 budget_ci: received command byte 0x43 budget_ci: received device byte 0x35 budget_ci: received command byte 0xd8 budget_ci: received device byte 0x95 budget_ci: received command byte 0x44 budget_ci: received device byte 0x35 budget_ci: received command byte 0xc4 budget_ci: received device byte 0xb5 ... cut --- evdev is compiled into the kernel. It seems that the budget-ci kernel module gets the key presses, but somewhere between there and the evdev they disappears. What else can i do to track down the issue. kind regards Petric ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost
Re: [linux-dvb] Problems with KNC1 DVB-C
Rudy Zijlstra wrote: e9hack wrote: Oliver Endriss wrote: Apparently it works in polling mode, but not in interrupt mode. Why? Can someone else confirm problems with this card type (Terratec Cinergy 1200 DVB-C, sub-system 0x153b:0x1156)? Now I consider the following options: - Add a module parameter to disable irq mode. - Turn off irq mode for card type 0x153b:0x1156. - Turn off irq mode for the TDA10021 frontend. - Revert to polling mode for all cards. :-( Any opinions? The windows driver uses a reduced i2c bit rate. I've reduced the bit rate with the patch for the new DVB-C cards. Possible, it does solve the problem. - Hartmut Original start configuration: dual PIII with KNC-1, as well as 2 DVB-S cards, running 2.6.19.1 Was running with mild problems: the CAM on the KNC-1 was loosing sync. P4 with Terratec Synergy, mostly being used for TS recordings. No apparent problems, running older kernel. Then i got problems with the KNC-1, in that suddenly i could still tune but no longer got any data off the card. Action 1: swap KNC-1 and Terratec. Result 1: PIII system still giving same problems P4 system with KNC-1 doing well. Action2: thinking i was facing some weird application problem, i took an older Mythtv, build that on the P4 as a separate test system for DVB-C and slowly upgraded to most recent SVN head. Result2: no problem found Action3: upgrade the PIII to 2.6.21.1 Result3: The DVB-S cards work quit well (although diseqc seems to give intermitent problems), Terratec lost interupts, showing in i2c problems (see this thread). Action4: Implement patch from Oliver Endriss. Result4: On the dual PIII i2c works again, tuning works but i cannot get any data from the card.. Action5: upgrade the P4 to unpatched 2.6.21.1 Result5: The P4 with the KNC-1 works without problems. At request i am willing to swap the Terratec and the KNC-1 to double verify the terratec also behaves well in the P4 with unpatched 2.6.21.1 Provisional conclusion: The dual PIII is having interupt problems, most likely at least one PCI slot is no longer working correctly on interrupt level. I am saying at least one PCI as i suspect the intermittent diseqc problems can also be caused by missing interupts. Next action not yet known If anyone has a suggestion on how to test for problems on the other PCI slots, i'd be happy to know that. Cheers, Rudy Some additional information. Changing the cards in PCI slots made no difference. Then i remembered i had disabled ACPI on this system, after previous IRQ problems. Enabling ACPI resulted in better behaviour. After a while i still seem to get lost interrupts though. (i get hickups in the stream). So it seems a Netfinity 5000 can handle 2 DVB cards, and with some trouble 3. But above 2 it seems to get less stable. Unless this is a kernel level IRQ routing problem? Cheers, Rudy ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 15:06:11 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you.
[linux-dvb] Msi DigiVOX A/D II compatibility
Hi everybory I saw that the Msi DigiVOX A/D pctv hybrid card works on linux; is it the same for the Msi DigiVOX A/D II version ? Has it the same em2880 module as the previous version? Did someone ever install it? thank you Clhona ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 07:49:52 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Markus Rechberger [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Uwe Bugla wrote: So please Linus - rip that crap out of 2.6.21-git2. And if you do see questions what parts you need to rip out, please feel free to ask me Uwe. I'll say this ONCE more. No. Sorry! Sigh! Very utmost bad decision, but I must respect it. The accumulative principle is the opposite of effectiveness. Even if you do not understand the dvb issues in git2 (well I cannot expect this, can I?), you push a. immature code b. a regression Isn't it a pity that the maintainer title has more influence than any kind of common sense, reason or sophisticated argumentation? What a horrible thought! P. S.: In former kernel releases the specific last release candidate was almost identical to the official kernel release. Not only I have largest problems to understand why this wonderful principle has been broken, with the effect, that the so-called stable kernel releases are unusable in the end. 2.6.20, 2.6.21, 2.6.19, and may be former ones that I do not know about. A Final release should be round, but never in this life highly incomplete, shouldn't it?? And unless you can become politer and more respectful and stop ranting all the time, you'll be in the very rare situation of hitting my auto-filters and going into an email mbox of your own (read: one that I read in my copious spare time. Hint: I don't _have_ any.) Linus Poor Linus! I have got thousands of good reasons to be so rude towards some people. And I certainly know the smart polite way of the game too. I know both ways of dealing with. But if someone continues to nerve me for such a long time (whoever the specified person may be) I get out the big stick and then there will be bambule pure! Excuse me, you are only finnish origin: Bambule is an invention of Ulrike Meinhof and other 68ers and stands for revolt or something similar. BTW: Wasn't it you yourself stating that if one wants changes it is not always useful to be polite?? If you want to change something, it's not fine to be entirely polite all the time: (Linus Torvalds, March 6, 2007, 09:57:34, public Email). Happy reflection, Mister Torvalds! Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Uwe Bugla wrote: And I swear that this dvb-pll.c is completely obsolete for this scenario! For that reason (old variant): # CONFIG_DVB_TUNER_LGH06XF is not set And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey, but it was produced by Michael Krufky himself, and I was very thankful for that and still am! [...] And why the hell is that dvb-pll.c rollback part of git2 now? Additionally - with the acknowlegdement of Michael Krufky - incredible! The LG-H06xF NIM is slightly different from the other tuners supported by the dvb-pll library, in that it requires a 5th auxiliary byte, as opposed to only four bytes that are sent for all of the other devices supported by dvb-pll. In order to handle this, I had created a separate module, called lgh06xf. This module was able to re-use some code inside the dvb-pll module, while adding the additional required code to handle that 5th byte. As a side effect, caused by the creation of the lgh06xf module, the static dependency of dvb-bt8xx on dvb-pll was removed. Instead of dvb-bt8xx having to call dvb_pll_configure, causing the static dependency, it would now call lgh06xf_attach. lgh06xf_attach would fill the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the lgh06xf module. This change was done in an effort to improve support for the LG-TDVS-H06xF NIM family... The removal of the static dependency of dvb-bt8xx on dvb-pll was merely a side effect. I DID NOT DO THIS FOR YOUR BENEFIT, UWE. There is always a chance that a new bt8xx-based card may come around with a new tuner, and need the dvb-pll module in order to work properly. Then, Trent suggested that we add this 5th byte functionality to dvb-pll. Trent has shown us how this 5th byte is helpful for other devices, including the Thomson DTT 761X, and the Philips FMD1216ME, among others. Trent made the appropriate changes to the dvb-pll module, allowing it to absorb the functionality of the lgh06xf module into a centralized location, so that any other tuners can benefit from this shared code. Trent did a great thing here, by making the dvb-pll module a much more robust library, not to mention that his changes have in fact REDUCED the size of the kernel. (see Trent's earlier post in this thread) Uwe, this is quite a silly argument. You've been singing the same song ever since before I got involved with linuxtv.org, and quite frankly, I am sick of it. Let it be known to the world, that Uwe has praised me in his previous emails, as I have kept quiet and ignored his rants. Now that I am finally opening up my mouth, I am quite sure that I will be his next flame target. Nobody can take this kind of behavior seriously -- the only thing we can do is ignore you, and maybe you'll go away. My suggestion to you, Uwe, is to stop flaming the lists, and stop bothering us developers. Your devices work. You are complaining about wasted memory -- get over it. It is a small price to pay for globally supported devices and autodetection. You should be happy that people are still here working on this code. It seems that your emails are focused at driving away developers -- nothing more could be gained by this, then everybody is screwed. If your patches were correct, then, by all means, we would apply them. However, developers have pointed out problems in your patches, and you have done nothing but flame them. Who wants to continue a discussion with you, after only being flamed? I sure don't. Just know that if you respond to this email with yet another flame, I will simply ignore it. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch] Trivial: Enable DiSEqC in Starbox II (vp7021a)
Having used this patch against multiple kernels starting at 2.6.17, and
having shared it with others and they have all had success, I would like
to see it merged into mainline. It only uncomments code that was
already there.
Pat Erley
--- linux-2.6.21-gentoo-orig/drivers/media/dvb/dvb-usb/vp702x-fe.c 2007-04-27 19:58:02.0 -0400
+++ linux-2.6.21-gentoo/drivers/media/dvb/dvb-usb/vp702x-fe.c 2007-04-30 11:21:21.0 -0400
@@ -204,8 +204,8 @@
static int vp702x_fe_send_diseqc_msg (struct dvb_frontend* fe,
struct dvb_diseqc_master_cmd *m)
{
- //struct vp702x_fe_state *st = fe-demodulator_priv;
- u8 cmd[8];//,ibuf[10];
+ struct vp702x_fe_state *st = fe-demodulator_priv;
+ u8 cmd[8],ibuf[10];
memset(cmd,0,8);
deb_fe(%s\n,__FUNCTION__);
@@ -218,12 +218,12 @@
memcpy(cmd[3], m-msg, m-msg_len);
cmd[7] = vp702x_chksum(cmd,0,7);
-// vp702x_usb_inout_op(st-d,cmd,8,ibuf,10,100);
+ vp702x_usb_inout_op(st-d,cmd,8,ibuf,10,100);
-// if (ibuf[2] == 0 ibuf[3] == 0)
-// deb_fe(diseqc cmd failed.\n);
-// else
-// deb_fe(diseqc cmd succeeded.\n);
+ if (ibuf[2] == 0 ibuf[3] == 0)
+ deb_fe(diseqc cmd failed.\n);
+ else
+ deb_fe(diseqc cmd succeeded.\n);
return 0;
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] Trivial: Enable DiSEqC in Starbox II (vp7021a)
Hi can you please send your Signed-off-by-line so that we can accept the patch. thanks, Patrick. On Mon, 30 Apr 2007, pat-lkml wrote: Having used this patch against multiple kernels starting at 2.6.17, and having shared it with others and they have all had success, I would like to see it merged into mainline. It only uncomments code that was already there. Pat Erley ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] Trivial: Enable DiSEqC in Starbox II (vp7021a)
Uncomments code in vp702x-fe.c to enable DiSEqC in vp7021a
Signed-off-by: Pat Erley [EMAIL PROTECTED]
--- linux-2.6.21-gentoo-orig/drivers/media/dvb/dvb-usb/vp702x-fe.c 2007-04-27 19:58:02.0 -0400
+++ linux-2.6.21-gentoo/drivers/media/dvb/dvb-usb/vp702x-fe.c 2007-04-30 11:21:21.0 -0400
@@ -204,8 +204,8 @@
static int vp702x_fe_send_diseqc_msg (struct dvb_frontend* fe,
struct dvb_diseqc_master_cmd *m)
{
- //struct vp702x_fe_state *st = fe-demodulator_priv;
- u8 cmd[8];//,ibuf[10];
+ struct vp702x_fe_state *st = fe-demodulator_priv;
+ u8 cmd[8],ibuf[10];
memset(cmd,0,8);
deb_fe(%s\n,__FUNCTION__);
@@ -218,12 +218,12 @@
memcpy(cmd[3], m-msg, m-msg_len);
cmd[7] = vp702x_chksum(cmd,0,7);
-// vp702x_usb_inout_op(st-d,cmd,8,ibuf,10,100);
+ vp702x_usb_inout_op(st-d,cmd,8,ibuf,10,100);
-// if (ibuf[2] == 0 ibuf[3] == 0)
-// deb_fe(diseqc cmd failed.\n);
-// else
-// deb_fe(diseqc cmd succeeded.\n);
+ if (ibuf[2] == 0 ibuf[3] == 0)
+ deb_fe(diseqc cmd failed.\n);
+ else
+ deb_fe(diseqc cmd succeeded.\n);
return 0;
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 11:30:34 -0400 Von: Michael Krufky [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Markus Rechberger [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], Trent Piepho [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Uwe Bugla wrote: And I swear that this dvb-pll.c is completely obsolete for this scenario! For that reason (old variant): # CONFIG_DVB_TUNER_LGH06XF is not set And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey, but it was produced by Michael Krufky himself, and I was very thankful for that and still am! [...] And why the hell is that dvb-pll.c rollback part of git2 now? Additionally - with the acknowlegdement of Michael Krufky - incredible! The LG-H06xF NIM is slightly different from the other tuners supported by the dvb-pll library, in that it requires a 5th auxiliary byte, as opposed to only four bytes that are sent for all of the other devices supported by dvb-pll. In order to handle this, I had created a separate module, called lgh06xf. This module was able to re-use some code inside the dvb-pll module, while adding the additional required code to handle that 5th byte. As a side effect, caused by the creation of the lgh06xf module, the static dependency of dvb-bt8xx on dvb-pll was removed. Instead of dvb-bt8xx having to call dvb_pll_configure, causing the static dependency, it would now call lgh06xf_attach. lgh06xf_attach would fill the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the lgh06xf module. This change was done in an effort to improve support for the LG-TDVS-H06xF NIM family... The removal of the static dependency of dvb-bt8xx on dvb-pll was merely a side effect. I DID NOT DO THIS FOR YOUR BENEFIT, UWE. There is always a chance that a new bt8xx-based card may come around with a new tuner, and need the dvb-pll module in order to work properly. Then, Trent suggested that we add this 5th byte functionality to dvb-pll. Trent has shown us how this 5th byte is helpful for other devices, including the Thomson DTT 761X, and the Philips FMD1216ME, among others. Trent made the appropriate changes to the dvb-pll module, allowing it to absorb the functionality of the lgh06xf module into a centralized location, so that any other tuners can benefit from this shared code. Trent did a great thing here, by making the dvb-pll module a much more robust library, not to mention that his changes have in fact REDUCED the size of the kernel. (see Trent's earlier post in this thread) Uwe, this is quite a silly argument. You've been singing the same song ever since before I got involved with linuxtv.org, and quite frankly, I am sick of it. Let it be known to the world, that Uwe has praised me in his previous emails, as I have kept quiet and ignored his rants. Now that I am finally opening up my mouth, I am quite sure that I will be his next flame target. Nobody can take this kind of behavior seriously -- the only thing we can do is ignore you, and maybe you'll go away. My suggestion to you, Uwe, is to stop flaming the lists, and stop bothering us developers. Your devices work. You are complaining about wasted memory -- get over it. It is a small price to pay for globally supported devices and autodetection. Hi Mike, first of all thank you for explainig us all the context - well done! I spent some 4 hours yesterday to try to find a compromise solution as Trent Piepho ignored my criticism, which is no fine behaviour at all. Even if you do not believe I even managed to nearly complete a compromise, making dvb-pll.c deselectable for both of the v4l layers. I only stumbled over line 614 of module dvb-bt8xx.c in current 2.6.21-git2 kernel. For this static dependency concerning support for the Fusion HDTV 5 Lite card I did not manage to find out a solution how to get rid of. I think I will send my stuff to Markus who already offered to help me to work this out. So there is no small price to pay at all if one knows how to resolve it. It's quite simple in fact - I am just missing the appropriate thought kick. You should be happy that people are still here working on this code. It seems that your emails are focused at driving away developers -- nothing more could be gained by this, then everybody is screwed. If your patches were correct, then, by all means, we would apply them. However, developers have pointed out problems in your patches, and you have done nothing but flame them. Who wants to continue a discussion with you, after only being flamed? I sure don't. Again I state: I haven't found any unresolved symbols caused by my DST deselection patches. Even if Mauro Chehab repeats that like a parrot it is like an air bubble on my testing side: empty,
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 17:56:17 +0100 (BST) Von: Mauro Carvalho Chehab [EMAIL PROTECTED] An: Helge Hafting [EMAIL PROTECTED] CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Hi Helge and others, On Mon, 30 Apr 2007, Helge Hafting wrote: what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months. ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise. A sufficiently bad maintainer will also do it. If lots of submitters send their patches to andrew in order to get past a dysfunctional maintainer, then the subsystem effectively is unmaintained. The point is that Uwe patch will generate regressions by breaking for Twinhan. His patch just removes compilation for dst and dst_ca on Kconfig, without taking care or driver internals. So, two initialization functions won't be called by symbol_request(). Although those two functions will be undefined, as the dvb will do the linkedition at module runtume (if DVB_ATTACH is selected), modprobe won't detect the lack of those functions. At the end, cards with ST chips (DST and/or DST CA) will stop working, without even printing a warning. Mister Chehab, for the first and for the utmost last time now: My deselection patch implies a very good text to strongly discourage the use of DST and DST_CA in case someone does not know what he or she is doing. In so far the case that cards with ST chips (DST and/ or DST CA) will stop working will not happen at all. This patch IS NOT DONE TO MAKE ANY DST OR DST_CA MODULE REQUIRING CARD WORK - THIS IS YOUR PART OF SO-CALLED LOGIC THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL Example: Pinnacle PCTV SAT!!! And once again and for the last time: I did not manage to at least find one single unresolved module during compilation, and I have been working with this almost fantastic solution with several kernels for months now! Above that I gave you every proof one can ever give: You received dmesg, you received configs, you received proven thesis, you received everything. It would really be a perfect solution to bomb away the almost incredible meters thick wall in front of your head and your eyes. And at this time I will stop responding to your mails - I got enough of you!!! It's enough!! I've tried to explain this to Uwe several times, but, at the end, he always start insulting me and/or other developers. Cheers, Mauro. Happy reflection, Mister Chehab! -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [PATCH] Re: More than 2Gb problem (dvb related) ?
On Mon, 2007-04-30 at 18:52 +0200, Gregoire Favre wrote: On Sat, Apr 28, 2007 at 09:14:37PM +0100, Jon Burgess wrote: While the above patch works, it seems the underlying causes is that vmalloc_32() is providing memory above 4Gb on x86-64 which is not what the driver expects. This same issue came up a few weeks ago with regards to DRM on radeon http://lkml.org/lkml/2007/4/1/257 Andi Kleen included a patch to ensure vmalloc_32() returns memory 4Gb in a patch which is currently in -mm http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-vmalloc-32.patch With this patch applied the current driver appears to work OK. Attached is a smaller patch against v4l-dvb which just adds the missing pci_unmap_sg() call. I was using 2.6.20.1 with the x86_64-mm-vmalloc-32.patch and you small patch : working but not perftctly stable. So I compiled 2.6.21-rc7-mm2 and at boot I got a problem : ksymoops dmesg-2.6.21-rc7-mm2-4Gb.txt ksymoops 2.4.11 on x86_64 2.6.21-rc7-mm2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.21-rc7-mm2/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod SGI XFS with large block/inode numbers, no debug enabled ehci_hcd :00:1a.7: debug port 1 ehci_hcd :00:1d.7: debug port 1 kernel BUG at mm/slab.c:2766! CPU 1 Pid: 6616, comm: cx88[0] dvb Tainted: P 2.6.21-rc7-mm2 #1 RIP: 0010:[802608e5] [802608e5] cache_alloc_refill+0x495/0x560 Using defaults from ksymoops -t elf64-x86-64 -a i386:x86-64 RSP: :8101045dfd50 EFLAGS: 00010002 RAX: RBX: 003c RCX: RDX: 81010006a400 RSI: 0004 RDI: 81010001c180 RBP: 81010006a400 R08: R09: 0004 R10: 0020 R11: 0001 R12: 81010001e2c0 R13: 81010001c140 R14: R15: 8101b000 FS: () GS:810100027540() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2aaab0a9ea18 CR3: 00201000 CR4: 06e0 Stack: 00021024 81010001c180 810100054060 c204 0286 0030 810102b83140 6000 0004 81010241c0e0 802c95b8 Call Trace: [802c95b8] __kmalloc+0x68/0x70 [802c19e7] __vmalloc_area_node+0x157/0x1a0 [880bc8a0] :video_buf:videobuf_dma_init_kernel+0x50/0xd0 [880bcdbe] :video_buf:videobuf_iolock+0xbe/0xf0 [880fc07e] :cx8802:cx8802_buf_prepare+0xde/0x130 [880bc0c7] :video_buf:videobuf_read_start+0xc7/0x170 [880c23b0] :video_buf_dvb:videobuf_dvb_thread+0x0/0x190 [880c23e9] :video_buf_dvb:videobuf_dvb_thread+0x39/0x190 [880c23b0] :video_buf_dvb:videobuf_dvb_thread+0x0/0x190 [802342eb] kthread+0x4b/0x80 [802622a8] child_rip+0xa/0x12 [802342a0] kthread+0x0/0x80 [8026229e] child_rip+0x0/0x12 Code: 0f 0b eb fe 0f 0b eb fe 41 8b 44 24 30 a8 01 0f 84 ed fd ff RIP; 802608e5 cache_alloc_refill+495/560 = RDX; 81010006a400 phys_startup_64+8100ffe6a400/8000 RDI; 81010001c180 phys_startup_64+8100ffe1c180/8000 RBP; 81010006a400 phys_startup_64+8100ffe6a400/8000 R08; phys_startup_64+ffdf/8000 R12; 81010001e2c0 phys_startup_64+8100ffe1e2c0/8000 R13; 81010001c140 phys_startup_64+8100ffe1c140/8000 R15; 8101b000 phys_startup_64+8100ffe0b000/8000 Trace; 802c95b8 __kmalloc+68/70 Trace; 802c19e7 __vmalloc_area_node+157/1a0 Trace; 880bc8a0 _end+79f1b1c/7ef3527c Trace; 880bcdbe _end+79f203a/7ef3527c Trace; 880fc07e _end+7a312fa/7ef3527c Trace; 880bc0c7 _end+79f1343/7ef3527c Trace; 880c23b0 _end+79f762c/7ef3527c Trace; 880c23e9 _end+79f7665/7ef3527c Trace; 880c23b0 _end+79f762c/7ef3527c Trace; 802342eb kthread+4b/80 Trace; 802622a8 child_rip+a/12 Trace; 802342a0 kthread+0/80 Trace; 8026229e child_rip+0/12 Code; 802608e5 cache_alloc_refill+495/560
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 11:04:36 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Mauro Carvalho Chehab [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Uwe, you just made my kill-list. I've not actually done that in _years_. So you can feel proud. Your emails will get automatically filtered to their own (ignored) folder. I told you why, and you didn't seem to understand at all. Linus Wrong, but understandable reaction. But I have found somebody to help me to get this thing solved - in so far: counterproductive from your side! Cheers Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [dvbtools-devel] dvbtune-0.5 inverts diseqc pol and band bits
Zoilo Gomez wrote: dvbtune-0.5 source apparently contains a bug where it inverts both the polarization and high/low band bits in the diseqc command ... as I cannot find any info on this anywhere, I am posting my results here. I discovered this while using a KNC1 DVB-S card to compare diseqc handling with VP1034 (because diseqc is not (yet) working on my VP1034). I am using a Spaun 17089-NF 16-input switch (4 sats) + 8 outputs, which supports up to Diseqc 2.0. First I got confused, because the Mantis driver simultaneously uses the old 18/13V+22kHz method to control polarization and band, as well as the Diseqc method. So for a while I believed that Diseqc was (partially) working, until I found out that in fact 18/13V+22kHz seems to be responsible for the (partial) job! As a result of no Diseqc-functionality on VP1034, it seems that with VP1034 on my switch, sat-selection is always fixed to sat=1 (makes sense, = the first 4 inputs, which happens to be Hotbird 13.0E in my setup), however input selection from the 4 feeds V/H and H/L works fine and correctly, although based on 18/13V+22kHz. When I compared this with my KNC-1 DVB-S card (to find out why Sat-selection is not working with VP1034), I found that with KNC1, Sat-selection does switch to Sat=2 (so it must be using diseqc), but polarization and band-selection were inverted ... So when I issued the following command: dvbtune -D 2 -f 10832000 -p H -s 22000 I found that it was actually selecting sat=2 pol=V band=H (e0 10 38 f5= switch input 7), instead of sat=2 pol=H band=L (= switch input 6 / e0 10 38 f6). The Diseqc-specs at http://www.eutelsat.com/satellites/pdf/Diseqc/Reference%20docs/bus_spec.pdf (table on page 13) confirm that dvbtune is in fact sending the wrong command. With a patched dvbtune (pol-bit and band-bit both inverted) it works OK, and is also according to the Eutelsat specs. Hope someone benefits from this. Z. nice, but i don't see the patch, but I wonder how I can have been using my sat switch for years ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 11:14:14 -0700 Von: Andrew Morton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Mauro Carvalho Chehab [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007 19:25:47 +0200 Uwe Bugla [EMAIL PROTECTED] wrote: I did not manage to at least find one single unresolved module during compilation, and I have been working with this almost fantastic solution with several kernels for months now! That isn't what Mauro is saying. What he is saying is that the missing symbols will not be reported at build time. The kernel will all link correctly and will appear to load modules correctly. See, there's a third mechanism for symbol resolution which is used at runtime, not at build time: symbol_request(). What Mauro is saying is that these changes will cause symbol_request() to return different results on some people's setups with different hardware, causing those setups to fail. Hi Andrew, But, even if this is the case, it should be transparent WHAT DIFFERENT HARDWARE IS MEANT EXACTLY! DST AND DST_CA CANNOT BE MEANT - this I have made quite shure! I swear I did not notice any errors - so as long as I cannot see through where the problem is, and as long as I have been working with my patches without the slightest noise for months now - where should I apply some additions then? See, there's a third mechanism for symbol resolution which is used at runtime, not at build time: symbol_request(). If this symbol_request() appears at runtime, then there should be some feedback in dmesg or any other kind of syslog. But I swear I haven't seen any kind of bad or counterproductive messages like this! My system runs excelent with my patches - so why should I care? I meanwhile have sent my patches to someone, he will have a look at them - and we all will see what happens then. Above that I will at least try to enhance those two patches by a dvb-pll.c deselection feature which I said very politely to Trent that I am missing it. And I want to get out now of that horrible discussion - I am exhausted. Cheers Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216me integration (fwd)
Trent Piepho wrote:
Here's my latest patch for fmd1216me integration into dvb-pll. It's little
changed from when I posted it three weeks ago, except for cxusb which is
now part of the patch.
I'm going to try to get it into mainline soon for the 2.6.22 window, so if
there are comments now is the time.
This patch is quite a nice cleanup of the handling of the fmd1216me tuner. The
change looks more than fine to me. Would be nice to see an Ack from Hartmut,
but I see no harm can come from applying this patch.
Signed-off-by: Michael Krufky [EMAIL PROTECTED]
-
Integrate all users of the fmd1216 tuner with dvb-pll
From: Trent Piepho [EMAIL PROTECTED]
Enhance the dvb-pll definition of the fmd1216 tuner by adding an init sequence
and a sleep sequence.
The init sequence sets the AGC control register to 0xa0, selecting the fast
time constant and 112 dBuV take-over point. This the recommended value for
DVB-T operation.
The sleep sequence sets bit P4 (which is believed to turn the analog
demodulator on), turns off the tuning voltage, and sets the AGC control
register to 0x60 (external AGC voltage, the recommended value for analog
operation).
The existing dvb-pll users in the cx88 driver, listed below, will gain these
init and sleep sequences.
CX88_BOARD_HAUPPAUGE_HVR1100Hauppauge WinTV-HVR1100 DVB-T/Hybrid
CX88_BOARD_HAUPPAUGE_HVR1100LP Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low
Profi
CX88_BOARD_WINFAST_DTV2000H WinFast DTV2000 H
CX88_BOARD_HAUPPAUGE_HVR3000Hauppauge WinTV-HVR3000 TriMode
Analog/DVB-S/DV
CX88_BOARD_HAUPPAUGE_HVR1300Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG
Encod
This non-dvb-pll user in the cx88 driver should only gain the sleep sequence,
as it already had an equivalent init sequence. The non-dvb-pll code for this
user is removed.
X88_BOARD_DNTV_LIVE_DVB_T_PRO digitalnow DNTV Live! DVB-T Pro
In these saa7134 driver, these non-dvb-pll users are converted to use dvb-pll:
SAA7134_BOARD_MD7134Medion 7134
SAA7134_BOARD_ASUS_EUROPA2_HYBRID Asus Europa2 OEM
The saa7134 functions philips_fmd1216_tuner_init(),
philips_fmd1216_tuner_sleep(), and philips_fmd1216_tuner_set_params() are
deleted and the dvb-pll versions are used.
This should result in equivalent sleep, init, and tuning sequences being sent
to the tuner.
For the cxusb driver, only one board is effected:
USB_PID_MEDION_MD95700Medion MD95700
This board used dvb_usb_tuner_init_i2c() and dvb_usb_tuner_set_params_i2c()
for init and tuning, respectively. These functions are effectively the same
as the dvb-pll versions. They call a tuner pass control function defined at
the dvb-usb level, but this does not matter, as this card does not have a
tuner pass control function (only the dib3000mb does). This board will gain
the sleep sequence, while init and tuning should be unchanged.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff --git a/linux/drivers/media/dvb/dvb-usb/cxusb.c
b/linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c
@@ -354,14 +354,8 @@ static struct mt352_config cxusb_mt352_c
/* Callbacks for DVB USB */
static int cxusb_fmd1216me_tuner_attach(struct dvb_usb_adapter *adap)
{
- u8 bpll[4] = { 0x0b, 0xdc, 0x9c, 0xa0 };
- adap-pll_addr = 0x61;
- memcpy(adap-pll_init, bpll, 4);
- adap-pll_desc = dvb_pll_fmd1216me;
-
- adap-fe-ops.tuner_ops.init = dvb_usb_tuner_init_i2c;
- adap-fe-ops.tuner_ops.set_params = dvb_usb_tuner_set_params_i2c;
-
+ dvb_attach(dvb_pll_attach, adap-fe, 0x61, adap-dev-i2c_adap,
+dvb_pll_fmd1216me);
return 0;
}
diff --git a/linux/drivers/media/dvb/frontends/dvb-pll.c
b/linux/drivers/media/dvb/frontends/dvb-pll.c
--- a/linux/drivers/media/dvb/frontends/dvb-pll.c
+++ b/linux/drivers/media/dvb/frontends/dvb-pll.c
@@ -38,6 +38,12 @@
0x50 = AGC Take over point = 103 dBuV */
static u8 tua603x_agc103[] = { 2, 0x80|0x40|0x18|0x06|0x01, 0x00|0x50 };
+/* 0x04 = 166.67 kHz divider
+
+ 0x80 = AGC Time constant 50ms Iagc = 9 uA
+ 0x20 = AGC Take over point = 112 dBuV */
+static u8 tua603x_agc112[] = { 2, 0x80|0x40|0x18|0x04|0x01, 0x80|0x20 };
+
struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
.name = Thomson dtt7579,
.min = 17700,
@@ -282,6 +288,8 @@ struct dvb_pll_desc dvb_pll_fmd1216me =
.max = 85800,
.iffreq= 36125000,
.setbw = fmd1216me_bw,
+ .initdata = tua603x_agc112,
+ .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 },
.count = 7,
.entries = {
{ 14387, 17, 0xbc, 0x41 },
diff --git a/linux/drivers/media/video/cx88/cx88-dvb.c
b/linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c
@@ -224,64
[linux-dvb] no write access to CAM? /dev/dvb/adapter0/ca0
Hi I've just added an Irdeto CI adapter to my TT-1500 Budget card. But I can't decrypt channels, and get the following errors: In /var/log/messages: Apr 30 19:31:26 media1 vdr: [2774] CAM 1: module present Apr 30 19:31:28 media1 kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Apr 30 19:31:28 media1 vdr: [2774] CAM 1: module ready Apr 30 19:31:29 media1 vdr: [2774] ERROR: can't write to CI adapter on device 0: Input/output error In dmesg: dvb_ca adapter 0: DVB CAM detected and initialised successfully dvb_ca adapter 0: DVB CAM detected and initialised successfully dvb_ca adapter 0: DVB CAM detected and initialised successfully (etc) and in the CAM menu on VDR: 1 CAM present 1 CAM ready 1 CAM present 1 CAM ready (etc) vdr-1.5.2, v4l-dvb hg snapshot from Saturday. Any ideas? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [dvbtools-devel] dvbtune-0.5 inverts diseqc pol and band bits
Nico Sabbi wrote: Zoilo Gomez wrote: dvbtune-0.5 source apparently contains a bug where it inverts both the polarization and high/low band bits in the diseqc command ... as I cannot find any info on this anywhere, I am posting my results here. I discovered this while using a KNC1 DVB-S card to compare diseqc handling with VP1034 (because diseqc is not (yet) working on my VP1034). I am using a Spaun 17089-NF 16-input switch (4 sats) + 8 outputs, which supports up to Diseqc 2.0. First I got confused, because the Mantis driver simultaneously uses the old 18/13V+22kHz method to control polarization and band, as well as the Diseqc method. So for a while I believed that Diseqc was (partially) working, until I found out that in fact 18/13V+22kHz seems to be responsible for the (partial) job! As a result of no Diseqc-functionality on VP1034, it seems that with VP1034 on my switch, sat-selection is always fixed to sat=1 (makes sense, = the first 4 inputs, which happens to be Hotbird 13.0E in my setup), however input selection from the 4 feeds V/H and H/L works fine and correctly, although based on 18/13V+22kHz. When I compared this with my KNC-1 DVB-S card (to find out why Sat-selection is not working with VP1034), I found that with KNC1, Sat-selection does switch to Sat=2 (so it must be using diseqc), but polarization and band-selection were inverted ... So when I issued the following command: dvbtune -D 2 -f 10832000 -p H -s 22000 I found that it was actually selecting sat=2 pol=V band=H (e0 10 38 f5= switch input 7), instead of sat=2 pol=H band=L (= switch input 6 / e0 10 38 f6). The Diseqc-specs at http://www.eutelsat.com/satellites/pdf/Diseqc/Reference%20docs/bus_spec.pdf (table on page 13) confirm that dvbtune is in fact sending the wrong command. With a patched dvbtune (pol-bit and band-bit both inverted) it works OK, and is also according to the Eutelsat specs. Hope someone benefits from this. Z. nice, but i don't see the patch, but I wonder how I can have been using my sat switch I have attached a patch for you. The problem is only in dvbtune (version 0.5); you may not have been using dvbtune (dvbtools); dvbscan and szap (linuxtv-dvb-apps) do not suffer from this problem. Z. diff -Naur dvbtune-0.5.orig/tune.c dvbtune-0.5/tune.c --- dvbtune-0.5.orig/tune.c 2004-02-06 15:00:36.0 +0100 +++ dvbtune-0.5/tune.c 2007-04-30 21:22:53.0 +0200 @@ -203,7 +203,7 @@ * bits are: option, position, polarizaion, band */ cmd.cmd.msg[3] = - 0xf0 | (((sat_no * 4) 0x0f) | (hi_lo ? 1 : 0) | (pol ? 0 : 2)); + 0xf0 | (((sat_no * 4) 0x0f) | (hi_lo ? 0 : 1) | (pol ? 2 : 0)); diseqc_send_msg(secfd, pol, cmd, hi_lo, ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL [...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Msi DigiVOX A/D II compatibility
On 4/30/07, Claudio Ghirlanda [EMAIL PROTECTED] wrote: Hi everybory I saw that the Msi DigiVOX A/D pctv hybrid card works on linux; is it the same for the Msi DigiVOX A/D II version ? Has it the same em2880 module as the previous version? Did someone ever install it? thank you best would be if you could ask MSI about that (chances that they'll tell you shouldn't be bad, since it's no secret information) on the em28xx project website someone took the driver for the MSI DigiVox A/D II for his MSI DigiVox A/D I em28xx device. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216me integration (fwd)
I've some question to this patch:
Trent Piepho wrote:
Include the patch this time
diff --git a/linux/drivers/media/dvb/frontends/dvb-pll.c
b/linux/drivers/media/dvb/frontends/dvb-pll.c
--- a/linux/drivers/media/dvb/frontends/dvb-pll.c
+++ b/linux/drivers/media/dvb/frontends/dvb-pll.c
@@ -38,6 +38,12 @@
0x50 = AGC Take over point = 103 dBuV */
static u8 tua603x_agc103[] = { 2, 0x80|0x40|0x18|0x06|0x01, 0x00|0x50 };
+/* 0x04 = 166.67 kHz divider
+
+ 0x80 = AGC Time constant 50ms Iagc = 9 uA
+ 0x20 = AGC Take over point = 112 dBuV */
+static u8 tua603x_agc112[] = { 2, 0x80|0x40|0x18|0x04|0x01, 0x80|0x20 };
Why is the AGC time constant set permanently to 50ms (short time)? Usually, the
AGC time constant of the tuner is set to
the short time during tuning only. After the pll lock + some time (ca. 100ms),
the AGC time constant should be switched
back to 2s (long time). If the time constant isn't changed during tuning, they
should be set to the long time.
+
struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
.name = Thomson dtt7579,
.min = 17700,
@@ -282,6 +288,8 @@ struct dvb_pll_desc dvb_pll_fmd1216me =
.max = 85800,
.iffreq= 36125000,
.setbw = fmd1216me_bw,
+ .initdata = tua603x_agc112,
+ .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 },
In sleep mode, the AGC shouldn't be set into high impedance mode. A better
solution is to disable the AGC. 0x60 should
be 0x70. In sleep mode, P0 and P1 must be set to 1. This means 0x54 should be
0x54|0x03. Why is the value of the band
switch byte 0x54? Bits 5,6 and 7 aren't used.
- Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Hi, Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb as far as I see from that patch it cleans up a memory leak which would happen when the system tries to load the dst module if it's not available and it also prints a message that points the user should enable it in the kernel if needed. It also bundles the dst and dst_ca objects to one selectable option. So the idea remains the same. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. Markus On 4/30/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 4/30/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL [...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus -- Markus Rechberger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] want to work on the Pinnacle PCTV 200e
Okay, the card has it's own page in the Wiki. Its already loaded with some information I could gather.. http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_200e Markus Rechberger wrote: Hi, can you put all your current information together onto a wikisite? It shouldn't be hard to get that device work I have the same one but I haven't had time to get my fingers on it yet... I can give you some hints what to look at in the logfiles if you put everything together somewhere. Markus On 4/28/07, Jakob Steidl [EMAIL PROTECTED] wrote: Hello, just like some other people, I want to use my above mentioned DVB-T adapter under Linux. As it seems one else is interested in writing a driver and since I've read this should be pretty easy, I think it's time to do it myself. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Asus P7131 hybrid analog/DVB-T
I bought an Asus P7131 hybrid. I'm only trying to use the DVB-T part. It is recognized as a Philips TDA10046H DVB-T. On the card there are several Philips chips (I may need a magnifying glass to identify them if required) and a very flat tuner that I can't identify. Scan just throws Tuning failed!!! at me for every frequency, and the +167 trick doesn't seem to work either. Antenna and cable are OK. HG just updated. Anyone knows some more tricks or something I may have forgotten? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Linux Kernel Mailing list [EMAIL PROTECTED], Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Piepho, you are a devil, and your links do not work at all! Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 5/1/07, Manu Abraham [EMAIL PROTECTED] wrote: Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? Please show me where this change makes your work more difficult, Trent's change is small and I don't see the problem where it seriously affects your work. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Dienstag, den 01.05.2007, 01:05 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Linux Kernel Mailing list [EMAIL PROTECTED], Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Piepho, you are a devil, and your links do not work at all! Uwe Try again, this devil's stuff almost always works :) Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Tue, 01 May 2007 02:58:49 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Trent Piepho [EMAIL PROTECTED] CC: Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linus Torvalds [EMAIL PROTECTED], Linux Kernel Mailing list [EMAIL PROTECTED], Linux DVB linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and pseudo-authorities Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Mister Manuel Abraham, 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - and in so far I personally would deeply recommend you to shut up now and go to hell (where you belong) without any thinkable return ticket as you are nothing else but just another motherfucker... 3. You have been ignoring my contributions out of a gesture of ignorance and arrogance and incapability of every kind of human skills for months now, and I will never even try to have any mercy for that 4. Your effort of making dvb-bt8xx cards independent from bttv has been dying out of your personified asociality, ignorance, and anti-communicative behaviour - thus the very hopeful cx878 project is another dead born child produced by your personal behaviour, asociality, ignorance, stupidity and incompatibility, with the effect that Christoph Pfister has turned off from that development tree and now is maintainer of kaffeine where he is doing a very good job, neglecting any further cooperation with you deeply asocial human being in pure incarnation 5. Mister Manuel Abraham, I am not alone just to say that I want you to vanish and shrink from here without any return ticket at all Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again Just goto hell, you goddamn deeply asocial miserable sonofabitch!! Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x40],Data[0x1e] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x41],Data[0x23] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x54],Data[0xff] May 1 02:12:27 localhost mb86a16_write: writing to
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: synchronization problems Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS. I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches. In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: bythe or, even worse: autodected and Recognise) It was ME who corrected that in the past, and it was YOU personally who reversed that, if not to say: fucked it up in the current 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and apologize for that, but not MINE! b. attempts of documentation that do NOT correspond to their appropriate kernel design What do I mean with b.? 1. In Kernels 2.6.12 AND 2.6.13 the simple command modprobe dvb-bt8xx caused ALL OTHER modules to load automatically: cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the automatic loading of dst, dst-ca and dst-ci, every attempt of discussion about debug parameters is simply obsolete! So if I cannot load the dst module separately, how should I be able to hack in debug parameters? I know what debug parameters are for, and I deeply respect developers work, but what the hell is it all worth for if a kernel design suppresses hacking in debug parameters? 2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID = 113. But perhaps I have problems to deal with hexadecimal numbers, and this would
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x40],Data[0x1e] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x41],Data[0x23] May 1 02:12:27 localhost mb86a16_write:
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Manu, also for you please stop it, we know that Uwe writes abusive stuff but you don't have to go on with it. It's about the patch Trent wrote if you're not able to discuss it wait for others to comment it. I only saw subjective reasons why you are against it, but the actual patch doesn't cross your development there. Markus On 5/1/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: synchronization problems Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS. I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches. In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: bythe or, even worse: autodected and Recognise) It was ME who corrected that in the past, and it was YOU personally who reversed that, if not to say: fucked it up in the current 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and apologize for that, but not MINE! b. attempts of documentation that do NOT correspond to their appropriate kernel design What do I mean with b.? 1. In Kernels 2.6.12 AND 2.6.13 the simple command modprobe dvb-bt8xx caused ALL OTHER modules to load automatically: cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the automatic loading of dst, dst-ca and dst-ci, every attempt of discussion about debug parameters is simply obsolete! So if I cannot load the dst module separately, how should I be able to hack in debug parameters? I know what debug parameters are for,
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x40],Data[0x1e] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x41],Data[0x23] May 1 02:12:27 localhost
