Re: [linux-dvb] ndiswrapper for dvb drivers?
Am Freitag, den 08.04.2011, 11:22 +0200 schrieb pigeonskil...@libero.it: Good day to you all. My question is simple: it would be possible to write a program like ndiswrapper for dvb drivers? Just think: only a small initial effort to write a program that can use hundreds of DVB drivers taken from the Windows world... Hi, I'm going through mail backlash again. Arrgh, what a not aware of anything major BS. Either you have the not yet public driver details, than you can write wrappers, please then do so. Not the preferred solution. Or you ask people still hacking on some stuff, why the damned hell some those idiots still try to hack it ... Patches are welcome. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
Hi Jason, Hi Hermann, Hopefully it does help in that other case. that one really counts now. I have it working now. I had to add a delay of 120 seconds in the mythtv backend script to allow the driver enough time to scan both cards and install the firmware properly. Previously the mythtv backend at startup was trying to talk to the cards before the firmware was loaded and so they'd fail to work. It's not a big hassle but it would seem in spite of a test in the startup script to ensure udev configuration was complete before mythbackend was loaded it would seem that udev device configuration Sorry, no time yet to dig into it further, but I seem to hear some faint noise. How sure you are to have original eeprom content on your card ? Some bill, original packing material or similar? On some first impression, l doubt we deal with something it claims to be. Cheers, Hermann was completing before the firmware was loaded. Is there the possibility of adding some feature into the driver to make sure it fails on opening if the firmware isn't properly loaded? Another general question, does V4L sequentially initialise hardware or does it run in parallel? It would seem to be a good time saver to have all DVB cards initialised in parallel to speed up booting of a system. I have reverted back to Mythbuntu 10.04 and kernel 2.6.32 and the cards work fine now (though with the latest v29 of the firmware for these cards). Cheers Jason -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
Hi Jason, Am Samstag, den 12.03.2011, 10:43 +1100 schrieb Jason Hecker: I just bought a pair of what are a version of the My Cinema 7131 Hybrid cards. The kernel reports it as saa7134: Asus Tiger revision 1.0, subsys 1043:4857 I did inititially try Mythbuntu 10.04 but the firmware upload seemed to fail fairly consistently. Restarting with v10.10 the firmware loads but I can't seem to scan the channels with Mythbackend - it has a 0% signal and 100% signal to noise. I am using MythTV 0.24 with Avenard's latest patches. This version of the card has written on the silkscreen Tiger rev 3.02, a sticker that says Tiger_8M AA.F7.C0.01 (which would appear to be the latest firmware for this card on Asus's support site) but there is only one RF connector on CON1. CON2 is not fitted nor is the IR receiver. Now I saw mentioned on a list that to get DVB working on this card in Linux you need to connect the TV antenna to the FM port, which I suspect is the one not fitted. The latest Windows drivers for this card is circa 2009. Two questions: - Is there some sort of SAA7134 module argument I need to use to get the card working on the TV RF input? - Why does the kernel show the firmware is being reloaded every time MythTV seems to want to talk to the card? This slows down access as it seems to take about 30 seconds for the firmware to install each time. I am happy to provide whatever debug dumps or more info if need be. this hits me only by accident, reading through backlash, but I added that Asus Tiger Revision 1.0 with subsys 1043:4857, with a huge delay only. (approximately 1 1/2 years) The development and testing for the new tuner types was done only much later on freely available stuff, a so called Asus Dual _non_ OEM variant. Not to tell what we did all see thereafter, but that all was at least, with only one exception, valid using the PCI subsystem as unique identifier. Luckily, as far as I can see, we have only a fictional radio device on your new variant left over. This can still be very annoying, but won't do any harm, except wasting a users time, bad enough, but at least not any radiation from that sort of radio flaw. Since the PCI subsystem is identical with mine, still around somewhere, with radio support, either take that dead radio device for now or a last chance is to discover, if any eeprom differences are there to eventually filter that minor, but unpleasant shortcoming for those trying in vain on the radio. Cheers, Hermann To restore the power on a failing power plant in urgent need of it seems to be a good idea, after six or seven days ... All my excuses for the failing radio device on that not yet seen OEM stuff, but I can ensure, to piss on it doesn't help any further. Hopefully it does help in that other case. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
Hi guys, Am Sonntag, den 05.12.2010, 13:22 -0500 schrieb Devin Heitmueller: On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov 4er...@gmail.com wrote: Hello, Steve, thank you very much for your comments! As for DVB maybe I'm not correct. The initialization itself, which the DVB part of patch is about, is fully tested by me and works successfully on my everyday PC. The thing I meant saying 'untested' concerned receiving DVB signal through the initialized device. So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Hello Alexey, What I believe Steven is trying to say is the device successfully initializing is not enough to consider the DVB part of the driver to be working. If you have not seen the device receiving digital television, the DVB parts of this patch should not be committed. There are a variety of other reasons why DVB streaming would not work even if the device properly initializes. These can include an improperly configured IF, wrong GPIOs, missing power management code, etc. It is far worse for a user to be led to believe the driver should be working but doesn't then it is for the driver claim to not work with DVB at all. This is how we end up with users wasting hours wondering what is wrong with their MythTV setup when in fact the driver never actually worked in the first place. Find someone to test the DVB parts of the board that it shows DVB streaming. If you cannot do that, remove those parts from the patch until someone can be found who is able to test the functionality. Devin Devin and Steven are totally right. There should not be any untested hardware functionality enabled. I have spend countless time, zillions of emails, often even years after the initial support for a new device was enabled, to hunt down what people did really test and what was only copy/paste from a previous card entry. Never add untested stuff ! We agreed, years ago, that even in a case we can likely expect a standard behavior on some new hardware, given the expertise of someone who might have seen maybe hundreds of similar devices previously, only #if 0 for the untested stuff is allowed. Even if we have muxes, gpios etc, we can take from windows drivers, .inf files or regspy.exe/DScaler for example, it is still not really safe to enable such untested inputs and leave only a comment in the code like untested, taken from the .inf or so. PCI cards for example, with the same subvendor and subdevice ID, can have never ending new revisions, changing almost everything they started with on the first revision for _multiple_ times. Audio and video muxes, all sort of gpio controls from all sort of chips on the board, the AGC, the LNA type, the i2c gate, the IR support ... All you can imagine and more really happens concerning hardware, and we have cases where even eeprom decoding doesn't help and some unknown vendor specific checksums come into the game. We still are in need of full hardware documentation, down to the smallest chip and any line on the PCB, and do miss it. And overall this is improved by more and more hidden devices in products with a seal stating, if broken any warranty is gone, and soldered RF shielding over the relevant parts, hardly to remove without breaking the device. Never add untested stuff. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)
Hi, Am Donnerstag, den 25.11.2010, 00:56 -0500 schrieb Hooman B.: Thanks, I see the drivers for both TDA18271HDC2 and TDA8290 loaded. I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is the digital channel decoder different from the digital tuner?? Should be looking for a different chip? they are detected by chip IDs. The tda8290 is the IF demodulator for global analog TV. In case of the saa7135 it is an extra chip on the PCB, which most often can also control the tuner over an i2c gate. The tda18271hdc2 is a global hybrid tuner for analog and digital terrestrial TV. It can also provide a FM radio IF. Further processing and stereo separation for that is done on capable bridges like saa7133/35/31e, not on the tda 8290. Yes, for any terrestrial digital TV you need an extra channel decoder and all known details about it. http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards In case of terrestrial ATSC, it must be able to deal with 8VSB modulation. IIRC, on the saa713x we have that tuner only in combination with the tda10048 and DVB-T for now, but other combinations seem to be already around. Hermann Based on these to chips, I added my card in saa7134_tda8290_callback to call saa7134_tda8290_18271_callback and here is the output of my dmesg: [ 828.879454] dvb_init() allocating 1 frontend [ 829.180234] nxt200x: nxt200x_readbytes: i2c read error (addr 0x0a, err == -5) [ 829.180244] Unknown/Unsupported NXT chip: 00 00 00 00 00 [ 829.180542] saa7133[0]/dvb: frontend initialization failed Hooman On Wed, Nov 24, 2010 at 7:21 PM, hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Dienstag, den 23.11.2010, 17:34 -0500 schrieb Hooman B.: Hello! I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid ATSC (17de:a134) to work with the latest v4l drivers from source (in Ubuntu). Right now, everything [capture, analog, radio, even IR] works - except the ATSC tuner (there is no front-end device). But that's the one thing I need working :-( OK. Here's the output of lspci -nnvv 03:01.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) Subsystem: KWorld Computer Co. Ltd. Device [17de:a134] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 255 (63750ns min, 63750ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at fdaff000 (32-bit, non-prefetchable) [size=2K] Capabilities: access denied Kernel driver in use: saa7134 Kernel modules: saa7134 This is the most similar card that I forced in saa7134-cards.c: .vendor = PCI_VENDOR_ID_PHILIPS, .device = PCI_DEVICE_ID_PHILIPS_SAA7133, .subvendor= 0x17de, .subdevice= 0xa134, .driver_data = SAA7134_BOARD_MSI_TVATANYWHERE_PLUS, The chips are : SAA7135HL/203 and TDA18271HDC2 Both variants of the MSI t...@nywhere Plus do not have any support for digital TV. You need to find out the type of digital channel decoder on your board at first. Then you check saa7134-dvb.c, if it is already supported on other cards. You have to investigate the details of how the channel decoder is employed, but with some luck can try with already supported cards. If i2c traffic locks up and chips disappear from the bus, a cold boot might be necessary to continue with testing. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)
Hi, Am Dienstag, den 23.11.2010, 17:34 -0500 schrieb Hooman B.: Hello! I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid ATSC (17de:a134) to work with the latest v4l drivers from source (in Ubuntu). Right now, everything [capture, analog, radio, even IR] works - except the ATSC tuner (there is no front-end device). But that's the one thing I need working :-( OK. Here's the output of lspci -nnvv 03:01.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) Subsystem: KWorld Computer Co. Ltd. Device [17de:a134] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 255 (63750ns min, 63750ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at fdaff000 (32-bit, non-prefetchable) [size=2K] Capabilities: access denied Kernel driver in use: saa7134 Kernel modules: saa7134 This is the most similar card that I forced in saa7134-cards.c: .vendor = PCI_VENDOR_ID_PHILIPS, .device = PCI_DEVICE_ID_PHILIPS_SAA7133, .subvendor= 0x17de, .subdevice= 0xa134, .driver_data = SAA7134_BOARD_MSI_TVATANYWHERE_PLUS, The chips are : SAA7135HL/203 and TDA18271HDC2 Both variants of the MSI t...@nywhere Plus do not have any support for digital TV. You need to find out the type of digital channel decoder on your board at first. Then you check saa7134-dvb.c, if it is already supported on other cards. You have to investigate the details of how the channel decoder is employed, but with some luck can try with already supported cards. If i2c traffic locks up and chips disappear from the bus, a cold boot might be necessary to continue with testing. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with Compro T200 (TDA1004x) and tuning Hi
Hi Mike, Am Dienstag, den 23.11.2010, 13:36 + schrieb Mike Martin: On 22 November 2010 19:43, hermann pitton hermann-pit...@arcor.de wrote: Am Montag, den 22.11.2010, 15:08 + schrieb Mike Martin: On 22 November 2010 06:08, hermann pitton hermann-pit...@arcor.de wrote: Hi Mike, Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin: I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling usually, in the UK, this can be caused by the missing ability to detect some frequencies offsets by the tda10046. Since you have already a minus of 167000Hz, typically for the UK, in your initial scan/tuning file, this most common problem likely can be excluded. So there are eventually three variants causing the problem on a first idea. 1. They changed to 498 MHz. (or did change something else too, auto is your friend in the initial scan file then, except for the freq.) tried that no difference 2. Your overall signal is not good enough. well up until friday I was using a HVR900, until it decided to refuse to believe it was plugged into a USB2 bus, and it was working fine 3. You sit on some kernel with some bug. [...] Well, it is still very easy to install the latest remaining v4l-dvb from hg/mercurial for a quick test too. I don't have your hardware, but all my stuff is still fine there so far. AFAIR, your device, added by Hartmut, has some sort of TD1316 without an extra tda9887 IF demodulator for analog reception soldered outside of the tuner on the PCB. However, it is in a loop for eeprom auto detection on the side of the bridge. If that fails, and for my experience four of five attempts to fiddle with that later did fail, you don't have a chance for any DVB either. You might have to force the card number in such a case, but I'm still far away from what might be going on and your report is without any details so far. Cheers, Hermann One problem is the last time I used it - it worked. Although that was in a different location/PC yup, I know too it did work for years. Current system P4 Fedora 14, stock kernel output scandvb scanning uk-Aberdare_auto using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 474167000 3 9 9 6 2 4 4 initial transponder 482167000 3 9 9 6 2 4 4 initial transponder 497833000 3 9 9 6 2 4 4 initial transponder 506167000 3 9 9 6 2 4 4 initial transponder 521833000 0 2 9 3 0 0 0 initial transponder 530167000 0 2 9 3 0 0 0 tune to: 474167000:INVERSION_AUTO:BANDWIDTH_AUTO:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO WARNING: tuning failed!!! One thing I forgot about, you might have to force the bandwidth too. If that still fails, you might be on the road for bisecting through the previous patches. I can't even tell, how reliable bisecting can work currently. However, it might be worth to test with the remaining v4l-dvb mercurial code as a start. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with Compro T200 (TDA1004x) and tuning Hi
Am Montag, den 22.11.2010, 15:08 + schrieb Mike Martin: On 22 November 2010 06:08, hermann pitton hermann-pit...@arcor.de wrote: Hi Mike, Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin: I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling usually, in the UK, this can be caused by the missing ability to detect some frequencies offsets by the tda10046. Since you have already a minus of 167000Hz, typically for the UK, in your initial scan/tuning file, this most common problem likely can be excluded. So there are eventually three variants causing the problem on a first idea. 1. They changed to 498 MHz. (or did change something else too, auto is your friend in the initial scan file then, except for the freq.) tried that no difference 2. Your overall signal is not good enough. well up until friday I was using a HVR900, until it decided to refuse to believe it was plugged into a USB2 bus, and it was working fine 3. You sit on some kernel with some bug. [...] Well, it is still very easy to install the latest remaining v4l-dvb from hg/mercurial for a quick test too. I don't have your hardware, but all my stuff is still fine there so far. AFAIR, your device, added by Hartmut, has some sort of TD1316 without an extra tda9887 IF demodulator for analog reception soldered outside of the tuner on the PCB. However, it is in a loop for eeprom auto detection on the side of the bridge. If that fails, and for my experience four of five attempts to fiddle with that later did fail, you don't have a chance for any DVB either. You might have to force the card number in such a case, but I'm still far away from what might be going on and your report is without any details so far. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with Compro T200 (TDA1004x) and tuning Hi
Hi Mike, Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin: I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling usually, in the UK, this can be caused by the missing ability to detect some frequencies offsets by the tda10046. Since you have already a minus of 167000Hz, typically for the UK, in your initial scan/tuning file, this most common problem likely can be excluded. So there are eventually three variants causing the problem on a first idea. 1. They changed to 498 MHz. (or did change something else too, auto is your friend in the initial scan file then, except for the freq.) 2. Your overall signal is not good enough. 3. You sit on some kernel with some bug. Case one and two are not hard to come through, for case three, the remedies are slipping away. You might have to install some latest .rc-git stuff, likely without support for your graphics card, coming up in vesa mode only, try to record something, and boot back into some kernel with support for displaying the record, we all have HDTV these days ... It might look like that, since the mobile devices and webcams took it all over here ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] saa7134: make module parameters boolean
Am Samstag, den 20.11.2010, 00:43 +0100 schrieb David Härdeman: int to bool conversion for module parameters which are truely boolean. Signed-off-by: David Härdeman da...@hardeman.nu --- drivers/media/video/saa7134/saa7134-input.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c index 8b80efb..aea74e2 100644 --- a/drivers/media/video/saa7134/saa7134-input.c +++ b/drivers/media/video/saa7134/saa7134-input.c @@ -29,12 +29,12 @@ #define MODULE_NAME saa7134 -static unsigned int disable_ir; -module_param(disable_ir, int, 0444); +static bool disable_ir; +module_param(disable_ir, bool, 0444); MODULE_PARM_DESC(disable_ir,disable infrared remote support); -static unsigned int ir_debug; -module_param(ir_debug, int, 0644); +static bool ir_debug; +module_param(ir_debug, bool, 0644); MODULE_PARM_DESC(ir_debug,enable debug messages [IR]); static int pinnacle_remote; Hi, not exactly that one, but given all the previous changes, I wonder if there will ever be some tested-by: from someone ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] rc: Remove ir-common module
Am Samstag, den 13.11.2010, 17:33 -0200 schrieb Mauro Carvalho Chehab:
Now, just one old bttv board uses the old RC5 raw decoding routines.
Its conversion to rc-core requires the generation of IRQ data for both
positive and negative transitions at the IRQ line. I'm not sure if
bttv driver supports it or if the transitions will be reliable enough.
So, due to the lack of hardware for testing, the better for now is to
just move the legacy routines to bttv driver, and wait for someone with
a Nebula Digi could help to port it to use also rc-core raw decoders.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Without any testing feedback from the bttv Nebula Digi since we made it
available for the saa7134 for Asus IR IRQ sampling too
Acked-by: hermann pitton hermann-pit...@arcor.de
Cheers,
Hermann
delete mode 100644 drivers/media/rc/ir-functions.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 2d15468..ef19375 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -10,11 +10,6 @@ menuconfig IR_CORE
if you don't need IR, as otherwise, you may not be able to
compile the driver for your adapter.
-config IR_LEGACY
- tristate
- depends on IR_CORE
- default IR_CORE
-
if IR_CORE
config LIRC
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 859c12c..8c0e4cb 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -1,10 +1,8 @@
-ir-common-objs := ir-functions.o
rc-core-objs := rc-main.o rc-raw.o
obj-y += keymaps/
obj-$(CONFIG_IR_CORE) += rc-core.o
-obj-$(CONFIG_IR_LEGACY) += ir-common.o
obj-$(CONFIG_LIRC) += lirc_dev.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
diff --git a/drivers/media/rc/ir-functions.c b/drivers/media/rc/ir-functions.c
deleted file mode 100644
index 14397d0..000
--- a/drivers/media/rc/ir-functions.c
+++ /dev/null
@@ -1,120 +0,0 @@
-/*
- * some common functions to handle infrared remote protocol decoding for
- * drivers which have not yet been (or can't be) converted to use the
- * regular protocol decoders...
- *
- * (c) 2003 Gerd Knorr kra...@bytesex.org [SuSE Labs]
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include linux/module.h
-#include linux/string.h
-#include linux/jiffies.h
-#include media/ir-common.h
-#include rc-core-priv.h
-
-/*
-- */
-
-MODULE_AUTHOR(Gerd Knorr kra...@bytesex.org [SuSE Labs]);
-MODULE_LICENSE(GPL);
-
-/* RC5 decoding stuff, moved from bttv-input.c to share it with
- * saa7134 */
-
-/* decode raw bit pattern to RC5 code */
-static u32 ir_rc5_decode(unsigned int code)
-{
- unsigned int org_code = code;
- unsigned int pair;
- unsigned int rc5 = 0;
- int i;
-
- for (i = 0; i 14; ++i) {
- pair = code 0x3;
- code = 2;
-
- rc5 = 1;
- switch (pair) {
- case 0:
- case 2:
- break;
- case 1:
- rc5 |= 1;
- break;
- case 3:
- IR_dprintk(1, ir-common: ir_rc5_decode(%x) bad
code\n, org_code);
- return 0;
- }
- }
- IR_dprintk(1, ir-common: code=%x, rc5=%x, start=%x, toggle=%x,
address=%x,
- instr=%x\n, rc5, org_code, RC5_START(rc5),
- RC5_TOGGLE(rc5), RC5_ADDR(rc5), RC5_INSTR(rc5));
- return rc5;
-}
-
-void ir_rc5_timer_end(unsigned long data)
-{
- struct card_ir *ir = (struct card_ir *)data;
- struct timeval tv;
- unsigned long current_jiffies;
- u32 gap;
- u32 rc5 = 0;
-
- /* get time */
- current_jiffies = jiffies;
- do_gettimeofday(tv);
-
- /* avoid overflow with gap 1s */
- if (tv.tv_sec - ir-base_time.tv_sec 1) {
- gap = 20;
- } else {
- gap = 100 * (tv.tv_sec - ir-base_time.tv_sec) +
- tv.tv_usec - ir-base_time.tv_usec;
- }
-
- /* signal we're ready to start a new code */
- ir-active = 0;
-
- /* Allow some
Re: Bounty for the first Open Source driver for Kinect
Am Donnerstag, den 11.11.2010, 00:36 +0100 schrieb Markus Rechberger: On Thu, Nov 11, 2010 at 12:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Thu, 11 Nov 2010 00:13:09 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: If there are arguments against a kernel driver I can't see them yet. [...] If I want to use this device, I will add many userspace code to create the skeleton model and that need much computation. Kernel Module adds performance to my other code. just some experience from our side, we do have fully working video4linux1/2 drivers in userspace, the only exception we have is a very thin layered kernelmodule in order to improve the datatransfer. Markus, can you point to some example so I can get a clearer picture? unfortunately we're closed source (and much more advanced) but you can have a look at other projects: Markus, please go away with such. Despite of all previously, this is _not_ a place for any closed source to discuss. There is nothing to discuss on that, please stop it. Either try to come back with open source in a new round, or at least don't try to hide what you have. Without all the code and hardware specific stuff _previously_ developed/hacked on v4l-dvb, you don't exist. I still admit, overall, you did a very good job previously, but all others are _not_ just your captives after some clashes. With unfortunately we're closed source, you deliberately declare, that you have nothing to do with open source at all anymore. ? So, what is the remaining interest for you, except that you can continue easier in userspace, instead of getting a hard block in the kernel, if some enough have enough of your closed source ? Cheers, Hermann * libv4l2 * freebsd has webcamd or something like that to emulate analog tv/webcams and dvb (they are even reusing linux kernel drivers with a userspace wrapper - so everything works in userspace for them). aside of that you can just debug userspace drivers with gdb, valgrind etc. if issues come up it will only affect your work not the entire system, kernel is seriously something critical. Markus Thanks, Antonio -- Antonio Ospite http://ao2.it -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L/DVB/IR patches pending merge
Am Montag, den 01.11.2010, 11:30 +0100 schrieb Bjørn Mork: Mauro Carvalho Chehab mche...@redhat.com writes: == mantis patches - Waiting for Manu Abraham abraham.m...@gmail.com == Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c http://patchwork.kernel.org/patch/92961 David Härdeman da...@hardeman.nu Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, improve http://patchwork.kernel.org/patch/107036 Marko Ristola marko.rist...@kolumbus.fi Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files http://patchwork.kernel.org/patch/107062 Bjørn Mork bj...@mork.no Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module removal http://patchwork.kernel.org/patch/107063 Bjørn Mork bj...@mork.no Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules http://patchwork.kernel.org/patch/107147 Manu Abraham abraham.m...@gmail.com Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits http://patchwork.kernel.org/patch/109972 Ben Hutchings b...@decadent.org.uk Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, improve http://patchwork.kernel.org/patch/110909 Marko Ristola marko.rist...@kolumbus.fi Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery http://patchwork.kernel.org/patch/111090 Marko Ristola marko.rist...@kolumbus.fi Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of busy reg http://patchwork.kernel.org/patch/111245 Marko Ristola marko.rist...@kolumbus.fi Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) http://patchwork.kernel.org/patch/112708 Niklas Claesson nicke.claes...@gmail.com Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola marko.rist...@kolumbus.fi Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod http://patchwork.kernel.org/patch/244201 Tuxoholic tuxoho...@hotmail.de Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus http://patchwork.kernel.org/patch/105621 Florent AUDEBERT florent.audeb...@anevia.com What to say? Well, still waiting for Manu to handle those patches. He said he had a problem with his dish and should be working on it next week. Let's hope we can finally have some movement on those patches in time for .37. Can we agree that this was yet another useless waiting exercise? Please start learning from experience. You are just repeating the same mistake again and again. Its rather frustrating to watch. Like watching a rat in a maze banging it's head against the same wall over and over again. Bjørn Bjorn, you are taking it wrong. Indeed, neither Manu nor Mauro can do anything on this now. It got stuck from outside. There is a war. If you look closer, beside of Mantis stuff, there are drivers for much more recent chipsets, failing for not having linux support right now, being able to do the triple performance and even much more. Without help, neither Manu nor Mauro can hack them together. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi Giorgio, Am Mittwoch, den 06.10.2010, 13:50 +0200 schrieb Giorgio: [big snip] Likely, I only have to read the LKML daily ... Despite of that, we need a good analysis of course, and a way how to avoid such. Maybe we can have some kind of test team? It would help to find regressions before it's too late. Cheers, Hermann Giorgio Vazzana Yes, we always need test teams. And Mauro explicitly did call for testing. I did, Dmitry did and Mauro. But we did not find the potential bug, caused by moving some identical code between saa7134-ts and saa7134-core forth and back. This was still on hg and I only have _some_ of such cards. Having this on latest Linus git stuff, likely only compile fixes on previous -next, can find such ... ;) I'm sorry for repeating my dumbness on that. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi Giorgio, Am Montag, den 04.10.2010, 18:11 +0200 schrieb Giorgio: On 04/10/2010 01:48, Dejan Rodiger wrote: Hi Hermann, I finally found the time to wire analog antena and I checked it with my TV if it is working correctly. Since I am using local cable provider which didn't upgrade their system in 10 years and they are still broadcast in analog, I had a problem off finding channel list, so in the end I tried tvtime-scanner and it found about 58 channels. But, out of this 58 most of them were not good (no signal). I was able to finetune few programs. My main programs (local Croatian TV stations) were not found. Maybe I need to finetune every found station. I also tried zapping which crashed my X. I am also lost in setting mythtv. I set analog tunner on /dev/video0. But I think I have a problem of setting the channel list for my local cable provider. Is it possible to scan whole list or something. If you have any reading recommendation to set this, I would be helpfull Dejan, I have the exact same card: # sudo lpci -vnn 02:07.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) Subsystem: ASUSTeK Computer Inc. Device [1043:4876] Flags: bus master, medium devsel, latency 64, IRQ 20 Memory at fbfff800 (32-bit, non-prefetchable) [size=2K] Capabilities: [40] Power Management version 2 Kernel driver in use: saa7134 Kernel modules: saa7134 and I can confirm you that it's autodetected and works very well (both the analog and the digital part) on 2.6.35. 2.6.32 has a problem with dvb-t reception, but I have reported it and hopefully it will be fixed soon upstream: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/23604 thanks for the report and pointing to the details again. We can see, that my testings on four different machines and Dmitri's tests have not been enough. Mauro had the Dual card=78 version from me too at least for analog TV testing. And, that was on hg with most backward compat as possible. How good are our chances, to run in such and similar troubles in the future, in fact staying only on latest -rc, rc-git and in best case on -next stuff previously? It will all come down to the distros and such a bug fix might take just a year in the future regularly ... So, if the quality control was not even sufficient on hg, what will happen on latest -rc git stuff for that? Obviously zillions of people do much more prefer to crash around there than on hg ... ;) Likely, I only have to read the LKML daily ... Despite of that, we need a good analysis of course, and a way how to avoid such. Cheers, Hermann If you want to test the analog part, install MPlayer and run the following command: mplayer tv:// -tv driver=v4l2:device=/dev/video0:norm=PAL:input=0:chanlist=europe-west and then press 'k' or 'h' to select previous/next channel (after you switch channel, wait some seconds until the card tunes, for some channels I need 5 seconds here, for others about 1 second). Now, with some patience, explore all the channels and you should be able to find your local tv stations. Also, you might need to adjust mplayer options, like norm= or chanlist= (you could try chanlist=europe-east). The command line above doesn't grab audio though, so you won't hear a thing. If you want to hear the audio you need to make sure saa7134-alsa is loaded and run something like: mplayer tv:// -tv driver=v4l2:device=/dev/video0:norm=PAL:input=0:alsa:adevice=hw.1,0:amode=1:immediatemode=0:chanlist=europe-west (make sure you select the right alsa device in adevice=) The wiki has a good page about MPlayer: http://www.linuxtv.org/wiki/index.php/MPlayer and of course the MPlayer man page explain all the options too. These pages are also useful (but some things might be a bit outdated): http://www.linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid http://www.linuxtv.org/wiki/index.php/Saa7134-alsa I hope this can help you and others reading this ML. Regards, Giorgio Vazzana Thanks -- Dejan Rodiger S: callto://drodiger On Thu, Sep 23, 2010 at 00:46, hermann-pit...@arcor.de wrote: Hi Dejan, - Original Nachricht Von: Dejan Rodiger dejan.rodi...@gmail.com An: hermann pitton hermann-pit...@arcor.de Datum: 22.09.2010 13:20 Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support Hi Herman, here is dmesg output without forcing card=78. As I see it uses card=112, autodetected [ 16.043345] IR RC6 protocol handler initialized [ 16.173473] IR JVC protocol handler initialized [ 16.236641] IR Sony protocol handler initialized [ 16.433187] lirc_dev: IR Remote Control driver registered, major 250 [ 16.572705] IR LIRC bridge handler initialized [ 16.894983] Linux video capture interface: v2.00 [ 16.957585
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Am Montag, den 04.10.2010, 19:59 -0400 schrieb Devin Heitmueller: On Mon, Oct 4, 2010 at 7:21 PM, hermann pitton hermann-pit...@arcor.de wrote: thanks for the report and pointing to the details again. We can see, that my testings on four different machines and Dmitri's tests have not been enough. Mauro had the Dual card=78 version from me too at least for analog TV testing. And, that was on hg with most backward compat as possible. How good are our chances, to run in such and similar troubles in the future, in fact staying only on latest -rc, rc-git and in best case on -next stuff previously? It will all come down to the distros and such a bug fix might take just a year in the future regularly ... So, if the quality control was not even sufficient on hg, what will happen on latest -rc git stuff for that? Obviously zillions of people do much more prefer to crash around there than on hg ... ;) I think it's been made pretty clear: we don't give a crap about whether users' PCs crash. Getting the code into the bleeding edge kernel is the most important thing. Reducing maintainership overhead is clearly more important than whether the code actually works. Forget about the hg backport system. We would rather get crap code into the bleeding edge kernel where almost zero users will test it than to put it into HG where there is actually a chance for users to see the problems before it goes into the mainline kernel (except for the 0.1% of users who are willing to install the latest bleeding edge kernel and make it work with all their other hardware). Yes, we should all be prepared for lots of regressions being introduced, and nobody notices them until the code is already in the distros and has reached the masses. And then maybe if the users are lucky the distro maintainers will backport fixes. It's been made pretty clear that reducing merge overhead is more important than delivering a quality product. I'll stop hijacking the thread now. Devin Devin, you are always very welcome! I know for sure, that you know what you are talking about. Thanks, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi Dejan, Am Montag, den 04.10.2010, 01:48 +0200 schrieb Dejan Rodiger: Hi Hermann, I finally found the time to wire analog antena and I checked it with my TV if it is working correctly. Since I am using local cable provider which didn't upgrade their system in 10 years and they are still broadcast in analog, I had a problem off finding channel list, so in the end I tried tvtime-scanner and it found about 58 channels. But, out of this 58 most of them were not good (no signal). I was able to finetune few programs. My main programs (local Croatian TV stations) were not found. Maybe I need to finetune every found station. that doesn't sound good. The card should just work. Anyone else still out there with the same? Or are we finally destroyed by so called compile fixes and linux next stuff ? I also tried zapping which crashed my X. Yeah, goes on since years, but has still good vbi :) dunno, if Michael has further plans on that. I am also lost in setting mythtv. I set analog tunner on /dev/video0. But I think I have a problem of setting the channel list for my local cable provider. Is it possible to scan whole list or something. If you have any reading recommendation to set this, I would be helpfull Thanks -- Dejan Rodiger S: callto://drodiger For DVB-T try kaffeine or low level tools. Allow full delay for tuning and locking. If that fails, and no other well known other hardware restrictions are in place, we have some broken code. I do have a triple Asus 3in1 OEM with the same LNA config as that first hybrid board has. If really broken, not noticed yet here, but also not used since long, we can meet on some same code base and track it down. Cheers, Hermann On Thu, Sep 23, 2010 at 00:46, hermann-pit...@arcor.de wrote: Hi Dejan, - Original Nachricht Von: Dejan Rodiger dejan.rodi...@gmail.com An: hermann pitton hermann-pit...@arcor.de Datum: 22.09.2010 13:20 Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support Hi Herman, here is dmesg output without forcing card=78. As I see it uses card=112, autodetected [ 16.043345] IR RC6 protocol handler initialized [ 16.173473] IR JVC protocol handler initialized [ 16.236641] IR Sony protocol handler initialized [ 16.433187] lirc_dev: IR Remote Control driver registered, major 250 [ 16.572705] IR LIRC bridge handler initialized [ 16.894983] Linux video capture interface: v2.00 [ 16.957585] saa7130/34: v4l2 driver version 0.2.16 loaded [ 16.958300] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 [ 16.958306] alloc irq_desc for 18 on node 0 [ 16.958309] alloc kstat_irqs on node 0 [ 16.958320] saa7134 :01:06.0: PCI INT A - Link[APC3] - GSI 18 (level, low) - IRQ 18 [ 16.958327] saa7133[0]: found at :01:06.0, rev: 209, irq: 18, latency: 32, mmio: 0xfdeff000 [ 16.958334] saa7133[0]: subsystem: 1043:4876, board: ASUSTeK P7131 Hybrid [card=112,autodetected] [ 16.958378] saa7133[0]: board init: gpio is 0 [ 17.010075] Registered IR keymap rc-asus-pc39 [ 17.010197] input: saa7134 IR (ASUSTeK P7131 Hybri as /devices/pci:00/:00:09.0/:01:06.0/rc/rc0/input4 [ 17.010268] rc0: saa7134 IR (ASUSTeK P7131 Hybri as /devices/pci:00/:00:09.0/:01:06.0/rc/rc0 [ 17.190477] saa7133[0]: i2c eeprom 00: 43 10 76 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 17.190490] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff [ 17.190502] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 d5 ff ff ff ff [ 17.190513] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190524] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 55 50 ff ff ff ff ff ff [ 17.190534] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190545] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190556] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190566] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190577] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190587] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190598] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190609] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190620] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190641] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.610120] tuner 2-004b: chip found @ 0x96 (saa7133[0]) [ 17.780037] tda829x 2-004b: setting tuner address to 61 [ 17.940020] tda829x 2
Re: [GIT PULL for 2.6.36] V4L/DVB fixes
Linus, Am Montag, den 27.09.2010, 17:02 -0700 schrieb Linus Torvalds: On Mon, Sep 27, 2010 at 1:57 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The following changes since commit 32163f4b2cef28a5aab8b226ffecfc6379a53786: alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus I get scripts/kconfig/conf --oldconfig arch/x86/Kconfig drivers/media/Kconfig:146: 'endif' in different file than 'if' drivers/media/IR/Kconfig:15: location of the 'if' drivers/Kconfig:114: unexpected 'endmenu' within if block drivers/Kconfig:1: missing end statement for this entry make[1]: *** [oldconfig] Error 1 make: *** [oldconfig] Error 2 with this. And it seems to be due to a totally broken commit at the very beginning of the series by a commit called Kconfig fixes (Hah!), that clearly has not been tested at all. The commit sequence was also done today, apparently immediately before sending me the pull request. Which sure as hell explains the clearly not tested at all situation. Don't do this. You are now officially on my shit-list for sending me total crap. How effing hard can it be to understand: you don't send me stuff that hasn't been tested. It needs to be in -next for SEVERAL DAYS, and you don't rebase it or take it from some random quilt series just before sending it to me. That's true _especially_ during the -rc series. But it's damn well true at any other time too. I'm angry. I expect at least some _minimal_ amount of competence from people I pull from. This was not it. Get your ^#! act together! Linus you should not be such rude. You have never been in any hardware details on v4l and dvb. After Gerd Knorr did quit, out of reasons, you noticed there is some noise on v4l and dvb, but you never had to fix much on your own in the last eight years. Shouting around and blaming others always was enough ... I agree, a rc-1 should be at least compile tested. Any idea, why this goes away? Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 2.6.36] V4L/DVB fixes
Am Donnerstag, den 30.09.2010, 00:08 -0300 schrieb Mauro Carvalho Chehab: Em 29-09-2010 22:04, hermann pitton escreveu: Linus, Am Montag, den 27.09.2010, 17:02 -0700 schrieb Linus Torvalds: On Mon, Sep 27, 2010 at 1:57 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The following changes since commit 32163f4b2cef28a5aab8b226ffecfc6379a53786: alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus I get scripts/kconfig/conf --oldconfig arch/x86/Kconfig drivers/media/Kconfig:146: 'endif' in different file than 'if' drivers/media/IR/Kconfig:15: location of the 'if' drivers/Kconfig:114: unexpected 'endmenu' within if block drivers/Kconfig:1: missing end statement for this entry make[1]: *** [oldconfig] Error 1 make: *** [oldconfig] Error 2 with this. And it seems to be due to a totally broken commit at the very beginning of the series by a commit called Kconfig fixes (Hah!), that clearly has not been tested at all. The commit sequence was also done today, apparently immediately before sending me the pull request. Which sure as hell explains the clearly not tested at all situation. Don't do this. You are now officially on my shit-list for sending me total crap. How effing hard can it be to understand: you don't send me stuff that hasn't been tested. It needs to be in -next for SEVERAL DAYS, and you don't rebase it or take it from some random quilt series just before sending it to me. That's true _especially_ during the -rc series. But it's damn well true at any other time too. I'm angry. I expect at least some _minimal_ amount of competence from people I pull from. This was not it. Get your ^#! act together! Linus you should not be such rude. You have never been in any hardware details on v4l and dvb. After Gerd Knorr did quit, out of reasons, you noticed there is some noise on v4l and dvb, but you never had to fix much on your own in the last eight years. Shouting around and blaming others always was enough ... I agree, a rc-1 should be at least compile tested. Any idea, why this goes away? Hermann, That's OK. I did crap. Linus is right. I'll send him the patches again after having the same tree branch being tested for a few days at linux-next, without any bad results. Cheers, Mauro. Mauro, hopefully, a few days on linux-next can replace all what we had in the past, causing sometimes years of delay ... What to say ? OK, if you say we are fine with it now, it is up to you. So, the whole mistake was, that Linus did not start kicking asses harder earlier? What a total crap! Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi Dejan, - Original Nachricht Von: Dejan Rodiger dejan.rodi...@gmail.com An: hermann pitton hermann-pit...@arcor.de Datum: 22.09.2010 13:20 Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support Hi Herman, here is dmesg output without forcing card=78. As I see it uses card=112, autodetected [ 16.043345] IR RC6 protocol handler initialized [ 16.173473] IR JVC protocol handler initialized [ 16.236641] IR Sony protocol handler initialized [ 16.433187] lirc_dev: IR Remote Control driver registered, major 250 [ 16.572705] IR LIRC bridge handler initialized [ 16.894983] Linux video capture interface: v2.00 [ 16.957585] saa7130/34: v4l2 driver version 0.2.16 loaded [ 16.958300] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 [ 16.958306] alloc irq_desc for 18 on node 0 [ 16.958309] alloc kstat_irqs on node 0 [ 16.958320] saa7134 :01:06.0: PCI INT A - Link[APC3] - GSI 18 (level, low) - IRQ 18 [ 16.958327] saa7133[0]: found at :01:06.0, rev: 209, irq: 18, latency: 32, mmio: 0xfdeff000 [ 16.958334] saa7133[0]: subsystem: 1043:4876, board: ASUSTeK P7131 Hybrid [card=112,autodetected] [ 16.958378] saa7133[0]: board init: gpio is 0 [ 17.010075] Registered IR keymap rc-asus-pc39 [ 17.010197] input: saa7134 IR (ASUSTeK P7131 Hybri as /devices/pci:00/:00:09.0/:01:06.0/rc/rc0/input4 [ 17.010268] rc0: saa7134 IR (ASUSTeK P7131 Hybri as /devices/pci:00/:00:09.0/:01:06.0/rc/rc0 [ 17.190477] saa7133[0]: i2c eeprom 00: 43 10 76 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 17.190490] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff [ 17.190502] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 d5 ff ff ff ff [ 17.190513] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190524] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 55 50 ff ff ff ff ff ff [ 17.190534] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190545] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190556] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190566] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190577] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190587] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190598] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190609] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190620] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.190641] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 17.610120] tuner 2-004b: chip found @ 0x96 (saa7133[0]) [ 17.780037] tda829x 2-004b: setting tuner address to 61 [ 17.940020] tda829x 2-004b: type set to tda8290+75a [ 24.000114] saa7133[0]: registered device video0 [v4l2] [ 24.000150] saa7133[0]: registered device vbi0 [ 24.000182] saa7133[0]: registered device radio0 [ 24.027730] saa7134 ALSA driver for DMA sound loaded [ 24.027770] saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 18 registered as card -2 [ 25.900159] DVB: registering new adapter (saa7133[0]) [ 25.900165] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... [ 26.710050] tda1004x: setting up plls for 48MHz sampling clock [ 27.710043] tda1004x: found firmware revision 29 -- ok -- Dejan Rodiger M: +385917829076 S: callto://drodiger all looks fine now. With auto detection you should have correct LNA support for analog tuning and DVB-T. You need to connect the DVB-T signal to the FM/RF antenna input and the analog TV signal to the cable RF input.. If you plug in the remote receiver, gpio 0x04 will switch to high. Does this help any further? What went wrong previously, making you think you might have to force for example card = 78 ? I can revive almost all of the Asus cards on the saa713x driver if needed. Have fun, hopefully. Cheers, Hermann On Wed, Sep 22, 2010 at 01:13, hermann pitton hermann-pit...@arcor.de wrote: Hi Dejan, Am Dienstag, den 21.09.2010, 10:07 +0200 schrieb Dejan Rodiger: Hi, I am using Ubuntu linux 10.10 with the latest kernel 2.6.35-22-generic on x86_64. I have installed nonfree firmware which should support this card, but to be sure, can somebody confirm that my TV card is supported in Analog or DVB mode? sudo lspci -vnn 01:06.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid [1043:4876
Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface
Am Mittwoch, den 22.09.2010, 08:08 +0200 schrieb Guennadi Liakhovetski:
On Wed, 22 Sep 2010, hermann pitton wrote:
Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
This is a V4L2 driver for TI OMAP1 SoC camera interface.
[snip]
+
+ } else {
+ dev_warn(dev, %s: unhandled camera interrupt, status
==
+ 0x%0x\n, __func__, it_status);
Please, don't split strings
sorry for any OT interference.
But, are there any new rules out?
Maybe I missed them.
Either way, the above was forced during the last three years.
Not at all ?
No. Splitting print strings has always been discouraged, because it makes
tracking back kernel logs difficult. The reason for this has been the 80
character line length limit, which has now been effectively lifted. I'm
sure you can find enough links on the internet for any of these topics.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Guennadi,
thanks for the update!
If somebody ever would like to waste time on it, lots of patches and
whole drivers have been forced into this limitations for strings too.
In fact, fixing only a few lines, including the offset, you almost
always did hit it.
I'm pleased to hear now, that this problem never did exist ;))
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi Dejan,
Am Dienstag, den 21.09.2010, 10:07 +0200 schrieb Dejan Rodiger:
Hi,
I am using Ubuntu linux 10.10 with the latest kernel 2.6.35-22-generic
on x86_64. I have installed nonfree firmware which should support this
card, but to be sure, can somebody confirm that my TV card is
supported in Analog or DVB mode?
sudo lspci -vnn
01:06.0 Multimedia controller [0480]: Philips Semiconductors
SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid
[1043:4876]
Flags: bus master, medium devsel, latency 32, IRQ 18
Memory at fdeff000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [40] Power Management version 2
Kernel driver in use: saa7134
Kernel modules: saa7134
It says Hybrid, but I put the following in
the /etc/modprobe.d/saa7134.conf
options saa7134 card=78 tuner=54
Thanks
--
Dejan Rodiger
S: callto://drodiger
don't have time to follow this closely anymore.
But forcing it to card=78 is plain wrong. It has an early additional LNA
in confirmed config = 2 status.
Your card should be auto detected and previously always was, based on
what we have in saa7134-cards.c and further for it. (saa7134-dvb and
related tuner/demod stuff)
}, {
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x1043,
.subdevice= 0x4876,
.driver_data = SAA7134_BOARD_ASUSTeK_P7131_HYBRID_LNA,
},{
I remember for sure, that this card was fully functional for all use
cases and it was not easy to get it there. I don't have it.
Please provide the dmesg for failing auto detection without forcing
some card = number as a starting point.
I for sure want to see this board fully functional again.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface
Hi,
Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
This is a V4L2 driver for TI OMAP1 SoC camera interface.
[snip]
+
+ } else {
+ dev_warn(dev, %s: unhandled camera interrupt, status ==
+ 0x%0x\n, __func__, it_status);
Please, don't split strings
sorry for any OT interference.
But, are there any new rules out?
Maybe I missed them.
Either way, the above was forced during the last three years.
Not at all ?
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch for lifeview hybrid mini
Am Montag, den 23.08.2010, 16:06 +0200 schrieb tomloh...@gmail.com: Le 17/08/2010 02:24, hermann pitton a écrit : Hi, Am Sonntag, den 15.08.2010, 07:20 +0200 schrieb tomloh...@gmail.com: Hi, the proposed patch is 6 month old and the owner of the card does not give any more sign of life for the support of the radio. can someone review it and push it as is? Cheers, Signed-off-by: thomas gentytomloh...@gmail.com Thomas, just some quick notes, since nobody else cares. The m$ regspy gpio logs do show only gpio22 changing for analog and DVB-T and this should be the out of reference AGC control on a hopefully single hybrid tuner on that device called DUO. Remember, gpios not set in the mask of the analog part of the device do not change/switch anything, but those set there will change to zero even without explicit gpio define for that specific analog input. Out of historical reasons, we don't have this in our logs for DVB, also else they would be littered by the changing gpios for the TS/MPEG interface, but should be OK. We don't need to mark DVB related gpio stuff in the analog gpio mask, since we need to use some sort of hack to switch gpios on saa713x in DVB mode. dvb and v4l still don't know much about what each other subsystem does on that, but we have some progress. So, for now, I don't know for what gpio21 high in analog TV mode should be good, since the m$ driver seems not to do anything on that one, for what we have so far. Also it is common on later LifeView stuff (arrgh), but always is present in related logs then too. If ever needed, despite of that line inputs and muxes are also totally unconfirmed, and radio is plain madness ... drop the radio support for now, mark the external inputs as untested and I give some reviewed by so far with headaches. If we can't get more from here anymore, we must let it bounce. Cheers, Hermann Hi Hermann, thanks for you response for gpios : there is no software bundled with this card to listen to the radio so there is maybe a gpio not showed in regspy when trying to listen music. Is this a bad assumption? anyway gpios 22 and 16 are hight in regspy with gpiomask 410 000 : dvb, analog tv and svideo work fine only radio remains : you can hear the results for radio here (2 Mo): http://perso.orange.fr/tomlohave/linux/radio.test we can clearly hear the sound of a song but it is broken and interrupted, the question is why have you a suggestion ? Cheers T.G Hello Thomas, the assumption is good then. Latest revisions of the Lifeview cards do switch to radio mode with gpio21 high and let it low for TV. (it was the other way round previously) I was just wondering, if it might have radio support at all, since gpio21 is not set in the m$ gpio mask and you say it does not come with radio software. The gpio18 and 16 can trigger IRQs and are usually in use on such remotes for the button up/down signal and related IRQ sampling. All saa7133/35/31e with tda8275ac and radio IF support use a special 7.5MHz ceramic filter, usually a huge well visible part in blue or orange color, but on latest designs they are hard to identify, since they might appear as SMD discrets now too. The switch to this filter is often related to a an antenna connector RF input switch triggered by the same gpio, but not necessarily. All sort of combinations do exist. Anyway, we demodulate the radio IF from such tuners on the saa7133/35/31e on the saa chip and do also the stereo separation and detection there. Hartmut added the needed code in saa7134-tvaudio and it is valid for all tuner=54. To achieve that, you need to use amux = TV for radio and likely also some gpio is involved for the RF routing. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch for lifeview hybrid mini
Hi, Am Sonntag, den 15.08.2010, 07:20 +0200 schrieb tomloh...@gmail.com: Hi, the proposed patch is 6 month old and the owner of the card does not give any more sign of life for the support of the radio. can someone review it and push it as is? Cheers, Signed-off-by: thomas gentytomloh...@gmail.com Thomas, just some quick notes, since nobody else cares. The m$ regspy gpio logs do show only gpio22 changing for analog and DVB-T and this should be the out of reference AGC control on a hopefully single hybrid tuner on that device called DUO. Remember, gpios not set in the mask of the analog part of the device do not change/switch anything, but those set there will change to zero even without explicit gpio define for that specific analog input. Out of historical reasons, we don't have this in our logs for DVB, also else they would be littered by the changing gpios for the TS/MPEG interface, but should be OK. We don't need to mark DVB related gpio stuff in the analog gpio mask, since we need to use some sort of hack to switch gpios on saa713x in DVB mode. dvb and v4l still don't know much about what each other subsystem does on that, but we have some progress. So, for now, I don't know for what gpio21 high in analog TV mode should be good, since the m$ driver seems not to do anything on that one, for what we have so far. Also it is common on later LifeView stuff (arrgh), but always is present in related logs then too. If ever needed, despite of that line inputs and muxes are also totally unconfirmed, and radio is plain madness ... drop the radio support for now, mark the external inputs as untested and I give some reviewed by so far with headaches. If we can't get more from here anymore, we must let it bounce. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear Kuninori,
Am Donnerstag, den 15.07.2010, 14:37 +0900 schrieb Kuninori Morimoto:
Dear hermann
Is there any documentation and how can a user know about it?
Ecovec board which I and Guennadi were talking about is an evaluation board.
If you buy this board, you can find DVD including manual in its box.
Please check
${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf
on that stage it is now, you can't call me to crawl the web or buy any
evaluation board, likely high priced, still not even providing a link.
If you use GNU/Linux, free of charge, you have to provide acceptable
documentation too.
dip-switch settings is wrote in
3.4 Switch Specification
If you don't have this board,
but have kernel source code,
you can watch explain comment on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Best regards
--
Kuninori Morimoto
This is lame. I do want to know what is out in the markets already and
no fall back on initial dip-switch comments. Comparable sensors ship
from China directly for some 5 Euros and less here.
This is a change (chance?) in culture too, and was already discussed in
1976 by some, but was at least public for all those a little bit more
interested since, let's say, 1982.
This is going on for a long time now, it did not hit the linuxtv.org
wiki at all until today, but introduces most relevant API changes. To
stop to provide support for older devices, in favor of the like of such
stuff, was mentioned several times already to get quicker to the
bonanza.
All major hardware manufacturers, and/or those claiming to be codec
possessors, have hired linux devel teams around the globe to move this
forward.
What it means, that everyone likely can film his life soon with two HD
cameras on mobile devices at once, let's say with 1080p for now, one
following his view to the outside world, the other one pointing to
him/her at the same time, about that, there is no word on this list.
It is not about missing some dip switch settings on an evaluation board.
It is about missing documentation, but much more about missing
reflection, if GNU/Linux should give the vehicle for such.
And it obviously does, even without any further comments.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Am Mittwoch, den 14.07.2010, 09:12 +0900 schrieb Kuninori Morimoto:
Dear Guennadi
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Hmm I understand.
I guess, at first, we need test program for it.
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
Hmm.. strange...
No kernel patch is needed to use tw9910 on Ecovec.
Ahh...
Maybe the criminal is dip-switch.
We can not use tw9910 and 2nd camera in same time.
Please check DS2[3] on Ecovec.
It should OFF when you use tw9910.
I wrote dip-switch info on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Please check it too.
Best regards
--
Kuninori Morimoto
Kuninori,
you are well treated and highly honored by all staying in development
with you. For me it is just some glitch on the edges, but very well
noted.
For now, a dip-switch, you must have been abroad somewhere, can't be a
criminal. Or?
http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ
Could you eventually agree with that about what a dip-switch is or do I
miss what you mean?
Do you really tell there are still unclear dip-switches in 2010?
If so, please let's know, but then you can't do anything against such in
software, of course.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Terratec Cinergy 250 PCI support
Hi Jean-Michel,
Am Sonntag, den 04.07.2010, 19:03 +0200 schrieb Jean-Michel Grimaldi:
Thanks Hermann,
Yes my card is 153b:1160 in dmesg. After testing, the right audio is
actually LINE2 rather than LINE1 (it did not make any difference for
me since I did not use the audio on this card). Hence the following
patch does the job for my card:
sorry for the delay.
Ah, indeed the same PCI subsystem on yours.
Looks like the documentation of the card variants needs improvement.
On the low profile one at the bttv-gallery the chips for digital TV are
not soldered, it has the huge brown 7.5MHz radio IF filter, the yellow
input connector seems to be for radio RF antenna input.
Especially to be noted, it has a KS008 for i2c IR.
But that fuzzy picture on the package there shows the same card as on
your second link. It has extra connectors for audio in and out. (blue
and green)
Like on your card on your first link, 250 PCI Ver.1.0, the KS008 is
missing, the digital TV chips are present, the huge radio IF ceramic
filter is gone and likely replaced by some SMD part, since analog radio
support is still announced, but you don't have the blue and green audio
connectors.
Thanks for testing also the audio input.
Your result is conform to the .inf file in the bttv-gallery.
Is external audio-in over a break out cable together with S-Video?
Is the yellow input for the radio RF antenna or Composite?
The vmux 3 is typically used for an extra Composite input whereas vmux 0
is in most cases Composite over the S-Video connector.
Please post also all dmesg related to the card for the record and in
case we should need it in the future.
BTW, the recent Cinergy HT PCI is cx88x based and comes with a Composite
to S-Video adapter.
http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html
But for the connectivity they show the HT PCI with saa7131e ...
and point to the yellow input from VCR/DVD/etc.
--- saa7134-cards.old.c2010-07-04 18:50:13.0 +0200
+++ saa7134-cards.new.c2010-07-04 18:17:54.0 +0200
@@ -2832,6 +2832,10 @@
.amux = TV,
.tv = 1,
},{
+.name = name_comp1,
+.vmux = 3,
+.amux = LINE2,
+},{
.name = name_svideo, /* NOT tested */
.vmux = 8,
.amux = LINE1,
I did not touch the existing sections in case another variation of the
card worked with them.
Is this patch ok now?
Regards,
Jean-Michel
Yes, looks at least much better.
We can change the amux of svideo to LINE2 too.
In the attached version of your patch against mercurial v4l-dvb I do
this and sign off for it.
Please reply with your SOB for adding and testing the Composite input
and put it above my reviewed by and the patch should be ready for
lift-off now.
Thanks for working on it,
Hermann
patch is attached
saa7134: add the Composite input on Cinergy 250 PCI and fix related amux
This was untested until now and the changes are also conform to the
.inf file of the Philips driver. We change the amux for S-Video
accordingly too. There are slightly different variants of the card
not yet fully investigated.
Priority: normal
Reviewed-by: hermann pitton hermann-pit...@arcor.de
Signed-off-by: hermann pitton hermann-pit...@arcor.de
2010/7/2 hermann pitton hermann-pit...@arcor.de
Hi Jean-Michel,
Am Mittwoch, den 30.06.2010, 00:02 +0200 schrieb Jean-Michel
Grimaldi:
Hi Hermann,
Thanks for your answer. Do you mean I should add an entry
with .name =
name_comp1, .vmux = 3, .amux = LINE1 ?
Should I remove the svideo entry, given that the card (which
can be
seen at [1]) only has a (proprietary) composite jack?
However there
seems to exist another card with the same name Terratec
Cinergy 250
PCI but different connectors : [2]
What do you think? Should I just add a composite entry and
leave the
svideo as it is?
Jean-Michel
[1] http://www.arminformatique.fr/images/TerraTec%20Cinergy%
20250%
20PCI.jpg
[2] http://www.notebookland.hu/shop
+TERRATEC-CINERGY-250-PCI-TERRATEC-TV-tuner_29849_49
there is also a low profile PCI card.
http://www.terratec.net/de/produkte/bilder/img/2195346_5f78fcd0d7.png
http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html
Without any such device in my possession and without
sufficient testing
and reports, hard to tell.
Do you have the known subsystem 153b:1160 ?
For that one from http://www.bttv-gallery.de
chips: saa7131e, KS008, 8275ac1
pcb: TV-7131 Ver:B
:00:0b.0 Multimedia controller
Re: Fwd: Firmware for HVR-1110
Hi, JD, Am Montag, den 05.07.2010, 19:08 + schrieb JD: All seems to be working fine now, I followed the installtion guide for the HVR-1120 and used the tda10048 f/w and I can now find DVB channels; I am still not sure as to why my card is looking for a different f/w tho, and would like to know why if anyone finds out. Thanks for your help. can't see the problem with different firmware in your logs. I guess the root cause for all your prior trouble was that the HVR 1120 is packed as a HVR1110. Such unfortunately is a known problem with new Hauppauge products since a decade :( That flaw is compensated by best auto detection and open eeprom content. Also guys like Steven and Michael did develop the drivers you need on that new card during their free time. (demodulator is in serial TS mode and new tuner on saa7134) All auto detection looks OK and of course also correct firmware is uploaded then. Especially the C2 tuner variant is still quite new and I guess Michael would prefer reports based on code on development level. Cheers, Hermann [ 12.185935] saa7130/34: v4l2 driver version 0.2.15 loaded [ 12.185990] saa7134 :03:04.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 12.185997] saa7133[0]: found at :03:04.0, rev: 209, irq: 16, latency: 64, mmio: 0xfebff800 [ 12.186004] saa7133[0]: subsystem: 0070:6707, board: Hauppauge WinTV-HVR1120 DVB-T/Hybrid [card=156,autodetected] [ 12.186027] saa7133[0]: board init: gpio is 4 [ 12.208619] IRQ 16/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 12.222966] HDA Intel :00:1b.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 12.223016] HDA Intel :00:1b.0: setting latency timer to 64 [ 12.292676] hda_codec: ALC662 rev1: BIOS auto-probing. [ 12.294322] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input6 [ 12.360024] saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 12.360044] saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff ff ff ff ff ff ff [ 12.360062] saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff 00 b0 ff ff ff ff [ 12.360080] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 12.360097] saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04 00 20 00 ff ff ff [ 12.360114] saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360131] saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360149] saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360166] saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 ba 54 5e f0 73 05 29 00 [ 12.360183] saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 19 8d 72 07 70 73 09 [ 12.360201] saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72 0e 01 72 0f 01 72 [ 12.360215] saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79 8d 00 00 00 00 00 [ 12.360224] saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360233] saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360241] saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360250] saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.360260] i2c i2c-1: Invalid 7-bit address 0x7a [ 12.360745] tveeprom 1-0050: Hauppauge model 67209, rev C1F5, serial# 6182074 [ 12.360748] tveeprom 1-0050: MAC address is 00-0D-FE-5E-54-BA [ 12.360750] tveeprom 1-0050: tuner model is NXP 18271C2 (idx 155, type 54) [ 12.360753] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [ 12.360755] tveeprom 1-0050: audio processor is SAA7131 (idx 41) [ 12.360757] tveeprom 1-0050: decoder processor is SAA7131 (idx 35) [ 12.360759] tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter [ 12.360761] saa7133[0]: hauppauge eeprom: model=67209 [ 12.628148] tuner 1-004b: chip found @ 0x96 (saa7133[0]) [ 12.695985] r8169: eth0: link up [ 12.695992] r8169: eth0: link up [ 12.708063] tda829x 1-004b: setting tuner address to 60 [ 12.954972] tda18271 1-0060: creating new instance [ 13.21] TDA18271HD/C2 detected @ 1-0060 [ 14.458202] CPU0 attaching NULL sched-domain. [ 14.458209] CPU1 attaching NULL sched-domain. [ 14.480104] CPU0 attaching sched-domain: [ 14.480108] domain 0: span 0-1 level MC [ 14.480110] groups: 0 1 [ 14.480116] CPU1 attaching sched-domain: [ 14.480118] domain 0: span 0-1 level MC [ 14.480120] groups: 1 0 [ 14.520030] tda18271: performing RF tracking filter calibration [ 15.810914] CPU0 attaching NULL sched-domain. [ 15.810921] CPU1 attaching NULL sched-domain. [ 15.832110] CPU0 attaching sched-domain: [ 15.832114] domain 0: span 0-1 level MC [ 15.832117] groups: 0 1 [ 15.832122] CPU1 attaching sched-domain: [ 15.832124] domain 0: span 0-1 level MC [ 15.832126] groups: 1 0 [
Re: Fwd: Firmware for HVR-1110
Hi JD, Am Samstag, den 03.07.2010, 03:32 +0100 schrieb JD: I'm confused as to what firmware in needed for the HVR-1110. Scouring the web, everywhere claims that the dvb-fe-tda10046 is required; however, dmesg logs show that this fails to be uploaded, and instead it is looking for dvb-fe-tda-10048: If I use tda-10048 then this seems to successfully loaded, but I am unable to find any channels with a scan; the dvb nodes within /dev/ are created and modules loaded, but dvbscan fails to tune. -- dmesg $ dmesg |grep firmware tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... saa7134 :03:04.0: firmware: requesting dvb-fe-tda10048-1.0.fw tda10048_firmware_upload: firmware read 24878 bytes. tda10048_firmware_upload: firmware uploading tda10048_firmware_upload: firmware uploaded Any tips? Thanks. -- all variants of the HVR-1110 have a tda 10046. I can't see, how firmware loading can fail on auto detection of those and even switch over to tda10048 as an alternative. Do you force some card = number and are maybe on a not yet detected HVR-1120? Please provide the full dmesg log related to your card and make sure you are on Michael Krufky's latest patches. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Terratec Cinergy 250 PCI support
for the radio antenna
RF input and changing to a low profile regularly calls for smaller
connectors too.
The opposite can be true of course too and much did change ...
In best case, they do have a different PCI subsystem then, if not and
much worse, maybe we can still figure out some difference from the
eeprom content. Worst case, we don't know how to make any difference and
the OEM does not follow Philips recommendations for the eeprom content
and uses some proprietary methods to detect the cards.
Cheers,
Hermann
2010/6/25 hermann pitton hermann-pit...@arcor.de
Am Freitag, den 25.06.2010, 01:43 +0200 schrieb hermann
pitton:
Hi, Jean-Michel,
Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel
Grimaldi:
Hi, I have a Terratec Cinergy 250 PCI video card, and a
small
modification in saa7134-cards.c is needed for it to work.
I built the
patch on 2.6.34 version (I sent the modification to the
maintainer in
early 2009 but got no feedback):
-- saa7134-cards.old.c 2010-06-25 00:31:16.0
+0200
+++ saa7134-cards.new.c 2010-06-25 00:30:52.0
+0200
@@ -2833,7 +2833,7 @@
.tv = 1,
},{
.name = name_svideo, /* NOT tested */
- .vmux = 8,
+ .vmux = 3,
.amux = LINE1,
}},
.radio = {
Thanks for taking it into account in future kernels.
hm, don't know who missed it. After Gerd, the main mover on
saa7134 was
Hartmut, also /me and some well known others cared.
Official maintainer these days is Mauro.
For latest DVB stuff, you also will meet Mike Krufky.
I'm sorry, but your patch is still wrong.
You do have only a Composite signal. S-Video, with separated
chroma and
luma, can only be on vmux 5-9.
NACKED-by: hermann pitton hermann-pit...@arcor.de
Jean-Michel,
do you understand?
You need to add the missing Composite inputs instead.
One of them can be Composite over the S-Video-in connector.
Have a look at other cards in saa7134-cards.c.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi Avl, Am Samstag, den 26.06.2010, 12:08 + schrieb Avl Jawrowski: Hi, there are some news with 2.6.34 (or previous). The IR is detected and the device seems to be created, but it doesn't work. saa7130/34: v4l2 driver version 0.2.15 loaded saa7134 :01:02.0: PCI INT A - GSI 22 (level, low) - IRQ 22 saa7133[0]: found at :01:02.0, rev: 209, irq: 22, latency: 32, mmio: xcfddf800 saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[0]: board init: gpio is 600c000 IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2e 15 13 ff ff saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2 saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 03 c5 e8 9d saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff input: i2c IR (Pinnacle PCTV) as /class/input/input5 Creating IR device irrcv0 ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-0/0-0047/ir0 [saa7133[0]] tuner 0-004b: chip found @ 0x96 (saa7133[0]) tda829x 0-004b: setting tuner address to 61 tda829x 0-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... And loading it with i2c_debug=1 ir_debug=1 I get a lot of these: [ 3757.243258] input: i2c IR (Pinnacle PCTV) as /class/input/input6 [ 3757.243314] Creating IR device irrcv0 [ 3757.243318] ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-0/0-0047/ir0 [saa7133[0]] [ 3757.243330] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3757.243470] i2c IR (Pinnacle PCTV)/ir: read error [ 3757.243512] saa7133[0]: i2c xfer: 10 3c 33 60 [ 3757.251420] saa7133[0]: i2c xfer: 84 ERROR: NO_DEVICE [ 3757.251599] saa7133[0]: i2c xfer: 86 ERROR: NO_DEVICE [ 3757.251777] saa7133[0]: i2c xfer: 94 ERROR: NO_DEVICE [ 3757.251955] saa7133[0]: i2c xfer: 96 [ 3757.256422] saa7133[0]: i2c xfer: 96 00 [ 3757.262970] saa7133[0]: i2c xfer: 97 =01 =01 =00 =11 =01 =04 =01 =85 [ 3757.269646] saa7133[0]: i2c xfer: 96 1f [ 3757.276302] saa7133[0]: i2c xfer: 97 =89 [ 3757.283045] tuner 0-004b: chip found @ 0x96 (saa7133[0]) [ 3757.283135] saa7133[0]: i2c xfer: 96 1f [ 3757.289700] saa7133[0]: i2c xfer: 97 =89 [ 3757.296308] saa7133[0]: i2c xfer: 96 2f [ 3757.302981] saa7133[0]: i2c xfer: 97 =00 [ 3757.309643] saa7133[0]: i2c xfer: 96 21 c0 [ 3757.339639] saa7133[0]: i2c xfer: c1 ERROR: NO_DEVICE [ 3757.339818] saa7133[0]: i2c xfer: c3 =0a [ 3757.346302] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3793.576474] i2c IR (Pinnacle PCTV)/ir: read error [ 3793.678145] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3793.678290] i2c IR (Pinnacle PCTV)/ir: read error [ 3793.776341] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3793.776481] i2c IR (Pinnacle PCTV)/ir: read error [ 3793.876338] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3793.876480] i2c IR (Pinnacle PCTV)/ir: read error [ 3793.976343] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3793.976484] i2c IR (Pinnacle PCTV)/ir: read error [ 3794.076337] saa7133[0]: i2c xfer: 8f ERROR: NO_DEVICE [ 3794.076478] i2c IR (Pinnacle PCTV)/ir: read error It is an improvement or not? Thanks, Avl unfortunately no improvement for you. Jean Delvare just changed i2c to use reads at 0x8f for probing the device instead of writes at 0x8e previously. The result for you is the same. Also no news about how to make any difference between the 310i variants. Those later ones with some first sort of LNA should still be broken. All I can say is, some people reported, proved by bisecting, that they need the old LNA config = 1, Mike Krufky also assured to me, that he can't say, which of the HVR 1110 needs the new LNA config = 1, but can't exclude it is needed on some card. You, obviously with some latest variant of the
Re: [PATCH] Terratec Cinergy 250 PCI support
Am Freitag, den 25.06.2010, 01:43 +0200 schrieb hermann pitton:
Hi, Jean-Michel,
Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel Grimaldi:
Hi, I have a Terratec Cinergy 250 PCI video card, and a small
modification in saa7134-cards.c is needed for it to work. I built the
patch on 2.6.34 version (I sent the modification to the maintainer in
early 2009 but got no feedback):
-- saa7134-cards.old.c 2010-06-25 00:31:16.0 +0200
+++ saa7134-cards.new.c 2010-06-25 00:30:52.0 +0200
@@ -2833,7 +2833,7 @@
.tv = 1,
},{
.name = name_svideo, /* NOT tested */
- .vmux = 8,
+ .vmux = 3,
.amux = LINE1,
}},
.radio = {
Thanks for taking it into account in future kernels.
hm, don't know who missed it. After Gerd, the main mover on saa7134 was
Hartmut, also /me and some well known others cared.
Official maintainer these days is Mauro.
For latest DVB stuff, you also will meet Mike Krufky.
I'm sorry, but your patch is still wrong.
You do have only a Composite signal. S-Video, with separated chroma and
luma, can only be on vmux 5-9.
NACKED-by: hermann pitton hermann-pit...@arcor.de
Jean-Michel,
do you understand?
You need to add the missing Composite inputs instead.
One of them can be Composite over the S-Video-in connector.
Have a look at other cards in saa7134-cards.c.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Terratec Cinergy 250 PCI support
Hi, Jean-Michel,
Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel Grimaldi:
Hi, I have a Terratec Cinergy 250 PCI video card, and a small
modification in saa7134-cards.c is needed for it to work. I built the
patch on 2.6.34 version (I sent the modification to the maintainer in
early 2009 but got no feedback):
-- saa7134-cards.old.c2010-06-25 00:31:16.0 +0200
+++ saa7134-cards.new.c 2010-06-25 00:30:52.0 +0200
@@ -2833,7 +2833,7 @@
.tv = 1,
},{
.name = name_svideo, /* NOT tested */
- .vmux = 8,
+ .vmux = 3,
.amux = LINE1,
}},
.radio = {
Thanks for taking it into account in future kernels.
hm, don't know who missed it. After Gerd, the main mover on saa7134 was
Hartmut, also /me and some well known others cared.
Official maintainer these days is Mauro.
For latest DVB stuff, you also will meet Mike Krufky.
I'm sorry, but your patch is still wrong.
You do have only a Composite signal. S-Video, with separated chroma and
luma, can only be on vmux 5-9.
NACKED-by: hermann pitton hermann-pit...@arcor.de
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Laptop failing to suspend when WinTV-HVR950 installed.
Hi David, Am Montag, den 21.06.2010, 20:19 -0500 schrieb David Hagood: I have a 100% repeatable failure for my laptop runing Lucid 64 bit to suspend when my WinTV-HVR950 is installed, and a 100% success rate on it suspending when the device is not installed. If I put the device in, remove the device, and suspend (e.g. by closing the lid) it will suspend. There are no processes opening the device (as confirmed by lsof | grep dvb). Additionally, most of the time the failure to suspend occurs, the machine becomes unresponsive, and I have to hard power off to get it back. Has anybody else seen this? just as a hint. You need some cloud of users, that somebody sticks in. I still have cases, where a single user claims on the wiki, all Asus stuff is rubbish, but he still is exactly the only one failing after years. I don't deny, that it might fail for him. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Laptop failing to suspend when WinTV-HVR950 installed.
Am Dienstag, den 22.06.2010, 04:19 +0200 schrieb hermann pitton: Hi David, Am Montag, den 21.06.2010, 20:19 -0500 schrieb David Hagood: I have a 100% repeatable failure for my laptop runing Lucid 64 bit to suspend when my WinTV-HVR950 is installed, and a 100% success rate on it suspending when the device is not installed. If I put the device in, remove the device, and suspend (e.g. by closing the lid) it will suspend. There are no processes opening the device (as confirmed by lsof | grep dvb). Additionally, most of the time the failure to suspend occurs, the machine becomes unresponsive, and I have to hard power off to get it back. Has anybody else seen this? just as a hint. You need some cloud of users, that somebody sticks in. I still have cases, where a single user claims on the wiki, all Asus stuff is rubbish, but he still is exactly the only one failing after years. To stop joking, well noticed from you. The dvb subsystem never had any way to suspend and recover reliable. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix av7110 driver name
Hi Barry, Am Sonntag, den 13.06.2010, 12:07 +0200 schrieb BOUWSMA Barry: On Sat (Saturday) 12.Jun (June) 2010, 05:10, VDR User wrote: This patch simply changes the name of the av7110 driver to AV7110 instead of the generic dvb it's set to currently. Although it's somewhat trivial, it still seems appropriate to fix the name to be descriptive of the driver. Thanks Derek; I'll just note that as submitted, the trivial patch is a ``reversed'' patch, but I'd hope that any tools written for auto-patch-handing should be able to detect this and correct this issue. The other patch is in ``proper'' order, so no worries. --- v4l-dvb/linux/drivers/media/dvb/ttpci/av7110.c 2010-06-11 13:24:29.0 -0700 +++ v4l-dvb.orig/linux/drivers/media/dvb/ttpci/av7110.c 2010-06-11 12:49:50.0 -0700 - .name = AV7110, + .name = dvb, thanks, barry bouwsma the whole situation, dealing with such sort of patches, also given the noise for nothing previously, is of course somewhat unpleasant. But out of such, we had best support from people not obviously related to linux many times and that counts. So, for my experience, it is always worth to have some rumble. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: What ever happened to standardizing signal level?
Hi Manu, - Original Nachricht Von: Manu Abraham abraham.m...@gmail.com An: hermann pitton hermann-pit...@arcor.de Datum: 07.06.2010 05:04 Betreff: Re: What ever happened to standardizing signal level? On Mon, Jun 7, 2010 at 2:01 AM, hermann pitton hermann-pit...@arcor.de wrote: Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User: hermann pitton hermann-pit...@arcor.de, you are contributing absolutely nothing to this thread aside of annoying people with your by trolling and half incoherent nonsense. It's quite ironic you suggest _I_ am the one trolling when this is a thread _I_ created. And further, several people have posted legitimate responses to -- clearly you are the only one suffering from your delusion. Dream on. The question never was, if you are trolling from time to time, but only if you are a duplicate of another troll or on your own. I have talked with Mauro about that and since then I ask you to provide your full name or point at least to a patch from you, where you have to agree to provide your real name in your SOB line. There was none and you also did not point to somebody else, to confirm for us, that you are known and on kernel development not only as a troll. You did not give an sufficient answer during the last two years. Additionally you've been stalking me in email as well. Your behavior is not only uncalled for, it's abusive of both this mailing list and the people willingly participating in the discussion. As I understand it, this is not the first time you've been the source of harassment. The opposite again is true, you stalked me by private e-mail and therefor my reply went as copy also to Mauro and Manu. If even Manu does not have your contact data, who else? Please provide them at least to him or someone else you trust and you are free for rants, within limitations. Sorry, that I could not reply in-time. I had been traveling and hence. Also, with little free time in between additionally. Hermann, what's going on ? I don't see the reason for such a long thread, nor can't believe that time is so cheap .. Anyway ... He doesn't do much of coding, or maybe next to nothing. But he does test hardware and drivers, from what I know, for quite a long time from the time of the FF cards. I know his real name as Derek Kelly and on IRC as hotwings. Well, I do appreciate the time he puts into testing, as it helps to make realize code better, or identify hardware bugs etc. At least a couple of times, I was able to find bugs in my own code, thanks to him. But the other side, unlike most people, he seemed to not have a taste for taking credits at all (don't know why, eventhough I had pointed out to him a few times) .. Regards, Manu many thanks for your time and help. Ah. Derek please take some credits. I suspected him to be a troll only, since for more than two years he refused to provide at least a full name. There was also no single patch with a valid SOB. This has changed now and there should be no reasons for any further clashes. His temper and harshness, when me was insisting on a full name, did always remind me on Uwe, who is using multiple email accounts on his attempts to improve development. If you trust him, I'll trust him too. Derek, sorry for have being preemptive on you. Thanks, Hermann Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User: hermann pitton hermann-pit...@arcor.de, you are contributing absolutely nothing to this thread aside of annoying people with your by trolling and half incoherent nonsense. It's quite ironic you suggest _I_ am the one trolling when this is a thread _I_ created. And further, several people have posted legitimate responses to -- clearly you are the only one suffering from your delusion. Dream on. The question never was, if you are trolling from time to time, but only if you are a duplicate of another troll or on your own. I have talked with Mauro about that and since then I ask you to provide your full name or point at least to a patch from you, where you have to agree to provide your real name in your SOB line. There was none and you also did not point to somebody else, to confirm for us, that you are known and on kernel development not only as a troll. You did not give an sufficient answer during the last two years. Additionally you've been stalking me in email as well. Your behavior is not only uncalled for, it's abusive of both this mailing list and the people willingly participating in the discussion. As I understand it, this is not the first time you've been the source of harassment. The opposite again is true, you stalked me by private e-mail and therefor my reply went as copy also to Mauro and Manu. If even Manu does not have your contact data, who else? Please provide them at least to him or someone else you trust and you are free for rants, within limitations. Do us all a favor -- go find some other thread to infect with your childishness, find some other user(s) to harass/stalk/obsess over, or simply grow up and stop wasting everyone's time. In case you haven't noticed there has been absolutely nobody supporting your rants. Take a hint. http://linuxtv.org/wiki/index.php/People_behind_V4L-DVB I did not put myself on this list and you should take me a little more serious when asking you to fulfill the minimum requirements for participating in kernel development. Also, if you further associate me with illegal drugs, I give you a 100% guarantee, that this will become _very_ expensive for you. You also won't make the vine sour I have after working on my linux hobby. Now, after wasting my time looking at it, I can see you have a first alsa patch in 2.6.33 with an invalid SOB, since only Derek, but corrected to Derek Kelly in 2.6.34. Missing is still, if you are working as a Hobbyist or if you are paid for your work. Greg might ask you such soon or did already. If your name is true, you could have saved yourself and all others most of all the trouble. Looking at your methods, my doubts are not gone, but I let it to others now. Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correction: success
Hi Alexander, Am Freitag, den 04.06.2010, 13:57 +0200 schrieb Alexander Apostolatos: Original-Nachricht Datum: Fri, 04 Jun 2010 06:39:30 +0200 Von: hermann pitton hermann-pit...@arcor.de An: Alexander Apostolatos alexander.apostola...@gmx.de CC: linux-media@vger.kernel.org Betreff: Re: success Hi, Am Freitag, den 04.06.2010, 03:59 +0200 schrieb Alexander Apostolatos: Hi, had success in activating analog tuner in: http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards Philips TV/Radio Card CTX918, (Medion 7134), PCI In my case, device is labeled: MEDION Type: TV-Tuner 7134 V.92 Data/Fax Modem Rev: CTX918_V2 DVB-T/TV P/N: 20024179 Label on tuner (other side of PCB) offers info on tuner type: Label reads: 3139 147 22491c# FMD1216ME/I H-3 SV21 6438 mine is SV21 0437. Guess you have 0438 and both should work as tuner=63. Made in INONESIA So I suppose tuner=78 is the compatible type for FMD1216ME/I H-3, NOT tuner=63 as detected by system. Please check and alter if applicable. Suspect different Hardware revs come with identical hardware ID's. Will provide additional info if told hot to obtain (hardware ID or whatever), but have to take a nap right now. It's 4 in the morning. I have such stuff with some known flaws, easily to circumvent. The CTX918 V2 needs to be in the original dual bus master capable blue MSI/Medion PCI slot. Else, it can become very tricky. Cheers, Hermann Hermann, thanks for the reply. I knew of the blue slot from the manufacturer's website, so the device always was in the blue slot. Good, that is most important. However, I have to correct myself. I double checked last night, instead of having a nap and it turned out, that there are preconditions involved for the function of the card: in my case, the card works only after provoking a segfault by loading with card=97 Tuner=38 and running eg. tvtime. After the ensuing segfault, a modprobe with card=12 and everyone of tuner 38, 63 and 78 yields a working device as it seems. This means that after a segfault, the drive works with the parameters passed by autodetect. I have too look into that, find out what exactly the segfault does. However I have a bit of a learning curve to get there. I'm currently running ubuntu lucid live and I have to look at the behaviour when installed. If You'd like to share Your experiences with the card, especially the easily to convent problems, I'd be very grateful. Especially if it involves getting how to get DVB (T) to work or how to enable dma sound instead of using an audio cable. Your's Alex On current kernels the tuner by default is only enabled for DVB-T. There are some special bits in tuner core code to enable it for analog mode, which currently don't come through in the init sequences on first load. You will notice in dmesg that the analog IF demodulator tda9887 is missing. You must reload the driver once and it will be there. You might set options saa7134 alsa=0 in /etc/modprobe.d/saa7134.conf, else on recent distros the audio daemons might hold use count on saa7134-alsa and you can't modprobe -vr saa7134-dvb, which also unloads saa7134. On the wiki should be some instructions for saa7134-alsa usage. http://www.linuxtv.org/wiki/index.php/Saa7134-alsa On radio autoscan does not work, since the tuner does not provide a stereo detection bit, but sound is good stereo. Radio sound is better with audio cable in the red connector. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
Am Montag, den 07.06.2010, 00:12 +0200 schrieb Lars Schotte: stop flaming all the time, there are ppl out there like me who have some problems w/ their HW, and you are arguing here about nothing. On Mon, 07 Jun 2010 00:01:22 +0200 hermann pitton hermann-pit...@arcor.de wrote: If your name is true, you could have saved yourself and all others most of all the trouble. Looking at your methods, my doubts are not gone, but I let it to others now. Hermann ugh, seems you start new flaming ;) Am Sonntag, den 06.06.2010, 21:28 +0200 schrieb Lars Schotte: OK, i am using w_scan, it scanned and found DVB-S2 channels but szap-s2 doesnt tune in and there is no data, exactly like i said, so either you are lying and you have none of this things running or you were paid by huappauge to say this. I fore sure will stay away ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
Hi, Am Sonntag, den 30.05.2010, 00:01 -0700 schrieb VDR User: On Sat, May 29, 2010 at 10:52 PM, hermann pitton hermann-pit...@arcor.de wrote: ...troll spam removed... Hermann, you're a known troll with clearly nothing to contribute to this thread therefore you're comments are unwelcome. Your mostly incoherent rant sounds like the ramblings of somebody who has consumed too much alcohol, and you're obviously using this mailing list as a cry for attention. I'll ask you kindly to stop wasting everyones time with your moronic nonsense and direct your harassment elsewhere. I'm sure you can find something better to do with your time then polluting this mailing list and making yourself look foolish. To everyone else, please disregard this post and the imbecile in which I'm replying to. I tried in vain, several times, to get the VDR User to some ground. To participate in development is about patches, as a minimum. Driver maintainers are on a much higher level and can disregard patches. If patches go to mainline, one has to allow to be authenticated. There is no other way to get any stuff in else, with reasons. If one is acting under some anonymous name and email account, there is no way to fulfill this first requirement. So, anything coming in from such, is taken as trolling. Especially, if one did already qualify for taking it all over, rule the personal engaged and so on ... I'm not sure, if we have to improve the wiki for those never ever sending any patches, since this is the first on what we meet. But some, taking it all over, seem still to be in urgent need about how to improve that ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: success
Hi, Am Freitag, den 04.06.2010, 03:59 +0200 schrieb Alexander Apostolatos: Hi, had success in activating analog tuner in: http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards Philips TV/Radio Card CTX918, (Medion 7134), PCI In my case, device is labeled: MEDION Type: TV-Tuner 7134 V.92 Data/Fax Modem Rev: CTX918_V2 DVB-T/TV P/N: 20024179 Label on tuner (other side of PCB) offers info on tuner type: Label reads: 3139 147 22491c# FMD1216ME/I H-3 SV21 6438 Made in INONESIA So I suppose tuner=78 is the compatible type for FMD1216ME/I H-3, NOT tuner=63 as detected by system. Please check and alter if applicable. Suspect different Hardware revs come with identical hardware ID's. Will provide additional info if told hot to obtain (hardware ID or whatever), but have to take a nap right now. It's 4 in the morning. I have such stuff with some known flaws, easily to circumvent. The CTX918 V2 needs to be in the original dual bus master capable blue MSI/Medion PCI slot. Else, it can become very tricky. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
- Original Nachricht Von: VDR User user@gmail.com An: hermann pitton hermann-pit...@arcor.de Datum: 30.05.2010 09:01 Betreff: Re: What ever happened to standardizing signal level? On Sat, May 29, 2010 at 10:52 PM, hermann pitton hermann-pit...@arcor.de wrote: ...troll spam removed... Hermann, you're a known troll with clearly nothing to contribute to this thread therefore you're comments are unwelcome. On requests without success http://linuxtv.org/pipermail/linux-dvb/2009-August/032299.html you are well known for being in good company soon. http://linuxtv.org/pipermail/linux-dvb/2008-December/030704.html I wonder, if this will ever change, but hope so. Hermann Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate M1F
-dvb_orig/drivers/media/video/saa7134/saa7134-input.c2010-05-26
20:34:09.0 +0300
+++ v4l-dvb/drivers/media/video/saa7134/saa7134-input.c 2010-05-26
21:14:54.764339462 +0300
@@ -815,6 +815,11 @@ int saa7134_input_init1(struct saa7134_d
mask_keyup = 0x02;
polling = 50; /* ms */
break;
+ case SAA7134_BOARD_VIDEOMATE_M1F:
+ ir_codes = RC_MAP_VIDEOMATE_M1F;
+ mask_keycode = 0x0ff00;
+ mask_keyup = 0x04;
+ break;
break;
}
if (NULL == ir_codes) {
diff -uprN v4l-dvb_orig/include/media/rc-map.h
v4l-dvb/include/media/rc-map.h
--- v4l-dvb_orig/include/media/rc-map.h 2010-05-26 20:34:11.0
+0300
+++ v4l-dvb/include/media/rc-map.h 2010-05-26 21:07:32.494384159
+0300
@@ -111,6 +111,7 @@ void rc_map_init(void);
#define RC_MAP_TERRATEC_CINERGY_XS rc-terratec-cinergy-xs
#define RC_MAP_TEVII_NEC rc-tevii-nec
#define RC_MAP_TT_1500 rc-tt-1500
+#define RC_MAP_VIDEOMATE_M1F rc-videomate-m1f
#define RC_MAP_VIDEOMATE_S350rc-videomate-s350
#define RC_MAP_VIDEOMATE_TV_PVR rc-videomate-tv-pvr
#define RC_MAP_WINFAST rc-winfast
Signed-off-by: Pavel Osnova pvosn...@gmail.com
On Wed, 2010-05-26 at 02:00 +0200, hermann pitton wrote:
Hi Pavel,
Am Dienstag, den 25.05.2010, 20:42 +0300 schrieb Pavel Osnova:
This patch add support for Compro VideoMate M1F analog TV tuner.
just some small comments.
You must find a way to get patches to patchwork without line breakages.
Patches should be against recent git or mercurial v4l-dvb and you should
run make checkpatch and review the minor stuff it complains about.
For my knowledge, there is no TUNER_LG_PAL_NEW_TAPC with tda9887.
The NEW_TAPC uses LG tuner API and those with tda9887 Philips MK3.
They are different for the UHF switch. Did you test on anything in UHF?
We have some stuff in that cruft unfortunately.
Even with extra radio tuner, Composite and S-Video should have the same
amux.
You set gpios without defining a gpio mask.
Such has no effect.
Cheers,
Hermann
diff -urN linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
linux-2.6.34patched orig/Documentation/video4linux/CARDLIST.saa7134
--- linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
2010-05-17 00:17:36.0 +0300
+++ linux-2.6.34patched
orig/Documentation/video4linux/CARDLIST.saa71342010-05-24
13:33:01.915467949 +0300
@@ -175,3 +175,4 @@
174 - Asus Europa Hybrid OEM [1043:4847]
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
+177 - Compro VideoMate M1F [185b:c900]
diff -urN linux-2.6.34/drivers/media/IR/ir-keymaps.c
linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
--- linux-2.6.34/drivers/media/IR/ir-keymaps.c2010-05-17
00:17:36.0 +0300
+++ linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
2010-05-24 13:37:59.872106122 +0300
@@ -3492,3 +3492,65 @@
.ir_type = IR_TYPE_NEC,
};
EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
+
+/* Compro VideoMate M1F
+ * Pavel Osnova pvosn...@gmail.com
+ */
+static struct ir_scancode ir_codes_videomate_m1f[] = {
+{ 0x01, KEY_POWER },
+{ 0x31, KEY_TUNER },
+{ 0x33, KEY_VIDEO },
+{ 0x2f, KEY_RADIO },
+{ 0x30, KEY_CAMERA },
+{ 0x2d, KEY_NEW }, /* TV record button */
+{ 0x17, KEY_CYCLEWINDOWS },
+{ 0x2c, KEY_ANGLE },
+{ 0x2b, KEY_LANGUAGE },
+{ 0x32, KEY_SEARCH }, /* '...' button */
+{ 0x11, KEY_UP },
+{ 0x13, KEY_LEFT },
+{ 0x15, KEY_OK },
+{ 0x14, KEY_RIGHT },
+{ 0x12, KEY_DOWN },
+{ 0x16, KEY_BACKSPACE },
+{ 0x02, KEY_ZOOM }, /* WIN key */
+{ 0x04, KEY_INFO },
+{ 0x05, KEY_VOLUMEUP },
+{ 0x03, KEY_MUTE },
+{ 0x07, KEY_CHANNELUP },
+{ 0x06, KEY_VOLUMEDOWN },
+{ 0x08, KEY_CHANNELDOWN },
+{ 0x0c, KEY_RECORD },
+{ 0x0e, KEY_STOP },
+{ 0x0a, KEY_BACK },
+{ 0x0b, KEY_PLAY },
+{ 0x09, KEY_FORWARD },
+{ 0x10, KEY_PREVIOUS },
+{ 0x0d, KEY_PAUSE },
+{ 0x0f, KEY_NEXT },
+{ 0x1e, KEY_1 },
+{ 0x1f, KEY_2 },
+{ 0x20, KEY_3 },
+{ 0x21, KEY_4 },
+{ 0x22, KEY_5 },
+{ 0x23, KEY_6 },
+{ 0x24, KEY_7 },
+{ 0x25, KEY_8 },
+{ 0x26, KEY_9 },
+{ 0x2a, KEY_NUMERIC_STAR }, /* * key */
+{ 0x1d, KEY_0 },
+{ 0x29, KEY_SUBTITLE }, /* # key */
+{ 0x27, KEY_CLEAR },
+{ 0x34, KEY_SCREEN },
+{ 0x28, KEY_ENTER },
+{ 0x19, KEY_RED },
+{ 0x1a, KEY_GREEN },
+{ 0x1b, KEY_YELLOW },
+{ 0x1c, KEY_BLUE },
+{ 0x18, KEY_TEXT },
+};
+struct
Re: [PATCH] Compro Videomate T750F Vista digital+analog support
Hi Davor,
Am Montag, den 31.05.2010, 01:48 +0200 schrieb Davor Emard:
HI!
I have downloaded latest hg v4l and adapted the compro
t750f support patch. The patch is the same but v4l code is
newer so there's some improvement
Restarting VDR is now stable. Tried it cca 10x VDR restarts,
DVB-T tuner always worked. Remote still has 10% keys lost.
ALSA device now appears with alsa=1 in the list
arecord -l (but I haven't tried to capture anything yet)
Someone mentioned that MCE-alike remote is the same to all
f-series of the cards so I called it rc-videomate-f.
Here's the patch
likely one of the most difficult cards on that driver during the last
time.
Does't look such bad to me, after all, without having one.
Hmm, somehow its #define in the saa7134.h header is missing?
I'm also wondering, why we don't see the usual three lines offset on the
end of current patches.
Cheers,
Hermann
diff -r 304cfde05b3f linux/drivers/media/IR/keymaps/Makefile
--- a/linux/drivers/media/IR/keymaps/Makefile Tue May 25 23:50:51 2010 -0400
+++ b/linux/drivers/media/IR/keymaps/Makefile Mon May 31 01:18:12 2010 +0200
@@ -63,5 +63,6 @@
rc-tt-1500.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
+ rc-videomate-f.o \
rc-winfast.o \
rc-winfast-usbii-deluxe.o
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Tue May 25
23:50:51 2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon May 31
01:18:12 2010 +0200
@@ -4920,12 +4920,14 @@
},
[SAA7134_BOARD_VIDEOMATE_T750] = {
/* John Newbigin j...@it.swin.edu.au */
+ /* Emard 2010-05-10 v18-v4l davorem...@gmail.com */
.name = Compro VideoMate T750,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_XC2028,
.radio_type = UNSET,
- .tuner_addr = ADDR_UNSET,
+ .tuner_addr = 0x61,
.radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -6752,6 +6754,11 @@
msleep(10);
saa7134_set_gpio(dev, 18, 1);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ saa7134_set_gpio(dev, 20, 0);
+ msleep(10);
+ saa7134_set_gpio(dev, 20, 1);
+ break;
}
return 0;
}
@@ -7171,6 +7178,11 @@
saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xC000, 0xC000);
saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xC000, 0xC000);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ dev-has_remote = SAA7134_REMOTE_GPIO;
+ saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000);
+ saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000);
+ break;
}
return 0;
}
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue May 25 23:50:51
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon May 31 01:18:12
2010 +0200
@@ -55,6 +55,7 @@
#include tda8290.h
#include zl10353.h
+#include qt1010.h
#include zl10036.h
#include zl10039.h
@@ -886,6 +887,17 @@
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config videomate_t750_zl10353_config = {
+ .demod_address = 0x0f,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+ .i2c_address = 0x62
+};
+
+
/* ==
* tda10086 based DVB-S cards, helper functions
*/
@@ -1569,6 +1581,21 @@
__func__);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ printk(Compro VideoMate T750 DVB setup\n);
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+ videomate_t750_zl10353_config,
+ dev-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ // if there is a gate function then the i2c bus
breaks.!
+ fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
+ if (dvb_attach(qt1010_attach,
+ fe0-dvb.frontend,
+ dev-i2c_adap,
+ videomate_t750_qt1010_config) == NULL)
+ wprintk(error attaching QT1010\n);
+ }
+
Re: [PATCH] Compro Videomate T750F Vista digital+analog support
Hmm, somehow its #define in the saa7134.h header is missing? I'm also wondering, why we don't see the usual three lines offset on the end of current patches. Forget about the later, is in new file mode. Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
Hi, Am Sonntag, den 30.05.2010, 23:02 -0400 schrieb Michael Krufky: Markus Rechberger wrote: On Sun, May 30, 2010 at 5:21 PM, Michael Krufky mkru...@linuxtv.org wrote: Markus Rechberger wrote: Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus There is a power level value that can be read from the tda18271 -- I had a patch that enabled reading of this value, for testing purposes, but it wasn't as useful as I had hoped, so I never bothered to merge it. If you'd like to play with it, I pushed up some code last year: http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29 Let me know how this works for you, or if you choose to change it. I If you find it valuable, we can merge it in somehow. hmm.. I somewhat tried the same but the register kept flipping back and the powerlevel register returned 0. Markus ...I think it only works on the c2 rev silicon. Not sure about that, though. -Mike that is such stuff that really happens and nobody has any intentions to hide better signal/SNR measurements from the users. Some multiple subscribed trolls may take it for a next round, but it is _nowhere_ any better. Even worse, on S2, the whole previous model of doing so, will come under pressure, if I'm not totally blind. Best, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
Am Freitag, den 28.05.2010, 20:09 -0700 schrieb VDR User: A lot of people were anticipating this happening but it seems to have stalled out. Does anyone know what the intentions are? Many users were also hoping to _finally_ get a good signal meter for linux as well. If anyone has any info, please share! Stop sending SPAM to this list. What should be the intentions? What should happen? Please reiterate all details! Intentions of chip manufacturers are simple, sell more and make more profit than others for others. Further questions on that? On what do _you_ have any progress and can contribute? Is it at least any better on m$? For sure not! There is no as well. Please provide at least one _single_ patch, showing you have any direction on that ... What ever happened? Nothing new. Please try it also from that side then ... IIRC, XCeive supposed a market, for tuners alone, above 6 billions for the next year as a starting argument for investors. Buy whatever you want. As long, those acting on the markets, even without any freely agreeable convention for measurements as reference, how can we have any? Tell from which _instance_ punishing points are allowed and why ... Since it is such a mass/global market, looking promising, lots jump in, but often are out again only a little later. Ever looked in details? To have no proper signal/SNR measurement agreement across all products is only a side effect, but for sure not related to Open Source ;) Show me a treaty, _all_ involved parties did sign, and then _eventually_ some prediction on that in some next future for outdated hardware is feasible. regards -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Compro videomate T750F DVB-T mode works now
Hi,
Am Donnerstag, den 27.05.2010, 14:17 -0300 schrieb Mauro Carvalho
Chehab:
Em Sat, 8 May 2010 01:50:24 +0200
Emard davorem...@gmail.com escreveu:
HI
... tried to post this few times to thhis list I don't know if
it has made it maybe this time it will appear on the mailing list
I have european version of Compro Videomate T750F Vista
hybrid dvb-t + tv (PAL) + FM card. In kernels up to date (2.6.33.3)
it didn't want to initialize in analog mode (tuner xc2028 always failed).
Here's sligthly adapted patch from
http://www.linuxtv.org/pipermail/linux-dvb/2008-May/025945.html
that works for me. It disables analog tuner xc2028 which doesn't
work (maybe because current driver is only for ntsc version of the
card) and enables digital tuner that consists of zarlink 10353 and
qt1010. Tested and works on kernel 2.6.33.3
xc2028 tuner driver supports PAL standards as well. If it is not working fine,
it is probably because the GPIO's are wrong. You need to run REGSPY.EXE
program,
from DScaler project, to get the proper gpio values for your board.
Btw, please send your Signed-off-by: on your patches.
Best regards, Emard
--- linux-2.6.33.3/drivers/media/video/saa7134/saa7134-cards.c.orig
2010-05-02 00:06:45.0 +0200
+++ linux-2.6.33.3/drivers/media/video/saa7134/saa7134-cards.c
2010-05-02 01:20:50.0 +0200
@@ -4883,10 +4883,11 @@ struct saa7134_board saa7134_boards[] =
/* John Newbigin j...@it.swin.edu.au */
.name = Compro VideoMate T750,
.audio_clock= 0x00187de7,
- .tuner_type = TUNER_XC2028,
+ .tuner_type = TUNER_ABSENT,
Instead of touching at the existing entry, you should be adding a new one,
with
your board specifics, otherwise your patch would break support for the other
board variant.
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -7192,6 +7193,7 @@ int saa7134_board_init2(struct saa7134_d
case SAA7134_BOARD_AVERMEDIA_SUPER_007:
case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
case SAA7134_BOARD_CREATIX_CTX953:
+case SAA7134_BOARD_VIDEOMATE_T750:
{
/* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
--- linux-2.6.33.3/drivers/media/video/saa7134/saa7134-dvb.c.orig
2010-05-01 23:57:08.0 +0200
+++ linux-2.6.33.3/drivers/media/video/saa7134/saa7134-dvb.c
2010-05-02 00:51:44.0 +0200
@@ -55,6 +55,7 @@
#include tda8290.h
#include zl10353.h
+#include qt1010.h
#include zl10036.h
#include zl10039.h
@@ -886,6 +887,17 @@ static struct zl10353_config behold_x7_c
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config videomate_t750_zl10353_config = {
+ .demod_address = 0x0f,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+ .i2c_address = 0x62
+};
+
+
/* ==
* tda10086 based DVB-S cards, helper functions
*/
@@ -1556,6 +1568,26 @@ static int dvb_init(struct saa7134_dev *
__func__);
break;
+/*FIXME: What frontend does Videomate T750 use? */
+case SAA7134_BOARD_VIDEOMATE_T750:
+printk(Compro VideoMate T750 DVB setup\n);
+fe0-dvb.frontend = dvb_attach(zl10353_attach,
+
videomate_t750_zl10353_config,
+dev-i2c_adap);
+if (fe0-dvb.frontend != NULL) {
+printk(Attaching pll\n);
+// if there is a gate function then the i2c bus
breaks.!
+fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
+
+if (dvb_attach(qt1010_attach,
+ fe0-dvb.frontend,
+ dev-i2c_adap,
+ videomate_t750_qt1010_config) ==
NULL)
+{
+wprintk(error attaching QT1010\n);
+}
+}
+break;
case SAA7134_BOARD_ZOLID_HYBRID_PCI:
fe0-dvb.frontend = dvb_attach(tda10048_attach,
zolid_tda10048_config,
just for reference, here is a link about what we tried last summer.
The followups do have also some regspy logs.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg07478.html
Re: v4l-dvb does not compile with kernel 2.6.34
Hi Helmut, Am Dienstag, den 25.05.2010, 23:59 +0200 schrieb Helmut Auer: Hello I just wanted to compile v4l-dvb for my Gen2VDR Ditribution with kernel 2.6.34, but it fails because many modules are missing: #include linux/slab.h and are getting errors like: /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c: In function 'free_firmware': /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c:252: error: implicit declaration of function 'kfree' /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c: In function 'load_all_firmwares': /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c:314: error: implicit declaration of function Am I missing something or is v4l-dvb broken ? I did not test on all, but had some rant few days ago and explanations followed and I likely missed some RFCs in that direction previously. If I do get it right now, the released vanilla 2.6.34 should be stable. For the upcoming 2.6.35, like always, only the first upcoming rc1 is a potential candidate for some first stability there. On mercurial v4l-dvb, with all patch porting in this hybrid ;) situation with mixed up- and backports, after the git branch is official, only 2.6.33 is considered to be stable for now. There are still compatibility bugs on all earlier kernels I guess, but /me agreed to have at least four weeks for fixing them. An average kernel release cycle is about three months. I asked, if we should not all go to latest stable vanilla and upcoming rc candidates instead. By that mass of devices we have now, those with relevant hardware must come back for testing on rc stuff anyway. The decision for now was to keep backward compat, to allow to have more testers, this was always my point of view over all the years too. During all that, we changed a lot these days from hacked drivers to by chip manufacturers and OEMs fully supported ones. This is the root cause for going to git and includes to stay in sync with other subsystems on git level doing the same. For what is still trickling in from active users, I also have to say, that this throws one back into time consuming efforts again, even more time consuming than that times v4l and dvb did go out of sync on every new kernel in the past and if it is only about to avoid latest vanilla or upcoming rc stuff and keep staying on older kernels, is it worth it? Testers will vote with their feet. In other words, to keep bisecting reliable on Linus' git level is already a huge task, to keep mercurial v4l-dvb bisecting with all the compat stuff functional, ugh. Also, no doubt, Hans' daily build reports are really helpful, but to assume only seeing warnings there now, after a first fix for some upper older kernel came in, and previously say eight did error out at the same point, is no replacement for testing with real devices on every such later kernel ... The rest is pure luck and a rare case. We likely should wait for two/three kernel release cycles, but I predict Douglas will have a very hard job, if not much more people come in to support backward compatibility on mercurial level. Thanks for your report from the upper side ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate M1F
Hi Pavel,
Am Dienstag, den 25.05.2010, 20:42 +0300 schrieb Pavel Osnova:
This patch add support for Compro VideoMate M1F analog TV tuner.
just some small comments.
You must find a way to get patches to patchwork without line breakages.
Patches should be against recent git or mercurial v4l-dvb and you should
run make checkpatch and review the minor stuff it complains about.
For my knowledge, there is no TUNER_LG_PAL_NEW_TAPC with tda9887.
The NEW_TAPC uses LG tuner API and those with tda9887 Philips MK3.
They are different for the UHF switch. Did you test on anything in UHF?
We have some stuff in that cruft unfortunately.
Even with extra radio tuner, Composite and S-Video should have the same
amux.
You set gpios without defining a gpio mask.
Such has no effect.
Cheers,
Hermann
diff -urN linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
linux-2.6.34patched orig/Documentation/video4linux/CARDLIST.saa7134
--- linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
2010-05-17 00:17:36.0 +0300
+++ linux-2.6.34patched
orig/Documentation/video4linux/CARDLIST.saa71342010-05-24
13:33:01.915467949 +0300
@@ -175,3 +175,4 @@
174 - Asus Europa Hybrid OEM [1043:4847]
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
+177 - Compro VideoMate M1F [185b:c900]
diff -urN linux-2.6.34/drivers/media/IR/ir-keymaps.c
linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
--- linux-2.6.34/drivers/media/IR/ir-keymaps.c2010-05-17
00:17:36.0 +0300
+++ linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
2010-05-24 13:37:59.872106122 +0300
@@ -3492,3 +3492,65 @@
.ir_type = IR_TYPE_NEC,
};
EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
+
+/* Compro VideoMate M1F
+ * Pavel Osnova pvosn...@gmail.com
+ */
+static struct ir_scancode ir_codes_videomate_m1f[] = {
+{ 0x01, KEY_POWER },
+{ 0x31, KEY_TUNER },
+{ 0x33, KEY_VIDEO },
+{ 0x2f, KEY_RADIO },
+{ 0x30, KEY_CAMERA },
+{ 0x2d, KEY_NEW }, /* TV record button */
+{ 0x17, KEY_CYCLEWINDOWS },
+{ 0x2c, KEY_ANGLE },
+{ 0x2b, KEY_LANGUAGE },
+{ 0x32, KEY_SEARCH }, /* '...' button */
+{ 0x11, KEY_UP },
+{ 0x13, KEY_LEFT },
+{ 0x15, KEY_OK },
+{ 0x14, KEY_RIGHT },
+{ 0x12, KEY_DOWN },
+{ 0x16, KEY_BACKSPACE },
+{ 0x02, KEY_ZOOM }, /* WIN key */
+{ 0x04, KEY_INFO },
+{ 0x05, KEY_VOLUMEUP },
+{ 0x03, KEY_MUTE },
+{ 0x07, KEY_CHANNELUP },
+{ 0x06, KEY_VOLUMEDOWN },
+{ 0x08, KEY_CHANNELDOWN },
+{ 0x0c, KEY_RECORD },
+{ 0x0e, KEY_STOP },
+{ 0x0a, KEY_BACK },
+{ 0x0b, KEY_PLAY },
+{ 0x09, KEY_FORWARD },
+{ 0x10, KEY_PREVIOUS },
+{ 0x0d, KEY_PAUSE },
+{ 0x0f, KEY_NEXT },
+{ 0x1e, KEY_1 },
+{ 0x1f, KEY_2 },
+{ 0x20, KEY_3 },
+{ 0x21, KEY_4 },
+{ 0x22, KEY_5 },
+{ 0x23, KEY_6 },
+{ 0x24, KEY_7 },
+{ 0x25, KEY_8 },
+{ 0x26, KEY_9 },
+{ 0x2a, KEY_NUMERIC_STAR }, /* * key */
+{ 0x1d, KEY_0 },
+{ 0x29, KEY_SUBTITLE }, /* # key */
+{ 0x27, KEY_CLEAR },
+{ 0x34, KEY_SCREEN },
+{ 0x28, KEY_ENTER },
+{ 0x19, KEY_RED },
+{ 0x1a, KEY_GREEN },
+{ 0x1b, KEY_YELLOW },
+{ 0x1c, KEY_BLUE },
+{ 0x18, KEY_TEXT },
+};
+struct ir_scancode_table ir_codes_videomate_m1f_table = {
+.scan = ir_codes_videomate_m1f,
+.size = ARRAY_SIZE(ir_codes_videomate_m1f),
+};
+EXPORT_SYMBOL_GPL(ir_codes_videomate_m1f_table);
diff -urN linux-2.6.34/drivers/media/video/saa7134/saa7134-cards.c
linux-2.6.34patched orig/drivers/media/video/saa7134/saa7134-cards.c
--- linux-2.6.34/drivers/media/video/saa7134/saa7134-cards.c
2010-05-17 00:17:36.0 +0300
+++ linux-2.6.34patched
orig/drivers/media/video/saa7134/saa7134-cards.c2010-05-24
13:44:41.618731443 +0300
@@ -5355,7 +5355,39 @@
.amux = LINE2,
},
},
-
+[SAA7134_BOARD_VIDEOMATE_M1F] = {
+.name = Compro VideoMate M1F,
+.audio_clock= 0x00187de7,
+.tuner_type = TUNER_LG_PAL_NEW_TAPC,
+.radio_type = TUNER_TEA5767,
+.tuner_addr = ADDR_UNSET,
+.radio_addr = 0x60,
+.tda9887_conf = TDA9887_PRESENT,
+.inputs = {{
+.name = name_tv,
+.vmux = 1,
+.amux = TV,
+.tv = 1,
+},{
+.name = name_comp1,
+.vmux = 3,
+.amux = LINE2,
+},{
+.name = name_svideo,
+.vmux = 8,
+.amux = LINE1,
+}},
+.radio = {
+.name
Re: [linux-dvb] Leadtek DVT1000S W/ Phillips saa7134
Hi, Am Freitag, den 21.05.2010, 06:01 +1000 schrieb Nathan Metcalf: Thanks Hermann, Does this mean I need to apply that patch you linked to me? Then recompile the module and re-insert? Regards, Nathan depends on your source. The 2.6.32 has no support for that card and it depends also on further patches for tuner and demodulator However, all 4 patches in question are in this pull request Von: Mauro Carvalho Chehab mche...@redhat.com An: Linus Torvalds torva...@linux-foundation.org Kopie: Andrew Morton a...@linux-foundation.org, linux-ker...@vger.kernel.org, linux-media@vger.kernel.org Betreff: [GIT PULL for 2.6.33] V4L/DVB updates Datum: Wed, 9 Dec 2009 02:16:39 -0200 (05:16 CET) and via Michael Krufky and Michael Obst for the remote. (add the card, fix the entry, add the remote support, fix some coding style) You need a kernel = 2.6.33 or have to build and install mercurial v4l-dvb from linuxtv.org on older kernels. The current v4l-dvb is in process to gain deeper compatibility for older kernels again, see the daily mails. [cron job] v4l-dvb daily build Progress was made from 2.6.33 only a few days ago down to 2.6.25 now. My latest test was on a 2.6.29. Else you can also use a snapshot from May 04 2010, after that backward compat was limited to 2.6.33 only for a while, see the v4l-dvb daily build messages. For 2.6.32 the recent is good again. Cheers, Hermann On 20/05/10 09:28, hermann pitton wrote: Hi Nathan, Am Freitag, den 21.05.2010, 04:48 +1000 schrieb Nathan Metcalf: Hey Guys, I hope this is the correct place, I am trying to get a LEADTEK DVT1000S HD Tuner card working in Ubuntu (Latest) When I load the saa7134_dvb kernel module, there are no errors, but /dev/dvb is not created. I have tried enabling the debug=1 option when loading the module, but don't get any more useful information. Can someone please assist me? Or direct me to the correct place? Regards, Nathan Metcalf there was some buglet previously, but the card is else supported since Nov. 01 2009 on mercurial v4l-dvb and later kernels. http://linuxtv.org/hg/v4l-dvb/rev/855ee0444e61b8dfe98f495026c4e75c461ce9dd Support for the remote was also added. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Leadtek DVT1000S W/ Phillips saa7134
Hi Nathan, Am Freitag, den 21.05.2010, 04:48 +1000 schrieb Nathan Metcalf: Hey Guys, I hope this is the correct place, I am trying to get a LEADTEK DVT1000S HD Tuner card working in Ubuntu (Latest) When I load the saa7134_dvb kernel module, there are no errors, but /dev/dvb is not created. I have tried enabling the debug=1 option when loading the module, but don't get any more useful information. Can someone please assist me? Or direct me to the correct place? Regards, Nathan Metcalf there was some buglet previously, but the card is else supported since Nov. 01 2009 on mercurial v4l-dvb and later kernels. http://linuxtv.org/hg/v4l-dvb/rev/855ee0444e61b8dfe98f495026c4e75c461ce9dd Support for the remote was also added. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: av7110 and budget_av are broken!
Hi, Am Sonntag, den 16.05.2010, 06:21 +0200 schrieb Oliver Endriss: On Sunday 16 May 2010 03:53:48 hermann pitton wrote: Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling Landgraf: Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Sorry, I do not want to cope with experimental kernels and their bugs on my systems. I need a stable and reliable platform, so that I can concentrate on 'my' bugs. Usually I update the kernel every 3..4 releases (which causes enough trouble due to changed features, interfaces etc). that is what everyone does prefer and that I call subsystem developer service. In fact, everyone has to be on .rc stuff starting with .rc1 ;) Failing on being there, than blaming the one doing the backports for being in delay, likely without any related hardware in his possession, that can't work. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: av7110 and budget_av are broken!
Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling Landgraf: Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Despite of getting more users for testing, on _that_ front does not happen such much currently, keeping v4l-dvb is mostly a service for developers this time. So, contributing on the backports and helping Douglas with such is really welcome. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi, Am Donnerstag, den 13.05.2010, 15:45 -0300 schrieb Mauro Carvalho Chehab: Mauro Carvalho Chehab wrote: hermann pitton wrote: My view is that the backport tree is very useful to have a broader number of people testing V4L/DVB code, as it can be applied against legacy kernels. Of course, for this to work, people should quickly fix broken backports (that means that not only Douglas should work on it, but other developers are welcomed to contribute with backport fixes). For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb then to provide relevant debug output and eventually patches. Until Douglas or someone fix the breakages with older kernels, yes. As the fix patch is really trivial, I found a couple of minutes to write a patch for fixing this issue. I haven't test the patch, but, as it uses the same backport logic as found at cx2355-ir, I don't expect much troubles on it. Mauro, fine, it is a start. Compiles down to to 2.6.30, but has some __check_debug warnings for three static bool insmod options there. (build cron job of today) To replace them with some int seems ok, but since no such warnings on higher kernels for bool, likely some compat issue. IR oopses on 2.6.30 with Pinnacle 310i on a first try. Thanks for all explanations of the current sync procedures, Douglas does well and four weeks without in depth backward compat are hard to avoid either way. Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after the merge window. Cheers, Hermann saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 5-004b: chip found @ 0x96 (saa7133[1]) tda829x 5-004b: setting tuner address to 61 tda829x 5-004b: type set to tda8290+75a saa7133[1]: registered device video1 [v4l2] saa7133[1]: registered device vbi1 saa7133[1]: registered device radio1 saa7133[2]: setting pci latency timer to 64 saa7133[2]: found at :02:09.0, rev: 208, irq: 19, latency: 64, mmio: 0xfdefd000 saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[2]: board init: gpio is 600c000 IRQ 19/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 6-004b: chip found @ 0x96 (saa7133[2]) tda829x 6-004b: setting tuner address to 61 tda829x 6-004b: type set to tda8290+75a Registered IR keymap rc-pinnacle-color input: i2c IR (Pinnacle PCTV) as /devices/virtual/input/input8 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core] PGD 3ecbd067 PUD 2006b067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/module/saa7134/initstate CPU 0 Modules linked in: rc_pinnacle_color ir_kbd_i2c(+) tda827x tda8290 tuner saa7134(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core ir_common ir_core tveeprom sit tunnel4 fuse bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer r8169 ppdev snd mii soundcore snd_page_alloc parport_pc shpchp k8temp parport hwmon joydev floppy serio_raw pcspkr i2c_nforce2 ata_generic pata_acpi pata_amd radeon drm i2c_algo_bit i2c_core [last unloaded: v4l1_compat] Pid: 3399, comm: modprobe Not tainted 2.6.30.10-105.2.16.fc11.x86_64 #1 RIP: 0010:[a00e97c7] [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core] RSP: 0018:88003b459cb8 EFLAGS: 00010246 RAX
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi, [snip] Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after the merge window. The saa7134 card=2 gpio remote is OK on 2.6.33.4 with current v4l-dvb. Sander, let's know about further questions. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia
M135A,
since this is the board I'm using at the IR refactoring tests, but the
same approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16.
For GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference
of the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the
wiki page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree.
Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git for development, but patches and pull
requests against the backport tree are accepted.
Long answer
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi,
Am Donnerstag, den 13.05.2010, 09:32 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia
M135A,
since this is the board I'm using at the IR refactoring tests, but the
same approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16.
For GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write
one table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name.
See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a
reference of the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the
wiki page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree.
Also,
backports are made at the best efforts basis. So, nobody can warrant that
the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git
Re: Remote control at Zolid Hybrid TV Tuner
Hi Sander, Am Samstag, den 08.05.2010, 16:12 +0200 schrieb Sander Pientka: Hi Hermann, I am going to revive this old thread, I completely forgot about it and I still want to solve this problem. Yes, with the IR transmitter not plugged in, the gpio is reported as 0 by dmesg. I am aware there is a picture of the backside missing on the wiki, I will try to make one a.s.a.p. NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c. Besides, dmesg outputs a section of error messages I don't understand: [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 1585.548229] tda18271_toggle_output: error -5 on line 47 [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 1585.720129] tda18271_init: error -5 on line 826 [ 1585.720136] tda18271_tune: error -5 on line 904 [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041 [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1, i2c_transfer returned: -5 [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1, i2c_transfer returned: -5 [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1, i2c_transfer returned: -5 [ 1586.629458] tda18271_channel_configuration: error -5 on line 160 [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041 Do you have any idea about the origin of these errors? Do you think they affect the IR functionality? you are still welcome with such delayed reports. But I don't have any influence anymore, how such are treated. For the tda18271 stuff, you must be on latest and Michael Krufky should take it on. For to be on latest, I also can't give any advice anymore. For the IR/remote stuff, try with Mauro and all others working through. Cheers, Hermann -- Sander Pientka 2010/2/17 hermann pitton hermann-pit...@arcor.de: Hi, Am Mittwoch, den 17.02.2010, 17:38 +0100 schrieb Sander Pientka: Thanks for your answer. If I understand you correctly, I should disattach the IR receiver, which is a cable with a diode at the end? It is plugged in to a port like the green one for audio. did you remove the copy to the list by will? Then I will not complain about top posting here ;) I think we have only a photo of the frontside of that card. One line from the IR input connector vanishes to the backside. If on the backside is not a dedicated IR controller chip, gpio18 might be in use for the remote. This gpio is capable of triggering IRQs and is also connected to the clock. On recent Asus saa713x cards it is used for some RC5 protocol derived from those IRQs, gpio18 is the up/down button and the only changing gpio pin concerning the remote. That pin goes low, if the receiver is not plugged on the Asus cards. Mauro recently added also support for NEC IR protocol also on that gpio. You should be able to track rc5 and nec support from the mercurial/cvs interface or from the lists. Maybe it gets you started. Cheers, Hermann 2010/2/17 hermann pitton hermann-pit...@arcor.de: Hi Sander, Am Dienstag, den 16.02.2010, 20:16 +0100 schrieb Sander Pientka: Hi, my Zolid Hybrid TV Tuner has been working like a charm for over two months now. The remote control is not working though, which is a showstopper. I don't have experience with remote controls in any kind, I've heard of LIRC but I would rather choose a more elegant solution, for instance evdev in X11. It's wiki page: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner gpio init of your board is reported as 0x24. So gpio18/0x4 is high. Assuming the IR receiver is plugged during that, unplug it on next boot and see if gpio init is now only 0x20. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote control at Zolid Hybrid TV Tuner
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
since this is the board I'm using at the IR refactoring tests, but the same
approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For
GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of
the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the wiki
page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
Hi Thierry, Am Dienstag, den 11.05.2010, 16:50 +0200 schrieb Thierry LELEGARD: I finally gave up using this card. I replaced it with an old Hauppauge WinTV Nova-S in the same PCI slot and the same transponder is received fine. No discontinuity is observed. Using the Nova-HD-S2 in the same PCI slot, on the same transponder, gave a lot of discontinuities, correlated with the pci_abort errors. I think that the Hauppauge WinTV Nova-HD-S2 should be marked as partially supported only since it seems to work fine on some systems and poorly in other systems (mine). -Thierry I can confirm, that such usage conditions do exist also on other hardware. There is not any stable HD and S2 support even on m$. Hermann Without knowing if this is appropriate or not, as a test, I replaced the 3 occurrences of IRQF_SHARED | IRQF_DISABLED by simply IRQF_SHARED in cx88 driver. The number of pci_abort was considerably reduced but I still get some. Again, this was just a try, not a patch proposal. And it seems not to be a final solution, but it just changed the behavior a little bit. Any other idea ? -Thierry -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD Envoyé : vendredi 7 mai 2010 11:38 À : Paul Shepherd; linux-media@vger.kernel.org Objet : RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) Hi, The firmware version can be seen using dmesg the first time the tuner is actually used after power up. From dmesg: cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... cx88-mpeg driver manager :05:05.2: firmware: requesting dvb-fe-cx24116.fw cx24116_firmware_ondemand: Waiting for firmware upload(2)... cx24116_load_firmware: FW version 1.26.90.0 cx24116_firmware_ondemand: Firmware upload complete By removing or swapping cards on the PCI bus, I can see that the number of cx88[0]: irq mpeg [0x8] pci_abort varies. From once every 10 seconds, at best, to once per second, at worst. The following message can be interesting: IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs After some googling, I saw messages mentioning that this kind of message can be the symptom of unexpected behaviors. Could this explain the pci_abort ? Also, some messages suggest that a driver code should not request both IRQF_DISABLED and IRQF_SHARED. In the complete v4l-dvb source code, this combination is found only 20 times, in 12 drivers, including the cx88. Could this be a problem in the driver ? -Thierry -Message d'origine- De : Paul Shepherd [mailto:p...@whitelands.org.uk] Envoyé : jeudi 6 mai 2010 20:59 À : linux-media@vger.kernel.org Cc : Thierry LELEGARD Objet : Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) On 06/05/2010 16:01, Thierry LELEGARD wrote: I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry I have the board working in a Ubuntu 9.10 system, log below shows no pci errors: Apr 21 18:32:11 antec300 kernel: [ 16.576416] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.576711] cx88[0]: subsystem: 0070:6906, board:
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hi, Am Mittwoch, den 28.04.2010, 17:13 +0400 schrieb Manu Abraham: On Wed, Apr 28, 2010 at 12:33 PM, Guy Martin gms...@tuxicoman.be wrote: On Wed, 28 Apr 2010 09:45:39 +0200 André Weidemann andre.weidem...@web.de wrote: I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. I'm currently running two of these cards in the same box with this patch. Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because sometimes diseqc wasn't working fine and that seemed to solve the problem. I would advise to not do this: since disabling current limiting etc will cause a large problem in the case of a short circuit thereby no protection to the hardware. In such an event, it could probably damage the tracks carrying power on the card as well as the tracks on the motherboard, and in some cases the gold finches themselves and or the PCI connector. Generally, there are only a few devices capable of sourcing 0.5A, So I wonder Regards, Manu for the few devices I do have, you seem to be for sure right. All the Creatix stuff drawing up to 900mA on a potentially dual isl6405 has direct voltage from the PSU over an extra floppy connector. Max. 500mA should be sufficient with a DiSEqC 1.2 compliant rotor. Nothing else should come above that limit. I wonder, if someone close in reading specs just now, can tell if 900mA can be sufficient for two rotors ;) Andre, BTW, assuming you still have a CTX944 (md8800 Quad), can you measure if the 16be:0008 device really does switch between 13 and 18V. Mine does not, but is also not in the original PC and the 0007 and 0008 devices are swapped on the PCI bus compared to that one. Seen from my limited skills, it should not make any difference. So I don't know why some did report all is fine on 0008 and I can only say it hangs on 18V after init from the i2c capable 0007 device and on exit it powers down properly, that's all, but _never_ is on 13V. Be aware, that RF loopthrough between the two DVB-S tuners is enabled ... Thanks, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hi André, Am Freitag, den 30.04.2010, 07:44 +0200 schrieb André Weidemann: Hi Hermann, [snip] Andre, BTW, assuming you still have a CTX944 (md8800 Quad), can you measure if the 16be:0008 device really does switch between 13 and 18V. You seem to mistake me for someone else. I do not have a CTX944 and never had. Regards André yes, sorry, over the years with tda10086 questions and those about BBC HD reception I confused Weidemann with Weymann (Helmut), who had such a device in 2005. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Am Montag, den 26.04.2010, 21:51 +1000 schrieb 0123pe...@gmail.com: [snip] If it is a additional new regression, then mercurial bisect can find the patch in question fairly quick. That sounds like something that I should be able to do, if only I'd read the instructions. It is totally up to you and all others with that hardware. Can you provide a like for where to start reading? README.patches. Part III - Best Practices 1. Community best practices 2. Mercurial specific procedures 3. Knowing about newer patches committed at the development repositories 4. Patch submission from the community 5. Identifying regressions with Mercurial I have not found the file README.patches. Peter, for that one. yum, or whatever, install mercurial. hg clone http://linuxtv.org/hg/v4l-dvb; cd v4l-dvb less README.patches Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue loading SAA7134 module
Am Mittwoch, den 21.04.2010, 13:22 -0300 schrieb Donald Bailey: I've got a couple of boxes that have two no-name 8-chip SAA713X cards. Both have the same issue: the kernel will only set up the first eight on one board and only two on the second. It leaves the other six unusable with error -23. I am unable to figure out what that means. Sample dmesg as follows. More (/proc/ioports, /proc/interrupts, etc) can be posted if requested. Tried kernels 2.6.18 and 2.6.33.2 on CentOS 5.4 and Fedora 11 fully updated. The module is loaded as card=0. The following is output for chips 11 through 16. saa7130[10]: subsystem: 1131:, board: UNKNOWN/GENERIC [card=0,autodetected] saa7130[10]: board init: gpio is 1 saa7130[10]: Huh, no eeprom present (err=-5)? saa7130[10]: can't register video device saa7134: probe of :05:0f.0 failed with error -23 Due to some unknown bug we have ;), it likely works only perfectly with unidentified devices with more than 128 saa713x chips in a single PCI slot. Read on the wiki, about how to add a new device, and feel free to improve it. China is going totally mad. (or is it from somewhere else?) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi Peter, Am Donnerstag, den 15.04.2010, 23:30 +1000 schrieb 0123pe...@gmail.com: on Thu, 15 Apr 2010 01:32 pm in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure hermann pitton wrote: Hi, to be honest, there is a little too much delay on those reports. I have been very slow, sorry. no problem, but it becomes also a little hard to me to recap the issues. As said, Hartmut had the best pointers I guess. did not even notice a problem with Trent's prior patch. The same is also at vivi. Should I have a file called /etc/modprobe.d/TVanywhereAD that contains the line, options saa7134 card=94 gpio_tracking i2c_debug=1 and then watch the command line output of kaffeine? I've found a GUI that allows tweaking lots of module parameters that I have never heard of. Card=94 in the config file, gpio_tracking and i2c_debug are set to 1 in the GUI. Strange things are appearing in dmesg and syslog. I assume that [snip] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-0: Invalid 7-bit address 0x7a saa7133[0]: i2c xfer: 8e ERROR: NO_DEVICE [snip] is significant. No, not at all for my knowledge. Unsurprisingly, that just highlights my ignorance. If you want to produce debug output for failing firmware loading from file after a cold boot, yes, you might eventually be able to see that failing tuner initialization brings down i2c. If it is a additional new regression, then mercurial bisect can find the patch in question fairly quick. That sounds like something that I should be able to do, if only I'd read the instructions. It is totally up to you and all others with that hardware. Can you provide a like for where to start reading? README.patches. Part III - Best Practices 1. Community best practices 2. Mercurial specific procedures 3. Knowing about newer patches committed at the development repositories 4. Patch submission from the community 5. Identifying regressions with Mercurial Since already in some multiple broken conditions, never working without flaws previously, I would suggest not to wait any longer, until some sort of hadron collider is available ... Now I'm discouraged. It might be a better use of my time to do something else - anything else. Maybe I'll just put it in a box for a year and see what happens. I (un)fortunately ;) don't have such hardware and Hartmut did not have any at that time either. Don't just wait, also no need to hurry on next day. If the problem is described well, someone can take it as a challenge to work on it. We indeed had people from CERN fixing tuners. Trying to recap. You have been interested to add the card to auto detection, but firmware load was only successful in one of three cases only already that time and we have not been aware of that flaw in the beginning. Hartmut assumed later, on such a card is some locking protection needed during the firmware load, and my guess is the longish tuner initialization sequence gets corrupted, because of that missing locking, and all goes doom. (at least well known on all of such before any support for the tda8275a) Now, improved, only one of ten tries loads the firmware and keeps the card in a responding state. That is of course also very unpleasant for using mercurial bisect, I really do admit. Also, as reported too now, with two of such kind of cards in one machine, likely better don't try at all. OTOH, the m$ driver obviously does manage to load the firmware even for multiple such cards. (but maybe breaks all others ...) Which doesn't help us, since rebooting after that only hides our problem. Those cards following the Philips/NXP/Trident reference designs do not have it, but I don't test per day anymore. (we have problems with different cards with the same PCI subsystem IDs and different LNAs too, introduced by OEMs) So, on some first thought, which is only as random as the card's behavior, debug logs from the time it was added might be useful. (i2c works/works not) That it is now even worse, is still a chance to find out something more and not only a improved regression on something never working properly. If the hardware is not going out of specs by will, excluding others, OEM engineers, having more details, can still help to improve it for us too. Anyway, we should have start with some #ifdef 0 on it. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi, to be honest, there is a little too much delay on those reports. did not even notice a problem with Trent's prior patch. The same is also at vivi. Should I have a file called /etc/modprobe.d/TVanywhereAD that contains the line, options saa7134 card=94 gpio_tracking i2c_debug=1 and then watch the command line output of kaffeine? I've found a GUI that allows tweaking lots of module parameters that I have never heard of. Card=94 in the config file, gpio_tracking and i2c_debug are set to 1 in the GUI. Strange things are appearing in dmesg and syslog. I assume that [snip] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-0: Invalid 7-bit address 0x7a saa7133[0]: i2c xfer: 8e ERROR: NO_DEVICE [snip] is significant. No, not at all for my knowledge. If you want to produce debug output for failing firmware loading from file after a cold boot, yes, you might eventually be able to see that failing tuner initialization brings down i2c. If it is a additional new regression, then mercurial bisect can find the patch in question fairly quick. That sounds like something that I should be able to do, if only I'd read the instructions. It is totally up to you and all others with that hardware. Since already in some multiple broken conditions, never working without flaws previously, I would suggest not to wait any longer, until some sort of hadron collider is available ... First try in all known ways. We likely don't have the budget for anything else that soon ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DVB-T initial scan file for Israel (dvb-utils)
Hi Shaul, Am Samstag, den 10.04.2010, 02:16 +0300 schrieb Shaul Kremer: Hi, Here is an initial scan file for IBA's DVB-T transmitters. Generated from info at http://www.iba.org.il/reception/ (Hebrew) # HG changeset patch # User Shaul Kremer shau...@gmail.com # Date 1270854557 -10800 # Node ID ac84f6db6f031db82509c247ac1775ca48b0e2f3 # Parent 7de0663facd92bbb9049aeeda3dcba9601228f30 Added DVB-T initial tuning tables for Israel. diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN1 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN1 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-1 transmitter (northern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN2 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN2 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-2 transmitter (central Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN3 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN3 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-3 transmitter (southern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE why you don't put them into one scan file for now? scan for sure does not know about any difference between northern and southern Israel from the above and to scan the central transponder too in one run might cost in worst case a few seconds. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi! Am Freitag, den 09.04.2010, 20:32 -0300 schrieb Mauro Carvalho Chehab: Andy Walls wrote: On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. Really? Have you actually seen any hardware where a particular scan code can be used to wake up the hardware? The only hardware I have seen has the ability to unsuspend on arrival of IR traffic, but you didn't have the granularity to dictate that it only wake up on particular scancodes. The CX23888 and CX23102 can do it. Basically any IR pulse pattern your heart desires; within reason. And any carrier freq you want too; within reason. But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere near properly supporing suspend/resume for their main video and DMA functions, AFAIK. AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV, do a suspend and waking the hardware again, and you'll keep seeing the same channel (I tested it some time ago, when the proper suspend code were added, on analog mode, with alsa enabled). Other drivers can suspend/resume, but they won't properly restore the video registers, so, you'll see artifacts when it returns. Yes, that was Maxim with enough testers around and Matthias Schwarzott had fixes. To remind, we don't recover from suspend on DVB, needs to reload the driver once. We are also not MFE ready with mixed init calls through v4l and dvb. But yes, analog is on leading edge on that ;) Cheers, Hermann So, yes, you're right: before any suspend/resume code on those drivers, we first need to add some code to properly handle kernel threads and work queues during suspend, and to restore all the registers to a sane state at resume, before implementing IR wakeup on them. In the case of mceusb, as there is already an userspace code for it on lirc, it would probably not be that hard to make this feature to work with ir-core. [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software decoder, the IR IRQ might be used to wake, but this means that everything, even a glitch, would wake the hardware, so this won't work neither. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
Hi, Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch: Am 06.04.2010 16:33, schrieb Mike Isely: [snip] Mike, do you know of anyone actively using that additional information? Yes. The VDR project at one time implemented a plugin to directly interface to the pvrusb2 driver in this manner. I do not know if it is still being used since I don't maintain that plugin. Just FYI: The PVR USB2 device is now handled by the pvrinput-plugin, which uses only ioctls. The old pvrusb2-plugin is obsolete. http://projects.vdr-developer.org/projects/show/plg-pvrinput Regards, Lars. [snip] thanks Lars. Mike is really caring and went out for even any most obscure tuner bit to help to improve such stuff in the past, when we have been without any data sheets. To open second, maybe third and even forth ways for apps to use a device, likely going out of sync soon, does only load maintenance work without real gain. We should stay sharp to discover something others don't want to let us know about. All other ideas about markets are illusions. Or? So, debugfs sounds much better than sysfs for my taste. Any app and any driver, going out of sync on the latter, will remind us that backward compat _must always be guaranteed_ ... Or did change anything on that and is sysfs excluded from that rule? Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: [RFC] Serialization flag example
- Original Nachricht Von: Andy Walls awa...@md.metrocast.net An: Mauro Carvalho Chehab mche...@redhat.com Datum: 03.04.2010 02:47 Betreff: Re: [RFC] Serialization flag example On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote: Devin Heitmueller wrote: In the case of a V4L x DVB type of lock, this is not to protect some memory, but, instead, to limit the usage of a hardware that is not capable of simultaneously provide V4L and DVB streams. This is a common case on almost all devices, but, as Hermann pointed, there are a few devices that are capable of doing both analog and digital streams at the same time, but saa7134 driver currently doesn't support. Mauro, to do digital and analog at once is not restricted to a few devices. The only restriction, except those hybrid tuners do have, is that in dual mode only packed video formats are allowed for analog, since planar formats are using DMA channel five, which is already in use by the TS interface then. I know a driver that does: Me too ;) and Trent tested on cx88xx, IIRC. cx18 can handle simultaneous streaming of DTV and analog. Yup. Not to talk about recent PCIe devices. During I'm writing this I watch DVB-S, DVB-T and Composite at once on a single saa7231e on vista. Supports also S2 and HDTV, vbi and radio and can have a dual remote interface. http://www.creatix.de/produkte/multimedia/ctx1924.htm Some cards have both an analog and digital tuner, so both DTV and analog can come from an RF source simultaneously. (No locking needed really.) We have quite some such cards with two tuners on the saa7134 since 2005. Also such with three and even four tuners, two of them hybrid. Even the simplest variant, say with a single DVB-S only tuner, can still have external analog baseband at once from TV, STB, VCR or whatever. Some cards only have one tuner, which means simultaneous streaming is limited to DTV from RF and analog from baseband inputs. Streaming analog from an RF source on these cards precludes streaming of DTV. (An odd locking ruleset when you consider MPEG, YUV, PCM, and VBI from the bridge chip can independently be streamed from the selected analog source to 4 different device nodes.) On that mentioned Medion Quad md8080/CTX944 it becomes even more interesting. Each of the two PCI bridges can only handle one digital and one analog stream at once. That one must know. And if RF loopthrough is enabled or not is another important point for its usage configuration. For the two hybrid tuners it is a manual switch the driver doesn't know about. For the two DVB-S tuners it could be switchable in software and one of the LNB connectors could even be used as RF out to another device. (Has usage restrictions) The user can make a lot of decisions how to use such a card and for sure doesn't want to have any limitations only because of the hybrid tuners. Cheers, Hermann Regards, Andy Frohe Ostern! Alles für's Fest der Hasen und Lämmer jetzt im Osterspecial auf Arcor.de: http://www.arcor.de/rd/footer.ostern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: V4L-DVB drivers and BKL
Hi! - Original Nachricht Von: Mauro Carvalho Chehab mche...@redhat.com An: Devin Heitmueller dheitmuel...@kernellabs.com Datum: 02.04.2010 01:10 Betreff: Re: V4L-DVB drivers and BKL Devin Heitmueller wrote: On Thu, Apr 1, 2010 at 5:07 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Most i2c locks typically are only held for the duration of a single i2c transaction. What you are proposing would likely result in just about every function having to explicitly lock/unlock, which just seems bound to be error prone. The i2c open/close should be part of the transaction. Of course, there's no need to send a command to open an already opened gate (yet, from some sniff dumps, it seems that some drivers for other OS's do it for every single i2c access). I'm not even talking about i2c gate control, which is a whole separate case where it is applied inconsistently across drivers. Even under Linux, we have lots of cases where there are double opens and double closes of the i2c gate, depending on whether the developer is controlling the gate from the tuner driver or the demodulator. What I'm getting at though is that the lock granularity today is typically at the i2c transaction level, so something like an demod driver attempting to set two disparate registers is likely to be two i2c transactions. Without moving the locking into the caller, the other half of the driver can take control between those two transactions. And moving the logic into the caller means we will have to litter the code all over the place with lock/unlock calls. I agree with a caller logic. Yet, even moving to the caller, an i2c lock is still needed. For example, i2c IR events are polling at interrupt time, so, they can happen anytime, including in the middle of one i2c transaction (by transaction, I mean gate control+i2c read/write ops go get/set a single register). We've got enough power management problems as it is without adding lots additional complexity with little benefit and only increasing the likelihood of buggy code. For sure a lock at the open() is simple, but I suspect that this may cause some troubles with applications that may just open everything on startup (even letting the device unused). Just as one example of such apps, kmix, pulseaudio and other alsa mixers love to keep the mixer node opened, even if nobody is using it. I'm frankly far less worried about the ALSA devices than I am about DVB versus V4L Vdeo/VBI, based on all the feedback I see from real users. Ok, but alsa driver may also try to access things like i2c. For example, msp34xx audio controls are reached via I2C. The cases where we are getting continuously burned are MythTV users who don't have their input groups properly defined and as a result MythTV attempts to use both digital and analog at the same time (input groups themselves are really a hack to deal with the fact that the Linux kernel doesn't have any way to inform userland of the relationships). We see the same on other OSs as well. In fact, to use digital and analog at once is totally valid. It is much too short to think about a device with a single hybrid tuner, best known meanwhile for causing troubles. The Medion Quad (md8080) on the saa713x with two hybrid tuners, two DVB-S tuners, four digital and two analog demodulators with two dedicated PCI bridges, with its restrictions too, is already ancient stuff. And the more I think about it, we can probably even implement the locking itself in the V4L and DVB core (further reducing the risk of some bridge maintainer screwing it up). All the bridge driver would have to do is declare the relationship between the DVB and V4L devices (both video and vbi), and the enforcement of the locking could be abstracted out. On older dual tuner, triple and quad stuff it needs granularity through each driver down to the physically existing device. No app on any OS seems to have it right. In best case they have some framework around to ask the user about his knowledge for what is a go and what a no go. Newer hardware can really do triple stuff at once for example. Nothing much left to configure wrong from the user and the app. But, to start simple, if a single bridge can pass DVB-T and DVB-S at once is as important to know these days as all details about tuners, demodulators and SECs on a given device. That mixture of old and new will continue over years anyway and to escape with some easy rules doesn't look simple. Some either digital or analog does not exist, except for a single hybrid tuner. Even then, on such a simplest hybrid device, the tuner can be in digital mode and without any problems you can have analog video from external inputs at once. I agree on having some sort of resource locking in core, but this type of lock between radio/audio/analog/analog mpeg-encoded/digital/vbi/... is
Re: [PATCH] Fix default state Beholder H6 tuner.
Hi Dimitry,
Am Mittwoch, den 31.03.2010, 13:14 +1000 schrieb Dmitri Belimov:
Hi Hermann
Hi,
Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov:
Hi
The hybrid tuner FMD1216MEX_MK3 after cold start has disabled IF.
This tuner has internal I2C switch. This switch switch I2C bus
between DVB-T and IF part. Default state is DVB-T. When module
saa7134 is load it can't find IF tda9887 and disable analog TV mode.
This patch set internal I2C switch of the tuner to IF by send
special value to the tuner as for receive analog TV from low band.
It can be usefule for other cards.
I didn't set configure a tuner by a tuner model because this tuner
can has different I2C address. May be we can do it later after
discuss for more robust support a tuners.
just as a reminder. It is the same for the FMD1216ME hybrid MK3.
After every boot, analog mode fails with missing tda9887.
Currently, after tuner modules are not independent anymore, one has to
reload the saa7134 driver once.
Relevant code in tuner.core.c.
case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
buffer[3] = 0x60;
i2c_master_send(c, buffer, 4);
mdelay(1);
buffer[2] = 0x86;
buffer[3] = 0x54;
i2c_master_send(c, buffer, 4);
if (!dvb_attach(simple_tuner_attach, t-fe,
t-i2c-adapter, t-i2c-addr,
t-type)) goto attach_failed;
break;
That is good. I'll try add case TUNER_PHILIPS_FMD1216MEX_MK3 here and test.
This is much better.
it wont work for any what I can tell.
We were forced into such an universal looking solution, but it was
broken only a short time later.
I for sure don't say that this time, late 2005, it was in anyway
perfect, too much random on module load orders and also duplicate
address stuff around meanwhile.
But, however, it seems to be blocked for a global attempt within the
current schemes too.
Cheers,
Hermann
With my best regards, Dmitry.
Hermann
diff -r 1ef0265456c8
linux/drivers/media/video/saa7134/saa7134-cards.c ---
a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Mar
26 00:54:18 2010 -0300 +++
b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Mar
28 08:21:10 2010 -0400 @@ -7450,6 +7450,21 @@ } break;
}
+ case SAA7134_BOARD_BEHOLD_H6:
+ {
+ u8 data[] = { 0x09, 0x9f, 0x86, 0x11};
+ struct i2c_msg msg = {.addr = 0x61, .flags =
0, .buf = data,
+ .len =
sizeof(data)}; +
+ /* The tuner TUNER_PHILIPS_FMD1216MEX_MK3 after
hardware*/
+ /* start has disabled IF and enabled DVB-T. When
saa7134*/
+ /* scan I2C devices it not detect IF tda9887 and
can`t */
+ /* watch TV without software reboot. For solve
this problem */
+ /* switch the tuner to analog TV mode
manually. */
+ if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
+ printk(KERN_WARNING
+ %s: Unable to enable IF of
the tuner.\n,
+dev-name);
+ break;
+ }
} /* switch() */
/* initialize tuner */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
d.beli...@gmail.com
With my best regards, Dmitry.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix default state Beholder H6 tuner.
Hi,
Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov:
Hi
The hybrid tuner FMD1216MEX_MK3 after cold start has disabled IF.
This tuner has internal I2C switch. This switch switch I2C bus between DVB-T
and IF part.
Default state is DVB-T. When module saa7134 is load it can't find IF tda9887
and disable
analog TV mode.
This patch set internal I2C switch of the tuner to IF by send special value
to the tuner as for receive
analog TV from low band. It can be usefule for other cards.
I didn't set configure a tuner by a tuner model because this tuner can has
different I2C address.
May be we can do it later after discuss for more robust support a tuners.
just as a reminder. It is the same for the FMD1216ME hybrid MK3.
After every boot, analog mode fails with missing tda9887.
Currently, after tuner modules are not independent anymore, one has to
reload the saa7134 driver once.
Relevant code in tuner.core.c.
case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
buffer[3] = 0x60;
i2c_master_send(c, buffer, 4);
mdelay(1);
buffer[2] = 0x86;
buffer[3] = 0x54;
i2c_master_send(c, buffer, 4);
if (!dvb_attach(simple_tuner_attach, t-fe,
t-i2c-adapter, t-i2c-addr, t-type))
goto attach_failed;
break;
Hermann
diff -r 1ef0265456c8 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Mar 26
00:54:18 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Mar 28
08:21:10 2010 -0400
@@ -7450,6 +7450,21 @@
}
break;
}
+ case SAA7134_BOARD_BEHOLD_H6:
+ {
+ u8 data[] = { 0x09, 0x9f, 0x86, 0x11};
+ struct i2c_msg msg = {.addr = 0x61, .flags = 0, .buf = data,
+ .len = sizeof(data)};
+
+ /* The tuner TUNER_PHILIPS_FMD1216MEX_MK3 after hardware*/
+ /* start has disabled IF and enabled DVB-T. When saa7134*/
+ /* scan I2C devices it not detect IF tda9887 and can`t */
+ /* watch TV without software reboot. For solve this problem */
+ /* switch the tuner to analog TV mode manually. */
+ if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
+ printk(KERN_WARNING
+ %s: Unable to enable IF of the tuner.\n,
+dev-name);
+ break;
+ }
} /* switch() */
/* initialize tuner */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers - part 1
Am Montag, den 29.03.2010, 08:40 +0200 schrieb Hans Verkuil:
Hi Xiaolin,
On Sunday 28 March 2010 16:42:30 Zhang, Xiaolin wrote:
From 1c18c41be33246e4b766d0e95e28a72dded87475 Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 21:31:24 +0800
Subject: [PATCH 2/10] This patch is second part of intel moorestown isp
driver and c files collection which is v4l2 implementation.
+struct videobuf_dma_contig_memory {
+ u32 magic;
+ void *vaddr;
+ dma_addr_t dma_handle;
+ unsigned long size;
+ int is_userptr;
+};
+
+#define MAGIC_DC_MEM 0x0733ac61
+#define MAGIC_CHECK(is, should)
\
+ if (unlikely((is) != (should))) {
\
+ pr_err(magic mismatch: %x expected %x\n, (is), (should));
\
+ BUG();
\
+ }
I will do a more in-depth review in a few days. However, I did notice that
you added your own dma_contig implementation. What were the reasons for doing
this? I've CC-ed Pawel since he will be interested in this as well.
Another question that came up is: what is 'marvin'? It's clearly a codename,
but a codename for what? This should be documented at the top of some source
or header. Apologies if it is already documented, I didn't read everything
yet.
A final point I noticed: don't cast away a function result:
(void)ci_isp_set_bp_detection(NULL);
No need for (void). The gcc compiler won't warn about this unless the function
is annotated with __must_check__.
Regards,
Hans
How to avoid this and similar?
you added your own dma_contig implementation
The answer is very simple.
NACK.
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi Peter, Am Montag, den 29.03.2010, 23:10 +1100 schrieb 0123pe...@gmail.com: Hi Hermann, I've been fixing my PC to the state that it stopped working. Hence the delay. Hi Peter, Am Samstag, den 20.03.2010, 16:20 +1100 schrieb 0123pe...@gmail.com: [snip] unfortunately the problem with these cards is known, but no good solution for now. Best description is from Hartmut and starts here. http://www.spinics.net/lists/linux-dvb/msg26683.html [snip] Interesting link. I have one of the cards mentioned (an MSI TV(at)nywhere A/D hybrid). I've decided not to throw it away. to not leave you without any response at least. In hind sight, seeing how unfortunate using such devices can be, mainly because of being forced to try at random again with a cold boot after some i2c war brought down the tuner, we better should have such only in a still experimental league and not as supported. This was not foreseeable in such rudeness and neither Hartmut nor me have such devices. The Asus triple OEM 3in1 I have does not have any problems with loading firmware from file, the others do all get it from eeprom. So, actually nobody is investigating on it with real hardware. Maybe you can catch something with gpio_tracking and i2c_debug=1. I would expect that the complex analog tuner initialization gets broken somehow. This is at least known to be good to bring all down. Cheers, Hermann There was a patch about alignment that went through recently. Revert V4L/DVB (11906): saa7134: Use v4l bounding/alignment function Maybe that was it. did not even notice a problem with Trent's prior patch. The same is also at vivi. Should I have a file called /etc/modprobe.d/TVanywhereAD that contains the line, options saa7134 card=94 gpio_tracking i2c_debug=1 and then watch the command line output of kaffeine? If you want to produce debug output for failing firmware loading from file after a cold boot, yes, you might eventually be able to see that failing tuner initialization brings down i2c. If it is a additional new regression, then mercurial bisect can find the patch in question fairly quick. Mauro has a MSI cardbus device using also the card=94 entry, but at home he has no DVB-T. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avermedia AVerTV GO 007 FM composite input problem
Hi, Am Freitag, den 26.03.2010, 13:10 +0200 schrieb Andras Barna: hi i have a Avermedia AVerTV GO 007 FM card , the problem is that i get nothing from Composite, i tried different apps (mplayer, tvtime, etc) none works. (television input works) ideas? looking it up from 2005 to now, Composite was never reported as tested, only S-Video. On the other hand, vmux=0 is what we regularly see on combined S-Video and Composite inputs where you need an adapter for Composite over S-Video. The card has no separate Composite-in connector. Assuming you did not plug by mistake into the radio antenna input, then you can also try with vmux 3, 2 and 4 for Composite in saa7134-cards.c. You might have a look at the manual and/or windows driver, since this information is not provided to us until now. (bttv-gallery/wiki/lists) Does it come with any simple 4pin adapter or even with a breakout cable with more pins and a dedicated yellow RCA input? Cheers, Hermann here're some infos [9.361212] saa7130/34: v4l2 driver version 0.2.15 loaded [9.361631] alloc irq_desc for 17 on node -1 [9.361635] alloc kstat_irqs on node -1 [9.361648] saa7134 :00:09.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [9.361768] saa7133[0]: found at :00:09.0, rev: 208, irq: 17, latency: 32, mmio: 0xcfffc800 [9.361955] saa7133[0]: subsystem: 1461:f31f, board: Avermedia AVerTV GO 007 FM [card=57,autodetected] [9.362198] saa7133[0]: board init: gpio is 8 [9.362424] input: saa7134 IR (Avermedia AVerTV GO as /devices/pci:00/:00:09.0/input/input6 [9.362713] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [9.501011] saa7133[0]: i2c eeprom 00: 61 14 1f f3 ff ff ff ff ff ff ff ff ff ff ff ff [9.501838] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.502592] saa7133[0]: i2c eeprom 20: ff d2 fe ff ff ff ff ff ff ff ff ff ff ff ff ff [9.503343] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.504095] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.504842] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.505593] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.506345] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.507097] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.507846] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.508600] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.509354] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.510107] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.510920] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.511672] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.512423] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.780106] tuner 0-004b: chip found @ 0x96 (saa7133[0]) [ 10.815008] tda829x 0-004b: setting tuner address to 61 [ 11.349012] tda829x 0-004b: type set to tda8290+75 [ 14.869150] saa7133[0]: registered device video0 [v4l2] [ 14.869305] saa7133[0]: registered device vbi0 [ 14.869447] saa7133[0]: registered device radio0 [ 14.968864] saa7134 ALSA driver for DMA sound loaded [ 14.970728] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 14.970892] saa7133[0]/alsa: saa7133[0] at 0xcfffc800 irq 17 registered as card -1 [snip] -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dmsg dump for Tevion High Speed DVD Maker
Hi, Am Freitag, den 26.03.2010, 23:26 -0400 schrieb OurMail: Hi, Was trying to get a firewire port working in Ubuntu 9.10 when I noticed that I had my USB Tevion DVD Maker plugged in and that you had a message requesting a copy of the dump for the unidentified DVD Maker. Attached is that dump as requested. Not sure where you are located but a German food store chain operating in the US under the name Aldi Food Stores has sold these a couple times that I know of. There are at least two versions although they function the same. A couple years ago they had them for $40 US. Last fall they had them for $20. At that price they should have been popular so should be other Linux users with them. Have seen a few users on the boards trying to get them going. They work well under Windows Vista but have never gotten one to work under Linux. Have been trying to get away from Windows for video work but have not been able to get either the this USB device or my Sony DSR-20 DV/DVCAM firewire deck to work under Linux. Am not all that good at Linux and any help you care to provide would be most welcome. Dave just a hint. If Aldi stuff is called Medion as well, you usually find the device at http://www.creatix.de. If it is called Tevion, it can be some AverMedia Kworld or whatever clone. Cheers, Hermann einfaches Textdokument-Anlage (dmesg-dump-ourmailATkconlineDOTcom) d...@systemax1:~$ dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.31-20-generic (bui...@palmer) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 (Ubuntu 2.6.31-20.58-generic) [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6a (usable) [0.00] BIOS-e820: bf6a - bf6ae000 (ACPI data) [0.00] BIOS-e820: bf6ae000 - bf6f (ACPI NVS) [0.00] BIOS-e820: bf6f - bf6fe000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] DMI present. [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] last_pfn = 0xbf6a0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CBFFF write-protect [0.00] CC000-D uncachable [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0BF70 mask 0 uncachable [0.00] 3 base 0BF80 mask FFF80 uncachable [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Scanning 0 areas for low memory corruption [0.00] modified physical RAM map: [0.00] modified: - 0001 (reserved) [0.00] modified: 0001 - 0009fc00 (usable) [0.00] modified: 0009fc00 - 000a (reserved) [0.00] modified: 000e - 0010 (reserved) [0.00] modified: 0010 - bf6a (usable) [0.00] modified: bf6a - bf6ae000 (ACPI data) [0.00] modified: bf6ae000 - bf6f (ACPI NVS) [0.00] modified: bf6f - bf6fe000 (reserved) [0.00] modified: fee0 - fee01000 (reserved) [0.00] modified: fff8 - 0001 (reserved) [0.00] initial memory mapped : 0 - 00c0 [0.00] init_memory_mapping: -377fe000 [0.00] Using x86 segment limits to approximate NX protection [0.00] 00 - 40 page 4k [0.00] 40 - 003740 page
Re: Which of my 3 video capture devices will work best with my PC?
Hi Serge, Am Donnerstag, den 25.03.2010, 00:06 +0100 schrieb hermann pitton: Am Mittwoch, den 24.03.2010, 16:45 -0600 schrieb Serge Pontejos: Greetings all... I'm interested in doing video transfer from VCR to PC and want to know which of the 3 capture devices I have has the best chance of working with my setup? I have 3 different symptoms happening with each. My PC setup: Ubuntu Karmic 9.10/2.6.31-20 generic Socket 754 AMD Sempron 3000+ with passive cooling (non AMD64) Biostar MB with Nforce3 250Gb chipset NV31 GPU (Geforce FX5600 Ultra 128MB) using Nvidia 196 driver 1GB PC3200 DDR RAM 34GB SCSI coupled to a Adaptec 19160 card Soundblaster Audigy dvd+-R floppy etc etc. The devices in question: USB: Dazzle Digital Photo Maker, using a USBvision driver recognized as a Global Village GV-7000) --This one recognizes and I can display video but if I try to record in either xawtv or Kdenlive the program crashes. PCI: Hauppauge WinTV model 38101 --When installed it shows /dev/video0 when I do an ls, but I don't get a signal with either composite or coax input. I tried following steps from this link http://howtoubuntu.org/?p=20 but it didn't change a thing... PCI: Aurora Systems Fuse previously used on a Mac --This card picks up the ZR36067 driver, but it's saying it can't initialize the i2c bus. Thus, no /dev/video* shows Let me know which I should focus on and then I'll show the query dumps. I guess you don't get any dog out of the hut with such offers. ;) please always provide us with the relevant dmesg output also for cards with trouble. Maybe we can fix them or at least others are informed about the issues too. The bttv WinTV model 38101 might be just a new revision and maybe the tuner is just missing in tveeprom? Old ones. bttv0: Bt878 (rev 17) at :05:04.0, irq: 18, latency: 66, mmio: 0xf840 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb bttv0: using: Hauppauge (bt878) [card=10,autodetected] bttv0: gpio: en=, out= in=00fb [init] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] tveeprom 0-0050: Hauppauge model 38101, rev B410, serial# 1993042 tveeprom 0-0050: tuner model is Philips FI1236 MK2 (idx 10, type 2) tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 0-0050: audio processor is None (idx 0) tveeprom 0-0050: has no radio bttv0: Hauppauge eeprom indicates model#38101 and bttv0: Bt878 (rev 17) at :05:04.0, irq: 18, latency: 66, mmio: 0xf840 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb bttv0: using: Hauppauge (bt878) [card=10,autodetected] bttv0: gpio: en=, out= in=00fb [init] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] tveeprom 0-0050: Hauppauge model 38101, rev B426, serial# 1890608 tveeprom 0-0050: tuner model is Temic 4036FY5 (idx 26, type 8) tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 0-0050: audio processor is None (idx 0) tveeprom 0-0050: has no radio bttv0: Hauppauge eeprom indicates model#38101 Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which of my 3 video capture devices will work best with my PC?
Am Donnerstag, den 25.03.2010, 16:06 -0600 schrieb Serge Pontejos: On Thu, Mar 25, 2010 at 1:18 PM, hermann pitton hermann-pit...@arcor.de wrote: Hi Serge, Am Donnerstag, den 25.03.2010, 00:06 +0100 schrieb hermann pitton: please always provide us with the relevant dmesg output also for cards with trouble. I figured I would try to determine if there was a specific card that might have a better chance of working first, then focus on that card's problem. But I'll just supply the dmesg with the BT878 installed here... [ 33.150658] Bt87x :02:0a.1: PCI INT A - Link[APC3] - GSI 18 (level, low) - IRQ 18 [ 33.150914] bt87x0: Using board 1, analog, digital (rate 32000 Hz) [ 33.294887] EMU10K1_Audigy :02:07.0: PCI INT A - Link[APC4] - GSI 19 (level, low) - IRQ 19 [ 33.429554] bttv: driver version 0.9.18 loaded [ 33.429559] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 33.429609] bttv: Bt8xx card found (0). [ 33.429629] bttv :02:0a.0: PCI INT A - Link[APC3] - GSI 18 (level, low) - IRQ 18 [ 33.429639] bttv0: Bt878 (rev 17) at :02:0a.0, irq: 18, latency: 32, mmio: 0xe400 [ 33.429672] bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [ 33.429675] bttv0: using: Hauppauge (bt878) [card=10,insmod option] [ 33.429678] IRQ 18/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs [ 33.429709] bttv0: gpio: en=, out= in=00fb [init] [ 33.432194] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] [ 33.432232] bt878 #0 [sw]: Test OK [ 33.475356] tveeprom 3-0050: Hauppauge model 38101, rev B410, serial# 1974546 [ 33.475361] tveeprom 3-0050: tuner model is Philips FI1236 MK2 (idx 10, type 2) [ 33.475365] tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08) [ 33.475368] tveeprom 3-0050: audio processor is None (idx 0) [ 33.475371] tveeprom 3-0050: has no radio [ 33.475373] bttv0: Hauppauge eeprom indicates model#38101 [ 33.475376] bttv0: tuner type=2 [ 33.640466] bttv0: audio absent, no audio device found! [ 33.671316] tuner 3-0061: chip found @ 0xc2 (bt878 #0 [sw]) [ 33.816641] tuner-simple 3-0061: creating new instance [ 33.816648] tuner-simple 3-0061: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles)) [ 33.817329] bttv0: registered device video1 [ 33.817357] bttv0: registered device vbi1 [ 33.817374] bttv0: PLL: 28636363 = 35468950 .. ok ...which has similar output to your first dmesg example Serial# appears to be a little earlier than your example. Maybe we can fix them or at least others are informed about the issues too. The bttv WinTV model 38101 might be just a new revision and maybe the tuner is just missing in tveeprom? Old ones. bttv0: Bt878 (rev 17) at :05:04.0, irq: 18, latency: 66, mmio: 0xf840 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb bttv0: using: Hauppauge (bt878) [card=10,autodetected] bttv0: gpio: en=, out= in=00fb [init] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] tveeprom 0-0050: Hauppauge model 38101, rev B410, serial# 1993042 tveeprom 0-0050: tuner model is Philips FI1236 MK2 (idx 10, type 2) tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 0-0050: audio processor is None (idx 0) tveeprom 0-0050: has no radio bttv0: Hauppauge eeprom indicates model#38101 Cheers, Hermann This is the xawtv output: se...@bracken:~$ xawtv -noxv -device /dev/video0 This is xawtv-3.95.dfsg.1, running on Linux/i686 (2.6.31-20-generic) xinerama 0: 1680x1050+0+0 WARNING: No DGA direct video mode for this display. WARNING: couldn't find framebuffer base address, try manual configuration (v4l-conf -a addr) v4l2: WARNING: framebuffer base address mismatch v4l2: me=(nil) v4l=(nil) Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string -*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*, -efont-biwidth-bold-r-normal--16-*-*-*-*-*-*-*, -*-*-bold-r-normal-*-16-*-*-*-m-*-*-*, -*-*-bold-r-normal-*-16-*-*-*-c-*-*-*, -*-*-*-*-*-*-16-*-*-*-*-*-*-*,* to type FontSet Warning: Cannot convert string -*-ledfixed-medium-r-*--39-*-*-*-c-*-*-* to type FontStruct Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string -*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*, -efont-biwidth-bold
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi Peter, Am Samstag, den 20.03.2010, 16:20 +1100 schrieb 0123pe...@gmail.com: on Wed, 17 Mar 2010 09:12 am in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure hermann pitton wrote: [snip] unfortunately the problem with these cards is known, but no good solution for now. Best description is from Hartmut and starts here. http://www.spinics.net/lists/linux-dvb/msg26683.html [snip] Interesting link. I have one of the cards mentioned (an MSI TV(at)nywhere A/D hybrid). I've decided not to throw it away. to not leave you without any response at least. In hind sight, seeing how unfortunate using such devices can be, mainly because of being forced to try at random again with a cold boot after some i2c war brought down the tuner, we better should have such only in a still experimental league and not as supported. This was not foreseeable in such rudeness and neither Hartmut nor me have such devices. The Asus triple OEM 3in1 I have does not have any problems with loading firmware from file, the others do all get it from eeprom. So, actually nobody is investigating on it with real hardware. Maybe you can catch something with gpio_tracking and i2c_debug=1. I would expect that the complex analog tuner initialization gets broken somehow. This is at least known to be good to bring all down. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FM1216ME MK5 radio
Hi Dmitry, please have a look at tveeprom concerning your FM1216ME/I MK5. It still maps to the MK3 and should break for radio. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add AverTV Studio 509UA
Hi,
Am Samstag, den 20.03.2010, 16:08 +0200 schrieb Евгений Бацман:
2010/3/20 hermann pitton hermann-pit...@arcor.de:
Hi, Евгений,
is there any reason, why you set the charge pump bit to low and slow
tuning on a non FM tuner?
Cheers,
Hermann
Am Freitag, den 19.03.2010, 20:32 +0200 schrieb Евгений Бацман:
A add tv tuner AverTV Studio 509UA but radio now not
work(tuner_tea5764hn not in kernel)
diff -r a/linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/common/tuners/tuner-types.c 2010-03-19
14:25:24.0 +0200
@@ -1353,6 +1353,30 @@
.count = ARRAY_SIZE(tuner_sony_btf_pxn01z_ranges),
},
};
+/* TUNER_PHILIPS_FQ1216ME_MK5 - Philips PAL */
+
+static struct tuner_range tuner_fq1216me_mk5_pal_ranges[] = {
+ { 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
+ { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 999.99, 0x8e, 0x04, },
+};
+
+static struct tuner_params tuner_fq1216me_mk5_params[] = {
+ {
+ .type = TUNER_PARAM_TYPE_PAL,
+ .ranges = tuner_fq1216me_mk5_pal_ranges,
+ .count = ARRAY_SIZE(tuner_fq1216me_mk5_pal_ranges),
+ .cb_first_if_lower_freq = 1,
+ .has_tda9887 = 1,
+ .port1_active = 1,
+ .port2_active = 1,
+ .port2_invert_for_secam_lc = 1,
+ .default_top_mid = -2,
+ .default_top_secam_low = -2,
+ .default_top_secam_mid = -2,
+ .default_top_secam_high = -2,
+ },
+};
/* -
*/
@@ -1827,6 +1851,11 @@
.params = tuner_sony_btf_pxn01z_params,
.count = ARRAY_SIZE(tuner_sony_btf_pxn01z_params),
},
+ [TUNER_PHILIPS_FQ1216ME_MK5] = { /* Philips PAL */
+ .name = Philips PAL/SECAM multi (FQ1216ME MK5),
+ .params = tuner_fq1216me_mk5_params,
+ .count = ARRAY_SIZE(tuner_fq1216me_mk5_params),
+ },
};
EXPORT_SYMBOL(tuners);
diff -r a/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-03-19
16:34:17.0 +0200
@@ -5411,7 +5411,44 @@
.gpio = 0x389c00,
} },
},
-
+ [SAA7134_BOARD_AVERMEDIA_STUDIO_509UA] = {
+ /* Evgen Batsman evgenbats...@gmail.com */
+ .name = Avermedia AVerTV Studio 509UA,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_FQ1216ME_MK5,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+ .gpiomask = 0x03,
+ .inputs = { {
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ .gpio = 0x00,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ .gpio = 0x00,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ .gpio = 0x00,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x01,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = LINE1,
+ .gpio = 0x00,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6567,6 +6604,12 @@
.subvendor= 0x107d,
.subdevice= 0x6655,
.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
+ },{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0xa14b,
+ .driver_data = SAA7134_BOARD_AVERMEDIA_STUDIO_509UA,
}, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
diff -r a/linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134.h 2010-03-19
13:13
Re: Add AverTV Studio 509UA
I think best would be to create two patches. 1/2 adds the new tuner. (tuner-types.c/tuner.h/tveeprom.c) 2/2 adds the new Avermedia card. Else it looks fine. To add some for the record here for those eventually later on it. We have seen over so many years now, that hundreds of new can tuners did appear and, IIRC, we got them all with any combination of previous chips. The filters, mainly the SAW filters did make a difference to the original products they follow all in what ever combination concerning quality. However, a main annoyance was, that lots of such clones did appear and some did start to use extra radio tuners on cheap silicon on separate addresses, hard to track, since hidden under some welded shielding. This was with all such clones all over Asia and the extra silicon radio tuner was always Philips/NXP in the beginning. What is new now, I think, and first seen, is that the last can tuner flagship MK5 series has a FQ non radio variant on a AverMedia using some extra silicon from Philips/NXP/Trident _themselves_ to make some extra profit against a FM MK5 they have. I would call this a management disaster, but my education might be outdated. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: add capture boards Hawell HW-404M7 and HW-808M7
Hi Vladimir,
Am Samstag, den 20.03.2010, 17:58 +0300 schrieb Vladimir Ermakov:
Hi Hermann.
1. It's my mistake. Fixed.
2. Dead code. Removed.
thanks for looking at it.
We likely need your SOB line again, since it is a new patch.
Here is my
Reviewed-by: hermann pitton hermann-pit...@arcor.de
Cheers,
Hermann
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1269096094 -10800
# Node ID a91db2cf4f5774866c8c5bf906d9ac4faff9173d
# Parent 929298149eba4b6d0696124b9880113c25cd0788
saa7134: fix GPIO HW-404M7
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 18
23:47:27 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Mar 20
17:41:34 2010 +0300
@@ -5403,12 +5403,12 @@
.radio_type= UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .gpiomask = 0x01fc00,
+ .gpiomask = 0x389c00,
.inputs = {{
.name = name_comp1,
.vmux = 3,
.amux = LINE1,
- .gpio = 0x389c00,
+ .gpio = 0x01fc00,
} },
},
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Thu Mar 18
23:47:27 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sat Mar 20
17:41:34 2010 +0300
@@ -531,7 +531,6 @@
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
- case SAA7134_BOARD_HAWELL_HW_404M7:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
В Птн, 19/03/2010 в 00:21 +0100, hermann pitton пишет:
Hi Vladimir,
thanks, your patch is already accepted, but if have a two comments.
Am Mittwoch, den 10.03.2010, 18:44 +0300 schrieb Vladimir Ermakov:
This patch adds new capture boards Hawell HW-404M7 and HW-808M7.
Those cards have 4 or 8 SAA7130 chips and for the work it only needs
initialize registers.
The value of those registers were dumped under Windows using flytest.
But board haven't EEPROM.
For the first chip:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389C00
Value: 0x00016C00
Later in the code you swapped mode (gpio mask) and value (out status).
This does not cause a functional problem in this case, but is visible
for example with saa7134 gpio_tracking=1.
Second, you did add the card to the flyvideo remotes in saa7134-input,
but this is only a line of dead code currently.
If it really has such a remote, you must also add the card to the switch
case dev-has_remote = SAA7134_REMOTE_GPIO in in the function
int saa7134_board_init1 in saa7134-cards.c or please remove it from
saa7134-input.c.
Thanks,
Hermann
Video input: 3
Audio input: Analog Line1
For other chips:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389200
Value: 0x0001
Video input: 3
Audio input: Analog Line1
Signed-off-by: Vladimir Ermakov vooon...@gmail.com
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1268232221 -10800
# Node ID 072cd67c6aabe0e700a9e4727b50ad6424cb59f5
# Parent 7a58d924fb049ff1d318514939b3a7e416670c13
saa7134: add Hawell HW-404M7 HW-808M7
diff -r 7a58d924fb04 -r 072cd67c6aab
linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 Tue Mar 09
23:00:59 2010 -0300
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Wed Mar 10
17:43:41 2010 +0300
@@ -175,3 +175,4 @@
174 - Asus Europa Hybrid OEM [1043:4847]
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
+177 - Hawell HW-404M7 / HW-808M7
diff -r 7a58d924fb04 -r 072cd67c6aab
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.cTue Mar 09
23:00:59 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.cWed Mar 10
17:43:41 2010 +0300
@@ -5394,6 +5394,23 @@
.amux = LINE2,
},
},
+ [SAA7134_BOARD_HAWELL_HW_404M7] = {
+ /* Hawell HW-404M7 Hawell HW-808M7 */
+ /* Bogoslovskiy Viktor bogo...@bk.ru */
+ .name = Hawell HW-404M7,
+ .audio_clock = 0x0020,
+ .tuner_type= UNSET,
+ .radio_type= UNSET,
+ .tuner_addr = ADDR_UNSET
Re: Add AverTV Studio 509UA
Hi, Евгений,
is there any reason, why you set the charge pump bit to low and slow
tuning on a non FM tuner?
Cheers,
Hermann
Am Freitag, den 19.03.2010, 20:32 +0200 schrieb Евгений Бацман:
A add tv tuner AverTV Studio 509UA but radio now not
work(tuner_tea5764hn not in kernel)
diff -r a/linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/common/tuners/tuner-types.c 2010-03-19
14:25:24.0 +0200
@@ -1353,6 +1353,30 @@
.count = ARRAY_SIZE(tuner_sony_btf_pxn01z_ranges),
},
};
+/* TUNER_PHILIPS_FQ1216ME_MK5 - Philips PAL */
+
+static struct tuner_range tuner_fq1216me_mk5_pal_ranges[] = {
+ { 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
+ { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 999.99, 0x8e, 0x04, },
+};
+
+static struct tuner_params tuner_fq1216me_mk5_params[] = {
+ {
+ .type = TUNER_PARAM_TYPE_PAL,
+ .ranges = tuner_fq1216me_mk5_pal_ranges,
+ .count = ARRAY_SIZE(tuner_fq1216me_mk5_pal_ranges),
+ .cb_first_if_lower_freq = 1,
+ .has_tda9887 = 1,
+ .port1_active = 1,
+ .port2_active = 1,
+ .port2_invert_for_secam_lc = 1,
+ .default_top_mid = -2,
+ .default_top_secam_low = -2,
+ .default_top_secam_mid = -2,
+ .default_top_secam_high = -2,
+ },
+};
/* - */
@@ -1827,6 +1851,11 @@
.params = tuner_sony_btf_pxn01z_params,
.count = ARRAY_SIZE(tuner_sony_btf_pxn01z_params),
},
+ [TUNER_PHILIPS_FQ1216ME_MK5] = { /* Philips PAL */
+ .name = Philips PAL/SECAM multi (FQ1216ME MK5),
+ .params = tuner_fq1216me_mk5_params,
+ .count = ARRAY_SIZE(tuner_fq1216me_mk5_params),
+ },
};
EXPORT_SYMBOL(tuners);
diff -r a/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-03-19
16:34:17.0 +0200
@@ -5411,7 +5411,44 @@
.gpio = 0x389c00,
} },
},
-
+ [SAA7134_BOARD_AVERMEDIA_STUDIO_509UA] = {
+ /* Evgen Batsman evgenbats...@gmail.com */
+ .name = Avermedia AVerTV Studio 509UA,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_FQ1216ME_MK5,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+ .gpiomask = 0x03,
+ .inputs = { {
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ .gpio = 0x00,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ .gpio = 0x00,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ .gpio = 0x00,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x01,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = LINE1,
+ .gpio = 0x00,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6567,6 +6604,12 @@
.subvendor= 0x107d,
.subdevice= 0x6655,
.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
+ },{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0xa14b,
+ .driver_data = SAA7134_BOARD_AVERMEDIA_STUDIO_509UA,
}, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
diff -r a/linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134.h 2010-03-19
13:13:00.0 +0200
@@ -302,6 +302,7 @@
#define SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S 175
#define SAA7134_BOARD_BEHOLD_505RDS_MK3 176
#define SAA7134_BOARD_HAWELL_HW_404M7177
+#define SAA7134_BOARD_AVERMEDIA_STUDIO_509UA 178
Re: RFC: Drop V4L1 support in V4L2 drivers
Am Freitag, den 19.03.2010, 12:04 -0700 schrieb VDR User: Keeping v4l1 because some guys are still using some ancient setup is not a good reason. Keeping v4l1 because some app devs still haven't bothered to update their apps is not a good reason, especially given the amount of time they've had to complete this task. Keeping v4l1 because package maintainers haven't bothered to update their packages is not a good reason. To put it simply, v4l1 is just dragging along dead weight. It has been replaced by something better and there's no reasonable excuse to keep dragging it along. There will always be someone complaining because there will always be someone neglecting to make the transition until the last possible second or resisting change even when it's for the better. App devs that haven't bothered to update -- you've had plenty of time to get it done. If you app breaks, it's not v4l's fault at this point. Users still on ancient hardware -- consider updating to cheap newer alternatives but don't expect v4l to be held back because you refuse to move forward. Or politely request old drivers be converted. Package maintainers -- if it's too much of a hassle to keep your package(s) updated, consider giving that responsibility to someone else. The points made in this thread make it pretty obvious that dumping v4l1 altogether is easily for the best and has only very minimal negative impact. And the negatives aren't anything that can't be resolved completely with a little commitment to do so. Best regards, Derek If you are so clear and up to date on all, please share your knowledge with us and tell at least, which vbi/cc and radio app would still work after your proposal? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi Alex, Am Montag, den 08.03.2010, 12:21 +0200 schrieb Alex Kasayev: Team, I would to inform you about my experience with Kworld DVB-T 210SE under Linux. It partially works only when I reboot computer from Win to Linux. If I power-on and boot Linux first - it not working at all and rebooting into win does not help - it not working under Win also until I power-off and load Win first. I Googled a lot and found that there are exactly same problems with DVB-T cards from different vendors which using the TDA10046 demodulator (example is recent post from Robin Raiton for MSI TV - I got exactly same messages). I tried with card=81 and card=114. I have played with different modprobe options and found that probably cause of error is incorrect TDA10046 initialization - see logs below (first is for power-on Linux boot and second is for reboot from Win). Please help me guys to get this card working. I am able to apply patches, re-build kernel and test changes. Now some info: Operating system: OpenSUSE 11.2 kernel 2.6.31.12 Card: Kworld DVB-T 210SE Chips on the card: SAA7131E/03/G, 8275AC1, HC4052, KS007, TDA10046A, ATMLH806. Crystals: 32.1 MHz, 20 MHz, 16MHz Logs and win driver's .inf attached. Thanks, Alex. unfortunately the problem with these cards is known, but no good solution for now. Best description is from Hartmut and starts here. http://www.spinics.net/lists/linux-dvb/msg26683.html Your card was also never fully tested and validated and thus is not yet in the driver, even it has it's own PCI subdevice ID. From your .inf we can see also a configuration difference. Kworld DVBT 210 17de:7250 [3xHybridK.AddReg] HKR, I2C Devices, Device 0, Data1,0x00010001,0x21,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data2,0x00010001,0xC2,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data3,0x00010001,0x96,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data4,0x00010001,0x10,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data5,0x00010001,0x03,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data6,0x00010001,0x32,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data7,0x00010001,0x15,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data8,0x00010001,0x06,0x00,0x00,0x00 HKR, I2C Devices, Number of I2C Devices,0x00010001,1 Kworld DVBT 210SE 17de:7253 [3xHybridQ.AddReg] HKR, I2C Devices, Device 0, Data1,0x00010001,0x21,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data2,0x00010001,0xC2,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data3,0x00010001,0x96,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data4,0x00010001,0x10,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data5,0x00010001,0x03,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data6,0x00010001,0x32,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data7,0x00010001,0x15,0x00,0x00,0x00 HKR, I2C Devices, Device 0, Data8,0x00010001,0x50,0x00,0x00,0x00 HKR, I2C Devices, Number of I2C Devices,0x00010001,1 Data8 differs and I don't know its meaning right now. In your eeprom is that byte even 0x56 and not 0x50. Maybe it plays some role. On triple cards we have the address of the DVB-S demod there. Else, if a previously fully working card is broken, we can find the patch causing it using mercurial bisect procedures. Does not take very long. Around November 2008 have at least been reports with normal log for a missing firmware file in /lib/firmware and one guy had DVB-t working in the UK, with some quality limitations, maybe caused by frequency offsets they use there. Try to check again. if there is really no second 8pin eeprom close to the tda10046 for its firmware. Put firmware in /lib/firmware. Disable early starting apps like myth backend. If i2c to the tuner is already lost, only a cold boot will help for a next try. Eventually disable its initialization for analog mode in saa7134-cards.c. Comment the card in that case statement. Good Luck, Hermann --- Robbin's mail follows (I'm constantly get exactly the same messages) : Hi List, Ages ago I wrote about trying to get a MSI TV Anywhere A/D V1.1 to work (in my MythBackend, but that part isn't important). Doing a quick search notice this was over 2 years ago! The original thread on the archives is here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28514.html Anyhow, at the time I gave up as it just wouldn't play. As some time has passed and was messing around with hardware decided to pull out the card and give it another go. It looks promising still, but still doesn't work :( Has anyone managed to get this card working in the mean time, or should I give up for sure this time and bin it? :( Cheers, Robin P.S. Some info to help out... dmesg gives this on boot: saa7130/34:
Aw: Re: v4l-utils, dvb-utils, xawtv and alevt
- Original Nachricht Von: Chicken Shack chicken.sh...@gmx.de An: hermann pitton hermann-pit...@arcor.de Datum: 14.03.2010 12:13 Betreff: Re: v4l-utils, dvb-utils, xawtv and alevt Am Sonntag, den 14.03.2010, 06:39 +0100 schrieb hermann pitton: Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack: Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede: Hi, On 03/13/2010 11:15 AM, Chicken Shack wrote: Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede: Hi, On 03/12/2010 08:10 PM, Chicken Shack wrote: 1. Alevt 1.7.0 is not just another tool, but it is instead a self-contained videotext application consisting of three parts: a. alevt, b. alevt-date c. alevt-cap While the packed size of alevt is 78770 the complete size of the dvb-apps as a whole ranges around 35. I am not against hosting this program at linuxtv.org, but if this decision is made the decision should be an intelligent one: alevt is a separate tree, and any other choice is simply a dumb one. Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps only need the libc6. More clever would have been never to rename it from alevt-dvb to alevt. On the prior you don't have any rights and I seriously doubt you have any on the later. Only a pure brainless idiot who understands less than nothing can rant crap like this. Typical Pitton, typical no-brain quality Good morning Hans, Good afternoon :) Definitely not. 3.95 is analogue only and thus is discontinued as version. 4.0 pre is the alpha-state tarball that you can get here: No, 3.95 is official and right for patching and 4x was never released. See above. I pointed to mpeg4ip only as a joke. Ah, ok. Well I must honestly say I've no interest in that I'm doing package maintenance for the 3.95 release in Fedora and I know it needs a lot of patching, AFAIK other distros are doing the same, so it would be good to have / become a new upstream for xawtv 3.95, to have a place to gather all the distro patches mostly and release that, and where new patches if needed can accumulate and new releases can be done from. http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz Inofficial end of development somewhere in 2005 or 2006, last external contribution from October 2008. It was on March 08 2005. You even don't know that? Completely irrelevant, stupid moron! http://linux.bytesex.org/v4l2/maintainer.txt Maybe improve your Pinnacle stuff first, I can point you to a lot on the TODO list. Don't owe no Pinnacle any longer for years now. I personally took part in flexcop development as well-informed people know. That's a good driver now, and Patrick is someone you can really work with, not unproblematic, but OK so far. He's no Abraham, and he's no Pitton http://www.mail-archive.com/linux-...@linuxtv.org/msg23780.html There is not any progress with you and likely never will be. Cheers, Hermann Topp oder Hopp? Tolle Figur, scharfes Dekolleté oder sehenswertes Tatoo?! Bewerten Sie die besten Bilder und zeigen Sie auch selbst, was Sie haben! Jetzt reinklicken und mitmachen: http://www.arcor.de/rd/footer.toh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Am Sonntag, den 14.03.2010, 03:38 +0100 schrieb Daro: Hi Jean, I am back and ready to go :) As I am not much experienced Linux user I would apprieciate some more details: I have few linux kernels installed; which one should I test or it does not matter? 2.6.31-14-generic 2.6.31-16-generic 2.6.31-17-generic 2.6.31-19-generic 2.6.31-20-generic and one I compiled myself 2.6.32.2 I assume that to proceed with a test I should patch the certain version of kernel and compile it or could it be done other way? Best regards Daro W dniu 12.03.2010 10:38, Jean Delvare pisze: Hi Daro, On Fri, 26 Feb 2010 17:19:38 +0100, Daro wrote: I did not forget I had offered to test the patch however I am now on vacation skiing so I will get back to you as soon I am back home. Are you back home by now? We are still waiting for your test results. We can't push the patch upstream without it, and if it takes too long, I'll probably just discard the patch and move to other tasks. Hi Daro, thanks for being back on it. Damned jokes aside, and not made. Sorry, let know if you have any problems to get Jeans patch stuff applied. Jean's review is good and valuable and we might to have to come back to it, if stuff with the same PCI subsystem and different remotes is validated to be out. (The LNA hell is even much more burning ;) It very much looks like that is already the case. It is a little confusing these days, patch p0, p1, hg or git patches. I let it to Jean, how to test best for now, but will help to prepare you with stuff you can test easily under any conditions. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-utils, dvb-utils, xawtv and alevt
Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack: Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede: Hi, On 03/13/2010 11:15 AM, Chicken Shack wrote: Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede: Hi, On 03/12/2010 08:10 PM, Chicken Shack wrote: 1. Alevt 1.7.0 is not just another tool, but it is instead a self-contained videotext application consisting of three parts: a. alevt, b. alevt-date c. alevt-cap While the packed size of alevt is 78770 the complete size of the dvb-apps as a whole ranges around 35. I am not against hosting this program at linuxtv.org, but if this decision is made the decision should be an intelligent one: alevt is a separate tree, and any other choice is simply a dumb one. Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps only need the libc6. More clever would have been never to rename it from alevt-dvb to alevt. On the prior you don't have any rights and I seriously doubt you have any on the later. Good morning Hans, Good afternoon :) Definitely not. 3.95 is analogue only and thus is discontinued as version. 4.0 pre is the alpha-state tarball that you can get here: No, 3.95 is official and right for patching and 4x was never released. I pointed to mpeg4ip only as a joke. Ah, ok. Well I must honestly say I've no interest in that I'm doing package maintenance for the 3.95 release in Fedora and I know it needs a lot of patching, AFAIK other distros are doing the same, so it would be good to have / become a new upstream for xawtv 3.95, to have a place to gather all the distro patches mostly and release that, and where new patches if needed can accumulate and new releases can be done from. http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz Inofficial end of development somewhere in 2005 or 2006, last external contribution from October 2008. It was on March 08 2005. You even don't know that? http://linux.bytesex.org/v4l2/maintainer.txt Maybe improve your Pinnacle stuff first, I can point you to a lot on the TODO list. Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-utils: i2c-id.h and alevt
Hi Hans, both, Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil: It's nice to see this new tree, that should be make it easier to develop utilities! After a quick check I noticed that the i2c-id.h header was copied from the kernel. This is not necessary. The only utility that includes this is v4l2-dbg and that one no longer needs it. Hans, can you remove this? The second question is whether anyone would object if alevt is moved from dvb-apps to v4l-utils? It is much more appropriate to have that tool in v4l-utils. i wonder that this stays such calm, hopefully a good sign. In fact alevt analog should come with almost every distribution, but the former alevt-dvb, named now only alevt, well, might be ok in some future, is enhanced for doing also dvb-t-s and hence there ATM. Does anyone know of other unmaintained but useful tools that we might merge into v4l-utils? E.g. xawtv perhaps? If for xawtv could be some more care, ships also since close to ever with alevtd, that would be fine, but I'm not sure we are talking about tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for example are also there and unmaintained. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual DVB-S2 PCIe card
Hi Per, Am Donnerstag, den 04.03.2010, 14:03 +0200 schrieb Per Lundberg: Hi Hermann, On Thu, Mar 4, 2010 at 11:05 AM, hermann pitton hermann-pit...@arcor.de wrote: Has anyone done any attempt at contacting TBS to see if they can release their changes under the GPLv2? Ideally, they would provide a patch themselves, but it should be fairly simple to diff the linux/ trees from their provided linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in fact, it could be that their patch is so trivial that we could just include it in the stock Linux kernel without asking them for license clarifications... but obviously, if we can get a green sign from them, it would be even better. It is always the other way round. In the end they need a green sign from us. Well... I guess we are both right. :-) They need to assert ownership and license the code under the GPL, and we need to ensure that the quality of the code is high enough (driver is working and does not interfer with other parts of the code base...). no, they must provide GPLed code accepted by NXP or someone else will do it. We can't assure quality of code we can't see. BTW, the TBS dual seems to be fine on m$, but there are some mysterious lockups without any trace, if used in conjunction with some prior S2/HDTV cards. I can't tell yet, if that it is evenly distributed over amd/ati and nvidia stuff or whatever on win7 ... , but people do spend lifetime in vain on it. This is pretty interesting, do you have any references? (forum links or similar) No, a friend recently bought that card in addition to a Terratec S2 PCI for his new windows 7 he already had. Likely totally unrelated to linux, but on his stuff it turned out he can't use both cards at once, single both are fine. In my particular case, I was thinking about using it as the only S2 card in the machine, later possibly adding a DVB-C card if/when we get cable... so, it might not be a problem for me, but it still doesn't feel really good. I guess the card is pretty new, so maybe (hopefully) it will get fixed by a new firmware release. Do we have any readers of this list who own the card and use it in Linux (with the drivers from TBS)? Could you please share your experiences: is the picture quality good? Sound? Does the tuner work well? (e.g. can you receive all channels you normally receive...) Sorry, can't help much yet and can't add anything new. For now I advised better not to try with binary blobs on linux, he was already burned enough on win7. He might try later and we will have it under GPL sooner or later. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual DVB-S2 PCIe card
Am Donnerstag, den 04.03.2010, 08:19 + schrieb Per Lundberg: Hi! I read the old thread about this card, at http://www.mail-archive.com/linux-media@vger.kernel.org/msg12753.html. I've also tried downloading the vendor-provided drivers from http://www.buydvb.net/download2/TBS6980/tbs6980linuxdriver2.6.32.rar As someone has already indicated, it seems like TBS (TurboSight) have made their own fork of v4l where the drivers for this card is included. I've also understood that the card works fine, which is nice (I down own it yet but am considering getting one). Has anyone done any attempt at contacting TBS to see if they can release their changes under the GPLv2? Ideally, they would provide a patch themselves, but it should be fairly simple to diff the linux/ trees from their provided linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in fact, it could be that their patch is so trivial that we could just include it in the stock Linux kernel without asking them for license clarifications... but obviously, if we can get a green sign from them, it would be even better. -- Best regards, Per Lundberg It is always the other way round. In the end they need a green sign from us. Cheers, Hermann BTW, the TBS dual seems to be fine on m$, but there are some mysterious lockups without any trace, if used in conjunction with some prior S2/HDTV cards. I can't tell yet, if that it is evenly distributed over amd/ati and nvidia stuff or whatever on win7 ... , but people do spend lifetime in vain on it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7231 is anybody trying
Hi, Am Samstag, den 20.02.2010, 09:53 +0100 schrieb Jens Chievitz: Hi developers Is anybody trying to get this device working under linux? I have found some code here: http://www.jusst.de/hg/saa7231 but it it is not finished. Regards Jens chievitz got some such fish on the hook, notoriously buying some latest Medion/Aldi/Tevion/Creatix stuff. That sort was not exactly wanted, but it has some big NXP on it and else the fuzzy picture was for nothing good enough ;) CTX1924_V2 isl6405ezr. Most important chip on it ;) saa7231ne cx24120-13z 24118a12 clock 40.44 tda18271HDC2 clock 16.00 Looks like Manu has a lot already and also Sergey. filename: /lib/modules/2.6.30.1/kernel/drivers/media/dvb/frontends/cx24120.ko license:GPL author: Sergey Tyurin description:DVB Frontend module for Conexant CX24120/CX24118 hardware srcversion: C9FCDA7FA6E37AED28B5DD8 depends:i2c-core vermagic: 2.6.30.1 SMP preempt mod_unload parm: cx24120_debug:Activates frontend debugging (default:0) (int) But still seems to be a long road. BTW, there are lots of complaints about overheating for that card within short time on the original machine, what I don't see on my old AMD Quad machine. DVB-T looks ok on vista, did not test any analog stuff yet, but DVB-S is very poor. Not even 50% of the usual services. S2 not tested, need to move the dish. Looks like we might import a DVB-S bug from initial m$ drivers again? Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IR RC, REGRESSION] Didn't work IR RC
Hi, Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho Chehab: Andy Walls wrote: On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote: Hi All After rework of the IR subsystem, IR RC no more work in our TV cards. As I see call saa7134_probe_i2c_ir, configure i2c call i2c_new_device New i2c device not registred. The module kbd-i2c-ir loaded after i2c_new_device. Jean, There was also a problem reported with the cx23885 driver's I2C connected IR by Timothy Lenz: http://www.spinics.net/lists/linux-media/msg15122.html The failure mode sounds similar to Dmitri's, but maybe they are unrelated. I worked a bit with Timothy on IRC and the remote device fails to be detected whether ir-kbd-i2c is loaded before the cx23885 driver or after the cx23885 driver. I haven't found time to do any folow-up and I don't have any of the hardware in question. Do you have any thoughts or a suggested troubleshooting approach? Andy/Dmitri, With the current i2c approach, the bridge driver is responsible for binding an i2c device into the i2c adapter. In other words, the bridge driver should have some logic to know what devices use ir-kbd-i2c, loading it at the right i2c address(es). Manually loading IR shouldn't make any difference. yes, we have info.addr at saa7134-input and Dmitri did add the Beholder IR address there recently. From Andy's comment, I suspect that such logic is missing at cx23885 for the board you're referring. Not sure if this is the same case of the boards Dmitri is concerned about. On a first look, Andy seems not to provide the IR addr from the bridge and without probing it can't work anymore. It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so, if this is the case, a patch should be sent also to -stable. In the case of saa7134, Jean worked on a fix for some boards: http://patchwork.kernel.org/patch/75883/ He is currently waiting for someone with the affected boards to test it and give some return. That fix should be unrelated and both variants of the patch are not anywhere yet. We can fake this single board in question on a P7131 Dual, but my receiver is broken, else all looked O.K., and it seems not worth yet to ask Mauro to lose time on faking it, assuming his IR receiver does still work. Here we can simply wait for Daro coming back from skiing, or can even apply already Jean's solution per this card without any risk. Else, do we not check for kernels 2.6.30 on hg v4l-dvb not using auto probing anymore? I tested only on two machines with some 2.6.30 and one with 2.6.29 and recent hg v4l-dvb. There at least all was fine, also with the patch moving IR init1 to saa7134_input_init2 and also for ir-kbd-ic2 for a early Pinnacle 310i under all conditions. Dmitri, on what kernel and/or SCM version of v4l-dvb you discover that flaw? Maybe I can reproduce it then. Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but breaks on 2.6.32. Do we already run out of sync? Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi Avl, Am Samstag, den 20.02.2010, 11:49 + schrieb Avl Jawrowski: Hi, sorry for the late. hermann pitton hermann-pitton at arcor.de writes: But I can't see any video. With Kaffeine I can see the same channels as well. My guess is, kaffeine has a bit more trust in error correction, but you over all reception quality seems to be on a critical limit. In Kaffeine I see signal at 72% and SNR at 100% for that channel, so I don't think it's so bad. yes, should be good enough. So it is still some sort of 310i, but you should mention the new name and that the remote chip on 0x47/0x8e is not detected. I add a note and some photos: http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_(310i) Can I add any other useful information, log or photo? We most likely need the former Pinnacle devs here, if not already fired. Maybe Mike and Devin can agree these days on it and it seems some work-flow does recover. You can have from me all details for the early device I do have now, after later ones caused more confusion, and of course can use all that on the wiki. Let me know, I'll sent photos off list then. After latest on wiki stuff, I'm for sure not interested to have an account and was always in doubt, how to separate developer announces and user reports there. I did vote for user reports, if in doubt, since you can't match all conditions, at least for such cards I was involved, and did stay away, even on worst wrong stuff you sometimes can read there. Either that wiki idea works or not. In longer terms it should, but can also become pretty crufty soon. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Hi Thomas, Am Samstag, den 27.02.2010, 00:34 +0100 schrieb thomas schorpp: Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-) Even at higher BER: Current parameters: Frequency: 1945.320 MHz Inversion: OFF Symbol rate: 22.000154 MSym/s FEC: FEC 5/6 cycle: 1 d_time: 0.001 s Sig: 18504 SNR: 39578 BER: 168 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.073 s Sig: 18247 SNR: 39578 BER: 225 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.079 s Sig: 18504 SNR: 37779 BER: 140 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 198 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.071 s Sig: 18504 SNR: 39835 BER: 221 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 18247 SNR: 39578 BER: 249 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 191 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 18504 SNR: 39578 BER: 185 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.072 s Sig: 18761 SNR: 39578 BER: 137 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] I'll report if issue reoccurs and try to finetune crystal based tuner/demod parameters, then. y tom I just started to try to look it up, but don't have ground yet. I reported unexpected bad performance under GNU/Linux for that card previously. Can you point me to the fix? Cheers, Hermann thomas schorpp wrote: Hi, Issue is already confirmed here: http://www.vdr-portal.de/board/thread.php?threadid=93268 Linux 2.6.32.8, 80cm dish. Do we have any Tuner/Decoder optimization points in the FE code? This is not OK: lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in use: saa7134 grep cTS2PES /var/log/syslog Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity errors Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity errors Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors dvbsnoop -s feinfo -adapter 2 Current parameters: Frequency: 1236.253 MHz Inversion: OFF Symbol rate: 31.794142 MSym/s FEC: FEC 3/4 dvbsnoop -s signal -adapter 2 cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Low signal strength values are AGC-loop misinterpretation as usual? y tom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
