Mailing List Archive: ivtv: devel

[RC1] Released ivtv-0.10.0rc1: please test this first release candidate!

Index | Next | Previous | View Threaded

hverkuil at xs4all

Feb 3, 2007, 3:48 AM

Post #1 of 16 (3477 views)
Permalink

[RC1] Released ivtv-0.10.0rc1: please test this first release candidate!

Hi all,

It took a long time (over 5 months) but here is the first release
candidate for the redesigned and cleaned up ivtv-0.10.0 driver.

This driver will work with kernels 2.6.18 and 2.6.19.

It can be downloaded here:
http://dl.ivtvdriver.org/ivtv/unstable/ivtv-0.10.0rc1.tar.gz

Note: while it has been tested pretty well it remains a release
candidate, so if you have a really stable production system you might
not want to use this driver when making important recordings.

My request is if you can all start testing this release candidate. I am
very happy with it as it is much easier to extend and improve than the
older versions. It should also be a lot more stable.

It is interesting to compare the 0.9.2 release with this 0.10.0rc1
release with regard to code size:

0.9.1: 19305 lines, 586420 bytes
0.10.0rc1: 14073 lines, 447377 bytes

That's a reduction of about 25%!

Before you start testing you should first read the notes at the
beginning of the included README file. The most important one is that
you need to use the included cx2341x encoder firmware. And if you use
ivtvfb then you will need to add extra kernel modules and most likely
you will also need to add the ivtv-fb module option osd_compat=1.

I'd appreciate it if any posts regarding this release candidate are
prefixed with [RC1] (as I did for this post).

If all goes well, then I hope to make a final release in 1-2 weeks. My
intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0 for
kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the numbering
nicely regular. There will probably also be a 0.21.0 for kernel 2.6.21,
but in all likelyhood ivtv will be merged into kernel 2.6.22.

Enjoy!

Hans

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hverkuil at xs4all

Feb 3, 2007, 3:59 AM

Post #2 of 16 (3379 views)
Permalink

