Re: [ivtv-devel] RE: ivtv releases timetable
On Friday 07 October 2005 01:16, Leonard Orb wrote: Hans Verkuil wrote: This usage is all over the place in the kernel and in fact also in the video4linux repository. So I am hesitant to add workarounds for what is by now a really old compiler. It is impossible to upgrade to a newer compiler? Once we start using the tuner module etc. from the video4linux repository you will need a new compiler anyway since that won't compile with gcc-2.95 (for pretty much the same reason probably). Gcc 2.95 will compile kernels up to 2.6.12.6 and probably also newer ones without problems, because no one there does #define M(format, args...) This certainly happens in 2.6.13. See e.g. drivers/scsi/ch.c. So this would mean that a gcc-2.95 can no longer compile the scsi subsystem. And this is certainly not the only place where this construct is used. Hans And yes, it is not easy to upgrade the compiler with Debian Woody and yes, there are reasons not to do it even if you are willing to, e.g. because it can cause very nasty errors if you have some modules of some sources compiled with 2.95, change some sources or some config and then compile some modules with gcc 3.x. Woody's qpopper, fetchmail, innd and other packets are really old ones, mplayer is not included and so on, so it is likely that users of Woody have had to compile some stuff theirselves and after a compiler upgrade they would have to do all this again or think about the gcc version mix-up in case of changes. It is living hell. All this can be as complex as upgrading to Sarge. If someone wants more elaborate instructions for an upgrade from Woody to Sarge than that on the Debian site: mail me. Sarge comes with gcc 3.3.5. ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] WinTV PVR-150 -- Cant change channel
On Friday 07 October 2005 05:52, Ross wrote: On 10/7/05, Edward Martin [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~$ /sbin/modinfo tuner filename: /lib/modules/2.6.13.3/kernel/drivers/media/video/tuner.ko Yep, there's your problem. Rename that file to tuner.ko.old, then rerun depmod -a And the same is true for tveeprom.ko. Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] 350 Cpu usage for Xv playback reduced a lot - may help video/audio sync
I have just submitted a patch for the YUV playback code which significantly reduces the cpu used during playback using the Xv code. Now the CPU usage for X has dropped from about 30-35% to about 0.5 2%. So I can now play back stuff with mplayer burning ~13%cpu and I have between 80 85% idle. Mplayer drops much fewer frames now (1 or 2 at start up) and the audio video should be more in sync than in the past. I have now finished all the planned changes for the Xv/yuv code before 0.4 is branched other than fixing issues that anyone finds with the last few changes. Thanks John ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] 350 Cpu usage for Xv playback reduced a lot - may help video/audio sync
Hey John, it still works :-) When playing back a recorded mpg over Xv, I get +- 20% usage for mythfrontend, and 7% usage for X. This is on an athlon 2000xp. I've just started playback of a multihour recording. Untill now a/v sync usually drifts off so that I had to rewind every 10 minutes orso. I'll go back in a few hours to see if the a/v sync is still ok. Thanks for all the Xv work, it's really the thing that made my mediabox come together. Bye, Lucas I have just submitted a patch for the YUV playback code which significantly reduces the cpu used during playback using the Xv code. Now the CPU usage for X has dropped from about 30-35% to about 0.5 – 2%. So I can now play back stuff with mplayer burning ~13%cpu and I have between 80 85% idle. Mplayer drops much fewer frames now (1 or 2 at start up) and the audio video should be more in sync than in the past. I have now finished all the planned changes for the Xv/yuv code before 0.4 is branched other than fixing issues that anyone finds with the last few changes. Thanks John ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] RE: ivtv releases timetable
Just tried with 2.95.3 on a sun machine at work and
get parse error before `)'
adding ,1 removed the error.
John
--- Hans Verkuil [EMAIL PROTECTED] wrote:
Gcc 2.95 will compile kernels up to 2.6.12.6 and
probably also newer
ones
without problems, because no one there does
#define M(format, args...)
and then uses M(str) without args.
I compiled Kernel 2.6.13.2 and some extern drivers
without any problems!
Only ivtv failed to compile.
I wonder if we're not having some other problem. The
oldest compiler I
have available to me is 2.96 and this construct
compiles without problem
there. I couldn't compile the driver itself (it's a
chroot environment) so
I just tried this:
#include stdio.h
#define WM8775_DEBUG(fmt, arg...) \
do { \
printf(%s debug %d-%04x:
fmt, hello, \
1, 2, ## arg); \
} while (0)
void test(void)
{
WM8775_DEBUG(test\n);
}
(I hope this isn't reformatted)
Can you try this with the Debian compiler?
Hans
___
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
___
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] 350 Cpu usage for Xv playback reduced a lot - may help video/audio sync
Lucas Meijer wrote: I've just started playback of a multihour recording. Untill now a/v sync usually drifts off so that I had to rewind every 10 minutes orso. I'll go back in a few hours to see if the a/v sync is still ok. Checked the playback after an hour. Normally a/v would have drifted terribly by now. With your new patch in svn I still have perfect a/v sync. Woohoo. Lucas ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] RE: ivtv releases timetable
Hans Verkuil wrote:
But there's indeed no such problem with the kernel sources although the
kernel people have defines of the same style and use it the same way.
Yes, how is that possible? Can you try to compile 2.6.14-rc3, and
especially the tuner*.c sources in drivers/media/video that definitely use
the same construct.
Google to the rescue: this works:
#define WM8775_DEBUG(fmt, arg...) \
do { \
printf(%s debug %d-%04x: fmt, hello, \
1, 2 , ## arg); \
} while (0)
Note the extra space in '2 ,'
Hans
___
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Video-Frequencies-0.03.tar.gz
Hi I've now got it working: ivtv-tune --device=/dev/video0 --freqtable=europe-west -c40 I was previously not selecting either a device or channel, because I was expecting an X frontend, similar to ptune-ui.pl. I can see the advantages of not having to download and compile the perl modules. The program is a nice replacement for ptune.pl. However since there currently does not appear to be a replacement for ptune-ui.pl, perhaps the perl modules should be either available on the website or included in the distribution. Best Regards Trev Hi again Further to may last message, I thought that it may be worthwhile adding to the help text an example of setting a frequency or channel. It may have just been that I was used to using ptune-ui.pl and was expecting something that the program is not and other users will not experience the same problem. Best Regards Trev ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] 350 Cpu usage for Xv playback reduced a lot - may help video/audio sync
On Friday 07 Oct 2005 14:07, Rutger Hendriks wrote: snip I can confirm this works really nice. Last week has been very good. I started with 60-70% CPU usage for Xorg with CPU running at 2GHz. Now CPU usage has dropped to 1% for Xorg and the CPU is only running at 800MHz (powernow)! Very nice indeed! This is all with mplayer -vo xv -fs. The only 'problem' with this command is that a not unsignificant portion of the picture falls off the screen due to the overscan of the PVR350 or the TV. I can solve this by doing some mplayer magic and use this command to play video: mplayer -vo xv -vf scale=660:-3,expand=760:576:64:50 Unfortunately when I do that, I have around 20% CPU usage for Xorg with CPU running at 2GHz again. For me this is a trade off I will not make, so I'm using mplayer -vo xv -fs again. Is that a typo for the expand setting ? 760 is too wide for the 350 to handle in hardware alone. That could explain the high CPU usage. Related to this issue I have 2 questions: - Will it be possible to 'fix' this so that mplayer -vo xv -fs will display the full picture on the TV and still use only a few percent CPU usage? I know every TV is different, so if at all possible this would probably involve passing 4 arguments to maybe ivtv-fb or xdriver or ... This should be possible at some point. The video size is limited to the size of the X screen. Depending on how it's done, when the xdriver is changed to allow sizing positioning to reduce the overscan of X itself, the maximum size of the video will be reduced as well. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] 350 Cpu usage for Xv playback reduced a lot - may help video/audio sync
On Friday 07 October 2005 17:58, Ian Armstrong wrote: On Friday 07 Oct 2005 14:07, Rutger Hendriks wrote: snip I can solve this by doing some mplayer magic and use this command to play video: mplayer -vo xv -vf scale=660:-3,expand=760:576:64:50 Unfortunately when I do that, I have around 20% CPU usage for Xorg with CPU running at 2GHz again. Is that a typo for the expand setting ? 760 is too wide for the 350 to handle in hardware alone. That could explain the high CPU usage. Point taken, I will check if 720 improves stuff CPU usage wise. Only, I found that when I used anything under 760 there was still some part visible of the Myth background at the edges of my TV screen. But since, as I said, the scale and expand numbers are not accurate at this moment, I will simply start over again with expand=720:576 and see where I end now. As a side note, if I remember correctly, expand=760 was as high as I could go... anything above 760 gave a green screen I think. Greetings Rutger pgpYkaGaKjP6p.pgp Description: PGP signature ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] PVR350 TV-Out, can't xinit (ivtv 0.3.8)
Anyone have any idea? The basic error message, when I run "xinit -- :1 -layout "Hauppauge" " is this: (EE) ivtvHWProvbe failed to do IVTVFB_IOCTL_GET_STATE for device (null) I've given more detail info here: http://forums.gentoo.org/viewtopic-t-388868.html running "modprobe saa7127 test_image=1" works just fine. I also see this error in dmesg, near the bottom: ivtv: Tried to open YUV output device but need to send data to mpeg decoder before it can be used ivtv-osd warning: ERROR: Direct writing is not safe for ivtv usage -dave ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] Re: oddity with ivtv mplayer
On Thu, Oct 06, 2005 at 18:49:45, D. Hugh Redelmeier said... It does not make a difference when I run mplayer as root (allowing better realtime scheduling). chown 666 /dev/rtc - this should allow mplayer to use the realtime clock directly, as any user, and schedule better. Not your issue, just a comment. -- Michael All I want out of the Universe is 10 minutes with the source code and a quick recompile. - unknown ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] Re: Re: oddity with ivtv mplayer
On Fri, Oct 07, 2005 at 14:03:35, Jason Tackaberry said... On Fri, 2005-10-07 at 13:44 -0400, Michael wrote: chown 666 /dev/rtc - this should allow mplayer to use the realtime clock directly, as any user, and schedule better. Read-only permission is sufficient. (Use 0644.) *doh* Of course, what was I thinking... -- Michael Were we ever colder on that day, a million miles away It seemed from all of eternity ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] ivtv should now be gcc-2.95-ready.
I've added the fix and you should now be able to compile ivtv with gcc-2.95. Please check! Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] PVR150 PVR350 - dmesg errors - 0.3.9 revision 2757M and before (at least back to 3.8) - full function -
I'm running a PVR350 and a PVR150 in a combined mythtv frontend/backend running mythtv release-0-18-fixes r7227 on FC3. Everything is working well (now) except for the occasional and sudden loss of avsync in recordings from the 150. I'd like to understand the errors in my dmesg output and wonder if they may point to the cause of the av sync issues. The dmesg output is attached below. From what I can see there are really two issues. 1) symbol errors when lirc_i2c loads. I can make this stop if I stop bttv and cx88xx from loading. If I add alias bttv none alias cx88xx none to modprobe.conf the errors go away. This solution works for me as I don't believe I need bttv or cx88xx for my current setup. Where the errors are comming from and why these modules get dragged in when lirc_i2c loads I don't understand. 2) cx25840: invalid ioctl No clue here. Chased firmware for a while but both of the following behave the same. ls: -rw-r--r-- 1 root root 13883 Oct 5 2004 HcwMakoA.ROM.1 md5sum: a6f6a90a3be338cdb89d59e835798408 HcwMakoA.ROM.1 ls: -rw-r--r-- 1 root root 14264 Jan 7 2005 HcwMakoA.ROM.2 md5sum: 3a4803384f749d644ee1f1ca9dcb12fa HcwMakoA.ROM.2 Thoughts? Mark Schindel. ivtv: START INIT IVTV ivtv: version 0.3.9 (development svn snapshot revision 2757M) loading ivtv: Linux version: 2.6.12-1.1378_FC3 686 REGPARM 4KSTACKS gcc-3.4 ivtv: In case of problems please include the debug info ivtv: between the START INIT IVTV and END INIT IVTV lines when ivtv: mailing the ivtv-devel mailinglist. ivtv: Autodetected WinTV PVR 350 card (iTVC15 based) PCI: Found IRQ 12 for device :00:09.0 PCI: Sharing IRQ 12 with :00:04.2 PCI: Sharing IRQ 12 with :00:0d.0 tveeprom: ivtv version tveeprom: Hauppauge: model = 48132, rev = K268, serial# = 7614492 tveeprom: tuner = LG TAPE H001F MK3 (idx = 68, type = 47) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio processor = MSP4448 (type = 1b) tveeprom: decoder processor = SAA7115 (type = 13) ivtv: i2c attach to card #0 ok [client=tveeprom[50], addr=50] tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0 ivtv: i2c attach to card #0 ok [client=(tuner unset), addr=61] ivtv: i2c attach to card #0 ok [client=saa7115[50], addr=21] saa7127 1-0044: saa7129 found @ 0x88 (ivtv i2c driver #0) ivtv: i2c attach to card #0 ok [client=saa7127, addr=44] msp34xx: ivtv version msp34xx: init: chip=MSP3448W-A2, has NICAM support, simple (D) mode, simpler (G) no-thread mode msp34xx: $Id$ compiled on: Sep 29 2005 10:58:39 ivtv: i2c attach to card #0 ok [client=MSP3448W-A2, addr=40] tda9885/6/7: (ivtv) chip found @ 0x86 ivtv: i2c attach to card #0 ok [client=tda9887, addr=43] ivtv: loading /lib/modules/ivtv-fw-enc.bin ivtv: loading /lib/modules/ivtv-fw-dec.bin ivtv: Encoder revision: 0x02050032 ivtv: Decoder revision: 0x02020023 ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total) ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total) ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total) ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total) ivtv: Create encoder radio stream ivtv: Allocate DMA decoder MPEG stream: 16 x 65536 buffers (1024KB total) ivtv: Allocate DMA decoder VBI stream: 512 x 2048 buffers (1024KB total) ivtv: Create decoder VOUT stream ivtv: Allocate DMA decoder YUV stream: 24 x 43200 buffers (1024KB total) ivtv: loading /lib/modules/ivtv_init_mpeg.bin tuner: type set to 47 (LG NTSC (TAPE series)) by ivtv i2c driver #0 ivtv: Initialized WinTV PVR 350, card #0 ivtv: == NEXT CARD == ivtv: Autodetected WinTV PVR 150 card (iTVC16 based) PCI: Found IRQ 11 for device :00:0c.0 tveeprom: ivtv version tveeprom: Hauppauge: model = 26552, rev = C268, serial# = 8402130 tveeprom: tuner = LG TAPE H001F MK3 (idx = 68, type = 47) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio processor = CX25843 (type = 25) tveeprom: decoder processor = CX25843 (type = 1e) ivtv: i2c attach to card #1 ok [client=tveeprom[50], addr=50] tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #1 ivtv: i2c attach to card #1 ok [client=(tuner unset), addr=61] tda9885/6/7: (ivtv) chip found @ 0x86 ivtv: i2c attach to card #1 ok [client=tda9887, addr=43] cx25840: loading /lib/modules/HcwMakoA.ROM ivtv: i2c attach to card #1 ok [client=cx25840, addr=44] ivtv: i2c attach to card #1 ok [client=wm8775, addr=1b] cx25840: invalid ioctl 400464C9 ivtv: loading /lib/modules/ivtv-fw-enc.bin ivtv: Encoder revision: 0x02050032 ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total) ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total) ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total) ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total) ivtv: Create encoder
[ivtv-devel] SOUND: no more silent tuners?
This is a final call before closing tickets #20 and #21 (no sound on one or more tuners). Is there anyone who has no sound whatsoever? Some people still have the problem that there is no sound on some channels, or that the sound kicks in after 10-30 seconds. I've created ticket #33 for that, but that propably won't be fixed until after 0.4.0 is released. Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
[ivtv-devel] Black White Picture on Yuan MPC622 with 0.3.9-2755svn
Hi folks, I haven't been keeping up with the mailing list for a while, and I come back and there's been s much progress! Way to go folks! I'm using a Yuan MPC622 (http://www.yuan.com.tw/en/products/vdo_mpc622.html) on a 2.4.31 kernel. I think this is very similar to the PG600, but with a different tuner. (I'm not using the tuner BTW, just composite or s-video input). Here's the issue: When using 'insmod ivtv cardtype=7; insmod cx25840' I get sound and video, but the video is only black and white. When using 'insmod ivtv; insmod cx25840', it's autodetected as a PVR-250 and I get a full color picture, but no sound. cardtype=7 seems to give me the best overall results (I get sound, and the inputs are more correct than with other card types), but I can't figure out why I'm only getting black white. Any thoughts? Thanks! Justin ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed radio support
On Thu, Sep 29, 2005, Hans Verkuil wrote: I'm surprised you do not have a PORT1 problem since we are supposed to have identical cards. Could Hauppauge ship slightly different cards with the same revision ID in different countries ? I have also had a look at the tda9887 datasheet, from what I understand PORT1 can be used for SAW switching or external AGC input. Maybe Hauppauge wired it to some component which fucks up everything. I haven't had the courage yet to remove the tuner cover and try to find what the chip is connected to. I'm still mystified by this chip to be honest. Me too. I have retried the latest SVN, and my PORT1 fix is no longer needed. Indeed the latest SVN works perfectly. I'm puzzled. -- Christophe Massiot Freebox S.A. ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Black White Picture on Yuan MPC622 with 0.3.9-2755svn
On Friday 07 October 2005 21:08, Justin I. Nevill wrote: Hi folks, I haven't been keeping up with the mailing list for a while, and I come back and there's been s much progress! Way to go folks! I'm using a Yuan MPC622 (http://www.yuan.com.tw/en/products/vdo_mpc622.html) on a 2.4.31 kernel. I think this is very similar to the PG600, but with a different tuner. (I'm not using the tuner BTW, just composite or s-video input). Here's the issue: When using 'insmod ivtv cardtype=7; insmod cx25840' I get sound and video, but the video is only black and white. When using 'insmod ivtv; insmod cx25840', it's autodetected as a PVR-250 and I get a full color picture, but no sound. cardtype=7 seems to give me the best overall results (I get sound, and the inputs are more correct than with other card types), but I can't figure out why I'm only getting black white. What happens if you choose cardtype 6? Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] /dev/video0 doesn't return anything in radio mode
On Friday 07 October 2005 21:31, Christophe Massiot wrote: On Wed, Sep 28, 2005, Christophe Massiot wrote: I have a machine where /dev/video0 becomes empty when I start ivtv-radio. It is clearly machine-specific because the same card with the same kernel and driver in another machine doesn't produce the problem. Here are the logs with ivtv_debug=0x1f, the last lines seem pretty related, but I don't know the driver enough to find the problem. It looks as though the MPEG encoder stopped working in radio mode. I have always had the problem on this machine with several kernel versions (including 2.4.31) and versions of ivtv as far back as 0.3.6z (the first with radio support). I have also tried ivtv_dynbuf=1 which didn't make a difference. At first I noticed that the PCI card was sharing the IRQ with the Ethernet chip so I moved the card so that it gets IRQ 5 for itself, but it wasn't that. I have retried with the latest SVN, and the behaviour has changed. When I switch to radio mode, every time I cat /dev/video0 /tmp/toto, it creates a /tmp/toto file of exactly 12224 bytes. It contains a pack header, a system header and the first I frame. It stops after that. Do you have any idea which changeset might have changed this behaviour ? This may be a hint as to where I must look. Thanks, Possible candidates: 2745, 2721. If it is the latter, then I'd advise testing encoder firmware 0x02040011 and 0x02050032 to see if there's any difference between them. Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
On Friday 07 Oct 2005 20:25, Hans Verkuil wrote: On Friday 07 October 2005 21:12, Hans Verkuil wrote: This is a final call before closing tickets #20 and #21 (no sound on one or more tuners). Is there anyone who has no sound whatsoever? That's tickets #21 and #22. Sorry. Hans Hi Hans This is sound related. It is currently not at all straight forward to switch audio source on the Adaptec AVC-2410. Would it be possible to apply Ticket #30 before 0.4.0 is released. I believe this would provide more or less complete the ivtv support of the Adaptec AVC-2410. I made the patches against 2754, but there don't appear to have been any changes to the relevant files since then. Best Regards Trev ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Video-Frequencies-0.03.tar.gz
On Fri, Oct 07, 2005 at 11:05:15AM -0400, Tommy Persson wrote: Yes, please do. I was suprised that record-v4l.pl was moved to obsolete since I could not find any other utilities that could be used in a convenient way to do for example: record-v4l2 -P 4 --no-record record-v4l2 -P comp --no-record record-v4l2 -P comp -P SVCD Good point- that is nice, and beyond the scope of what ivtv-tune is supposed to do. I'll move all those perl programs out of 'obsolete' and into a 'perl' directory. Maybe ptune-ui can be modified to call ivtv-tune, I'll try to look into that. -- Tyler Trafford ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Black White Picture on Yuan MPC622 with 0.3.9-2755svn
I get sound and black and white video - same as with cardtype=7. I did a cold boot after changing /etc/modules to cardtype=6. Thanks! Justin - Original message - From: Hans Verkuil [EMAIL PROTECTED] To: Discussion list for development of the IVTV driver ivtv-devel@ivtvdriver.org Date: Fri, 7 Oct 2005 21:26:45 +0200 Subject: Re: [ivtv-devel] Black White Picture on Yuan MPC622 with 0.3.9-2755svn On Friday 07 October 2005 21:08, Justin I. Nevill wrote: Hi folks, I haven't been keeping up with the mailing list for a while, and I come back and there's been s much progress! Way to go folks! I'm using a Yuan MPC622 (http://www.yuan.com.tw/en/products/vdo_mpc622.html) on a 2.4.31 kernel. I think this is very similar to the PG600, but with a different tuner. (I'm not using the tuner BTW, just composite or s-video input). Here's the issue: When using 'insmod ivtv cardtype=7; insmod cx25840' I get sound and video, but the video is only black and white. When using 'insmod ivtv; insmod cx25840', it's autodetected as a PVR-250 and I get a full color picture, but no sound. cardtype=7 seems to give me the best overall results (I get sound, and the inputs are more correct than with other card types), but I can't figure out why I'm only getting black white. What happens if you choose cardtype 6? Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Switching Audio on Adaptec AVC-2410
On Friday 07 Oct 2005 21:07, Hans Verkuil wrote: On Friday 07 October 2005 18:00, Trev Jackson wrote: Hi I've created a patch and submitted it as ticket #30 on the trac system. The patch allows audio to be switched between the tuner and the line-in using: ivtvctl -q0 and ivtvctl -q1 Is this similar to how audio is switched on other ivtv cards or do I need to do any other changes? I've committed the patch. I think this is OK. Does it also work well with the ivtvctl -p option? Hans Hi Hans Yes thanks ivtvctl -p4 switches to the tuner and ivtvctl -p3 switches to composite input. I think we can now say that there is not much more that can be done to make ivtv compatible with the Adaptec AVC-2410 and the Adaptec AVC-2010. I now use the following to load the driver: modprobe tuner ignore=0,0x6b modprobe ivtv ivtv_std=2 tuner=38 tda9887=0 modprobe lirc_i2c lircd -d /dev/lirc0 --permission=666 The only improvement possible is to avoid having to make the tuner ignore address 0x6b on the command line, but that is a very minor inconvenience. I'll update the wiki. Thanks Trev ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Switching Audio on Adaptec AVC-2410
On Friday 07 October 2005 22:50, Trev Jackson wrote: I think we can now say that there is not much more that can be done to make ivtv compatible with the Adaptec AVC-2410 and the Adaptec AVC-2010. I now use the following to load the driver: modprobe tuner ignore=0,0x6b modprobe ivtv ivtv_std=2 tuner=38 tda9887=0 modprobe lirc_i2c lircd -d /dev/lirc0 --permission=666 I don't think the tda9887=0 option is needed. The only improvement possible is to avoid having to make the tuner ignore address 0x6b on the command line, but that is a very minor inconvenience. I've asked and it is currently not possible. As I understand it it is a design flaw in the I2C or V4L2 system. Does the AVC-2410 have any eeprom? If you run 'i2cdetect -l', and then run 'i2cdetect -a i2cbus' for the ivtv i2c bus, what do you get? If you see a number, then that might be the I2C address of the eeprom. With luck the tuner is encoded in the eeprom. (i2cdetect is part of the lm-sensors package, BTW) Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] PVR150 PVR350 - dmesg errors - 0.3.9 revision 2757M and before (at least back to 3.8) - full function -
Both are due to using the ivtv tveeprom instead of the kernel / v4l tveeprom. On my system, if I don't let the cx88xx module get pulled in my remote doesn't work (pvr-350), so I use the kernel tveeprom. I rename the bttv module just like I do the kernel msp3400 and tuner modules so it doesn't get pulled in, even though it doesn't have any negative effects. On 10/7/05, Mark Schindel [EMAIL PROTECTED] wrote: I'm running a PVR350 and a PVR150 in a combined mythtv frontend/backend running mythtv release-0-18-fixes r7227 on FC3. Everything is working well (now) except for the occasional and sudden loss of avsync in recordings from the 150. I'd like to understand the errors in my dmesg output and wonder if they may point to the cause of the av sync issues. The dmesg output is attached below. From what I can see there are really two issues. 1) symbol errors when lirc_i2c loads. I can make this stop if I stop bttv and cx88xx from loading. If I add alias bttv none alias cx88xx none to modprobe.conf the errors go away. This solution works for me as I don't believe I need bttv or cx88xx for my current setup. Where the errors are comming from and why these modules get dragged in when lirc_i2c loads I don't understand. 2) cx25840: invalid ioctl No clue here. Chased firmware for a while but both of the following behave the same. ls: -rw-r--r-- 1 root root 13883 Oct 5 2004 HcwMakoA.ROM.1 md5sum: a6f6a90a3be338cdb89d59e835798408 HcwMakoA.ROM.1 ls: -rw-r--r-- 1 root root 14264 Jan 7 2005 HcwMakoA.ROM.2 md5sum: 3a4803384f749d644ee1f1ca9dcb12fa HcwMakoA.ROM.2 Thoughts? Mark Schindel. ivtv: START INIT IVTV ivtv: version 0.3.9 (development svn snapshot revision 2757M) loading ivtv: Linux version: 2.6.12-1.1378_FC3 686 REGPARM 4KSTACKS gcc-3.4 ivtv: In case of problems please include the debug info ivtv: between the START INIT IVTV and END INIT IVTV lines when ivtv: mailing the ivtv-devel mailinglist. ivtv: Autodetected WinTV PVR 350 card (iTVC15 based) PCI: Found IRQ 12 for device :00:09.0 PCI: Sharing IRQ 12 with :00:04.2 PCI: Sharing IRQ 12 with :00:0d.0 tveeprom: ivtv version tveeprom: Hauppauge: model = 48132, rev = K268, serial# = 7614492 tveeprom: tuner = LG TAPE H001F MK3 (idx = 68, type = 47) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio processor = MSP4448 (type = 1b) tveeprom: decoder processor = SAA7115 (type = 13) ivtv: i2c attach to card #0 ok [client=tveeprom[50], addr=50] tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0 ivtv: i2c attach to card #0 ok [client=(tuner unset), addr=61] ivtv: i2c attach to card #0 ok [client=saa7115[50], addr=21] saa7127 1-0044: saa7129 found @ 0x88 (ivtv i2c driver #0) ivtv: i2c attach to card #0 ok [client=saa7127, addr=44] msp34xx: ivtv version msp34xx: init: chip=MSP3448W-A2, has NICAM support, simple (D) mode, simpler (G) no-thread mode msp34xx: $Id$ compiled on: Sep 29 2005 10:58:39 ivtv: i2c attach to card #0 ok [client=MSP3448W-A2, addr=40] tda9885/6/7: (ivtv) chip found @ 0x86 ivtv: i2c attach to card #0 ok [client=tda9887, addr=43] ivtv: loading /lib/modules/ivtv-fw-enc.bin ivtv: loading /lib/modules/ivtv-fw-dec.bin ivtv: Encoder revision: 0x02050032 ivtv: Decoder revision: 0x02020023 ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total) ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total) ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total) ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total) ivtv: Create encoder radio stream ivtv: Allocate DMA decoder MPEG stream: 16 x 65536 buffers (1024KB total) ivtv: Allocate DMA decoder VBI stream: 512 x 2048 buffers (1024KB total) ivtv: Create decoder VOUT stream ivtv: Allocate DMA decoder YUV stream: 24 x 43200 buffers (1024KB total) ivtv: loading /lib/modules/ivtv_init_mpeg.bin tuner: type set to 47 (LG NTSC (TAPE series)) by ivtv i2c driver #0 ivtv: Initialized WinTV PVR 350, card #0 ivtv: == NEXT CARD == ivtv: Autodetected WinTV PVR 150 card (iTVC16 based) PCI: Found IRQ 11 for device :00:0c.0 tveeprom: ivtv version tveeprom: Hauppauge: model = 26552, rev = C268, serial# = 8402130 tveeprom: tuner = LG TAPE H001F MK3 (idx = 68, type = 47) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio processor = CX25843 (type = 25) tveeprom: decoder processor = CX25843 (type = 1e) ivtv: i2c attach to card #1 ok [client=tveeprom[50], addr=50] tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #1 ivtv: i2c attach to card #1 ok [client=(tuner unset), addr=61] tda9885/6/7: (ivtv) chip found @ 0x86 ivtv: i2c attach to card #1 ok [client=tda9887, addr=43] cx25840: loading /lib/modules/HcwMakoA.ROM ivtv: i2c attach to card #1 ok [client=cx25840, addr=44] ivtv: i2c
Re: [ivtv-devel] Switching Audio on Adaptec AVC-2410
On Friday 07 Oct 2005 22:05, Hans Verkuil wrote: On Friday 07 October 2005 22:50, Trev Jackson wrote: I think we can now say that there is not much more that can be done to make ivtv compatible with the Adaptec AVC-2410 and the Adaptec AVC-2010. I now use the following to load the driver: modprobe tuner ignore=0,0x6b modprobe ivtv ivtv_std=2 tuner=38 tda9887=0 modprobe lirc_i2c lircd -d /dev/lirc0 --permission=666 I don't think the tda9887=0 option is needed. The only improvement possible is to avoid having to make the tuner ignore address 0x6b on the command line, but that is a very minor inconvenience. I've asked and it is currently not possible. As I understand it it is a design flaw in the I2C or V4L2 system. Does the AVC-2410 have any eeprom? If you run 'i2cdetect -l', and then run 'i2cdetect -a i2cbus' for the ivtv i2c bus, what do you get? If you see a number, then that might be the I2C address of the eeprom. With luck the tuner is encoded in the eeprom. (i2cdetect is part of the lm-sensors package, BTW) Hans Hi Hans 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: UU XX XX UU XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: UU XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX 70: XX XX XX XX XX XX XX XX 11 CS53L32A DAC 21 SAA7115HL Video Decoder 40 MSP3415G Sound Processor 43 TDA9887 Tuner IF 60 FQ1216ME /I H-3 Tuner 6B PIC16C54C IR Remote Control There does not appear to be any more devices on the bus, so I guess there is no EEPROM. It was a nice thought though. I have previously tried loading ivtv without tda9887=0 and could not tune to anything. However I recall you have changed some stuff in relation to this, so I will try it again, and update the AVC-2410 wiki page if it works. Best Regards Trev ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Switching Audio on Adaptec AVC-2410
On Saturday 08 October 2005 00:22, Trev Jackson wrote: How does this work in Windows? Do they have separate NTSC and PAL drivers? Do they ask the user whether they are PAL or NTSC? It's not possible to autodetect the tuner type unfortunately, so they must use some other mechanism. Hans Hi Hans The Adaptec AVC-2410 book says: You have to set the Country or Region to your geographical locations, WinDVR uses this information to set the device standard. That sounds like the tuner is set in the software setup, rather than detected, so the equivalant for linux and ivtv is to set the tuner type and video standard manually. I've adapted the driver so that it selects a tuner based on the selected ivtv_std option. So the tuner option should also be no longer needed. I guessed the NTSC tuner (probably the NTSC model of the same tuner). Let me know if it works. Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] PVR150 PVR350 - dmesg errors - 0.3.9 revision 2757M and before (at least back to 3.8) - full function -
Adam Forsyth wrote: Both are due to using the ivtv tveeprom instead of the kernel / v4l tveeprom. On my system, if I don't let the cx88xx module get pulled in my remote doesn't work (pvr-350), so I use the kernel tveeprom. I rename the bttv module just like I do the kernel msp3400 and tuner modules so it doesn't get pulled in, even though it doesn't have any negative effects. Thanks Adam, That fixed it. I was sure I had tried both the ivtv and kern(v4l) modules and encountered the same behavior. This time I took better care to check whick modules were loading when. ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Le Vendredi 7 Octobre 2005 21:12, Hans Verkuil a écrit : This is a final call before closing tickets #20 and #21 (no sound on one or more tuners). Is there anyone who has no sound whatsoever? no sound the return but : dmesg cx25840 1-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0) cx25840 1-0044: loading /lib/modules/HcwMakoA.ROM i2c_adapter i2c-1: sendbytes: error - bailout. cx25840 1-0044: fast firmware load failed cx25840 1-0044: firmware load failed that's a good reason :-( -- Jacques Facquet. ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Jacques Facquet wrote: Le Vendredi 7 Octobre 2005 21:12, Hans Verkuil a écrit : This is a final call before closing tickets #20 and #21 (no sound on one or more tuners). Is there anyone who has no sound whatsoever? no sound the return but : dmesg cx25840 1-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0) cx25840 1-0044: loading /lib/modules/HcwMakoA.ROM i2c_adapter i2c-1: sendbytes: error - bailout. cx25840 1-0044: fast firmware load failed cx25840 1-0044: firmware load failed that's a good reason :-( After loading this, what's the output of: cx25840ctl -l | grep DL_ADDR -- Tyler Trafford ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Le Samedi 8 Octobre 2005 03:04, Tyler Trafford a écrit : Jacques Facquet wrote: cx25840 1-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0) cx25840 1-0044: loading /lib/modules/HcwMakoA.ROM i2c_adapter i2c-1: sendbytes: error - bailout. cx25840 1-0044: fast firmware load failed cx25840 1-0044: firmware load failed After loading this, what's the output of: cx25840ctl -l | grep DL_ADDR DL_ADDR_LB=231 (0xE7) DL_ADDR_HB=1 (0x1) -- Jacques Facquet. ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Le Samedi 8 Octobre 2005 04:02, Tyler Trafford a écrit : Jacques Facquet wrote: After loading this, what's the output of: cx25840ctl -l | grep DL_ADDR DL_ADDR_LB=231 (0xE7) DL_ADDR_HB=1 (0x1) That's odd because it's only failing on the fast load, but then it falls back to 100MHz and there's no error message on that... Does this happen with the same values for DL_ADDR_* every time? No, I'm trying some different code, stay tuned. -- Jacques Facquet. ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Jacques Facquet wrote: Le Samedi 8 Octobre 2005 04:02, Tyler Trafford a écrit : Jacques Facquet wrote: After loading this, what's the output of: cx25840ctl -l | grep DL_ADDR DL_ADDR_LB=231 (0xE7) DL_ADDR_HB=1 (0x1) That's odd because it's only failing on the fast load, but then it falls back to 100MHz and there's no error message on that... Does this happen with the same values for DL_ADDR_* every time? No, I'm trying some different code, stay tuned. You can always try the 'fastfw=0' option. -- Tyler Trafford ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Le Samedi 8 Octobre 2005 04:13, Jacques Facquet a écrit :
Le Samedi 8 Octobre 2005 04:02, Tyler Trafford a écrit :
Jacques Facquet wrote:
After loading this, what's the output of:
cx25840ctl -l | grep DL_ADDR
DL_ADDR_LB=231 (0xE7)
DL_ADDR_HB=1 (0x1)
That's odd because it's only failing on the fast load, but then
it falls back to 100MHz and there's no error message on that...
Does this happen with the same values for DL_ADDR_* every time?
No, I'm trying some different code, stay tuned.
Well ...
This append when I'm at minimum CPU speed on my PC.
AMD 64 ondemand, no chance to load the firmware if fast load fail.
check_fw_load() failed.
I think that the first time i2c_master_send return a negative value
some bytes have been writen, no idea how many.
my test code :
int rc;
int localsize;
u8 *localdata;
rc= i2c_master_send(client, data, size);
if (rc != size) {
if (info-fastfw) {
if (rc 0) rc=0;
CX25840_ERR(fast firmware load failed\n);
info-fastfw = 0;
cx25840_i2c_set_delay(client, 10);
localsize=size-rc;
localdata=data+rc;
loop=0; // just in case ...
do {
rc=i2c_master_send(client, localdata,
localsize);
rc == localsize ==1024, so, it's OK but check_fw_load()
failed.
that's all I can do today, it's 4h48 am and I'm pretty tired, sorry.
--
Jacques Facquet.
___
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] SOUND: no more silent tuners?
Jacques Facquet wrote: Le Samedi 8 Octobre 2005 04:13, Jacques Facquet a écrit : Le Samedi 8 Octobre 2005 04:02, Tyler Trafford a écrit : Jacques Facquet wrote: After loading this, what's the output of: cx25840ctl -l | grep DL_ADDR DL_ADDR_LB=231 (0xE7) DL_ADDR_HB=1 (0x1) That's odd because it's only failing on the fast load, but then it falls back to 100MHz and there's no error message on that... Does this happen with the same values for DL_ADDR_* every time? No, I'm trying some different code, stay tuned. Well ... This append when I'm at minimum CPU speed on my PC. AMD 64 ondemand, no chance to load the firmware if fast load fail. check_fw_load() failed. I think that the first time i2c_master_send return a negative value some bytes have been writen, no idea how many. Above, there was 0x1E7 (487) bytes written total. 14264 / 487 = 28 which is 34 bytes for every read/write loop, assuming you are not using the hotplug-loader, in which case it is 32. So after the speed fallback, the writes aren't failing out-right, but they aren't writing everything either. -- Tyler Trafford ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
