2.6.11-mm2 vs audio for kino and tvtime

2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

Greetings Andrew;

2.6.11-mm2 seems to work, mostly.

First, the ieee1394 stuff seems to have fixed up that driver, and kino 
can access my movie cameras video over the firewire very nicely 
without applying the bk-ieee1394-patch.  The camera has builtin 
stereo mics in it, but nary a peep can be heard from it thru the 
firewire.  Am I supposed to be able to hear that?

Second, I have a pdHDTV-3000 card, and up till now I've been 
overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz by 
doing a make clean;make;make install.  But now thats broken, and the 
error message doesn't seem to make sense to this old K&R C guy.

The error exit:
make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
  CC 
[M]  /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: 
error: unknown field `id' specified in initializer
/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: 
warning: missing braces around initializer
/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: 
warning: (near initialization for 
`bttv_i2c_client_template.released')
make[2]: *** 
[/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o] 
Error 1
make[1]: *** 
[_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] Error 
2
make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
make: *** [modules] Error 2

The braces are indeed there.

Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've lost 
my sensors except for one on the motherboard called THRM by 
gkrellm-2.28.  Nothing seems to be able to bring the w83627hf back to 
life.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Andrew Morton]

Gene Heskett <gene.heskett@verizon.net> wrote:
>
> Greetings Andrew;

g'day.

> 2.6.11-mm2 seems to work, mostly.
> 
> First, the ieee1394 stuff seems to have fixed up that driver, and kino 
> can access my movie cameras video over the firewire very nicely 
> without applying the bk-ieee1394-patch.  The camera has builtin 
> stereo mics in it, but nary a peep can be heard from it thru the 
> firewire.  Am I supposed to be able to hear that?

Was it working with 2.6.11+bk-ieee1394.patch?  Or with anything else?

Cc'ed linux1394-devel@lists.sourceforge.net

> Second, I have a pdHDTV-3000 card, and up till now I've been 
> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz by 
> doing a make clean;make;make install.  But now thats broken, and the 
> error message doesn't seem to make sense to this old K&R C guy.
>
> The error exit:
> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
>   CC 
> [M]  /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: 
> error: unknown field `id' specified in initializer
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: 
> warning: missing braces around initializer
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: 
> warning: (near initialization for 
> `bttv_i2c_client_template.released')
> make[2]: *** 
> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o] 
> Error 1
> make[1]: *** 
> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] Error 
> 2
> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
> make: *** [modules] Error 2
> 
> The braces are indeed there.

What's pcHDTV-1.6.tar.gz?  If it was merged up then these things wouldn't
happen.

CC'ed video4linux-list@redhat.com

> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've lost 
> my sensors except for one on the motherboard called THRM by 
> gkrellm-2.28.  Nothing seems to be able to bring the w83627hf back to 
> life.

CC'ed sensors@Stimpy.netroedge.com

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Wednesday 09 March 2005 01:44, Andrew Morton wrote:
>Gene Heskett <gene.heskett@verizon.net> wrote:
>> Greetings Andrew;
>
>g'day.
>
g'day to you, sir.

>> 2.6.11-mm2 seems to work, mostly.
>>
>> First, the ieee1394 stuff seems to have fixed up that driver, and
>> kino can access my movie cameras video over the firewire very
>> nicely without applying the bk-ieee1394-patch.  The camera has
>> builtin stereo mics in it, but nary a peep can be heard from it
>> thru the firewire.  Am I supposed to be able to hear that?
>
>Was it working with 2.6.11+bk-ieee1394.patch?  Or with anything
> else?

It did work previously with the svn download from the ieee1394 site 
for the kernels in the series of RT stuff that Ingo Molnar was 
working on.  Also, since I posted this, I tried catting a .wav file 
to /dev/dsp, which is the output that kino is expecting to use, and 
that sort of worked, playing the file at half speed and pitch.  So I 
believe its the upload from the camera, and the stripping of the 
audio data from the stream from the camera thats at fault.  But thats 
just a SWAG on my part, & I probably should not have used the S 
there. :)

