[PULL] http://linuxtv.org/hg/~awalls/cx18-feature
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-feature for the following 8 changesets: 01/08: cx18: Update MPEG Index stream buffers module option processing http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=eb875b71908a 02/08: cx18: Encapsulate check for a stream being enabled into an inline function http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=55c86b3e5a09 03/08: cx18: Fix TS and IDX stream buffer memory leak on module unload http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=9c341b693fcd 04/08: cx18: Allow MPEG index streams to be started and stopped internally http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=fc743523e7bd 05/08: cx18: Start IDX streams automatically as an internal associated stream http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=e18e865270ea 06/08: cx18: Perform automatic rotation of very old, unread IDX buffers http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=ee8c1c0eec7e 07/08: cx18: Add initial working VIDIOC_G_ENC_INDEX ioctl() support http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=dcb3c59fab66 08/08: cx18: Clean up dead code from ivtv once used for IDX processing http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=2b8531783c9d cx18-driver.c | 33 ++-- cx18-driver.h | 40 ++--- cx18-fileops.c | 235 - cx18-ioctl.c | 146 +++ cx18-mailbox.c |5 - cx18-queue.c |3 cx18-streams.c | 86 cx18-streams.h | 10 ++ 8 files changed, 384 insertions(+), 174 deletions(-) These changes implement the VIDIOC_G_ENC_INDEX ioctl() for cx18 analog capture of MPEG-2 PS, MPEG-2 DVD and similar streams. There are some minor annoyances - the firmware appears to report everything is a B-frame, and driver limitations mean one can't capture an index when doing sliced VBI insertion - but the rest of it is working properly if anyone would ever need to use it. Oh, and I did find and fix a big memory leak (changeset 03/08) where all the DMA buffers for the DVB TS and INDEX streams were being leaked on module unload. Thanks, Andy -- 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] dvb-apps ported for ISDB-T
Patrick Boettcher wrote: > Hi Mauro, > > On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote: > >> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu: >>> I wrote several patches those days in order to allow dvb-apps to >>> properly >>> parse ISDB-T channel.conf. >>> >>> On ISDB-T, there are several new parameters, so the parsing is more >>> complex >>> than all the other currently supported video standards. >>> >>> I've added the changes at: >>> >>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ >>> >>> I've merged there Patrick's dvb-apps-isdbt tree. >>> >>> While there, I fixed a few bugs I noticed on the parser and converted it >>> to work with the DVB API v5 headers that are bundled together with >>> dvb-apps. >>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. >>> The ones >>> there can now be removed. >>> >>> TODO: >>> = >>> >>> The new ISDB-T parameters are parsed, but I haven't add yet a code to >>> make >>> them to be used; >>> >>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the >>> segment parameters. Currently, the parser will fail if those >>> parameters are found. >>> >>> gnutv is still reporting ISDB-T as "DVB-T". >>> >> >> I've just fixed the issues on the TODO list. The DVB v5 code is now >> working fine >> for ISDB-T. >> >> Pending stuff (patches are welcome): >> - Implement v5 calls for other video standards; >> - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code >> for calling >> DVBv5 is now at /lib/libdvbapi/v5api.c); >> - Test/use the functions to retrieve values via DVBv5 API. The >> function is >> already there, but I haven't tested. >> >> With the DVBv5 API implementation, zap is now working properly with >> ISDB-T. >> gnutv also works (although some outputs - like decoder - may need some >> changes, in >> order to work with mpeg4/AAC video/audio codecs). > > Very good job! > > Have you had a look here on this one > > http://www.mail-archive.com/v...@linuxtv.org/msg11125.html > > ? > > I had this on my list because I wanted to spent some time on DVB-S2 > myself and it seemed to be a good step to merge it (back) into dvb-apps. > Though I haven't yet looked at it in detail. > > I will check your changes soon, but after the holidays. > > So, now you should have some quiet time for yourself! ;-) Ok, I've added a version 2 of the isdbt-aware dvb-apps scan tools. Basically, this version: - checks if v5 API is available on a driver. If not, it falls back to v3 API; - v5api.c is now fully internal to libdvbfe. For library clients, it is fully transparent if it is using v5 or v3 calls; - scan now uses libdvbfe, instead of directly implementing the ioctls for v3 and v5. The code were simplified by the removal of lots of if's for v5 API; - scan now supports a few parameters present on DVB-S2, but there are still a few missing bits to fully support DVB-S2; - as my previous tree, dvb-apps has a copy of the dvb headers, since the headers are stable enough to work with older drivers and since the API version check is done by an ioctl call; - it addresses the pertinent issues that Manu pointed. The big advantage of using libvbfe for scan is that we can remove all v5 (and v3) calls from scan, having a cleaner code. Also, applications like kaffeine that have their own scan codes can benefit on using libdvbfe. Probably, it makes sense to move some code from scan to libdvbfe or to create a libdvbscan, in order to easy the usage of the libdvb for applications that want to have the scan code integrated. I started to validate the delivery system descriptors against the EN 300 468 v 1.9.1, but I haven't finished yet. Due to that, a few new parameters were added, making easier to add DVB-S2 support. I intend later to finish the validation against ETSI for DVB standards and do some review on ARIB and ABNT specs to be sure that it is able to get all parameters reported by the NIT tables for ISDB-T. Yet, this version is not properly tested, but, as I intend to be on vacations next week, I wanted to post what I have, even without all tests, to avoid the risk of someone to be working on DVB-S2 or other improvements to do a similar work. So, the new tree is at: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ it was tested only with ISDB-T and may not work yet with other DTV standards. Enjoy! Happy New Year! Mauro. -- 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: Fwd: Compro S300 - ZL10313
On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: > Hi mailing list, > > I have a problem with my Compro S300 pci card under Linux 2.6.32. > > I cannot tune with this card and STR/SNRA is very bad compared to my > Technisat SkyStar 2 pci card, connected to the same dish. > > I have this card and are willing to run tests, tested drivers etc to > make this work. > > I currently load the module saa7134 with options: card=169 > > I enabled some debug parameters on the saa7134, not sure what else I > should enable. Please find my dmesg log attached. > > lsmod shows : > > # lsmod > Module Size Used by > zl10039 6268 2 > mt312 12048 2 > saa7134_dvb41549 11 > saa7134 195664 1 saa7134_dvb > nfsd 416819 11 > videobuf_dvb8187 1 saa7134_dvb > dvb_core 148140 1 videobuf_dvb > ir_common 40625 1 saa7134 > v4l2_common21544 1 saa7134 > videodev 58341 2 saa7134,v4l2_common > v4l1_compat24473 1 videodev > videobuf_dma_sg17830 2 saa7134_dvb,saa7134 > videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg > tveeprom 12550 1 saa7134 > thermal20547 0 > processor 54638 1 > > # uname -a > Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 Pentium > III (Coppermine) GenuineIntel GNU/Linux > > Thanks, > Theunis Hi, It's probably the GPIO settings that are wrong for your SAA7133 based card revision. See http://osdir.com/ml/linux-media/2009-06/msg01256.html for an explanation. For quick confirmation check if you have 12V - 20V DC going to your LNB. The relevant lines of code is in ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: case SAA7134_BOARD_VIDEOMATE_S350: dev->has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0x8000, 0x8000); saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000); break; Looking at your log, at least the demodulator and tuner is responding correctly. You can see this by looking at the i2c traffic addressed to 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my working SAA7130 based card. Regards JD 07:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7130 Video Broadcast Decoder [1131:7130] (rev 01) Subsystem: Compro Technology, Inc. Device [185b:c900] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: saa7134 Kernel modules: saa7134 and [6.560811] Linux video capture interface: v2.00 [6.602624] saa7130/34: v4l2 driver version 0.2.15 loaded [6.602776] saa7134 :07:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 [6.602783] saa7130[0]: found at :07:00.0, rev: 1, irq: 21, latency: 32, mmio: 0x50004800 [6.602788] saa7130[0]: subsystem: 185b:c900, board: Compro VideoMate S350/S300 [card=169,autodetected] [6.602803] saa7130[0]: board init: gpio is 843f00 [6.602873] input: saa7134 IR (Compro VideoMate S3 as /devices/pci:00/:00:1e.0/:07:00.0/input/input14 [6.602935] Creating IR device irrcv0 [6.602939] IRQ 21/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs [6.710132] saa7130[0]: i2c xfer: < a0 00 > [6.730092] saa7130[0]: i2c xfer: < a1 =5b =18 =00 =c9 =54 =20 =1c =00 =43 =43 =a9 =1c =55 =d2 =b2 =92 =00 =ff =86 =0f =ff =20 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =01 =40 =01 =02 =02 =01 =03 =01 =08 =ff =00 =87 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =d6 =00 =c0 =86 =1c =02 =01 =02 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =cb =30 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff = ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =f f =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff > [6.780031] saa7130[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [6.780044] saa7130[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff [6.780056] saa7130[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff [6.780068] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [6.780080] saa7130[0]: i2c eeprom 40: ff d6 00 c0 86 1c 02 01 02 ff
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Dec 31 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13877:59e746a1c5d1 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
On Thu, 2009-12-31 at 14:26 -0500, Andy Walls wrote: > On Thu, 2009-12-31 at 18:15 +0100, Martin Dauskardt wrote: Some corrections to errors: > My preferences in summary, is that not matter what the digitizer chip: My preferences are, in summary, that no matter what the digitizer chip: > a. I'd like to keep the audio clocks always up to avoid tinny audio. > > b. I'd also like to inhibit the video clock and add the delay after ^^^ refine > re-enabling the digitizer to avoid the *potential* for a hung machine. A value smaller than 300 ms should work, but a value smaller than 40 ms may not work, if my hypothesis is correct. > > c. I do not care to much about the delay after disbaling the video > clock, only that it is empirically "long enough". > > Thanks for taking the time to test and comment. > > Regards, > Andy Regards, Andy > > Greets and Happy New Year > > > > Martin > > > > PS: > > Readers on the ivtv-devel ML list will miss previous postings (the list was > > down a few days). Please have a look in > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14151 > > and > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14155 -- 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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
On Thu, 2009-12-31 at 18:15 +0100, Martin Dauskardt wrote:
> Hi everybody,
>
> first test results from me:
>
> As expected, the double "ivtv_msleep_timeout(300, 1);" in ivtv-streams.c
> increases the time for stopping/starting a stream. I removed the first call
> and it still works fine.
Yes, I knew the initial 300 ms delay before the call to
CX2341X_ENC_INITIALIZE_INPUT was lame, but it should always be safe. I
really want to avoid a video signal from the saa7115 causing the
CX2341[56] to hang the PCI bus.
I was hoping you could find a small number empirically that was safe. I
was thinking at *most* 10 ms for lines to settle: time for audio clocks
to come up to avoid tinny audio and time for video clocks to stop to
avoid PCI bus hangs. It sounds like you determined 0 ms is OK. I
suspect then, that the time to set up and send the
CX2341X_ENC_INITIALIZE_INPUT command to the encoder provides enough
delay.
> @ Mike:
> Previously I suggested to add a msleep(300) in state_eval_decoder_run
> (pvrusb2-hdw.c), after calling pvr2_decoder_enable(hdw,!0).
>
> With the change from Andy I now have again sporadic black screens with my
> saa7115-based PVRUSB2.
Hmmm. That's odd. All I did was separate out video and audio clock
enable/disable into two seperate steps for CX2584x units, or add a small
delay for SAA7115 units.
> So I moved the sleep directly into "static int
> pvr2_decoder_enable":
>
> --- v4l-dvb-bugfix-7753cdcebd28-orig/v4l-dvb-
> bugfix-7753cdcebd28/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> 2009-12-24
> 17:06:08.0 +0100
> +++ v4l-dvb-bugfix-7753cdcebd28-patched/v4l-dvb-
> bugfix-7753cdcebd28/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> 2009-12-31
> 17:19:22.836251706 +0100
> @@ -1716,6 +1716,7 @@
> (enablefl ? "on" : "off"));
> v4l2_device_call_all(&hdw->v4l2_dev, 0, video, s_stream, enablefl);
> v4l2_device_call_all(&hdw->v4l2_dev, 0, audio, s_stream, enablefl);
> + if (enablefl != 0) msleep(300);
> if (hdw->decoder_client_id) {
> /* We get here if the encoder has been noticed. Otherwise
> we'll issue a warning to the user (which should
>
> Funny- this seems to work, no more black screens appeared.
>
>
> The remaining questions are in my opinion:
>
> 1.)
> What is Hans opinion about the changes, especially the move of the 300ms
> sleep
> from "after disabling the digitizer" to "after enabling it" ?
My opinion is to use as short a delay as needed before the call to
CX2341X_ENC_INITIALIZE_INPUT, to avoid tinny audio and avoid PCI bus
hangs.
If you found 0 ms delay was fine, then perhaps I'll just remove that
delay or use something like 1 ms, OK?
For the delay after the CX2341X_ENC_INITIALIZE_INPUT, I think it is
good, as there are probably a few things going on:
a. The digitizer clock lines stabilizing as mentioned earlier
b. The CX2341X_ENC_INITIALIZE_INPUT call may still be executing on the
CX23416, when the ivtv_vapi() returns (I haven't disassembeld the
firmware to check if that is the actually case and how long it might
take).
c. before the call to CX2341X_ENC_START_CAPTURE to start the *first*
capture, the CX2341[56] may need a few valid rasters from the digitizer
stored in its memory.
So the delay after enabling the digitzer makes sure at least a few
rasters are available for the CX2341[56] to operate on. A 300 ms delay
is 15 fields for PAL and 18 fields for NTSC. A wait of 100 ms would be
5 fields for PAL and 6 fields for NTSC, and probably enough.
I think this hypothesis is consistent with the pvrusb2 and ivtv hardware
behavior you noticed.
> 2.)
> Do we want to keep disabling the digitizer during the
> CX2341X_ENC_INITIALIZE_INPUT call in case the digitizer is a cx25840x ?
> It seems to be necessary only for the saa7115.
> Note: The cx88-blackbird-driver does also no disabling/enabling of the
> digitizer (cx2388x) when doing this firmware call.
I would want to do so.
It is my understanding that, notwithstanding any firmware bugs, the
machines in the CX2341[56] chips have some hardware bugs. I want to
avoid tripping over those bugs and locking up someone's machine
intermittently.
The CX2388[0123] is a differnent type of machine internally, not subject
to the same of hardware bugs that the CX2341[56] have that may hang the
machine/PCI bus. The CX2388x should be providing the DMA engines and
the PCI bus connection. I do not know the full details of the Blackbird
board design, but I assume the CX23416 does not interface directly to
the PCI bus along with the CX2388x (which would require a PCI bridge
chip on the card much like a PVR-500).
However, yes it could be the case the Conexant digitizer (CX2584x and
CX2388x internal) output VIP/BT.656 data in a form that at all times
never causes the CX23416 any problems. I really just don't know what
conditions cause the CX23416 to intermittently hang a machine, so I'd
prefer want to avoid any potential
Re: [PATCH] MAINTAINERS: Andy Walls is the new ivtv maintainer
On Thu, 2009-12-31 at 14:55 +0100, Hans Verkuil wrote: > Hi Mauro, > > Attached is a diff for the 2.6.33-rc2 MAINTAINERS file that removes me as > cx18 maintainer and makes Andy the new ivtv maintainer. After 4 1/2 years > I've decided to hand over the ivtv driver to Andy. Andy was already doing > more work on ivtv than I did, so this just makes official what was happening > in practice. > > My SoB: > > Signed-off-by: Hans Verkuil > > Andy, can you add your own SoB as well? Sure. Signed-off-by: Andy Walls Regards, Andy > Regards, > > Hans > > --- MAINTAINERS.org 2009-12-31 13:25:48.0 +0100 > +++ MAINTAINERS 2009-12-31 13:26:50.0 +0100 > @@ -1638,7 +1638,6 @@ > F: sound/pci/cs5535audio/ > > CX18 VIDEO4LINUX DRIVER > -M: Hans Verkuil > M: Andy Walls > L: ivtv-de...@ivtvdriver.org > L: linux-media@vger.kernel.org > @@ -3021,7 +3020,7 @@ > F: drivers/isdn/hardware/eicon/ > > IVTV VIDEO4LINUX DRIVER > -M: Hans Verkuil > +M: Andy Walls > L: ivtv-de...@ivtvdriver.org > L: linux-media@vger.kernel.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git > -- 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
Terratec firmware / af9005.fw
Trying a Terratec "Cinergy T USB XE" USB DVB-T stick under Linux (http://www.terratec.net/en/products/driver/produkte_treiber_en_33211.html) it turns out that one needs specific firmware: usb 5-1: new full speed USB device using uhci_hcd and address 2 usb 5-1: New USB device found, idVendor=0ccd, idProduct=0055 usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 5-1: Product: Cinergy T USB XE usb 5-1: Manufacturer: AFA usb 5-1: configuration #1 chosen from 1 choice dvb-usb: found a 'TerraTec Cinergy T USB XE' in cold state, will try to load a firmware usb 5-1: firmware: requesting af9005.fw dvb-usb: did not find the firmware file. (af9005.fw) ... Checking the latest openSUSE firmware package (kernel-firmware-20091215) it seems this is still not included. Has anyone tried working with Terratec on this? If so, how did that go? Would it make sense for me to give it a try? (Any pointers on what exactly to ask from them in that case?) Gerald -- Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/ -- 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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Hi everybody,
first test results from me:
As expected, the double "ivtv_msleep_timeout(300, 1);" in ivtv-streams.c
increases the time for stopping/starting a stream. I removed the first call
and it still works fine.
@ Mike:
Previously I suggested to add a msleep(300) in state_eval_decoder_run
(pvrusb2-hdw.c), after calling pvr2_decoder_enable(hdw,!0).
With the change from Andy I now have again sporadic black screens with my
saa7115-based PVRUSB2. So I moved the sleep directly into "static int
pvr2_decoder_enable":
--- v4l-dvb-bugfix-7753cdcebd28-orig/v4l-dvb-
bugfix-7753cdcebd28/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-24
17:06:08.0 +0100
+++ v4l-dvb-bugfix-7753cdcebd28-patched/v4l-dvb-
bugfix-7753cdcebd28/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-31
17:19:22.836251706 +0100
@@ -1716,6 +1716,7 @@
(enablefl ? "on" : "off"));
v4l2_device_call_all(&hdw->v4l2_dev, 0, video, s_stream, enablefl);
v4l2_device_call_all(&hdw->v4l2_dev, 0, audio, s_stream, enablefl);
+ if (enablefl != 0) msleep(300);
if (hdw->decoder_client_id) {
/* We get here if the encoder has been noticed. Otherwise
we'll issue a warning to the user (which should
Funny- this seems to work, no more black screens appeared.
The remaining questions are in my opinion:
1.)
What is Hans opinion about the changes, especially the move of the 300ms sleep
from "after disabling the digitizer" to "after enabling it" ?
2.)
Do we want to keep disabling the digitizer during the
CX2341X_ENC_INITIALIZE_INPUT call in case the digitizer is a cx25840x ?
It seems to be necessary only for the saa7115.
Note: The cx88-blackbird-driver does also no disabling/enabling of the
digitizer (cx2388x) when doing this firmware call.
3.)
Does Andys Patch solve the tinny audio problem for Argus (who originally
posted the problem and a different solution in the ivtv-devel list). I add him
in cc.
Greets and Happy New Year
Martin
PS:
Readers on the ivtv-devel ML list will miss previous postings (the list was
down a few days). Please have a look in
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14151
and
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14155
--
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] IR: Fix sysfs attributes declaration
I can confirm this problem. Without this patch (thanks, Francesco!) I get a kernel stack trace when loading the media drivers: http://home.arcor-online.de/martin.dauskardt/trace1.jpg http://home.arcor-online.de/martin.dauskardt/trace2.jpg (An older v4l-dvb hg snapshot from December 5th wotks fine without patch.) I am also using 2.6.32 and have two DVB and two v4l2 cards in my machine. Greets, Martin Dauskardt -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IR Receiver on an Tevii S470
On 31 декабря 2009 14:46:49 Guillem Solà Aranda wrote: > Hi, > > I have a s470 and with > > s2-liplianin-7212833be10d > s2-liplianin-ab3a80e883ba > > began to work, but today I have tested > > s2-liplianin-b663b38d616f > > and seems that there are some problems trying to load the driver > > Linux video capture interface: v2.00 > cx23885: disagrees about version of symbol ir_codes_hauppauge_new_table > cx23885: Unknown symbol ir_codes_hauppauge_new_table > cx23885: disagrees about version of symbol ir_input_init > cx23885: Unknown symbol ir_input_init > cx23885: disagrees about version of symbol ir_input_nokey > cx23885: Unknown symbol ir_input_nokey > cx23885: disagrees about version of symbol ir_input_keydown > cx23885: Unknown symbol ir_input_keydown > > I'm running this on a DELL Server with RHEL and kernel 2.6.31. > > regards, > Guillem > -- > 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 Since module ir-common.ko moved to IR directory just remove old one. rm /lib/modules/$(uname -r)/kernel/drivers/media/common/ir-common.ko Happy New Year! -- 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
[PULL] http://kernellabs.com/hg/~mkrufky/tda8295
Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/tda8295 for: - tda8290: add autodetection support for TDA8295c2 tda8290.c |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Cheers, Mike -- 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
[PATCH] MAINTAINERS: Andy Walls is the new ivtv maintainer
Hi Mauro, Attached is a diff for the 2.6.33-rc2 MAINTAINERS file that removes me as cx18 maintainer and makes Andy the new ivtv maintainer. After 4 1/2 years I've decided to hand over the ivtv driver to Andy. Andy was already doing more work on ivtv than I did, so this just makes official what was happening in practice. My SoB: Signed-off-by: Hans Verkuil Andy, can you add your own SoB as well? Regards, Hans --- MAINTAINERS.org 2009-12-31 13:25:48.0 +0100 +++ MAINTAINERS 2009-12-31 13:26:50.0 +0100 @@ -1638,7 +1638,6 @@ F: sound/pci/cs5535audio/ CX18 VIDEO4LINUX DRIVER -M: Hans Verkuil M: Andy Walls L: ivtv-de...@ivtvdriver.org L: linux-media@vger.kernel.org @@ -3021,7 +3020,7 @@ F: drivers/isdn/hardware/eicon/ IVTV VIDEO4LINUX DRIVER -M: Hans Verkuil +M: Andy Walls L: ivtv-de...@ivtvdriver.org L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: em28xx: Not validated board + feature request [[0x2304:0x0226]]
Hi, I've a card I'll buy few years ago but he didn't work fully. em28xx's card name is [[Pinnacle Hybrid Pro (2)]], empia chipset is 330e (lsusb: "Bus 001 Device 002: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e") When I connect my card, i'll see this message: [...] [ 6102.988189] usb 1-1: new high speed USB device using ehci_hcd and address 3 [ 6103.130372] usb 1-1: New USB device found, idVendor=2304, idProduct=0226 [ 6103.130382] usb 1-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 6103.130389] usb 1-1: Product: PCTV 330e [ 6103.130394] usb 1-1: Manufacturer: Pinnacle Systems [ 6103.130399] usb 1-1: SerialNumber: 061101027954 [ 6103.130588] usb 1-1: configuration #1 chosen from 1 choice [ 6103.132620] em28xx: New device Pinnacle Systems PCTV 330e @ 480 Mbps (2304:0226, interface 0, class 0) [ 6103.133675] em28xx #0: chip ID is em2882/em2883 [ 6103.309411] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 26 02 d0 12 5c 03 8e 16 a4 1c [ 6103.309433] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [ 6103.309451] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b e0 00 00 [ 6103.309468] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 [ 6103.309484] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6103.309500] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6103.309516] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 [ 6103.309532] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 [ 6103.309549] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03 [ 6103.309565] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 33 00 33 00 30 00 [ 6103.309581] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 31 00 30 00 [ 6103.309597] em28xx #0: i2c eeprom b0: 31 00 30 00 32 00 37 00 39 00 35 00 34 00 00 00 [ 6103.309614] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6103.309629] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6103.309645] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6103.309661] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6103.309681] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb0b3aebf [ 6103.309686] em28xx #0: EEPROM info: [ 6103.309689] em28xx #0:AC97 audio (5 sample rates) [ 6103.309693] em28xx #0:500mA max power [ 6103.309698] em28xx #0:Table at 0x27, strings=0x168e, 0x1ca4, 0x246a [ 6103.311331] em28xx #0: Identified as Pinnacle Hybrid Pro (2) (card=56) [ 6103.311338] em28xx #0: [ 6103.311341] [ 6103.311346] em28xx #0: The support for this board weren't valid yet. [ 6103.311351] em28xx #0: Please send a report of having this working [ 6103.311355] em28xx #0: not to V4L mailing list (and/or to other addresses) [ 6103.311358] [ 6103.315206] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [ 6103.324057] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [ 6103.324234] xc2028 1-0061: creating new instance [ 6103.324241] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 6103.324254] usb 1-1: firmware: requesting xc3028-v27.fw [ 6103.334164] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 6103.381212] xc2028 1-0061: Loading firmware for type=BASE MTS (5), id . [ 6104.420147] xc2028 1-0061: Loading firmware for type=MTS (4), id b700. [ 6104.436024] xc2028 1-0061: Loading SCODE for type=MTS LCD NOGD MONO IF SCODE HAS_IF_4500 (6002b004), id b700. [ 6104.621338] em28xx #0: Config register raw data: 0xd0 [ 6104.622093] em28xx #0: AC97 vendor ID = 0x [ 6104.622425] em28xx #0: AC97 features = 0x6a90 [ 6104.622432] em28xx #0: Empia 202 AC97 audio processor detected [ 6104.750456] tvp5150 1-005c: tvp0050am1 detected. [ 6104.862343] em28xx #0: v4l2 driver version 0.1.2 [ 6104.954104] em28xx #0: V4L2 video device registered as /dev/video1 [ 6104.954112] em28xx #0: V4L2 VBI device registered as /dev/vbi0 [ 6104.954119] em28xx-audio.c: probing for em28x1 non standard usbaudio [ 6104.954123] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 6105.096806] tvp5150 1-005c: tvp5150am1 detected. [ 6105.386261] tvp5150 1-005c: tvp5150am1 detected. [...] Tests made: - Analog TV [Works] - Composite Acquisition [Works] - Analog Tune [Works] - Teletext [Not tested] - Sound Analog TV [I can't ear anything (but maybe it is a bug from my system and not your driver)] - Sound Analog Jack [I can't ear anything (but maybe it is a bug from my system and not from your driver)] - S-Video aquisition [Not tested] - DVB[DVB not yet implemented in em28xx driver] Tested-by: psykauze In source code of em28xx branch, we can see in "em28xx-cards.c" file in [EM2882_BOARD_PINNACLE_HYBRID_PRO] structure : [...] #if 0 /* FIXME: add an entry at
Re: IR Receiver on an Tevii S470
Hi, I have a s470 and with s2-liplianin-7212833be10d s2-liplianin-ab3a80e883ba began to work, but today I have tested s2-liplianin-b663b38d616f and seems that there are some problems trying to load the driver Linux video capture interface: v2.00 cx23885: disagrees about version of symbol ir_codes_hauppauge_new_table cx23885: Unknown symbol ir_codes_hauppauge_new_table cx23885: disagrees about version of symbol ir_input_init cx23885: Unknown symbol ir_input_init cx23885: disagrees about version of symbol ir_input_nokey cx23885: Unknown symbol ir_input_nokey cx23885: disagrees about version of symbol ir_input_keydown cx23885: Unknown symbol ir_input_keydown I'm running this on a DELL Server with RHEL and kernel 2.6.31. regards, Guillem -- 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
[PATCH] em28xx-dvb: fix memleak in dvb_fini()
Hi,
this patch fixes a memory leak which occurs when an em28xx card with DVB
extension is unplugged or its DVB extension driver is unloaded. In
dvb_fini(), dev->dvb must be freed before being set to NULL, as is done
in dvb_init() in case of error.
Note that this bug is also present in the latest stable kernel release.
Regards,
Francesco
Signed-off-by: Francesco Lavra
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c 2009-12-31
12:23:53.0 +0100
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c 2009-12-31
12:23:56.0 +0100
@@ -607,6 +607,7 @@ static int dvb_fini(struct em28xx *dev)
if (dev->dvb) {
unregister_dvb(dev->dvb);
+ kfree(dev->dvb);
dev->dvb = NULL;
}
--
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
[PATCH] move autoconf.h for 2.6.33
From: Márton Németh The linux/autoconf.h was moved to generated/autoconf.h as of 2.6.33. Signed-off-by: Márton Németh --- diff -r 62ee2b0f6556 v4l/scripts/make_config_compat.pl --- a/v4l/scripts/make_config_compat.pl Wed Dec 30 18:19:11 2009 +0100 +++ b/v4l/scripts/make_config_compat.pl Thu Dec 31 11:37:34 2009 +0100 @@ -383,9 +383,19 @@ # Do the basic rules open IN, "<$infile" or die "File not found: $infile"; -$out.= "#ifndef __CONFIG_COMPAT_H__\n"; -$out.= "#define __CONFIG_COMPAT_H__\n\n"; -$out.= "#include \n\n"; +$out .= <<'EOD' +#ifndef __CONFIG_COMPAT_H__ +#define __CONFIG_COMPAT_H__ + +#include +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 33) +#include +#else +#include +#endif + +EOD +; # mmdebug.h includes autoconf.h. So if this header exists, # then include it before our config is set. -- 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: Siano SMS1140 problem
Sorry for the delay in replying... A spiffy new year everyone for whom calendars and clocks and daylight and seasons have meaning, and also to the rest of you living in your mum's basement. On Tue, 29 Dec 2009, seba...@yahoo.it wrote: > I've already worked with different adapters (Pinnacle 320E with em28xx, > Intel CE9500B1, Hauppauge Nova-T Stick and SAA7134), and all have worked > without big problem reading the howto I've found online; but now I've a new > dvb-adapter, and it's a Siano SMS1140. I have a related, but different adapter, which until now I've just been using for DAB+ and DAB service reception, but I decided I'd check if there might be a regression in later kernels. Problem is I'm using a deliberately crippled machine, so that I don't trust all that I see. (Browser `lynx' tossing up kernel malloc failures I'd never seen before, for example) That aside, > - dmesg output: > usb 1-7: new high speed USB device using ehci_hcd and address 7 > usb 1-7: New USB device found, idVendor=187f, idProduct=0201 > usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-7: Product: MDTV Receiver > usb 1-7: Manufacturer: MDTV Receiver > usb 1-7: configuration #1 chosen from 1 choice > usb 1-7: firmware: requesting dvb_nova_12mhz_b0.inp > smscore_set_device_mode: firmware download success: dvb_nova_12mhz_b0.inp > usbcore: registered new interface driver smsusb What I see in my first failed attempt is [422523.242709] usb 3-2.2.1: firmware: requesting dvbt_bda_stellar_usb.inp [422523.329911] smsusb: probe of 3-2.2.1:1.1 failed with error -71 [422523.331556] usbcore: registered new interface driver smsusb Unfortunately, that prevents me from identifying at what point in the following sorta-successful attempt you would see the registration of the smsusb... And I am too lazy to unload those modules and try again :-) Here is what I see after a successful load of the firmware, that the device disconnects, reconnects with a different ID, and then runs into further problems: [422545.201374] usb 3-2.2.3: firmware: requesting dvbt_bda_stellar_usb.inp [422545.468215] usb 3-2.2.3: USB disconnect, address 26 [422547.750697] usb 3-2.2.3: new full speed USB device using uhci_hcd and address 27 [422547.883683] usb 3-2.2.3: New USB device found, idVendor=187f, idProduct=0100[422547.883826] usb 3-2.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [422547.883978] usb 3-2.2.3: Product: SMS DVBT-BDA Receiver [422547.884095] usb 3-2.2.3: Manufacturer: Siano Mobile Silicon [422547.886690] usb 3-2.2.3: configuration #1 chosen from 1 choice [422548.012889] smsusb_onresponse: line: 116: error, urb status -84, 0 bytes I am not sure if you should see the same thing (disconnect, reconnect with different ID from the firmware) with your particular device after firmware load. In any case, the kernel version I had used for DAB+ reception is several versions back, and the last time I attempted to use this device for DVB-T is even older than that (no problems then, but on different hardware, with a lot fewer USB hubs in the path to cause problems). I'd offer to see what I could do with the particular kernel source which gives me the above, except that I've already overwritten that source with newer. Anyway, I will see what I can do with my device with either the newest kernel, or the older stable one which I've patched into usefulness, sometime in the coming days or weeks, and report any successes or failures (plus differences to the Siano library that supports the Eureka-147 DAB decoding, should that also fail). > Someone can explain to me how to get it to work or where I miss something > ori, if it's due to some regression, how to debug it and support a programmer > for this? This isn't much, but in the absence of any other replies, it's the best I can offer. thanks, barry bouwmsa -- 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] Compro VideoMate U80 DVB-T USB 2.0 High Definition Digital TV Stick
drappa wrote: Hi All http://www.comprousa.com/en/product/u80/u80.html I'd be grateful if anyone can tell me if this device is supported yet, and if so, any pointers to getting it working. Thanks Drappa ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb In the absence of any feedback to my query, I had a look at the driver entry for this device in a Win7 system. It shows as: Videomate U1xx Digital Series The driver was written by Realtek and is version 5.55.828.2009 So, I guess there may be a number of devices in this series with the same chipset. Does this ring any bells with anyone? Thanks Drappa ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hi drappa, Things do seem quiet, so perhaps a couple of controversial remarks will liven it up. Several months ago I bought a USB dual DVB-T tuner (KWorld PlusTV) and was in a similar position to you, just a different model of stick. With Windows, the job would have been straightforward, as Windows has an architecture for adding new USB products. A couple of entries in the registry, a driver for the chipset, and you're away. With Linux, you've a choice of spending 35 hours trying to patch and recompile the kernel so that the new device is recognised, or if that sounds too onerous, wait 6 to 12 months until it's included in the standard kernel. While I recognise that I cannot legitimately complain, since Linux is a take-it-or-leave-it arrangement where if there's a problem, I should ideally volunteer to fix it myself, I still do think that it's bizarre that a recompile of the kernel is needed. I ask myself why it is not possible to have a database of devices (like the Windows registry) which can be easily updated. This would allow simple installation of new products which use chipsets identical to existing supported products. [The outcome with my tuner so far after a failed attempt at patching the kernel, I waited till 2.6.32 kernel was available, upon which the device was recognised, but still can only get one of the two tuners operating. This will likely be the subject of a separate forum thread in the near future.] Sorry I cannot shed light on your particular model of tuner. I will conclude by saying incidentally, that I have been a very satisifed user of mythTV (with multiple PCI tuners) for the last two and a bit years. dave -- 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
