Hi,
Tyler Trafford wrote:
Bryan Mayland wrote:
Morten Rnseth wrote:
Hah! I found
"/lib/modules/2.6.8.1-12mdk/kernel/drivers/media/video/tda9887.ko.gz"
- and I thought I'd gotten rid of all doubles... Would this one interfer?
I'll take a closer look tomorrow, too late
Hi,
I'm guessing that the I2C defined parameters are done in the 'obsolete
style' in Morten's kernel version, causing it to ignore all
non-obsoletely-defined ones.
BTW, what exactly is the difference between new-style parameters and
obsolete ones?
Cheers,
-Morten
--
Morten Rønseth wrote:
Hi,
I'm guessing that the I2C defined parameters are done in the 'obsolete
style' in Morten's kernel version, causing it to ignore all
non-obsoletely-defined ones.
BTW, what exactly is the difference between new-style parameters and
obsolete ones?
Theyare
Tyler Trafford wrote:
I'm guessing that the I2C defined parameters are done in the 'obsolete
style' in Morten's kernel version, causing it to ignore all
non-obsoletely-defined ones.
Ah yes, I didn't even think about that (even though he clearly
posted it in his log).
Actually, there's
Bryan Mayland wrote:
Proving once again that I can't produce a working patch before noon. I
got the #if backward so it defined new-style params on old systems and
old-style params on new systems. This patch has it the right way.
Index: driver/tda9887.c
Hi Bryan,
Bryan Mayland wrote:
Bryan Mayland wrote:
Proving once again that I can't produce a working patch before noon.
I got the #if backward so it defined new-style params on old systems
and old-style params on new systems. This patch has it the right way.
Hmmm - seems my system
Morten Rønseth wrote:
Hmmm - seems my system doesn't like the patch:
Gah! I thought these were defined in 2.6 series' tuner.h.
Apparently they didn't make it in until recently. Try patch #3!
Index: driver/tda9887.c
===
---
Hi :-)
Bryan Mayland wrote:
Morten Rønseth wrote:
Hmmm - seems my system doesn't like the patch:
Gah! I thought these were defined in 2.6 series' tuner.h.
Apparently they didn't make it in until recently. Try patch #3!
Uhm - sorry to be the bearer of bad omens, but I don't have
OK, never mind the bollocks, I'm a babbling fool. This did the
trick, Bryan, just what the doctor ordered. First impressions are
great, later tonight I'll give it the wife's stress testing :-)
Thanks!
Cheers,
-Morten
Bryan Mayland wrote:
Morten
Rnseth wrote:
Hmmm - seems my
Hi Bryan,
Bryan Mayland wrote:
Morten
Rnseth wrote:
I've just tried that - seems like it's
the cx25840 module that makes anything above 0.3.5 fail. After I load
0.3.5, I unload everything except the cx25840 module (ivtv, wm8775,
tveeprom tuner, in that order - anything else I
Morten Rønseth wrote:
This worked - almost :-) I get picture, but I seem to get vertical
ghosting - there seem to be slight ghosting shadows over under any
given point on the screen (almost like antialiasing), it is very
obvious when looking at letters.
Now we're getting somewhere!
Tyler Trafford wrote:
It turns out that kernels = 2.6.8 don't honor the INSTALL_MOD_DIR parameter.
Hey, you learn something every day. Growing up on old linux kernel
building (2.0-2.4), the 2.6 build process confuses and scares me. Damn
progresss!
Hi Bryan,
Bryan Mayland wrote:
Morten Rønseth wrote:
This worked - almost :-) I get picture, but I seem to get vertical
ghosting - there seem to be slight ghosting shadows over under
any given point on the screen (almost like antialiasing), it is very
obvious when looking at letters.
Morten Rønseth wrote:
Bullseye...! 10 out of 10 for style and precision :-)
Works great. I'm with my (rather active) 20 month old son right now,
so I'll test it some more later tonight. So far so good, love it!
Awesome news. When you get time: Do you have any module options set
in
Bryan Mayland wrote:
Morten Rønseth wrote:
Bullseye...! 10 out of 10 for style and precision :-)
Works great. I'm with my (rather active) 20 month old son right now,
so I'll test it some more later tonight. So far so good, love it!
Awesome news. When you get time: Do you have any
Morten Rønseth wrote:
As it turns out, I'm not using tda9887 - I have an udefined symbol
msleep_interruptible when compiling/loading and ivtv doesn't seem to
need it either. Anything else I could do?
hehe, you're blowing my mind! I'm hoping that this is because your
tda9887 is the 0.3.5
Bryan Mayland wrote:
Morten Rønseth wrote:
As it turns out, I'm not using tda9887 - I have an udefined symbol
msleep_interruptible when compiling/loading and ivtv doesn't seem
to need it either. Anything else I could do?
hehe, you're blowing my mind! I'm hoping that this is because
Morten Rønseth wrote:
I just sussed it.
My kernel version is 2.6.8.1-12mdk - tda9887.c, line 548 defines
msleep_iterruptible iff version is 2.6.7 or older. Don't know why, but
I seem to need it, version 2.6.8 ( can't believe I haven't seen this
before...). I changed the 7 to an 8 and voila!
Bryan Mayland wrote:
Morten Rønseth wrote:
I just sussed it.
My kernel version is 2.6.8.1-12mdk - tda9887.c, line 548 defines
msleep_iterruptible iff version is 2.6.7 or older. Don't know why,
but I seem to need it, version 2.6.8 ( can't believe I haven't seen
this before...). I changed
Hi Bryan,
Good work! Now comes the real test. Back out the magic patch I
posted for you, unload all the relevant modules and see if it goes
from scratch. Differences from the current ivtv release should be:
-- cx25840 line 221 should be commented out. (ACFG_DIS(0x01))
done
--
Morten Rønseth wrote:
Seems I was wrong. Without the black magic hack, every other channel
is mute, whilst others are audible as they should be. No pattern I
could find, but I'm sure there is a one.
WITH the hack, all is OK.
Can you try it without the hack and:
options tda9887 port1=0
Hi Bryan,
Bryan Mayland wrote:
Morten Rønseth wrote:
Seems I was wrong. Without the black magic hack, every other channel
is mute, whilst others are audible as they should be. No pattern I
could find, but I'm sure there is a one.
WITH the hack, all is OK.
Can you try it without the
Morten Rønseth wrote:
Can you try it without the hack and:
options tda9887 port1=0 port2=0
I get
tda9887: Unknown parameter `port1'
tda9887: Ignoring new-style parameters in presence of obsolete ones
Ack, you're kidding me. Well now I'm just confused (as if this
whole thing wasn't
Hi Bryan,
Bryan Mayland wrote:
Morten Rønseth wrote:
Can you try it without the hack and:
options tda9887 port1=0 port2=0
I get
tda9887: Unknown parameter `port1'
tda9887: Ignoring new-style parameters in presence of obsolete ones
Ack, you're kidding me. Well now I'm just
Morten Rønseth wrote:
Hah! I found
/lib/modules/2.6.8.1-12mdk/kernel/drivers/media/video/tda9887.ko.gz
- and I thought I'd gotten rid of all doubles... Would this one interfer?
I'll take a closer look tomorrow, too late now...going to bed, I'm
afraid.
It certainly could. Can't wait to
Hi,
Just couldn't stay away...
Bryan Mayland wrote:
Morten Rønseth wrote:
Hah! I found
/lib/modules/2.6.8.1-12mdk/kernel/drivers/media/video/tda9887.ko.gz
- and I thought I'd gotten rid of all doubles... Would this one
interfer?
I'll take a closer look tomorrow, too late now...going to
Bryan Mayland wrote:
Morten Rønseth wrote:
Hah! I found
/lib/modules/2.6.8.1-12mdk/kernel/drivers/media/video/tda9887.ko.gz
- and I thought I'd gotten rid of all doubles... Would this one interfer?
I'll take a closer look tomorrow, too late now...going to bed, I'm
afraid.
It
Hi,
Bryan Mayland wrote:
Tyler Trafford wrote:
If 0.3.5 is the last, then this must be more 'black magic' (tda9887)
fallout.
I would think that too, but that only messed with the audio. His
picture is wonky too.
This could be unrelated to your problem, but these are not messages
Tyler Trafford wrote:
Bryan Mayland wrote:
Tyler Trafford wrote:
If 0.3.5 is the last, then this must be more 'black magic' (tda9887) fallout.
I would think that too, but that only messed with the audio. His
picture is wonky too.
If he loads
Morten Rønseth wrote:
This is true though. Might want to do a
find /lib/modules/`uname -r` -name cx25840*
And see if you've got more than one version.
Here is the output:
[EMAIL PROTECTED] IVTV]$ sudo find /lib/modules/`uname -r` -name
cx25840*
Hi,
Bryan Mayland wrote:
Morten Rønseth wrote:
This is true though. Might want to do a
find /lib/modules/`uname -r` -name cx25840*
And see if you've got more than one version.
Here is the output:
[EMAIL PROTECTED] IVTV]$ sudo find /lib/modules/`uname -r` -name
cx25840*
Hi,
Tyler Trafford wrote:
Morten Rnseth wrote:
Output from /var/log/messages:
ivtv: START INIT IVTV
ivtv: version 0.3.6 (q) loading
ivtv: Linux version: 2.6.8.1-12mdk 686 gcc-3.4
cx25840: FW image
Morten Rønseth wrote:
Could it be becuase after loading 0.3.5 I only unload the ivtv module
before loading 0.3.6q ?
Ah! Yes. When you rmmod only ivtv, it leaves everything else
behind, so the cx25840 from 0.3.5 stays resident. Try removing that one
too when you switch versions.
Hi,
Bryan Mayland wrote:
Morten Rønseth wrote:
Could it be becuase after loading 0.3.5 I only unload the ivtv module
before loading 0.3.6q ?
Ah! Yes. When you rmmod only ivtv, it leaves everything else
behind, so the cx25840 from 0.3.5 stays resident. Try removing that
one too
Morten Rønseth wrote:
I've just tried that - seems like it's the cx25840 module that makes
anything above 0.3.5 fail. After I load 0.3.5, I unload everything
except the cx25840 module (ivtv, wm8775, tveeprom tuner, in that
order - anything else I should know of?), then load 0.3.6q. It works.
Hi,
Chris Kennedy wrote:
To get VBI working do this...
run...
ivtvctl -w cc,wss; ivtvctl -b cc,wss; ivtvctl -x 1
then turn on CC support in your TV set, so CC is displayed on output,
check normal TV to confirm this is on.
Then cat /dev/video0 /dev/video16 or any other form of encoding
Morten Rønseth wrote:
ioctl IVTV_IOC_S_VBI_EMBED failed: Invalid argument
This is because the cx25840-based cards (150 and 500) don't have
sliced VBI support in the driver (or at least so says the error message
in the code):
ivtv: Sliced VBI not supported for cx25840 so no vbi
Hi Bryan,
Bryan Mayland wrote:
Morten Rønseth wrote:
ioctl IVTV_IOC_S_VBI_EMBED failed: Invalid argument
This is because the cx25840-based cards (150 and 500) don't have
sliced VBI support in the driver (or at least so says the error
message in the code):
ivtv: Sliced VBI not
Bryan Mayland wrote:
Morten Rønseth wrote:
BTW, I'd love for the 0.3.6 series to be able to start my pvr150
correctly after a cold boot - the last version that does is 0.3.5. (re
pvr150 only capturing noise). :-)
What kind of noise are you seeing? A screen full of static or is it
Tyler Trafford wrote:
If 0.3.5 is the last, then this must be more 'black magic' (tda9887) fallout.
I would think that too, but that only messed with the audio. His
picture is wonky too.
This could be unrelated to your problem, but these are not messages
from the cx25840.ko included
Bryan Mayland wrote:
Tyler Trafford wrote:
If 0.3.5 is the last, then this must be more 'black magic' (tda9887) fallout.
I would think that too, but that only messed with the audio. His
picture is wonky too.
If he loads 0.3.5, unloads, and then loads 0.3.5a - it works, but
0.3.5a
To get VBI working do this...
run...
ivtvctl -w cc,wss; ivtvctl -b cc,wss; ivtvctl -x 1
then turn on CC support in your TV set, so CC is displayed on output,
check normal TV to confirm this is on.
Then cat /dev/video0 /dev/video16 or any other form of encoding from
the card and decoding
I don't need to leave the passthrough option on for normal operation
(i.e. watching pre-recorded shows via MythTV), do I?
I do get some kind of CC signal coming through using the options you
listed, but it's really garbled and only about 5% of it is
understandable. Also, my TV is 4:3 - do I
I have no answers, but I wanted to chime in and let the developers know
that I am yet another user who is very interested in Closed Caption
support via the PVR-350 as well. I'm willing to wait if it's coming, but
if there's no indication that it's at least being worked on then I'll
have to
44 matches
Mail list logo