>Cc'ed linux1394-devel@lists.sourceforge.net
>
>> Second, I have a pdHDTV-3000 card, and up till now I've been
>> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz
>> by doing a make clean;make;make install.  But now thats broken,
>> and the error message doesn't seem to make sense to this old K&R C
>> guy.
>>
>> The error exit:
>> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
>>   CC
>> [M] 
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: missing braces around initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: (near initialization for
>> `bttv_i2c_client_template.released')
>> make[2]: ***
>> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o]
>> Error 1
>> make[1]: ***
>> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver]
>> Error 2
>> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
>> make: *** [modules] Error 2
>>
>> The braces are indeed there.
>
>What's pcHDTV-1.6.tar.gz?  If it was merged up then these things
> wouldn't happen.
>
This is the latest driver set for this card, downloadable from the 
pcHDTV site.  It overwrites, when it builds and installs, the bttv 
and cx88xx stuffs in the modules dir.  And it has worked up to 
2.6.11-mm2, but I didn't get around to trying mm1. It worked with the 
last of the RT's from Ingo, and for 2.6.11(.1).

>CC'ed video4linux-list@redhat.com
>> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
>> lost my sensors except for one on the motherboard called THRM by
>> gkrellm-2.28.  Nothing seems to be able to bring the w83627hf back
>> to life.

I'm back on 2.6.11-rc5 and thats working as expected now.

>CC'ed sensors@Stimpy.netroedge.com

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Jean Delvare]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hi Gene, Andrew, all,

(Gene, note that I cannot write to you directly because Verizon are
idiots. Let's just hope you'll read that.)

[Gene Heskett]
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
> error: unknown field `id' specified in initializer

I've dropped the "id" member of struct i2c_client, as it were useless.
Third-party driver authors now need to do the same.

Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push the
latter to the author of hdPCTV. Note that the removed struct member was
really not used before, so the driver will still work with earlier
kernels.

[Andrew Morton]
> What's pcHDTV-1.6.tar.gz?  If it was merged up then these things
> wouldn't happen.

I second that, especially since the pcHDTV package is made up of
modified bttv and cx88 drivers, not an original driver. Merging the
changes into the kernel would obviously make everyone's life easier.

As a side note, I have (many) other changes to the i2c subystem in my
plans, some of them are rather intrusive, so expect pcHDTV to break
again soon, unless it gets merged until then.

[Gene Heskett]
> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
> lost my sensors except for one on the motherboard called THRM by
> gkrellm-2.28.  Nothing seems to be able to bring the w83627hf back
> to life.

THRM is most likely a temperature you get from /proc/acpi/thermal_zone,
and isn't related with the w83627hf driver.

I think that you are affected by recent changes made by the ACPI folks
to the way resources are reserved. See bug #4014:
  http://bugzilla.kernel.org/show_bug.cgi?id=4014

You can check /proc/ioports on the working system after loading
w83627hf, and compare with /proc/ioports on the non-working system. I'd
expect you to find that the non-working system has reserved a subrange
of what the w83627hf driver attempts to grab, making it fail.

-- 
Jean Delvare

[-- Attachment #2: pcHDTV-1.6-kill-i2c-client-id.diff --]
[-- Type: text/plain, Size: 829 bytes --]

diff -u -rN pcHDTV-1.6/kernel-2.6.x/driver.orig/bttv-i2c.c pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c
--- pcHDTV-1.6/kernel-2.6.x/driver.orig/bttv-i2c.c	Fri Dec 10 19:42:38 2004
+++ pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c	Wed Mar  9 13:52:24 2005
@@ -359,7 +359,6 @@
 
 static struct i2c_client bttv_i2c_client_template = {
 	I2C_DEVNAME("bttv internal"),
-        .id       = -1,
 };
 
 
diff -u -rN pcHDTV-1.6/kernel-2.6.x/driver.orig/cx88-i2c.c pcHDTV-1.6/kernel-2.6.x/driver/cx88-i2c.c
--- pcHDTV-1.6/kernel-2.6.x/driver.orig/cx88-i2c.c	Fri Dec 10 19:42:39 2004
+++ pcHDTV-1.6/kernel-2.6.x/driver/cx88-i2c.c	Wed Mar  9 13:51:19 2005
@@ -136,7 +136,6 @@
 
 static struct i2c_client cx8800_i2c_client_template = {
         I2C_DEVNAME("cx88xx internal"),
-        .id   = -1,
 };
 
 /* init + register i2c algo-bit adapter */

[-- Attachment #3: pcHDTV-2.0-kill-i2c-client-id.diff --]
[-- Type: text/plain, Size: 1702 bytes --]

diff -u -rN pcHDTV-2.0.orig/bttv-i2c.c pcHDTV-2.0/bttv-i2c.c
--- pcHDTV-2.0.orig/bttv-i2c.c	Fri Feb 18 21:54:35 2005
+++ pcHDTV-2.0/bttv-i2c.c	Wed Mar  9 13:56:34 2005
@@ -317,7 +317,6 @@
 
 static struct i2c_client bttv_i2c_client_template = {
 	I2C_DEVNAME("bttv internal"),
-        .id       = -1,
 };
 
 
diff -u -rN pcHDTV-2.0.orig/cx88-i2c.c pcHDTV-2.0/cx88-i2c.c
--- pcHDTV-2.0.orig/cx88-i2c.c	Fri Feb 18 21:54:38 2005
+++ pcHDTV-2.0/cx88-i2c.c	Wed Mar  9 13:56:58 2005
@@ -142,7 +142,6 @@
 
 static struct i2c_client cx8800_i2c_client_template = {
         I2C_DEVNAME("cx88xx internal"),
-        .id   = -1,
 };
 
 static char *i2c_devs[128] = {
diff -u -rN pcHDTV-2.0.orig/dpl3518.c pcHDTV-2.0/dpl3518.c
--- pcHDTV-2.0.orig/dpl3518.c	Fri Feb 18 21:54:36 2005
+++ pcHDTV-2.0/dpl3518.c	Wed Mar  9 13:57:11 2005
@@ -374,7 +374,6 @@
 static struct i2c_client client_template =
 {
         I2C_DEVNAME("dpl3518"),
-        .id         = -1,
         .driver     = &driver
 };
 
diff -u -rN pcHDTV-2.0.orig/saa7134-i2c.c pcHDTV-2.0/saa7134-i2c.c
--- pcHDTV-2.0.orig/saa7134-i2c.c	Fri Feb 18 21:54:36 2005
+++ pcHDTV-2.0/saa7134-i2c.c	Wed Mar  9 13:57:22 2005
@@ -361,7 +361,6 @@
 
 static struct i2c_client saa7134_client_template = {
 	I2C_DEVNAME("saa7134 internal"),
-        .id        = -1,
 };
 
 /* ----------------------------------------------------------- */
diff -u -rN pcHDTV-2.0.orig/tda9875.c pcHDTV-2.0/tda9875.c
--- pcHDTV-2.0.orig/tda9875.c	Fri Feb 18 21:54:38 2005
+++ pcHDTV-2.0/tda9875.c	Wed Mar  9 13:57:42 2005
@@ -418,7 +418,6 @@
 static struct i2c_client client_template =
 {
         I2C_DEVNAME("tda9875"),
-        .id        = -1,
         .driver    = &driver,
 };
 

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Wednesday 09 March 2005 14:33, Jean Delvare wrote:
>Hi Gene, Andrew, all,
>
>(Gene, note that I cannot write to you directly because Verizon are
>idiots. Let's just hope you'll read that.)

Got it, & can't argue with that label.  Some of the labels I've 
applied to them are even more 'colorfull'.. Unforch, they are the 
*only* game in this town. :-(

>[Gene Heskett]
>
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>
>I've dropped the "id" member of struct i2c_client, as it were
> useless. Third-party driver authors now need to do the same.

Aha!  As in just 'dd' any line containing the .id in vim?

>Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push
> the latter to the author of hdPCTV. Note that the removed struct
> member was really not used before, so the driver will still work
> with earlier kernels.

Good.  But where did you get the 2.0?  My 1.6 is only 2 weeks old here 
as thats about as long as I've had the card, but I haven't checked 
the dl page on Jacks site since yesterday sometime...

Humm, I see its labeled as for FC3, but since the kernel I'm booted to 
right now is linux-2.6.11.2-RT-V0.7.39-02, I'm going to make the 
assumption that I can use it till I find otherwise.

That kernel is locally built, using these patches, from my script:
VERP1="../2.6.11.1"
VERP2="../2.6.11.2"
VERP3="../2.6.11.2-RT-V0.7.39-02"
VERP4="../bk-ieee1394.patch"
VERP5="../2.6.11-forcedeth-fix"
VERP6="../Kconfig-1-patch"
VERP7="../Kconfig-2-patch"

The last 3 remove the '&& EXPERIMENTAL' from the respective Kconfigs 
for nforce2 stuffs.  If its not 'stable' yet, then lets get them 
fixed, this keeping stuff in experimental forever when half the 
planet is using them without any reported gotchas for extended 
periods just plain sucks.  So does the lag in getting 
bk-ieee1394.patch into mainline.  Firewire has been broken for quite 
a few moons now, so I fail to see the reason for the lag when the 
patch itself is demonstratably working great.  My hats off to Dan 
Dennedy & company there.

The only thing that didn't apply clean was Ingo's last RT patch, I 
dropped the ball on the EXTRAVERSION it was looking for in the main 
Makefile.  But vim fixed that right up after the fact.

So basicly, I'm cutting a fresh trail here, trying to scratch my 
personal itches and its not working too bad.  Not bad for an old 
fart.  I'll go see if the pcHDTV-2.0 version for kernels >2.6.9 works 
now, and get back to the list.  Thanks for the heads up on that.

>[Andrew Morton]
>
>> What's pcHDTV-1.6.tar.gz?  If it was merged up then these things
>> wouldn't happen.
>
>I second that, especially since the pcHDTV package is made up of
>modified bttv and cx88 drivers, not an original driver. Merging the
>changes into the kernel would obviously make everyone's life easier.
>
>As a side note, I have (many) other changes to the i2c subystem in
> my plans, some of them are rather intrusive, so expect pcHDTV to
> break again soon, unless it gets merged until then.

I'll second that, this having to do everything to build a new kernel 
twice before its actually built and working is a major PITA.  I'm 
also doing the same thing with the spca5xx stuffs for a webcam.

Silly Q?  How much trouble would it be for me to just copy over the 
revelant src code modules once the patch has been applied?  I could 
make that bit of copying a part of my buildit26 script, a snippet of 
which you see above.  This is my src code tree builder.

>[Gene Heskett]
>
>> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
>> lost my sensors except for one on the motherboard called THRM by
>> gkrellm-2.28.  Nothing seems to be able to bring the w83627hf back
>> to life.
>
>THRM is most likely a temperature you get from
> /proc/acpi/thermal_zone, and isn't related with the w83627hf
> driver.

Humm, it is the highest temp reported, as is temp2 in gkrellm, so I 
had assumed it was somehow a dup of the diode in the cpu, or of the 
thermistor against the bottom of it inside the socket.  Wrong 
assumption?

But I just in the last half hour managed to get it working again!

Somehow, in my playing with the CONFIG_BROKEN, (if you have an nforce2 
equipt board, never, ever, uncheck that option, its friggin dangerous 
to your sanity!) the building of the i2c-isa got erased from 
the .config.  Modularizing everything I needed, making sure the 
correct modprobe lines were in my rc.local, and fetching and 
installing the user portions of lm_sensors-2.9.0 to replace the 2.8.7 
stuff, and its suddenly working.

So now, sensors is working, as is gkrellm, and kino is working audio 
and all, but tvtime suddenly has a 2 second delay in anything it does 
including its on-screen clock sitting on a blue screen.  No video, 
just audio.

>I think that you are affected by recent changes made by the ACPI
> folks to the way resources are reserved. See bug #4014:
>  http://bugzilla.kernel.org/show_bug.cgi?id=4014
>
I haven't looked at that yet.

>You can check /proc/ioports on the working system after loading
>w83627hf, and compare with /proc/ioports on the non-working system.
> I'd expect you to find that the non-working system has reserved a
> subrange of what the w83627hf driver attempts to grab, making it
> fail.

Its working again, see above.

Many, many thanks to Jean D., and all on this.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Wednesday 09 March 2005 14:33, Jean Delvare wrote:
>Hi Gene, Andrew, all,
>[Gene Heskett]
>
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>
>I've dropped the "id" member of struct i2c_client, as it were
> useless. Third-party driver authors now need to do the same.
>
>Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push
> the latter to the author of hdPCTV. Note that the removed struct
> member was really not used before, so the driver will still work
> with earlier kernels.

I unpacked and patched the pcHDTV-2.0 driver kit, but the make bails 
out with this:

/usr/src/pcHDTV-2.0/cx88-cards.c: In function `hauppauge_eeprom_dvb':
/usr/src/pcHDTV-2.0/cx88-cards.c:772: warning: control reaches end of 
non-void function
[...]

That one I may be able to fix, probably a braces error.
Then 10 lines or so later:

 CC [M]  /usr/src/pcHDTV-2.0/saa7134-tvaudio.o
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c: In function 
`saa7134_tvaudio_init2':
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: warning: implicit 
declaration of function `DECLARE_MUTEX_LOCKED'
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: error: `sem' undeclared 
(first use in this function)
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: error: (Each undeclared 
identifier is reported only once
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: error: for each function it 
appears in.)
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:989: warning: ISO C90 forbids 
mixed declarations and code
make[2]: *** [/usr/src/pcHDTV-2.0/saa7134-tvaudio.o] Error 1
make[1]: *** [_module_/usr/src/pcHDTV-2.0] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.11.2-RT-V0.7.39-02'
make: *** [default] Error 2

Header file error?

I'll go try the 1.6 patch now.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Wednesday 09 March 2005 14:33, Jean Delvare wrote:
>Hi Gene, Andrew, all,
>[Gene Heskett]
>
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>
>I've dropped the "id" member of struct i2c_client, as it were
> useless. Third-party driver authors now need to do the same.
>
>Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push
> the latter to the author of hdPCTV. Note that the removed struct
> member was really not used before, so the driver will still work
> with earlier kernels.

The 1.6 patch won't apply due to -pn problems, so I did it by hand.
It now builds and installs ok, but tvtime is still dead, taking about 
5 seconds to open its initial window, and another 15 to display just 
the channel and time on a permanent blue screen, with its time 
display only being updated about every 3 seconds.  Audio works ok.
Clicking on the exit also takes about 5 seconds for it to quit.
Running it from a shell with the -vv doesn't show any problems that 
look like showstoppers:
---------
[root@coyote driver]# tvtime -vv
Running tvtime 0.9.15.
Reading configuration from /etc/tvtime/tvtime.xml
Reading configuration from /root/.tvtime/tvtime.xml
cpuinfo: CPU AMD Athlon(tm) XP 2800+, family 6, model 10, stepping 0.
cpuinfo: CPU measured at 2079.706MHz.
xcommon: Display :0.0, vendor The X.Org Foundation, vendor release 
60801901
xfullscreen: Single-head detected, pixel aspect will be calculated.
xfullscreen: Pixel aspect ratio on the primary head is: 1/1 == 1.00.
xfullscreen: Using the XFree86-VidModeExtension to calculate 
fullscreen size.
xfullscreen: Fullscreen to 0,0 with size 1600x1200.
xcommon: Have XTest, will use it to ping the screensaver.
xcommon: Pixel aspect ratio 1:1.
xcommon: Pixel aspect ratio 1:1.
xcommon: Window manager is KWin and is EWMH compliant.
xcommon: Using EWMH state fullscreen property.
xcommon: Using EWMH state above property.
xcommon: Using EWMH state below property.
xcommon: Pixel aspect ratio 1:1.
xcommon: Displaying in a 768x576 window inside 768x576 space.
xvoutput: Using XVIDEO adaptor 69: ATI Radeon Video Overlay.
speedycode: Using MMXEXT optimized functions.
station: Reading stationlist from /root/.tvtime/stationlist.xml
videoinput: Using video4linux2 driver 'cx8800', card 'pcHDTV HD3000 
HDTV' (bus PCI:0000:01:07.0).
videoinput: Version is 4, capabilities 5010011.
videoinput: Width 768 too high, using 640 instead as suggested by the 
driver.
videoinput: Maximum input width: 640 pixels.
tvtime: Sampling input at 640 pixels per scanline.
xcommon: Pixel aspect ratio 1:1.
xcommon: Displaying in a 768x576 window inside 768x576 space.
xcommon: Received a map, marking window as visible (71).
xcommon: Window fully obscured, marking window as hidden (71).
xcommon: Window made visible, marking window as visible (71).
------------
And unless the diff between 640 and 768 is the problem, there isn't 
much else to go on there.

Since this involves x, its xorg-6.8.1, locally built, and so far (4 
months?) absolutely dead stable.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Jean Delvare]

Hi Gene,

> > I've dropped the "id" member of struct i2c_client, as it were
> > useless. Third-party driver authors now need to do the same.
>
> Aha!  As in just 'dd' any line containing the .id in vim?

Exactly. Don't kill all lines with .id though, only the i2c_client id
was dropped, and there are plenty of other ids in the media/video
drivers.

> > THRM is most likely a temperature you get from
> > /proc/acpi/thermal_zone, and isn't related with the w83627hf
> > driver.
>
> Humm, it is the highest temp reported, as is temp2 in gkrellm, so I
> had assumed it was somehow a dup of the diode in the cpu, or of the
> thermistor against the bottom of it inside the socket.  Wrong
> assumption?

Not necessarily wrong. It is possible that the same diode temperature is
read from the W83627HF chip by both the ACPI subsystem and by the
w83627hf driver. But if this is the case, I would be worried by
concurrent I/O accesses to the chip, which could possibly cause trouble.

--
Jean Delvare

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Thursday 10 March 2005 03:52, Jean Delvare wrote:
>Hi Gene,
>
>> > I've dropped the "id" member of struct i2c_client, as it were
>> > useless. Third-party driver authors now need to do the same.
>>
>> Aha!  As in just 'dd' any line containing the .id in vim?
>
>Exactly. Don't kill all lines with .id though, only the i2c_client
> id was dropped, and there are plenty of other ids in the
> media/video drivers.

I found the patch location, it was off by about -30 lines after the 
other patches, and applied them.  It builds now, but still doesn't 
work, very slow screen updates and no video in tvtime.  It works 
properly with 2.6.11, 2.6.11.1, and 2.6.11.2.  As I didn't have the 
card until 2.6.11 was out, I should back up to the last rc4-RT, and 
see if this card will work with that. At least that will narrow the 
guilty patchset down a wee bit.  I'll try that later today if the 
honeydo's don't get in the way.

I noted last night too, that while my scanner worked, it was gawdawful 
slow at retrieving the data over the usb when running at a measly 
300dpi, 3 to 4 minutes for an 8.5x11, 23 MB of data (according to 
xsane) scan.  IIRC Its been only 45-50 seconds in past times.  So 
that may indicate a usb slowdown too, in the read path only.  The usb 
printer in 1440x1440 color was about its usual speed, needing a 
surveyer to measure page ejection progress. :)

That printer does very very nice indeed color work, but in those 
modes, theres no way to convince the frogs that an Epson C82 is 
faster than watching paint dry.  10 to 20 minutes a page depending on 
content.

OTOH, my output, after tweaking a few things, was a hell of a lot more 
brilliant than the page I scanned in!  (Plus the award recipients 
name is now spelled correctly, the reason for that little 3 hour 
exersize, ain't the gimp wunnerful?)

>> > THRM is most likely a temperature you get from
>> > /proc/acpi/thermal_zone, and isn't related with the w83627hf
>> > driver.
>>
>> Humm, it is the highest temp reported, as is temp2 in gkrellm, so
>> I had assumed it was somehow a dup of the diode in the cpu, or of
>> the thermistor against the bottom of it inside the socket.  Wrong
>> assumption?
>
>Not necessarily wrong. It is possible that the same diode
> temperature is read from the W83627HF chip by both the ACPI
> subsystem and by the w83627hf driver. But if this is the case, I
> would be worried by concurrent I/O accesses to the chip, which
> could possibly cause trouble.

I don't believe I'm seeing any evidence of that here.  OTOH, I don't 
run sensors very often when gkrellm is running.  Or are there other 
processes accessing through that bus that wouldn't play well?

>--
>Jean Delvare
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Wednesday 09 March 2005 01:44, Andrew Morton wrote:
>Gene Heskett <gene.heskett@verizon.net> wrote:
>> Greetings Andrew;
>
>g'day.
>
>> 2.6.11-mm2 seems to work, mostly.
>>
>> First, the ieee1394 stuff seems to have fixed up that driver, and
>> kino can access my movie cameras video over the firewire very
>> nicely without applying the bk-ieee1394-patch.  The camera has
>> builtin stereo mics in it, but nary a peep can be heard from it
>> thru the firewire.  Am I supposed to be able to hear that?
>
>Was it working with 2.6.11+bk-ieee1394.patch?  Or with anything
> else?

Yes, as long as that patch was applied.

>Cc'ed linux1394-devel@lists.sourceforge.net
>
>> Second, I have a pdHDTV-3000 card, and up till now I've been
>> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz
>> by doing a make clean;make;make install.  But now thats broken,
>> and the error message doesn't seem to make sense to this old K&R C
>> guy.
>>
>> The error exit:
>> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
>>   CC
>> [M] 
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: missing braces around initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: (near initialization for
>> `bttv_i2c_client_template.released')
>> make[2]: ***
>> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o]
>> Error 1
>> make[1]: ***
>> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver]
>> Error 2
>> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
>> make: *** [modules] Error 2
>>
>> The braces are indeed there.
>
>What's pcHDTV-1.6.tar.gz?  If it was merged up then these things
> wouldn't happen.
>
>CC'ed video4linux-list@redhat.com
>
>> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
>> lost my sensors except for one on the motherboard called THRM by
>> gkrellm-2.28.  Nothing seems to be able to bring the w83627hf back
>> to life.
>
>CC'ed sensors@Stimpy.netroedge.com

That I got, somewhere in trying to build a working kernel without the 
config_broken, i2c-isa got lost.  Restored that and all is well in 
that dept.

I've got 3 patches that remove the '&& EXPERIMENTAL' from the Kconfigs 
for the nforce2 stuffs, and even posted one here, but got .000zip 
response, so I don't know if they are welcome or not...
>
>--
>video4linux-list mailing list
>Unsubscribe
> mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime, now 2.6.12-rc1-mm1

[Gene Heskett]

On Monday 21 March 2005 18:37, Andrew Morton wrote:
>Gene Heskett <gene.heskett@verizon.net> wrote:
>> 2.6.11-mm2 seems to work, mostly.
>
>If you've tested 2.6.12-rc1-mm1 can you please send an update on
> your woes to linux-kernel?

Ok, got it built ok, but the reboot was hell, not of your doing 
though.  Someone had told me I could put a '-V' in a file 
called /fsckoptions and I'd get a bit more verbosity out of e2fsck.

I thought that might be a good thing and put an echo statement in my 
rc.local to regenerate that file.  Yup, attack of dumbass. I'd used 
the esc sequence to put an EOL on it, but that translated to a file 
containing '-V\n' which wasn't legal, so after looping around thru 
the reboot and dropping you to a shell thingies, and finding that I 
couldn't remount it rw under any circumstances I grabbed the rescue 
cd and got rid of all that.  So I'm just now rebooted to it.  So far 
it feels pretty good.

tvtime works, no audio glitches in the startup.  This is a pcHDTV-3000 
card, running in Never Twice Same Color mode as yet.

xsane works normally I believe, doing a preview scan ok.

kino works, but doesn't really want to time share with the much cpu 
hungrier tvtime, this results a very noticeable lag in the preview 
video coming in directly from the cameras imager via firewire, and 
sometimes an outright freeze of 2-3 seconds duration when kmail is 
makeing a mail fetch run.

spcagui works once I'd reinstalled the spca50x stuff

/. pops right up in mozilla-1.7.5, also in firefox

Those seem to be the main things of interest right now, to me.  

Anything else I should specifically check on this UP machine?

As I add content to this message, I am occasionally seeing lags 
between what I type and its showing up on the screen but its 
certainly better than 2.6.10 or 11 was by quite a ways.  This is 
related to the kino lags in that I believe its kmail's net access 
that is causeing them.

Overall, I don't have any instant squawks Andrew.  Looks good, 
generally feels good.  Itches might develop later though.  I'm using 
the cfq scheduler, were there any changes of note there?

-- 
Cheers Andrew & list, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime, now 2.6.12-rc1-mm1

[Andrew Morton]

Gene Heskett <gene.heskett@verizon.net> wrote:
>
> ...
> tvtime works, no audio glitches in the startup.  This is a pcHDTV-3000 
> card, running in Never Twice Same Color mode as yet.
> 
> xsane works normally I believe, doing a preview scan ok.

Whew.

> kino works, but doesn't really want to time share with the much cpu 
> hungrier tvtime, this results a very noticeable lag in the preview 
> video coming in directly from the cameras imager via firewire, and 
> sometimes an outright freeze of 2-3 seconds duration when kmail is 
> makeing a mail fetch run.

Is that unexpected?  Are there other kernels which you found better behaved
in this regard?  There are CPU scheduler changes in -mm, but they're
unlikely to affect UP or small SMP.

> spcagui works once I'd reinstalled the spca50x stuff
> 
> /. pops right up in mozilla-1.7.5, also in firefox
> 
> Those seem to be the main things of interest right now, to me.  
> 
> Anything else I should specifically check on this UP machine?
> 
> As I add content to this message, I am occasionally seeing lags 
> between what I type and its showing up on the screen but its 
> certainly better than 2.6.10 or 11 was by quite a ways.  This is 
> related to the kino lags in that I believe its kmail's net access 
> that is causeing them.

hm, OK.  Is much disk I/O happening during the lags?

> Overall, I don't have any instant squawks Andrew.  Looks good, 
> generally feels good.  Itches might develop later though.  I'm using 
> the cfq scheduler, were there any changes of note there?

Relative to 2.6.121-mm2?  Yes, CFQ underwent radical changes.

Re: 2.6.11-mm2 vs audio for kino and tvtime, now 2.6.12-rc1-mm1

[Gene Heskett]

On Monday 21 March 2005 21:56, Andrew Morton wrote:
>Gene Heskett <gene.heskett@verizon.net> wrote:
>> ...
>> tvtime works, no audio glitches in the startup.  This is a
>> pcHDTV-3000 card, running in Never Twice Same Color mode as yet.
>>
>> xsane works normally I believe, doing a preview scan ok.
>
>Whew.

:)

>> kino works, but doesn't really want to time share with the much
>> cpu hungrier tvtime, this results a very noticeable lag in the
>> preview video coming in directly from the cameras imager via
>> firewire, and sometimes an outright freeze of 2-3 seconds duration
>> when kmail is makeing a mail fetch run.
>
>Is that unexpected?

No. 

>Are there other kernels which you found better 
> behaved in this regard?  There are CPU scheduler changes in -mm,
> but they're unlikely to affect UP or small SMP.

Only 2.6.12-rc1 is comparable in "feel", and it will take me a while  
to reach a conclusion.  Stay tuned...
  
>> spcagui works once I'd reinstalled the spca50x stuff
>>
>> /. pops right up in mozilla-1.7.5, also in firefox
>>
>> Those seem to be the main things of interest right now, to me.
>>
>> Anything else I should specifically check on this UP machine?
>>
>> As I add content to this message, I am occasionally seeing lags
>> between what I type and its showing up on the screen but its
>> certainly better than 2.6.10 or 11 was by quite a ways.  This is
>> related to the kino lags in that I believe its kmail's net access
>> that is causeing them.
>
>hm, OK.  Is much disk I/O happening during the lags?

Not really, its spamassassins &^%$#@ perl scripts that are eating the 
cpu I think.

>> Overall, I don't have any instant squawks Andrew.  Looks good,
>> generally feels good.  Itches might develop later though.  I'm
>> using the cfq scheduler, were there any changes of note there?
>
>Relative to 2.6.121-mm2?  Yes, CFQ underwent radical changes.
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.11-mm2 vs audio for kino and tvtime

[Gene Heskett]

On Monday 21 March 2005 20:45, Andrew Morton wrote:
[...]
>> Lemme see if I've grabbed that patch, brb.  No, but I'll go get it
>> right now.  Got it.  Edited my two scripts and its building now.

After 2 days of running rc1-mm1, I've reverted to plain rc1, for one 
reason.  The last 2 days, its taken amdump/amverify till after 5am to 
finish, and its only done 2, instead of 3, units of setiathome, which 
is now shareing time with the einstein boinc project.

Running plain rc1, the amdump/amverify run was commonly done by a bit 
after 2am, starting at 1am, and seti was getting enough time to do 3 
units all the time. So an hour to hour & 45 max, to over 4 hours is 
the comparison there.

Note that we're talking mm1 here, not the mm2 in the subject line as 
it wasn't visible when I went after the patch at kernel.org. And 
there still is not an -mm2 there, so I assume that was a typu.

So while -mm1 didn't crash, and in fact was quite frugal with its 
memory use, so I haven't had the oom crashes some have reported.  It 
just isn't as fast by a noticable amount.

And I have no idea where to point fingers.  Running kino, there were 
many noticable instances of its video import being hung for at least 
a second at a time, something I haven't noticed with rc1 to anything 
near that extent.  A night and day difference, showstopper to usable  
there.

tvtime also had many more few stutters & skipped frames.  In either 
case, I'd often have to restart tvtime with the new settings to get 
decent audio, so there is no change there.

Scheduler?  DarnedifIknow.  All I could see was the canary getting 
sick, sorry. :(

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.