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 > 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- > >> SERR- >> 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: > >> 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 wrote: > > > > Am Montag, den 22.11.2010, 15:08 + schrieb Mike Martin: > >> On 22 November 2010 06:08, hermann pitton 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: 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- > SERR- 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: > 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
Am Montag, den 22.11.2010, 15:08 + schrieb Mike Martin: > On 22 November 2010 06:08, hermann pitton 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 > --- > 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
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
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 [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
> -#include
> -#include
> -#include
> -#include "rc-core-priv.h"
> -
> -/*
> -- */
> -
> -MODULE_AUTHOR("Gerd Knorr [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;
> -
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 > wrote: > > On Thu, 11 Nov 2010 00:13:09 +0100 > > Markus Rechberger wrote: > > > >> On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar > >> wrote: > >> > On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite > >> > 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 writes: > > > == mantis patches - Waiting for Manu Abraham > > == > > > > Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c > > http://patchwork.kernel.org/patch/92961 David Härdeman > > > > Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > > improve http://patchwork.kernel.org/patch/107036 Marko Ristola > > > > Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files > > http://patchwork.kernel.org/patch/107062 Bjørn Mork > > > > Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module > > removal http://patchwork.kernel.org/patch/107063 Bjørn Mork > > > > Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make > > modules http://patchwork.kernel.org/patch/107147 Manu Abraham > > > > Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits > > http://patchwork.kernel.org/patch/109972 Ben Hutchings > > > > Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > > improve http://patchwork.kernel.org/patch/110909 Marko Ristola > > > > Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery > > http://patchwork.kernel.org/patch/111090 Marko Ristola > > > > Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of > > busy reg http://patchwork.kernel.org/patch/111245 Marko Ristola > > > > Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) > > http://patchwork.kernel.org/patch/112708 Niklas Claesson > > > > Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per > > interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola > > > > Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 > > demod http://patchwork.kernel.org/patch/244201 Tuxoholic > > > > Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus > > http://patchwork.kernel.org/patch/105621 Florent AUDEBERT > > > > > > 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: [PATCH] xc5000 and switch RF input
Am Donnerstag, den 14.10.2010, 12:12 -0400 schrieb Dmitri Belimov: > Hi > > > On Wed, Oct 13, 2010 at 5:30 PM, Dmitri Belimov > > wrote: > > > Hi > > > > > > Our TV card Behold X7 has two different RF input. This RF inputs > > > can switch between different RF sources. > > > > > > ANT 1 for analog and digital TV > > > ANT 2 for FM radio > > > > > > The switch controlled by zl10353. > > > > > > I add some defines for the tuner xc5000 and use tuner callback to > > > saa7134 part. All works well. But my patch can touch other TV cards > > > with xc5000. > > > > > > Devin can you check my changes on the other TV cards. > > > > > > With my best regards, Dmitry. > > > > Hello Dmitri, > > > > I've looked at the patch. I really don't think this is the right > > approach. The tuner driver should not have any of this logic - it > > should be in the bridge driver. You can also look at Michael Krufky's > > frontend override patches, which allow the bridge to intervene when > > DVB frontend commands are made (for example, to toggle the antenna > > before the tune is performed). > > Ok. > > > I understand the problem you are trying to solve, but jamming the > > logic into the tuner driver really is a bad idea. > > > > NACK. > > > > Devin > > > > -- > > Devin J. Heitmueller - Kernel Labs > > http://www.kernellabs.com > > Ok. > > With my best regards, Dmitry. > > -- Dmitry, please adjust your timezone somehow better. I do read the stuff only in backlash mode currently, but it is annoying to have you always in the future and real time relations are broken within all the other stuff coming in. 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
Am Montag, den 04.10.2010, 19:59 -0400 schrieb Devin Heitmueller: > On Mon, Oct 4, 2010 at 7:21 PM, hermann pitton > 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 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, wrote: > >> > >> > >> Hi Dejan, > >> > >> - Original Nachricht > >> Von: Dejan Rodiger > >> An: hermann pitton > >> Datum: 22.09
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, wrote: > > > > > > Hi Dejan, > > > > - Original Nachricht > > Von: Dejan Rodiger > > An: hermann pitton > > 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 f
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 > >> 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: [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 > 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: [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, - Original Nachricht Von: Dejan Rodiger An: hermann pitton 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 > 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 f
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: [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 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 genty > > > > > > > > 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 genty > 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
Dear Kuninori, Am Mittwoch, den 14.07.2010, 14:18 +0900 schrieb Kuninori Morimoto: > Dear hermann > > > 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. > > I'm so sorry about my stupid English. > I should not use the words of "criminal". > > I should say > "The reason that there are no video output on Ecovec > might dip-switch setting issue. > DS2[3] should be OFF when you use video" > > Best regards > -- > Kuninori Morimoto > thanks for providing more insight. I really could not believe that we depend on dip-switch settings on v4l-dvb. Last I saw such, despite of mobos, was in the mid of the nineties on some ISA network cards. Assured for now enough, that such stuff exists, we still have a serious leak of documentation about hundreds of new devices recently rushed in. I take this dip-switch just as an example. Is there any documentation and how can a user know about it? Without any, "criminal" is fine so far :) 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] 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
Signed-off-by: hermann pitton
> 2010/7/2 hermann pitton
> 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 p
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] g
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
days like
undocumented checksums, then we can at least identify different devices
physically and can disable our failing auto detection and point to card
numbers.
A S-Video connector has only four pins, but we find regularly so called
break out connectors there, which can cover all sort of in- and outputs.
Cards can look extremely different, not only concerning connectors, but
might be still functional in the same for the inputs. There are a lot of
examples.
On some cards the yellow input connector is used 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
>
> 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
>
>
> 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 th
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
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
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: 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: [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 An: hermann pitton 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 > wrote: > > > > Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User: > >> hermann pitton , 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 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 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: 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 > > An: Alexander Apostolatos > > 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 Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User: > hermann pitton , 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: 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?
Hi, Am Sonntag, den 30.05.2010, 00:01 -0700 schrieb VDR User: > On Sat, May 29, 2010 at 10:52 PM, hermann pitton > 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: 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 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: [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: [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 */
> + /* Emard 2010-05-10 v18-v4l */
> .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
Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate M1F
t; > + .radio = {
> > + .name = name_radio,
> > + .amux = LINE2,
> > + },
> > + },
> > };
> >
> > const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
> > @@ -6890,6 +6916,7 @@ int saa7134_board_init1(struct saa7134_d
> > case SAA7134_BOARD_VIDEOMATE_TV_PVR:
> > case SAA7134_BOARD_VIDEOMATE_GOLD_PLUS:
> > case SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUSII:
> > + case SAA7134_BOARD_VIDEOMATE_M1F:
> > case SAA7134_BOARD_VIDEOMATE_DVBT_300:
> > case SAA7134_BOARD_VIDEOMATE_DVBT_200:
> > case SAA7134_BOARD_VIDEOMATE_DVBT_200A:
> > diff -uprN v4l-dvb_orig/drivers/media/video/saa7134/saa7134.h
> v4l-dvb/drivers/media/video/saa7134/saa7134.h
> > --- v4l-dvb_orig/drivers/media/video/saa7134/saa7134.h 2010-05-26
> 20:34:09.0 +0300
> > +++ v4l-dvb/drivers/media/video/saa7134/saa7134.h 2010-05-26
> 21:13:10.654349519 +0300
> > @@ -303,6 +303,7 @@ struct saa7134_format {
> > #define SAA7134_BOARD_HAWELL_HW_404M7 177
> > #define SAA7134_BOARD_BEHOLD_H7 178
> > #define SAA7134_BOARD_BEHOLD_A7 179
> > +#define SAA7134_BOARD_VIDEOMATE_M1F180
> >
> > #define SAA7134_MAXBOARDS 32
> > #define SAA7134_INPUT_MAX 8
> > diff -uprN v4l-dvb_orig/drivers/media/video/saa7134/saa7134-input.c
> v4l-dvb/drivers/media/video/saa7134/saa7134-input.c
> > --- v4l-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_S350"rc-videomate-s350"
> > #define RC_MAP_VIDEOMATE_TV_PVR "rc-videomate-tv-pvr"
> > #define RC_MAP_WINFAST "rc-winfast"
> > Signed-off-by: Pavel Osnova
> >
> >
> >
> > 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
Re: What ever happened to standardizing signal level?
- Original Nachricht Von: VDR User An: hermann pitton 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 > 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: 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 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 */
> > .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,
> >
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
> + */
> +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,
> +
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 > > 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: [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 An: Linus Torvalds Kopie: Andrew Morton , 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 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 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, [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
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: [] __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.1
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: >
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
> &g
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: 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 : > > 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 : > >> > 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: 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
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: [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 wrote: > > On Wed, 28 Apr 2010 09:45:39 +0200 > > André Weidemann 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: 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: [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 > >> 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: [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 > # 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: 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
Re: RFC: exposing controls in sysfs
Hi, Am Mittwoch, den 07.04.2010, 00:39 +0200 schrieb Hans Verkuil: > On Tuesday 06 April 2010 17:16:17 Mike Isely wrote: > > On Tue, 6 Apr 2010, Laurent Pinchart wrote: > > > > > Hi Andy, > > > > > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: > > > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: > > > > > > [snip] [snip] > > code. I don't know if that same strategy could be done in the V4L core. > > If it could, then this would probably alleviate a lot of concerns about > > testing / maintenance going forward. > > In other words, yes, it could do this. And with relatively little work and > completely transparent to all drivers. > > But I have a big question mark whether we really want to go that way. The > good thing about it is that the ioctls remain the primary API, as they should > be. Anything like this will definitely be a phase 3 (or 4, or...), but it > is at least nice to realize how easy it would be. That's a good sign of the > quality of the code. > > Regards, > > Hans that all looks really good now and quite promising, also IR/remote. Maybe too good? About what might be upcoming problems nobody is talking about currently. Never seen before ... I would wonder a lot, if we really should have made it close to such with a lot of buffering all around ;) Well, I guess the time on that beach might be short. Manu gave some pointers previously that HD+ is a serious issue for us, also it seems, that some lower level of firmware starts to hide GPIO's and i2c addresses on recent boards. We likely should stay hackish and able for quick responses and not over-engineer convenience we do not really have. Just my two cents. 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 An: Mauro Carvalho Chehab 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 An: Devin Heitmueller 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 > > 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 >
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
> > >
> > >
> > > 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
>
> 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: 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: [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
> > 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: 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 > [
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: 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
> 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 ")
> 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
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 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. ;) > Any help on this would be greatly appreciated. > > > > ~Serge -- 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: 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
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: Add AverTV Studio 509UA
Hi,
Am Samstag, den 20.03.2010, 16:08 +0200 schrieb Евгений Бацман:
> 2010/3/20 hermann pitton :
> > 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 */
> >> + .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 = {
> >> + .n
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
Cheers,
Hermann
> # HG changeset patch
> # User Vladimir Ermakov
> # 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
> >>
> >> # HG changeset patch
> >> # User Vladimir Ermakov
> >> # 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 Euro
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: 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 */
> + .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 S
Re: [PATCH] saa7134: add capture boards Hawell HW-404M7 and HW-808M7
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
>
> # HG changeset patch
> # User Vladimir Ermakov
> # 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.saa7134Tue Mar 09
> 23:00:59 2010 -0300
> +++ b/linux/Documentation/video4linux/CARDLIST.saa7134Wed 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.c Tue Mar 09
> 23:00:59 2010 -0300
> +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Wed 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 */
> + .name = "Hawell HW-404M7",
> + .audio_clock = 0x0020,
> + .tuner_type= UNSET,
> + .radio_type= UNSET,
> + .tuner_addr = ADDR_UNSET,
> + .radio_addr = ADDR_UNSET,
> + .gpiomask = 0x01fc00,
> + .inputs = {{
> + .name = name_comp1,
> + .vmux = 3,
> + .amux = LINE1,
> + .gpio = 0x389c00,
> + } },
> + },
>
> };
>
> diff -r 7a58d924fb04 -r 072cd67c6aab
> linux/drivers/media/video/saa7134/saa7134-input.c
> --- a/linux/drivers/media/video/saa7134/saa7134-input.c Tue Mar 09
> 23:00:59 2010 -0300
> +++ b/linux/drivers/media/video/saa7134/saa7134-input.c Wed Mar 10
> 17:43:41 2010 +0300
> @@ -529,6 +529,7 @@
> 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:
> diff -r 7a58d924fb04 -r 072cd67c6aab
> linux/drivers/media/video/saa7134/saa7134.h
> --- a/linux/drivers/media/video/saa7134/saa7134.h Tue Mar 09 23:00:59
> 2010 -0300
> +++ b/linux/drivers/media/video/saa7134/saa7134.h Wed Mar 10 17:43:41
> 2010 +0300
> @@ -301,6 +301,7 @@
> #define SAA7134_BOARD_ASUS_EUROPA_HYBRID 174
> #define SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S 175
> #define SAA7134_BOARD_BEHOLD_505RDS_MK3 176
> +#define SAA7134_BOARD_HAWELL_HW_404M7177
>
> #define SAA7134_MAXBOARDS 32
> #define SAA7134_INPUT_MAX 8
>
--
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
Aw: Re: v4l-utils, dvb-utils, xawtv and alevt
- Original Nachricht Von: Chicken Shack An: hermann pitton 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: 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: [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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Samstag, den 06.02.2010, 13:02 +0100 schrieb BOUWSMA Barry: > I'm not even trying to follow this discussion at all, but I > feel I have to chime in to be off-topic... > > On Sat, 6 Feb 2010, hermann pitton wrote: > > > > > > Bye bye Teletext. Nothing for future kernels, huh? > > > > > > > > Yes, you say it. It definitely will go away and we do have not any > > > > influence on that! Did you not notice the very slow update rate these > > > > days? > > > > > > a. NOTHING "will go away". This is empty rant, nothing else it is! > > > In US teletext is dead, yes. In Europe analogue television is close to > > > dead. Yes. > > > But I have found no information source that teletext will disappear in > > > general. At least not in Europe or Germany. > > > So if you keep that up then prove the assertion please. > > > > In the UK too. And after world war II we always followed BBC. > > Not that bad ... > > The BBC has switched over to ``Digital Text'' via the Red Button > service on Freeview. This is based on MHEG, and has the advantage > that pretty much all receivers are built around a particular > platform which specifies inclusion of the Red Button services, > a particular EPG, LCNs, and so on. Be that platform Freeview, or > Sky, or Freesat. > > This is not the case in your country -- the public broadcasters > have adopted MHP which has gone over about as well as a lead > balloon. There is also not a specified platform, but rather any > manufacturer can offer a receiver based on the DVB specifications. > Usually teletext support will be built-in to the decoder; also, > most boxes pass the DVB Teletext information to the television > regenerated as the analogue VBI interval which pretty much every > set supports. > > As far as I know, the proposed Eutelsat Viseo platform being > pushed does not specify a MHP- or MHEG-based replacement for > teletext, nor am I aware of any alternative platforms to take > over and mandate a replacement of the current level teletext. > > Can you even find a MHP-capable settop box in the shops today? > Also, as far as I know, the national MHP service was dropped from > terrestrial broadcasting some years ago, and at best there may > be still a regional and minimal service offered by Bayerischer > Rundfunk, but nothing like one finds on Freeview. > > Conditions have diverged too much between the two countries these > days. In the UK, Sky has a lion's share of the market, while I've > barely seen anything but a few sports bars with a Premiere > subscription. Also while the commercial public service > broadcasters in the UK have relied on terrestrial service through > the country, this has not been true of the comparable private > commercial broadcasters in germany, who are not even participating > in terrestrial broadcasting outside of a handful of strategic > centres. Also, teletext in germany is a service of the individual > broadcasters or contracted out in the commercial case, while the > Teletext and Teletext Holidays and such closing in the UK is its > own service. > > > Without support already in place for a transition away from VBI- > based teletext over the coming years, I can't see it happening. > I know that Austria made a big deal of their MHP-based ORF text > service, but I don't know how great a penetration it has. I've > read tht it requires significant bandwidth of the terrestrial > multiplexes, while conventional teletext requires around that of > an audio channel -- back when ZDFvision was sending MHP data plus > AC3 streams terrestrially, I clocked four MHP streams each with a > data rate comparable to a lower-quality audio stream, together > some twice the data rate of each of the three separate teletext > streams. > > > > > > What slow update rate please? > > > What the hell are you talking about, man? > > > > Previously information available there was updated within minutes, now > > in best case every six hours it seems to me. > > I don't know what services you are viewing; those which I use > are updated within seconds of updated data, and happen to be the > first place I turn to for current information. The amount and > quality of information I get from conventional teletext is far > more impressive than what I see on the BBC's Red Button service. > > > barry bouwsma Hi Barry, sorry for delay and thanks for your advice. I know it was already there previously and is best we have. ZDF is becoming very slow in updating news on page 112 and 113. KiKa seems to be already fully commercial. 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: 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
