On Fri, 2008-05-30 at 00:08 +0200, Yuri Warczynski (gmail) wrote:
> Hi Andy,
> >> >> I have this card (MPC718) on my Acer Aspire Idea 500.
> >> > We need to find out how the cards are wired up. Here's what you can do
> >> > to help get the analog side of the card working:
> >> >
> >> > 1. In cx18-cards.c find the cx18_card_mpc718 definition structure.
> >> >
> >> > 2. Change
> >> > .v4l2_capabilities = 0,
> >> > to
> >> > .v4l2_capabilities = CX18_CAP_ENCODER,
> >> >
> >> > 3. Start with the composite input (select using v4l2-ctl -i2). (If your
> >> > Acer box doesn't have a composite input, skip to step 4.)
> >> >
> >> > If the Composite 1 input does not work, find the line:
> >> >
> >> > { CX18_CARD_INPUT_COMPOSITE1, 1, CX23418_COMPOSITE3 }
> >> >
> >> > in video_inputs. Replace CX23418_COMPOSITE3 with CX23418_COMPOSITE1 and
> >> > rebuild, and reinstall the driver, and unload the old module and load
> >> > the new module. Then test again. Keep iterating with CX23418_COMPOSITE2
> >> > through CX23418_COMPOSITE8. One of these 8 possible inputs should work.
> >> >
> >>
> Indeed Brians advice helped. I've set vmalloc=256M.
> So now when I boot both cards get initialized. However when I try to
> re-initialize I get the following in dmesg:
> [ 2125.498239] cx18: Start initialization, version 1.0.0
> [ 2125.498305] cx18-0: Initializing card #0
> [ 2125.498309] cx18-0: Autodetected Yuan MPC718 card
> [ 2125.498337] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 20 (level,
> low) -> IRQ 21
> [ 2125.498615] cx18-0: cx23418 revision 01010000 (B)
> [ 2125.591934] cx18-0: Not yet supported!
> [ 2125.684322] cx18-0: Disabled encoder IDX device
> [ 2125.684396] cx18-0: Registered device video0 for encoder MPEG (2 MB)
> [ 2125.684431] cx18-0: Registered device video32 for encoder YUV (2 MB)
> [ 2125.684465] cx18-0: Registered device video24 for encoder PCM audio (1 MB)
> [ 2125.684498] cx18-0: Registered device radio0 for encoder radio
> [ 2125.691601] sysfs: duplicate filename '0000:02:00.0' can not be created
> [ 2125.691611] WARNING: at
> /build/buildd/linux-2.6.24/fs/sysfs/dir.c:424 sysfs_add_one()
> [ 2125.691618] Pid: 9580, comm: hald-probe-vide Not tainted 2.6.24-17-generic
> #1
> [ 2125.691654] [<c01d738f>] sysfs_add_one+0x9f/0xe0
> [ 2125.691690] [<c01d78c8>] create_dir+0x48/0x90
> [ 2125.691718] [<c01d7939>] sysfs_create_dir+0x29/0x50
> [ 2125.691730] [<c021536f>] kobject_get+0xf/0x20
> [ 2125.691741] [<c0215833>] kobject_add+0x93/0x1b0
> [ 2125.691754] [<c0215771>] kobject_set_name+0x81/0xb0
> [ 2125.691774] [<c02804a7>] device_add+0xa7/0x510
> [ 2125.691799] [<c0215509>] kobject_init+0x29/0x40
> [ 2125.691817] [<c02875a4>] _request_firmware+0x164/0x310
> [ 2125.691830] [<c031adc5>] schedule_timeout+0x45/0xd0
> [ 2125.691858] [<c02877ef>] request_firmware+0xf/0x20
> [ 2125.691870] [<f0c1774f>] cx18_firmware_init+0xbf/0x5e0 [cx18]
> [ 2125.691899] [<c0125c1e>] try_to_wake_up+0x4e/0x350
> [ 2125.691923] [<c01a7da3>] mntput_no_expire+0x13/0x70
> [ 2125.691936] [<c019bab5>] link_path_walk+0x65/0xc0
> [ 2125.691965] [<f0c1522b>] cx18_init_on_first_open+0x5b/0x1a0 [cx18]
> [ 2125.691993] [<c018fca2>] get_unused_fd_flags+0x52/0xd0
> [ 2125.692021] [<f0c19687>] cx18_v4l2_open+0x97/0x230 [cx18]
> [ 2125.692040] [<c021536f>] kobject_get+0xf/0x20
> [ 2125.692063] [<f0ad1397>] video_open+0x97/0x140 [videodev]
> [ 2125.692077] [<c0194350>] exact_match+0x0/0x10
> [ 2125.692092] [<f0ad1300>] video_open+0x0/0x140 [videodev]
> [ 2125.692104] [<c0194a33>] chrdev_open+0xa3/0x190
> [ 2125.692122] [<c018fdef>] __dentry_open+0xbf/0x1c0
> [ 2125.692138] [<c018ffa5>] nameidata_to_filp+0x35/0x40
> [ 2125.692148] [<c0194990>] chrdev_open+0x0/0x190
> [ 2125.692157] [<c0190000>] do_filp_open+0x50/0x60
> [ 2125.692195] [<c018fca2>] get_unused_fd_flags+0x52/0xd0
> [ 2125.692213] [<c019005c>] do_sys_open+0x4c/0xe0
> [ 2125.692232] [<c019012c>] sys_open+0x1c/0x20
> [ 2125.692240] [<c01043c2>] sysenter_past_esp+0x6b/0xa9
> [ 2125.692263] [<c0310000>] unix_dgram_recvmsg+0x110/0x2d0
> [ 2125.692284] =======================
> [ 2125.692292] kobject_add failed for 0000:02:00.0 with -EEXIST, don't
> try to register things with the same name in the same directory.
> [ 2125.692301] Pid: 9580, comm: hald-probe-vide Not tainted 2.6.24-17-generic
> #1
> [ 2125.692314] [<c02158b3>] kobject_add+0x113/0x1b0
> [ 2125.692326] [<c0215771>] kobject_set_name+0x81/0xb0
> [ 2125.692343] [<c02804a7>] device_add+0xa7/0x510
> [ 2125.692361] [<c0215509>] kobject_init+0x29/0x40
> [ 2125.692376] [<c02875a4>] _request_firmware+0x164/0x310
> [ 2125.692386] [<c031adc5>] schedule_timeout+0x45/0xd0
> [ 2125.692408] [<c02877ef>] request_firmware+0xf/0x20
> [ 2125.692418] [<f0c1774f>] cx18_firmware_init+0xbf/0x5e0 [cx18]
> [ 2125.692451] [<c0125c1e>] try_to_wake_up+0x4e/0x350
> [ 2125.692472] [<c01a7da3>] mntput_no_expire+0x13/0x70
> [ 2125.692483] [<c019bab5>] link_path_walk+0x65/0xc0
> [ 2125.692504] [<f0c1522b>] cx18_init_on_first_open+0x5b/0x1a0 [cx18]
> [ 2125.692529] [<c018fca2>] get_unused_fd_flags+0x52/0xd0
> [ 2125.692551] [<f0c19687>] cx18_v4l2_open+0x97/0x230 [cx18]
> [ 2125.692569] [<c021536f>] kobject_get+0xf/0x20
> [ 2125.692588] [<f0ad1397>] video_open+0x97/0x140 [videodev]
> [ 2125.692599] [<c0194350>] exact_match+0x0/0x10
> [ 2125.692613] [<f0ad1300>] video_open+0x0/0x140 [videodev]
> [ 2125.692624] [<c0194a33>] chrdev_open+0xa3/0x190
> [ 2125.692640] [<c018fdef>] __dentry_open+0xbf/0x1c0
> [ 2125.692655] [<c018ffa5>] nameidata_to_filp+0x35/0x40
> [ 2125.692663] [<c0194990>] chrdev_open+0x0/0x190
> [ 2125.692673] [<c0190000>] do_filp_open+0x50/0x60
> [ 2125.692706] [<c018fca2>] get_unused_fd_flags+0x52/0xd0
> [ 2125.692722] [<c019005c>] do_sys_open+0x4c/0xe0
> [ 2125.692739] [<c019012c>] sys_open+0x1c/0x20
> [ 2125.692747] [<c01043c2>] sysenter_past_esp+0x6b/0xa9
> [ 2125.692767] [<c0310000>] unix_dgram_recvmsg+0x110/0x2d0
> [ 2125.692785] =======================
This is a race condition in which two threads of control are calling
function which have the kernel try to build the same node under /sysfs.
Brian's dmesg showed this as well at times. With him it was moprobe at
fault, so I assumed something wrong in the kernel or something wrong in
the cx18 driver.
Here I see that "hald-probe-vide" triggered the problem. So I don't
know if on Ubuntu a modprobe triggers HALD to do something. This may be
an Ubuntu specific problem, that I'm not in a position to figure out.
The bad news is, it prevented the first MPC718 (cx18-0) from loading the
XCeive tuner firmware.
At least the rest of the firmware for card cx18-0 loaded on the second
try, so we can test everything but TV and radio on cx18-0.
> [ 2125.692789] fw_register_device: device_register failed
> [ 2125.692795] cx18-0: unable to open firmware v4l-cx23418-apu.fw
> (must be 141200 bytes)
> [ 2125.692799] cx18-0: did you put the firmware in the hotplug
> firmware directory?
> [ 2125.692804] cx18-0: Retry loading firmware
> [ 2125.733219] cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> [ 2125.733756] cx18-0: Initialized card #0: Yuan MPC718
> [ 2125.734013] cx18-1: Initializing card #1
> [ 2125.734021] cx18-1: Autodetected Yuan MPC718 card
> [ 2125.734069] ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 21 (level,
> low) -> IRQ 22
> [ 2125.734363] cx18-1: cx23418 revision 01010000 (B)
> [ 2125.786562] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
> (141200 bytes)
> [ 2125.845240] cx18-1: Not yet supported!
> [ 2125.871261] cx18-0: loaded v4l-cx23418-cpu.fw firmware (174716 bytes)
> [ 2125.876906] cx18-0: FW version: 0.0.71.0 (Release 2006/12/29)
> [ 2125.933325] tuner 3-0061: chip found @ 0xc2 (cx18 i2c driver #1-1)
> [ 2125.933839] cx18-1: Disabled encoder IDX device
> [ 2126.441729] cx18-1: Registered device video1 for encoder MPEG (2 MB)
> [ 2126.441770] cx18-1: Registered device video33 for encoder YUV (2 MB)
> [ 2126.441804] cx18-1: Registered device video25 for encoder PCM audio (1 MB)
> [ 2126.441837] cx18-1: Registered device radio1 for encoder radio
> [ 2126.441947] xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner
> [ 2126.481298] cx18-1: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> [ 2126.583482] cx18-1: loaded v4l-cx23418-apu.fw firmware V00120000
> (141200 bytes)
> [ 2126.668464] cx18-1: loaded v4l-cx23418-cpu.fw firmware (174716 bytes)
> [ 2126.674119] cx18-1: FW version: 0.0.71.0 (Release 2006/12/29)
> [ 2126.681970] xc2028 3-0061: Loading 80 firmware images from
> xc3028-v27.fw, type: xc2028 firmware, ver 2.7
> [ 2126.689090] xc2028 3-0061: Loading firmware for type=BASE FM (401),
> id 0000000000000000.
> [ 2126.698249] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2126.698285] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2126.698290] xc2028 3-0061: -14 returned from send
> [ 2126.698294] xc2028 3-0061: Error -22 while loading base firmware
> [ 2126.761972] xc2028 3-0061: Loading firmware for type=BASE FM (401),
> id 0000000000000000.
> [ 2126.771191] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2126.771228] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2126.771233] xc2028 3-0061: -14 returned from send
> [ 2126.771238] xc2028 3-0061: Error -22 while loading base firmware
> [ 2126.781941] xc2028 3-0061: Loading firmware for type=BASE (1), id
> 0000000000000000.
> [ 2126.791113] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2126.791146] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2126.791151] xc2028 3-0061: -14 returned from send
> [ 2126.791156] xc2028 3-0061: Error -22 while loading base firmware
> [ 2126.853825] xc2028 3-0061: Loading firmware for type=BASE (1), id
> 0000000000000000.
> [ 2126.862964] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2126.862996] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2126.863002] xc2028 3-0061: -14 returned from send
> [ 2126.863007] xc2028 3-0061: Error -22 while loading base firmware
> [ 2127.249224] xc2028 3-0061: Loading firmware for type=BASE (1), id
> 0000000000000000.
> [ 2127.25 i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2127.258415] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2127.258419] xc2028 3-0061: -14 returned from send
> [ 2127.258423] xc2028 3-0061: Error -22 while loading base firmware
> [ 2127.321158] xc2028 3-0061: Loading firmware for type=BASE (1), id
> 0000000000000000.
> [ 2127.330258] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2127.330291] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2127.330296] xc2028 3-0061: -14 returned from send
> [ 2127.330301] xc2028 3-0061: Error -22 while loading base firmware
> [ 2127.337091] xc2028 3-0061: Loading firmware for type=BASE (1), id
> 0000000000000000.
> [ 2127.346231] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2127.346262] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2127.346267] xc2028 3-0061: -14 returned from send
> [ 2127.346272] xc2028 3-0061: Error -22 while loading base firmware
> [ 2127.409049] xc2028 3-0061: Loading firmware for type=BASE (1), id
> 0000000000000000.
> [ 2127.418122] i2c-adapter i2c-3: sendbytes: error - bailout.
> [ 2127.418153] xc2028 3-0061: i2c output error: rc = -14 (should be 64)
> [ 2127.418158] xc2028 3-0061: -14 returned from send
> [ 2127.418164] xc2028 3-0061: Error -22 while loading base firmware
The firmware on the Xceive tuner on card cx18-1 couldn't be reloaded.
-14 ==> -EFAULT Bad address
-22 ==> -EINVAL Invalid argument
The Xceive tuner didn't properly respond on the I2C bus. This could be
because the tuner didn't get reset properly on reload, or you're
experiencing the i2c bus problems other users have. This will require a
look one we get the basics figured out.
> [ 2127.418171] cx18-1: Initialized card #1: Yuan MPC718
> [ 2127.418209] cx18: End initialization
>
> >> 2. The acer (which is a multimedia PC) provides 3 composite inputs two
> >> through a scart and one through the front pannel (the manual refers to
> >> these as AV1 , AV2 and AV3)
> >
> > OK, so:
> >
> > AV1 is wired to the COMPOSITE1 pin on the CX23418 on the first card
> > AV2 is wired to the COMPOSITE6 pin on the CX23418 on the first card
> >
> >
> Ok, here's what I have so far in cx18-cards.c
> { CX18_CARD_INPUT_SVIDEO1, 1,
> CX23418_SVIDEO_LUMA3|CX23418_SVIDEO_CHROMA4 },
> { CX18_CARD_INPUT_COMPOSITE1, 1, CX23418_COMPOSITE1 },
> { CX18_CARD_INPUT_COMPOSITE2, 2, CX23418_COMPOSITE6 },
> { CX18_CARD_INPUT_COMPOSITE3, 3, CX23418_COMPOSITE3 },
^
|
This points to audio_input entry 3 ------------+
but you only have 0-2 in the audio_input array
I find the second card having a composite input wired up to a different
chip pin very surprising. The Yuan MPC718 cards should be
interchangeable/identical. Perhaps they allow the OEM Acer, so options
for reconfiguration with jumpers or card connections.
Also CX23418_COMPOSITE3 and CX23418_SVIDEO_LUMA3 refer to the same
physical input pin on the CX23418. If you care for the details, see pin
In3 on page 3-1 and skim section 3-2 of this data sheet:
http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
>
> },
> .audio_inputs = {
> { CX18_CARD_INPUT_AUD_TUNER,
> CX23418_AUDIO8, 0 },
> { CX18_CARD_INPUT_LINE_IN1,
> CX23418_AUDIO_SERIAL, 0 },
> { CX18_CARD_INPUT_LINE_IN2,
> CX23418_AUDIO_SERIAL, 0 },
To stick with the convention in ivtv and cx18, we should order the
entries as
0. tuner video
1. svideo 1
2. composite 1
3. svideo 2
4. composite 2
5. composite 3
So if you could make it look something like this:
{ CX18_CARD_INPUT_VID_TUNER, 0, CX23418_COMPOSITE7
},
/* AV1/SCART1 */ { CX18_CARD_INPUT_SVIDEO1, 1,
CX23418_SVIDEO_LUMA3|CX23418_SVIDEO_CHROMA4 },
/* AV1/SCART1 */ { CX18_CARD_INPUT_COMPOSITE1, 1, CX23418_COMPOSITE1
},
/* AV2 */ { CX18_CARD_INPUT_SVIDEO2, 2,
CX23418_SVIDEO_LUMA#|CX23418_SVIDEO_CHROMA# },
/* AV2 */ { CX18_CARD_INPUT_COMPOSITE2, 2, CX23418_COMPOSITE6
},
/* AV3/SCART2 */ { CX18_CARD_INPUT_COMPOSITE3, 2, CX23418_COMPOSITE3
},
},
.audio_inputs = {
{ CX18_CARD_INPUT_AUD_TUNER, CX23418_AUDIO8, 0 },
{ CX18_CARD_INPUT_LINE_IN1, CX23418_AUDIO_SERIAL, 0 },
{ CX18_CARD_INPUT_LINE_IN2, CX23418_AUDIO_SERIAL, 0 },
I'd also like to point out that the SVideo 1 and Composite 1 definitions
look a lot like the definitions for the Yuan PG600 and Yuan MPC622 in
ivtv-cards.c. So if one needs a hint at what the proper tuner video and
audio input should be....
> This gives the following results:
> #------------------- AV1 ---------------------------
> #v4l2-ctl -d /dev/video0 -i2 <-- composite on AV1 (sound OK, video OK)
> #v4l2-ctl -d /dev/video0 -s pal-I
> #
> #v4l2-ctl -d /dev/video0 -i1 <-- SVIDEO on AV1 (video OK)
> #v4l2-ctl -d /dev/video0 -s pal-I
>
> #-------------------- AV2 ----------------------------
> #v4l2-ctl -d /dev/video0 -i3 <-- composite on AV2 (no sound, video OK)
> #v4l2-ctl -d /dev/video0 -s pal-I
>
> # I can not get SVIDEO neither on video0 nor on video1. I suspect that
> it should be on video1 since AV1 and AV3 SVIDEO is on video0
So if none of CX23418_SVIDEO_LUMA[1234] worked, then it must be one of
CX23418_SVIDEO_LUMA[45678] that the driver artificially restricts.
Looking at figure 3-1 of the CX28540 datasheet:
http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
All 8 Input lines go to the mux for CH1/ADC1. This is the channel that
must be used for luma, so any one of the 8 in lines will work for Luma.
Only CH2/ADC2 or CH3/ADC2 can be used to process Chroma, so only inputs
4 through 8 can be used for that. (The cx18 driver has that restriction
correct.)
So to figure out AV2 SVideo you'll need to add to cx18-cards.h:
CX23418_SVIDEO_LUMA5 = 0x50,
CX23418_SVIDEO_LUMA6 = 0x60,
CX23418_SVIDEO_LUMA7 = 0x70,
CX23418_SVIDEO_LUMA8 = 0x80,
and to cx18-av-core.h:
CX18_AV_SVIDEO_LUMA5 = 0x50,
CX18_AV_SVIDEO_LUMA6 = 0x60,
CX18_AV_SVIDEO_LUMA7 = 0x70,
CX18_AV_SVIDEO_LUMA8 = 0x80,
and in cx18-av-core.c:set_input(), fix the if statement: to
...
luma < CX18_AV_SVIDEO_LUMA1 ||
luma > CX18_AV_SVIDEO_LUMA8 ||
...
Now you should be able to experiment to find AV2's S-Video Luma.
> #--------------------- AV3 ----------------------------
> #v4l2-ctl -d /dev/video1 -i4 <-- composite on AV3 (sound OK, video OK)
> #v4l2-ctl -d /dev/video1 -s pal-I
> #
> #v4l2-ctl -d /dev/video0 -i1 <-- SVIDEO on AV3 (video OK)
> #v4l2-ctl -d /dev/video0 -s pal-I
^
|
Is this right for AV3? +
In other words, the wires for AV3 and AV1 SVideo input are connected
before they reach the CX2318 on card cx18-0 in your experience?
> So it looks like AV1 is card #0 , AV2 is card #0 +card #1, AV3 is card
> #1+card #0...
> As a side question:
> if I do mplayer /dev/video0 (or video1) sometimes I see these processes:
> #root 8910 1 0 21:18 ? 00:00:00 /usr/bin/dbus-daemon
> --fork --pr
> #root 8911 1 0 21:18 pts/1 00:00:00 dbus-launch
> --autolaunch 7941a67
> And until I kill them modprobe -r cx18 produces:
> # FATAL: Module cx18 is in use.
Argh. Ubuntu's taken it upon themselves to slightly integrate mplayer
with dbus for the sake of doing something with the screen saver (I
think).
You can always do a
$ cat /dev/video0 > foo.mpg
$ mplayer foo.mpg
to avoid some weird dbus fork for mplayer holding /dev/video0 open.
> > Thanks for your efforts. Have fun. ;)
> >
> hehe, thanks :)
>
> > Regards,
> > Andy
> >
> >
> >> > 4. Next try S-Video input (v4l2-ctl -i1): edit the line
> >> >
> >> > { CX18_CARD_INPUT_SVIDEO1, 1, CX23418_SVIDEO1},
> >> >
> >> > and replace CX23418_SVIDEO1 with CX23418_SVIDEO2 and rebuild and
> >> > reinstall the driver, and unload the old module and load the new module.
> >> > Then test again. Keep iterating with CX23418_SVIDEO2 through
> >> > CX23418_SVIDEO4, and hopefully one will work.
> >> >
> >> > If you get one to work, but it is only black and white, then the card
> >> > uses an uncommon combination of Luma and Chroma pins. Make a note of
> >> > which one gives you a black and white picture (that'll be the correct
> >> > Luma pin) and we'll walk through how to set the right Chroma pin. (The
> >> > end result will be something like
> >> > "CX23418_SVIDEO_LUMA1|CX23418_SVIDEO_CHROMA4", from the range of values
> >> > CX23418_SVIDEO_LUMA1-4 and CX23418_SVIDEO_CHROMA4-8.)
>
> All done, only problem remains with SVIDEO on AV2 (assumingly on card #1)
For that I suspect you'll have to look for SVIDEO Luma on input pins
5-8.
> >> > 5. Tuner: first get the firmware. See the file
> >> > linux/Documentation/video4linux/extract_xc3028.pl for instructions.
>
> Done. However dmesg result during re-initialization (see above) looks
> huge at the moment.. would be great if we can fix that before I go to
> step 6.
Well step 6 need not be done, if xceive firmware load looks good on
boot. Then we must already have the right pin.
To help debug problems on reload you may want to
# modprobe cx18 debug=67
You only get the problem on module reload, right?
> >> > 6. Now modprobe cx18. Then run modprobe -r cx18 and modprobe cx18 again.
> >> > If
> >> > you get errors in the kernel log regarding the xceive tuner, then you
> >> > need to change the xceive_pin setting in the card definition.
> >> > It should be in the range 8-15. Try 15 first.
> >> >
> >> >
> >> > 7. Once the tuner firmware appears to be loading, We need to find
> >> > the correct composite input for the tuner by editing the line:
> >> >
> >> > { CX18_CARD_INPUT_VID_TUNER, 0, CX23418_COMPOSITE7 },
> >> >
> >> > Again, it can be any value from CX23418_COMPOSITE1-8. Rebuild,
> >> > reinstall, unload, and reload and test.
Maybe the Tuner definition matches the MPC622 or PG600 in ivtv-cards.c,
so perhaps you can save some iterations.
> >> >
> >> > 8. To get audio from the tuner, you may need to change:
> >> >
> >> > { CX18_CARD_INPUT_AUD_TUNER, CX23418_AUDIO5, 0 },
> >> >
> >> > Possible values: CX23418_AUDIO4-8 or CX23418_AUDIO_SERIAL. Rebuild,
> >> > reinstall, unload, and reload and test.
> >> >
> >> > If none of those work, we may need to start experimenting with GPIO
> >> > pins.
Again, maybe the Tuner definition matches the MPC622 or PG600 in
ivtv-cards.c, so perhaps you can save some iterations.
Regards,
Andy
> >> >
> >> >
> >> > 9. For line in audio, you can try changing:
> >> >
> >> > { CX18_CARD_INPUT_LINE_IN1, CX23418_AUDIO_SERIAL, 0 }
> >> >
> >> > to CX23418_AUDIO4-8 if it doesn't already work. (I'm not expecting that
> >> > to work though).
> >>
> >> I did have audio wile testing composite on AV1.
> >>
> >> > If you have no line in audio after that, we may need to start
> >> > experimenting with GPIO pins.
> >> >
> >> >
> >> > Let Hans or I know how it goes. Especially for audio, we're having some
> >> > issues with the Hauppauge cards and mono/stereo audio, and Brian Hope on
> >> > the ivtv-users list has already indicated he currently gets no audio
> >> > with his MPC718 (He's working through similar steps.)
> >> >
> >> Seems I do not have a problem with line in audio on AV1, however I did
> >> not check mono/stereo functionality.
> >>
> >>
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