Re: [ivtv-users] [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Saturday 03 February 2007 12:48, Hans Verkuil wrote:
> Hi all,
>
> It took a long time (over 5 months) but here is the first release
> candidate for the redesigned and cleaned up ivtv-0.10.0 driver.

Oops, almost forgot: a special Thank You to Ian Armstrong for his
excellent work on ivtv-fb and the YUV decoding!

Thanks, Ian!

Hans

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

jrosink at gmail

Feb 3, 2007, 5:30 AM

Post #3 of 16 (3384 views)
Permalink

Re: [ivtv-users] [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On 2/3/07, Hans Verkuil <hverkuil [at] xs4all> wrote:
> On Saturday 03 February 2007 12:48, Hans Verkuil wrote:
> > Hi all,
> >
> > It took a long time (over 5 months) but here is the first release
> > candidate for the redesigned and cleaned up ivtv-0.10.0 driver.
>
> Oops, almost forgot: a special Thank You to Ian Armstrong for his
> excellent work on ivtv-fb and the YUV decoding!

I believe you forgot yourself Hans, do you have time to eat and breath ?

Will test this version tonight, many thanks for your work letting us
record some TV !!!

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hverkuil at xs4all

Feb 3, 2007, 5:43 AM

Post #4 of 16 (3371 views)
Permalink

Re: [ivtv-users] [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Saturday 03 February 2007 14:30, Jorgen Rosink wrote:
> On 2/3/07, Hans Verkuil <hverkuil [at] xs4all> wrote:
> > On Saturday 03 February 2007 12:48, Hans Verkuil wrote:
> > > Hi all,
> > >
> > > It took a long time (over 5 months) but here is the first release
> > > candidate for the redesigned and cleaned up ivtv-0.10.0 driver.
> >
> > Oops, almost forgot: a special Thank You to Ian Armstrong for his
> > excellent work on ivtv-fb and the YUV decoding!
>
> I believe you forgot yourself Hans, do you have time to eat and
> breath ?

I'll admit that I'll be very relieved when I can finally shove this
driver into the kernel. It's taken more of my time than I really like,
but at least the end is in sight now.

Hans

>
> Will test this version tonight, many thanks for your work letting us
> record some TV !!!
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

michel at verbraak

Feb 4, 2007, 4:56 AM

Post #5 of 16 (3361 views)
Permalink

Re: [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

Hans,

Just reporting back that ivtv 0.10.0RC1 is working allright for me. It
even looks like channel changing is faster. Currently no errors in
syslog after having it running mythtv on tv-out pvr-350 (not X) for
about 24 hours.

details of system: FC6, vanilla kernel 2.6.19.2 for saa7127 module,
x86_64, ASRock AM2NF3-VSTA motherboard, AMD X2 +5200 processor, 1GB
memory, PVR-350 and PVR-150. MythTV (svn) tv-out through pvr-350 (not X).

Thank you.

Regards,

Michel.

Feb 4 13:46:53 garfield kernel: ivtv: ==================== START INIT
IVTV ====================
Feb 4 13:46:53 garfield kernel: ivtv: version 0.10.0 (tagged release
candidate #1) loading
Feb 4 13:46:53 garfield kernel: ivtv: Linux version: 2.6.19.2 SMP
mod_unload
Feb 4 13:46:53 garfield kernel: ivtv: In case of problems please
include the debug info between
Feb 4 13:46:53 garfield kernel: ivtv: the START INIT IVTV and END INIT
IVTV lines, along with
Feb 4 13:46:53 garfield kernel: ivtv: any module options, when mailing
the ivtv-users mailinglist.
Feb 4 13:46:53 garfield kernel: ivtv0: Autodetected Hauppauge card
(cx23415 based)
Feb 4 13:46:53 garfield kernel: ACPI: PCI Interrupt 0000:02:06.0[A] ->
Link [LNKC] -> GSI 19 (level, low) -> IRQ 19
Feb 4 13:46:54 garfield kernel: ivtv0: loaded v4l-cx2341x-enc.fw
firmware (376836 bytes)
Feb 4 13:46:54 garfield kernel: ivtv0: loaded v4l-cx2341x-dec.fw
firmware (262144 bytes)
Feb 4 13:46:54 garfield kernel: ivtv0: Encoder revision: 0x02050032
Feb 4 13:46:54 garfield kernel: ivtv0: Untested encoder firmware
version, recommended version is 0x02060039.
Feb 4 13:46:54 garfield kernel: ivtv0: Decoder revision: 0x02020023
Feb 4 13:46:54 garfield kernel: tuner 2-0061: chip found @ 0xc2 (ivtv
i2c driver #0)
Feb 4 13:46:54 garfield kernel: saa7115 2-0021: saa7115 found
(1f7115d0e100000) @ 0x42 (ivtv i2c driver #0)
Feb 4 13:46:55 garfield kernel: saa7127 2-0044: saa7127 found @ 0x88
(ivtv i2c driver #0)
Feb 4 13:46:55 garfield kernel: msp3400 2-0040: MSP4418G-A2 found @
0x80 (ivtv i2c driver #0)
Feb 4 13:46:55 garfield kernel: msp3400 2-0040: MSP4418G-A2 supports
nicam and radio, mode is autodetect and autoselect
Feb 4 13:46:55 garfield kernel: lirc_i2c: chip found @ 0x18 (Hauppauge IR)
Feb 4 13:46:55 garfield kernel: lirc_dev: lirc_register_plugin:
sample_rate: 10
Feb 4 13:46:55 garfield kernel: tveeprom 2-0050: Hauppauge model 48134,
rev I121, serial# 6182877
Feb 4 13:46:55 garfield kernel: tveeprom 2-0050: tuner model is Philips
FM1216 (idx 21, type 5)
Feb 4 13:46:55 garfield kernel: tveeprom 2-0050: TV standards PAL(B/G)
(eeprom 0x04)
Feb 4 13:46:55 garfield kernel: tveeprom 2-0050: audio processor is
MSP4418 (idx 25)
Feb 4 13:46:55 garfield kernel: tveeprom 2-0050: decoder processor is
SAA7115 (idx 19)
Feb 4 13:46:55 garfield kernel: tveeprom 2-0050: has radio, has IR remote
Feb 4 13:46:55 garfield kernel: ivtv0: Autodetected Hauppauge WinTV PVR-350
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device video0 for
encoder MPEG (4 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device video32 for
encoder YUV (2 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device vbi0 for
encoder VBI (1 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device video24 for
encoder PCM audio (1 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device radio0 for
encoder radio
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device video16 for
decoder MPEG (1 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device vbi8 for
decoder VBI (1 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device vbi16 for
decoder VOUT
Feb 4 13:46:55 garfield kernel: ivtv0: Registered device video48 for
decoder YUV (1 MB)
Feb 4 13:46:55 garfield kernel: ivtv0: loaded v4l-cx2341x-init.mpg
firmware (155648 bytes)
Feb 4 13:46:55 garfield kernel: tuner 2-0061: type set to 5 (Philips
PAL_BG (FI1216 and compatibles))
Feb 4 13:46:56 garfield kernel: ivtv0: Initialized Hauppauge WinTV
PVR-350, card #0
Feb 4 13:46:56 garfield kernel: ivtv: ====================== NEXT
CARD ======================
Feb 4 13:46:56 garfield kernel: ivtv1: Autodetected Hauppauge card
(cx23416 based)
Feb 4 13:46:56 garfield kernel: ACPI: PCI Interrupt 0000:02:08.0[A] ->
Link [LNKA] -> GSI 18 (level, low) -> IRQ 18
Feb 4 13:46:56 garfield kernel: ivtv1: loaded v4l-cx2341x-enc.fw
firmware (376836 bytes)
Feb 4 13:46:56 garfield kernel: ivtv1: Encoder revision: 0x02050032
Feb 4 13:46:56 garfield kernel: ivtv1: Untested encoder firmware
version, recommended version is 0x02060039.
Feb 4 13:46:56 garfield kernel: tuner 3-0043: chip found @ 0x86 (ivtv
i2c driver #1)
Feb 4 13:46:56 garfield kernel: tda9887 3-0043: tda988[5/6/7] found @
0x43 (tuner)
Feb 4 13:46:56 garfield kernel: tuner 3-0061: chip found @ 0xc2 (ivtv
i2c driver #1)
Feb 4 13:46:56 garfield kernel: i2c_adapter i2c-3: Client creation
failed at 0x44 (-1)
Feb 4 13:46:56 garfield kernel: cx25840 3-0044: cx25843-23 found @ 0x88
(ivtv i2c driver #1)
Feb 4 13:47:01 garfield kernel: cx25840 3-0044: loaded v4l-cx25840.fw
firmware (16382 bytes)
Feb 4 13:47:01 garfield kernel: wm8775 3-001b: chip found @ 0x36 (ivtv
i2c driver #1)
Feb 4 13:47:01 garfield kernel: lirc_i2c: chip found @ 0x71 (Hauppauge
IR (PVR150))
Feb 4 13:47:01 garfield kernel: lirc_dev: lirc_register_plugin:
sample_rate: 10
Feb 4 13:47:02 garfield kernel: tveeprom 3-0050: Hauppauge model 26059,
rev C155, serial# 7583011
Feb 4 13:47:02 garfield kernel: tveeprom 3-0050: tuner model is Philips
FQ1216ME MK3 (idx 55, type 38)
Feb 4 13:47:02 garfield kernel: tveeprom 3-0050: TV standards PAL(B/G)
PAL(I) SECAM(L/L') PAL(D/D1/K) (eeprom 0x74)
Feb 4 13:47:02 garfield kernel: tveeprom 3-0050: audio processor is
CX25843 (idx 37)
Feb 4 13:47:02 garfield kernel: tveeprom 3-0050: decoder processor is
CX25843 (idx 30)
Feb 4 13:47:02 garfield kernel: tveeprom 3-0050: has no radio, has IR
remote
Feb 4 13:47:02 garfield kernel: ivtv1: Autodetected Hauppauge WinTV PVR-150
Feb 4 13:47:02 garfield kernel: ivtv1: reopen i2c bus for IR-blaster
support
Feb 4 13:47:02 garfield kernel: tuner 3-0043: chip found @ 0x86 (ivtv
i2c driver #1)
Feb 4 13:47:02 garfield kernel: tda9887 3-0043: tda988[5/6/7] found @
0x43 (tuner)
Feb 4 13:47:02 garfield kernel: tuner 3-0061: chip found @ 0xc2 (ivtv
i2c driver #1)
Feb 4 13:47:02 garfield kernel: i2c_adapter i2c-3: Client creation
failed at 0x44 (-1)
Feb 4 13:47:02 garfield kernel: cx25840 3-0044: cx25843-23 found @ 0x88
(ivtv i2c driver #1)
Feb 4 13:47:05 garfield kernel: cx25840 3-0044: loaded v4l-cx25840.fw
firmware (16382 bytes)
Feb 4 13:47:05 garfield kernel: wm8775 3-001b: chip found @ 0x36 (ivtv
i2c driver #1)
Feb 4 13:47:05 garfield kernel: lirc_i2c: chip found @ 0x71 (Hauppauge
IR (PVR150))
Feb 4 13:47:05 garfield kernel: lirc_dev: lirc_register_plugin:
sample_rate: 10
Feb 4 13:47:05 garfield kernel: ivtv1: Registered device video1 for
encoder MPEG (4 MB)
Feb 4 13:47:05 garfield kernel: ivtv1: Registered device video33 for
encoder YUV (2 MB)
Feb 4 13:47:05 garfield kernel: ivtv1: Registered device vbi1 for
encoder VBI (1 MB)
Feb 4 13:47:05 garfield kernel: ivtv1: Registered device video25 for
encoder PCM audio (1 MB)
Feb 4 13:47:05 garfield kernel: tuner 3-0061: type set to 38 (Philips
PAL/SECAM multi (FM1216ME MK3))
Feb 4 13:47:05 garfield kernel: ivtv1: Initialized Hauppauge WinTV
PVR-150, card #1
Feb 4 13:47:05 garfield kernel: ivtv: ==================== END INIT
IVTV ====================
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Framebuffer at 0xf1510000,
mapped to 0xffffc20000e10000, size 1665k
Feb 4 13:47:23 garfield kernel: ivtv0-fb: === Validated display mode ===
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Display size 720x576 (720x576
Virtual) @ 32bpp
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Display position 1,1
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Display filter : on
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Color space : RGB
Feb 4 13:47:23 garfield kernel: Console: switching to colour frame
buffer device 90x36
Feb 4 13:47:23 garfield kernel: ivtv0-fb: === Display mode change ===
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Display size 720x576 (720x576
Virtual) @ 32bpp
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Display position 1,1
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Display filter : on
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Color space : RGB
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Running in compatibility
mode. Display resize & mode change disabled
Feb 4 13:47:23 garfield kernel: ivtv0-fb: Framebuffer registered on
ivtv card id 0

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Axel.Thimm at ATrpms

Feb 5, 2007, 2:16 AM

Post #6 of 16 (3352 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Sat, Feb 03, 2007 at 12:48:10PM +0100, Hans Verkuil wrote:
> It took a long time (over 5 months) but here is the first release
> candidate for the redesigned and cleaned up ivtv-0.10.0 driver.

Thanks & congrats!

> This driver will work with kernels 2.6.18 and 2.6.19.

I'm building packages for RHEL and FC as appropriate, they will land
in atrpms-testing.

> My intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0
> for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the
> numbering nicely regular. There will probably also be a 0.21.0 for
> kernel 2.6.21,

If it wouldn't be a too big issue I would recommend using the same
versioning throughout all supported kernels. I think it makes the
users' handling easier, as well as for people reviewing the code,
e.g. it is easier to review some conditionals based on kernel versions
than to have several trees.

It also makes packaging far more easier, as the userland portions
remain in the same versioned subpackage, even if people have both
2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed.
--
Axel.Thimm at ATrpms.net

hverkuil at xs4all

Feb 5, 2007, 2:30 AM

Post #7 of 16 (3330 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Monday 05 February 2007 11:16, Axel Thimm wrote:
> On Sat, Feb 03, 2007 at 12:48:10PM +0100, Hans Verkuil wrote:
> > It took a long time (over 5 months) but here is the first release
> > candidate for the redesigned and cleaned up ivtv-0.10.0 driver.
>
> Thanks & congrats!
>
> > This driver will work with kernels 2.6.18 and 2.6.19.
>
> I'm building packages for RHEL and FC as appropriate, they will land
> in atrpms-testing.

Be aware of the new encoder firmware included with the package! When I
make a final release I'll ensure that it will be part of the firmware
tarball on ivtvdriver.org and that the older ivtv versions (0.4, 0.6,
0.7) can be used with that larger firmware.

> > My intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0
> > for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the
> > numbering nicely regular. There will probably also be a 0.21.0 for
> > kernel 2.6.21,
>
> If it wouldn't be a too big issue I would recommend using the same
> versioning throughout all supported kernels. I think it makes the
> users' handling easier, as well as for people reviewing the code,
> e.g. it is easier to review some conditionals based on kernel
> versions than to have several trees.
>
> It also makes packaging far more easier, as the userland portions
> remain in the same versioned subpackage, even if people have both
> 2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed.

True, but on the other hand it is much more like what it will be when
the driver enters the kernel: only limited fixes for older kernels. But
I'm not yet certain how to handle this.

Regards,

Hans

PS: the latest trunk contains patches to make it work with kernel
2.6.20, however I have major problems with the cx25840 module which
gives a kobject error and won't load its firmware. It's something in
the i2c setup somewhere that's causing it. For now I assume it is a
ivtv bug.

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Axel.Thimm at ATrpms

Feb 5, 2007, 3:04 AM

Post #8 of 16 (3333 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Mon, Feb 05, 2007 at 11:30:17AM +0100, Hans Verkuil wrote:
> > I'm building packages for RHEL and FC as appropriate, they will land
> > in atrpms-testing.
>
> Be aware of the new encoder firmware included with the package!

I was always packaging v4l-cx2341x-init.mpg, or is there something
else now?

> > > My intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0
> > > for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the
> > > numbering nicely regular. There will probably also be a 0.21.0 for
> > > kernel 2.6.21,
> >
> > If it wouldn't be a too big issue I would recommend using the same
> > versioning throughout all supported kernels. I think it makes the
> > users' handling easier, as well as for people reviewing the code,
> > e.g. it is easier to review some conditionals based on kernel
> > versions than to have several trees.
> >
> > It also makes packaging far more easier, as the userland portions
> > remain in the same versioned subpackage, even if people have both
> > 2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed.
>
> True, but on the other hand it is much more like what it will be when
> the driver enters the kernel: only limited fixes for older kernels. But
> I'm not yet certain how to handle this.

Once the driver is in the kernel I wouldn't backport small fixes at
all, I would simply move along with development of a single version
while allowing the software to build for a certain kernel range,
e.g. if certain APIs from 2.6.18 are needed then 2.6.18 upwards. If a
small number of conditionals allow for a broader range of kernel
that's OK (e.g. as long as the pain is small compared to the gain).

That's the typical model followed by many projects, whether they are
in the kernel already with some version or not, e.g. alsa, ipw*, v4l
etc. It makes talking about features entering the driver easier,
e.g. instead of "super-foo was added to 0.24.5, 0.25.2 and 0.26rc1"
one would just have a single version.

Having the version stick to the software itself and not correlate with
the kernel version has also other benefits: Once it hits say 2.6.22 as
an internal kernel module it would carry a modversion of
0.22.0. Perhaps 2.6.23 will see no changes at all, but the users will
be confused about still being on 0.22.0 because they have been
educated to associate the version of the module with that of the
kernel's and also have been warned not to mix.

And users could check whether their in-kernel or OOT version supports
"super-foo" by the same kernel-independent method, a simple modinfo
ivtv | grep ^version:
--
Axel.Thimm at ATrpms.net

hverkuil at xs4all

Feb 5, 2007, 3:26 AM

Post #9 of 16 (3342 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Monday 05 February 2007 12:04, Axel Thimm wrote:
> On Mon, Feb 05, 2007 at 11:30:17AM +0100, Hans Verkuil wrote:
> > > I'm building packages for RHEL and FC as appropriate, they will
> > > land in atrpms-testing.
> >
> > Be aware of the new encoder firmware included with the package!
>
> I was always packaging v4l-cx2341x-init.mpg, or is there something
> else now?

>From the README:

NOTE: this driver requires the latest encoder firmware (version
2.06.039, size 376836 bytes). This firmware is temporarily included
with this driver. When this driver is released officially, then the
firmware archive on www.ivtvdriver.org will also be updated. But for
the time being you will have to copy the included firmware over your
current v4l-cx2341x-enc.fw firmware.

>
> > > > My intention is to release a ivtv-0.18.0 for kernel 2.6.18,
> > > > 0.19.0 for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This
> > > > keeps the numbering nicely regular. There will probably also be
> > > > a 0.21.0 for kernel 2.6.21,
> > >
> > > If it wouldn't be a too big issue I would recommend using the
> > > same versioning throughout all supported kernels. I think it
> > > makes the users' handling easier, as well as for people reviewing
> > > the code, e.g. it is easier to review some conditionals based on
> > > kernel versions than to have several trees.
> > >
> > > It also makes packaging far more easier, as the userland portions
> > > remain in the same versioned subpackage, even if people have both
> > > 2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed.
> >
> > True, but on the other hand it is much more like what it will be
> > when the driver enters the kernel: only limited fixes for older
> > kernels. But I'm not yet certain how to handle this.
>
> Once the driver is in the kernel I wouldn't backport small fixes at
> all, I would simply move along with development of a single version
> while allowing the software to build for a certain kernel range,
> e.g. if certain APIs from 2.6.18 are needed then 2.6.18 upwards. If a
> small number of conditionals allow for a broader range of kernel
> that's OK (e.g. as long as the pain is small compared to the gain).
>
> That's the typical model followed by many projects, whether they are
> in the kernel already with some version or not, e.g. alsa, ipw*, v4l
> etc. It makes talking about features entering the driver easier,
> e.g. instead of "super-foo was added to 0.24.5, 0.25.2 and 0.26rc1"
> one would just have a single version.
>
> Having the version stick to the software itself and not correlate
> with the kernel version has also other benefits: Once it hits say
> 2.6.22 as an internal kernel module it would carry a modversion of
> 0.22.0. Perhaps 2.6.23 will see no changes at all, but the users will
> be confused about still being on 0.22.0 because they have been
> educated to associate the version of the module with that of the
> kernel's and also have been warned not to mix.
>
> And users could check whether their in-kernel or OOT version supports
> "super-foo" by the same kernel-independent method, a simple modinfo
> ivtv | grep ^version:

Once it is in the kernel there is no problem anymore: if you need the
latest functionality but have an older kernel, then you can 'just'
compile and install the latest v4l-dvb source tree. But I can't really
support an out-of-tree standalone ivtv package because ivtv relies
heavily on the v4l2 API changes that I'm making. That's why the trunk
ivtv can't be backported to pre-2.6.18 kernels (2.6.18 added the MPEG
encoder controls). Another cut-off point might be when the driver goes
into the kernel as that too requires new v4l2 API additions.

This is the reason why I basically stopped supporting ivtv-0.6 and 0.7
and only do very limited support for ivtv-0.4. (ivtv-0.5 was skipped)

Regards,

Hans

PS: of course it is technically possible to backport the trunk to older
kernels, but the amount of time it will take is just too much.

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

duncan-v4l at linuxowl

Feb 6, 2007, 12:59 PM

Post #10 of 16 (3306 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

Hans Verkuil wrote:
> On Monday 05 February 2007 12:04, Axel Thimm wrote:
>> On Mon, Feb 05, 2007 at 11:30:17AM +0100, Hans Verkuil wrote:
>>>> I'm building packages for RHEL and FC as appropriate, they will
>>>> land in atrpms-testing.
>>> Be aware of the new encoder firmware included with the package!
>> I was always packaging v4l-cx2341x-init.mpg, or is there something
>> else now?
>
>>From the README:
>
> NOTE: this driver requires the latest encoder firmware (version
> 2.06.039, size 376836 bytes). This firmware is temporarily included
> with this driver. When this driver is released officially, then the
> firmware archive on www.ivtvdriver.org will also be updated. But for
> the time being you will have to copy the included firmware over your
> current v4l-cx2341x-enc.fw firmware.

I quite like the idea of including the firmware in the tarballs, it
makes life much easier, don't have to go and check if I'm using the
correct version that the driver has been tested against.

If there are no licensing problems keeping the firmware with the driver
would be great.

Duncan

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Wilhelm.Eger at uni-jena

Feb 6, 2007, 11:33 PM

Post #11 of 16 (3304 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

Hi Hans,

I changed to the new version yesterday. I use it with Mythtv SVN. It seems to be
stable and fast. My kernel is 2.6.20.

There are only two issues:

First I got a very slight ghosting. I knew that there was something in the
2.6.19 kernel what produces the stronger ghosting before so I hoped to get rid
of this with the new kernel. I'm using the TV Out of my PVR 350 and don't run
MythtTV at PAL resolution because of overscan problems.

Second I get this in dmesg:

ivtv0 warning: IVTV_IOC_DEC_FLUSH is obsolete!
ivtv0 warning: Could not get result (CX2341X_DEC_GET_TIMING_INFO)
ivtv0 warning: GET_TIMING: couldn't read clock
ivtv0: Stereo mode changed
ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 113 jiffies (1000 per HZ)
ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 115 jiffies (1000 per HZ)
ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 110 jiffies (1000 per HZ)
ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 115 jiffies (1000 per HZ)
ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 101 jiffies (1000 per HZ)

Don't know wether that is bad or not. I just want to let you know.

Bye,

Wilhelm

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

michel at verbraak

Feb 8, 2007, 10:33 PM

Post #12 of 16 (3276 views)
Permalink

Re: [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

Hans,

Last night had a complete lock of my machine using mythtv and playing
back through the pvr-350.
Following was in my message log after a restart (power down and power up):

Feb 8 21:42:17 garfield kernel: ivtv0: Stereo mode changed
Feb 8 21:42:27 garfield kernel: ivtv0 warning: IVTV_IOC_DEC_FLUSH is
obsolete!
Feb 8 21:42:28 garfield kernel: ivtv0: Stereo mode changed
Feb 8 21:43:26 garfield kernel: i2c_adapter i2c-2: sendbytes: error -
bailout.
Feb 8 21:43:26 garfield kernel: msp3400 2-0040: I/O error #0 (read
0x10/0x200)
Feb 8 21:43:54 garfield kernel: ivtv0 warning: Could not get result
(CX2341X_DEC_GET_TIMING_INFO)
Feb 8 21:43:54 garfield kernel: ivtv0 warning: GET_TIMING: couldn't
read clock

I was watching livetv and the picture on my tvscreen frooze. This
morning I checked the computer and the scroll lock light on my keyboard
was blinking and my monitor was black but active (not in sleep mode) (I
have the normal FC6 X running).

Regards,

Michel.

Hans Verkuil schreef:
> Hi all,
>
> It took a long time (over 5 months) but here is the first release
> candidate for the redesigned and cleaned up ivtv-0.10.0 driver.
>
> This driver will work with kernels 2.6.18 and 2.6.19.
>
> It can be downloaded here:
> http://dl.ivtvdriver.org/ivtv/unstable/ivtv-0.10.0rc1.tar.gz
>
> Note: while it has been tested pretty well it remains a release
> candidate, so if you have a really stable production system you might
> not want to use this driver when making important recordings.
>
> My request is if you can all start testing this release candidate. I am
> very happy with it as it is much easier to extend and improve than the
> older versions. It should also be a lot more stable.
>
> It is interesting to compare the 0.9.2 release with this 0.10.0rc1
> release with regard to code size:
>
> 0.9.1: 19305 lines, 586420 bytes
> 0.10.0rc1: 14073 lines, 447377 bytes
>
> That's a reduction of about 25%!
>
> Before you start testing you should first read the notes at the
> beginning of the included README file. The most important one is that
> you need to use the included cx2341x encoder firmware. And if you use
> ivtvfb then you will need to add extra kernel modules and most likely
> you will also need to add the ivtv-fb module option osd_compat=1.
>
> I'd appreciate it if any posts regarding this release candidate are
> prefixed with [RC1] (as I did for this post).
>
> If all goes well, then I hope to make a final release in 1-2 weeks. My
> intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0 for
> kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the numbering
> nicely regular. There will probably also be a 0.21.0 for kernel 2.6.21,
> but in all likelyhood ivtv will be merged into kernel 2.6.22.
>
> Enjoy!
>
> Hans
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hverkuil at xs4all

Feb 9, 2007, 5:30 AM

Post #13 of 16 (3272 views)
Permalink

Re: Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Wednesday 07 February 2007 08:33, Wilhelm Eger wrote:
> Hi Hans,
>
> I changed to the new version yesterday. I use it with Mythtv SVN. It
> seems to be stable and fast. My kernel is 2.6.20.
>
> There are only two issues:
>
> First I got a very slight ghosting. I knew that there was something
> in the 2.6.19 kernel what produces the stronger ghosting before so I
> hoped to get rid of this with the new kernel. I'm using the TV Out of
> my PVR 350 and don't run MythtTV at PAL resolution because of
> overscan problems.

What do you mean, overscan problems? The overscan behavior is
independent AFAIK of the recorded resolution.

Anyway, can you post the output of 'v4l2-ctl --log-status' when playing
back a recording? That way I see the decoder settings.

> Second I get this in dmesg:
>
> ivtv0 warning: IVTV_IOC_DEC_FLUSH is obsolete!
> ivtv0 warning: Could not get result (CX2341X_DEC_GET_TIMING_INFO)
> ivtv0 warning: GET_TIMING: couldn't read clock
> ivtv0: Stereo mode changed
> ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 113 jiffies (1000 per
> HZ) ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 115 jiffies (1000
> per HZ) ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 110 jiffies
> (1000 per HZ) ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took 115
> jiffies (1000 per HZ) ivtv0 warning: CX2341X_DEC_GET_TIMING_INFO took
> 101 jiffies (1000 per HZ)
>
> Don't know wether that is bad or not. I just want to let you know.

This can be ignored. It's not relevant.

Hans

>
> Bye,
>
> Wilhelm
>
> ----------------------------------------------------------------
> This mail was sent through http://webmail.uni-jena.de
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

amcnabb at mcnabbs

Feb 9, 2007, 5:35 PM

Post #14 of 16 (3269 views)
Permalink

Re: [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Sat, Feb 03, 2007 at 12:48:10PM +0100, Hans Verkuil wrote:
>
> My request is if you can all start testing this release candidate. I
> am very happy with it as it is much easier to extend and improve than
> the older versions. It should also be a lot more stable.
>

I installed the new driver (make; make install; depmod -a) and did a
"modprobe -r ivtv". Unfortunately, I'm getting a memory allocation
error. I got the following output in dmesg, which I've followed with
the output from /proc/meminfo. Nothing else on the system seems too
unusual. Am I doing anything obviously wrong? Thanks.

ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.10.0 (tagged release candidate #1) loading
ivtv: Linux version: 2.6.19.1 SMP preempt mod_unload PENTIUM4
ivtv: In case of problems please include the debug info between
ivtv: the START INIT IVTV and END INIT IVTV lines, along with
ivtv: any module options, when mailing the ivtv-users mailinglist.
ivtv0: Autodetected Hauppauge card (cx23416 based)
ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv0: Encoder revision: 0x02060039
tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #0)
tda9887 0-0043: tda988[5/6/7] found @ 0x43 (tuner)
tuner 0-0060: TEA5767 detected.
tuner 0-0060: chip found @ 0xc0 (ivtv i2c driver #0)
tuner 0-0060: type set to 62 (Philips TEA5767HN FM Radio)
tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
cx25840 0-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
tveeprom 0-0050: Hauppauge model 23552, rev D592, serial# 8224053
tveeprom 0-0050: tuner model is Philips FQ1236A MK4 (idx 92, type 57)
tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 0-0050: second tuner model is Philips TEA5768HL FM Radio (idx 101, type 62)
tveeprom 0-0050: audio processor is CX25843 (idx 37)
tveeprom 0-0050: decoder processor is CX25843 (idx 30)
tveeprom 0-0050: has radio, has no IR remote
ivtv0: Autodetected WinTV PVR 500 (unit #1)
ivtv0: Registered device video0 for encoder MPEG (4 MB)
modprobe: page allocation failure. order:4, mode:0xd0
[<c013c899>] __alloc_pages+0x28e/0x29f
[<c0150207>] cache_alloc_refill+0x27c/0x472
[<c0150456>] __kmalloc+0x59/0x62
[<e89a9004>] ivtv_stream_alloc+0x156/0x212 [ivtv]
[<e89a706d>] ivtv_streams_setup+0x3a3/0x408 [ivtv]
[<e89a3938>] ivtv_probe+0x10c8/0x144c [ivtv]
[<c0112bea>] __wake_up_common+0x39/0x5b
[<c0113070>] __wake_up+0x32/0x43
[<c0113070>] __wake_up+0x32/0x43
[<c01ca8ee>] pci_device_probe+0x44/0x68
[<c02185bd>] really_probe+0x3d/0xe0
[<c02b00a8>] klist_next+0x60/0x78
[<c021878d>] __driver_attach+0x0/0x8b
[<c02187e0>] __driver_attach+0x53/0x8b
[<c0217b6d>] bus_for_each_dev+0x50/0x77
[<c02184ba>] driver_attach+0x26/0x2a
[<c021878d>] __driver_attach+0x0/0x8b
[<c0217ef6>] bus_add_driver+0x66/0x190
[<c02189ce>] driver_register+0x80/0x8d
[<c01caa9a>] __pci_register_driver+0x87/0xac
[<e89a252d>] module_start+0xba/0xe3 [ivtv]
[<c013431e>] sys_init_module+0x1780/0x1957
[<c0102dab>] syscall_call+0x7/0xb
=======================
Mem-info:
DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 179 Cold: hi: 62, btch: 15 usd: 48
CPU 1: Hot: hi: 186, btch: 31 usd: 81 Cold: hi: 62, btch: 15 usd: 61
Active:46684 inactive:43378 dirty:11 writeback:0 unstable:0 free:58027 slab:8467 mapped:10
488 pagetables:426
DMA free:7804kB min:80kB low:100kB high:120kB active:2800kB inactive:0kB present:16256kB p
ages_scanned:32 all_unreclaimable? no
lowmem_reserve[]: 0 618
Normal free:224304kB min:3140kB low:3924kB high:4708kB active:183936kB inactive:173512kB p
resent:633432kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
DMA: 411*4kB 296*8kB 139*16kB 47*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4
096kB = 7804kB
Normal: 12670*4kB 13299*8kB 3012*16kB 583*32kB 2*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2
048kB 0*4096kB = 224304kB
Swap cache: add 501558, delete 496210, find 603138/635664, race 0+403
Free swap = 1900244kB
Total swap = 1959920kB
Free swap: 1900244kB
163700 pages of RAM
0 pages of HIGHMEM
2327 reserved pages
37871 pages shared
5348 pages swap cached
11 pages dirty
0 pages writeback
10488 pages mapped
8178 pages slab
426 pages pagetables
ivtv0: Couldn't allocate buffers for encoder MPEG stream
ivtv0: Error -12 setting up streams
ivtv0: Error -12 on initialization
ivtv: probe of 0000:03:08.0 failed with error -12
ivtv: ====================== NEXT CARD ======================
ivtv1: Autodetected Hauppauge card (cx23416 based)
ivtv1: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv1: Encoder revision: 0x02060039
tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #1)
tda9887 0-0043: tda988[5/6/7] found @ 0x43 (tuner)
tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #1)
cx25840 0-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #1)
cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #1)
tveeprom 0-0050: Hauppauge model 23552, rev D592, serial# 8224053
tveeprom 0-0050: tuner model is Philips FQ1236A MK4 (idx 92, type 57)
tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 0-0050: second tuner model is Philips TEA5768HL FM Radio (idx 101, type 62)
tveeprom 0-0050: audio processor is CX25843 (idx 37)
tveeprom 0-0050: decoder processor is CX25843 (idx 30)
tveeprom 0-0050: has radio, has no IR remote
ivtv1: Correcting tveeprom data: no radio present on second unit
ivtv1: Autodetected WinTV PVR 500 (unit #2)
ivtv1: Registered device video1 for encoder MPEG (4 MB)
modprobe: page allocation failure. order:4, mode:0xd0
[<c013c899>] __alloc_pages+0x28e/0x29f
[<c0150207>] cache_alloc_refill+0x27c/0x472
[<c0150456>] __kmalloc+0x59/0x62
[<e89a9004>] ivtv_stream_alloc+0x156/0x212 [ivtv]
[<e89a706d>] ivtv_streams_setup+0x3a3/0x408 [ivtv]
[<e89a3938>] ivtv_probe+0x10c8/0x144c [ivtv]
[<c011a1e2>] vprintk+0x2e8/0x325
[<c0113070>] __wake_up+0x32/0x43
[<c0113070>] __wake_up+0x32/0x43
[<c01ca8ee>] pci_device_probe+0x44/0x68
[<c02185bd>] really_probe+0x3d/0xe0
[<c02b00a8>] klist_next+0x60/0x78
[<c021878d>] __driver_attach+0x0/0x8b
[<c02187e0>] __driver_attach+0x53/0x8b
[<c0217b6d>] bus_for_each_dev+0x50/0x77
[<c02184ba>] driver_attach+0x26/0x2a
[<c021878d>] __driver_attach+0x0/0x8b
[<c0217ef6>] bus_add_driver+0x66/0x190
[<c02189ce>] driver_register+0x80/0x8d
[<c01caa9a>] __pci_register_driver+0x87/0xac
[<e89a252d>] module_start+0xba/0xe3 [ivtv]
[<c013431e>] sys_init_module+0x1780/0x1957
[<c0102dab>] syscall_call+0x7/0xb
=======================
Mem-info:
DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 161 Cold: hi: 62, btch: 15 usd: 56
CPU 1: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 49
Active:46152 inactive:41361 dirty:25 writeback:0 unstable:0 free:61103 slab:7933 mapped:10
488 pagetables:425
DMA free:7804kB min:80kB low:100kB high:120kB active:2800kB inactive:0kB present:16256kB p
ages_scanned:64 all_unreclaimable? no
lowmem_reserve[]: 0 618
Normal free:236608kB min:3140kB low:3924kB high:4708kB active:181808kB inactive:165416kB p
resent:633432kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
DMA: 411*4kB 296*8kB 139*16kB 47*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4
096kB = 7804kB
Normal: 14106*4kB 13532*8kB 3239*16kB 618*32kB 5*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2
048kB 0*4096kB = 236856kB
Swap cache: add 501558, delete 496210, find 606100/638626, race 0+403
Free swap = 1900244kB
Total swap = 1959920kB
Free swap: 1900244kB
163700 pages of RAM
0 pages of HIGHMEM
2327 reserved pages
37816 pages shared
5348 pages swap cached
25 pages dirty
0 pages writeback
10488 pages mapped
7661 pages slab
425 pages pagetables
ivtv1: Couldn't allocate buffers for encoder MPEG stream
ivtv1: Error -12 setting up streams
ivtv1: Error -12 on initialization
ivtv: probe of 0000:03:09.0 failed with error -12
ivtv: ==================== END INIT IVTV ====================

MemTotal: 645800 kB
MemFree: 246736 kB
Buffers: 8716 kB
Cached: 218256 kB
SwapCached: 21392 kB
Active: 188456 kB
Inactive: 163684 kB
SwapTotal: 1959920 kB
SwapFree: 1900244 kB
Dirty: 8 kB
Writeback: 8 kB
AnonPages: 124040 kB
Mapped: 41788 kB
Slab: 27556 kB
SReclaimable: 16828 kB
SUnreclaim: 10728 kB
PageTables: 1704 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 2282820 kB
Committed_AS: 428192 kB
VmallocTotal: 384724 kB
VmallocUsed: 25076 kB
VmallocChunk: 338640 kB

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868

Attachments:

signature.asc (0.18 KB)

amcnabb at mcnabbs

Feb 9, 2007, 5:58 PM

Post #15 of 16 (3270 views)
Permalink

Re: [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Fri, Feb 09, 2007 at 06:35:13PM -0700, Andrew McNabb wrote:
>
> modprobe: page allocation failure. order:4, mode:0xd0

I rebooted, and the driver was able to load. I'm not sure why that
helped, but it seemed to.

It looks like the error about the MPEG stream buffers being full is gone
in this version of ivtv. I'll have to keep an eye on it for a while
longer to tell for sure, but things are looking good.

However, I still seem to be getting the error:

ivtv1: All encoder VBI stream buffers are full. Dropping data.
ivtv1: Cause: the application is not reading fast enough.

although it's not nearly as common as it was on the old beta driver.
I'm also getting some flickering (as I did in the old beta driver),
which I assume is related. It seems like there's less flickering than
there was earlier, so things have definitely improved.

Anyway, I just thought I'd give some feedback. Thank you, Hans, for all
of your work with this driver. I really appreciate it.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868

Attachments:

signature.asc (0.18 KB)

amcnabb at mcnabbs

Feb 9, 2007, 6:04 PM

Post #16 of 16 (3265 views)
Permalink

Re: [RC1] Released ivtv-0.10.0rc1: please test this first release candidate! [In reply to]

On Fri, Feb 09, 2007 at 06:35:13PM -0700, Andrew McNabb wrote:
>
> I installed the new driver (make; make install; depmod -a) and did a
> "modprobe -r ivtv". Unfortunately, I'm getting a memory allocation
> error. I got the following output in dmesg, which I've followed with
> the output from /proc/meminfo. Nothing else on the system seems too
> unusual. Am I doing anything obviously wrong? Thanks.

> modprobe: page allocation failure. order:4, mode:0xd0

I just did a modprobe -r to change some driver settings, and I'm getting
these again. I hope I don't have to reboot every time I change a driver
setting. :(

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868

Attachments:

signature.asc (0.18 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads