There appeares to be a broken driver out there
somewhere. Pick the ivtvdev_drv.o from one of Chris's
releases and use that one instead.
John
--- Dirk Schueller Moeller
[EMAIL PROTECTED] wrote:
I am setting up a MythTV-Box with a PVR350, using
the TV-OUT for X.
I have followed the
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Axel Thimm
Sent: 02 December 2004 19:32
To: [EMAIL PROTECTED]
Subject: [ivtv-devel] Re: Need help for X on TV-Out
In many ways the safest might be to get the original version again
Look in the wiki on the linked from ivtv.sourceforge.net. There is a page
about firmware versions there.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Bert Haverkamp
Sent: 02 December 2004 20:02
To: [EMAIL PROTECTED]
Subject:
--- Dirk Schueller Moeller
[EMAIL PROTECTED] wrote:
Dirk Schueller Moeller wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Dirk
Schueller Moeller
Sent: 03 December 2004 07:53
To: [EMAIL PROTECTED]
Subject:
:34, John Harvey wrote:
Nothing that I know of that would cause this.
The x driver hasn't changed for ages.
Try
ivtvfbctl /dev/fb/1 -prepdma
This should display an image that gradually gets darker on the frame
buffer
and should prove whether ivtv-fb is working.
John
Okay
2 things.
1) Use the ivtv driver bundled with rc2q it will be faster than the one from
bad website.
2) I suspect you haven't enabled the 350 support in the tv playback in myth.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Tony
slow/SW decoding
to TV-OUT)
How should I switch to use the ivtv driver? What should I change in
my XF86Config file?
When I was selecting the devices in the setup for the PVR-350 I did
look and used the PVR-350 card...
On Sat, 4 Dec 2004 21:04:32 -, John Harvey
[EMAIL PROTECTED
Of Chris Kennedy
Sent: 07 December 2004 02:51
To: [EMAIL PROTECTED]
Subject: Re: [ivtv-devel] dma_sync_single fix needed and [patch]
mod_param, ivtv-0.2.0-rc2t 2.6.10-rc2
On Mon, Dec 06, 2004 at 10:21:36PM -, John Harvey wrote:
Chris
There is still one occurrence
and they arent checked for NULL. So we
just need to fill the function table out a bit more.
I'll search tonight for any unchecked calls and add
them to the table and check to make sure it will build
with older kernels. So i should be able to get a patch
out later tonight.
John
--- John Harvey [EMAIL
]
[mailto:[EMAIL PROTECTED] On
Behalf Of Tim Fenn
Sent: 08 December 2004 05:39
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; 'Chris Kennedy'
Subject: Re: [ivtv-devel] Has anyone had ivtv-fb
working on Fedora Core 3
(2.6.9-1.681)?
On Tue, Dec 07, 2004 at 08:24:14PM -, John Harvey
wrote:
Attached
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Kenneth Berland
Sent: 08 December 2004 20:26
To: [EMAIL PROTECTED]
Subject: [ivtv-devel] (no subject)
Hi List,
My first post. Firstly, you all have done an amazing job. In a few days
The code only supports one frame buffer at the moment.
I don't think there is any really good reason for this but there are several
static variables in ivtv-osd.c that should really go into a per device
memory allocation. I don't think this would be very difficult but I am not
sure what issues we
You could maybe try running 2 x servers. At some point I believe that Xorg
added the novtswitching support so you could run a second one that doesn't
care about the vt switching and then you would have 2 single headed X
servers.
I have an XFree 4.4 server hacked to work like this if it the Xorg
That error comes when the Virtual Terminal switches to
or from the vt used for the X server it is harmless
and unrelated to this problem.
Can you pos the Xorg.0.log file
John
--- Bernd Müller [EMAIL PROTECTED] wrote:
Hello;
I've also tried before to specify the BusID like you
wrote in
Attached is the pre-compiled X driver for ivtv.
See seperate mail for information about changes
ivtvdev_drv.o.gz
Description: GNU Zip compressed data
for help.
Please also check the log file at
/var/log/Xorg.0.log for additional informati
on.
--- John Harvey [EMAIL PROTECTED] wrote:
Attached is my V0.7 xdriver source code.
There are no performance changes just some
configuration things
1) restore use of fbdev to indicate
Sent: 20 December 2004 20:41
To: [EMAIL PROTECTED]
Subject: Re: [ivtv-devel] Usabilty Question
On Mon, Dec 20, 2004 at 08:19:54PM -, John Harvey wrote:
kernel: ivtv: OSD: DMA xfer from 0xf6f2a2f8 of
262144 bytes failed with (-512) offset = 0x000eb2f0,
total 1225456
was 0x02:0x0a:0x00 and that worked fine. Now I set
it to 2:0a:0 but I get this error:
(WW) ivtvdev: No matching Device section for instance (BusID PCI:2:10:0)
found
(EE) No devices detected.
Any idea?
N.
On Sun, 19 Dec 2004 16:28:33 -, John Harvey
[EMAIL PROTECTED] wrote
Can you post your complete Xorg.conf file that you are using. I cant see
anything obviously different from my setup at the moment other than the list
of extensions loaded.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of [EMAIL
I cant see anything obviously broken. I would suggest trying removing
V4l dri glx modules from the modules section. If that doesn't help (and it
probably wont) then we need to get some debugging to work out what is
happening.
I suspect it would be best to start with doing this from the x driver
It is not configured to use the correct frame buffer.
It should have failed completely so I'll have to have another go at that at
some point but it looks like for some reason /dev/fb/1 is not the ivtv
device.
Either that or I've introduced a bigger bug somewhere.
John
-Original
Can you mail me a copy of
include/linux/sched.h
From your linux source tree. (probably /usr/src/linux)
The code has defaulted to the usual 2.4 kernel version of this header but at
least for Redhat 9 we had to add a bodge since it has some 2.6 code
backported. It is possible that Suse 9.0 has
I don't believe it's the x-driver. It is more likely to be the ivtv osd
driver.
The top bottom half thing comes from the x driver splitting large updates
into 2. So the 1st one has worked and the second on failed for some reason.
Turn full ivtv logging on and send me your messages file at the
This is v0.8 of the xdriver. This fixes a bug that we discovered in v0.7
where it was using fbdev in the probe function for the device name to use
but was still using ivtv for the option in the open function. If ivtv was
not found it would then revert to opening /dev/fb0
John
Attached is a pre-compiled version of the v0.8 driver. (See previous mail
for description of fix)
John
ivtvdev_drv.o.gz
Description: GNU Zip compressed data
The various distributions shipping 2.4 kernels are
starting to get to be a real pain to support.
RH9 has stuff from 2.6 in sched.h that means we need
to do 2.6 style process priority and signal handling for its 2.4 kernel.
Suse9.0 has the same process priority stuff but not
the signal
Yes but there's no point. By using YUV we reduce the dma transfers to a
point where we could play back dvd's etc without any problem. 9 * YUV
transfers is bigger than one complete OSD frame so we wouldn't be gaining
anything and we might as well write to the normal frame buffer.
John
(null)
(EE) Screen 0 deleted because of no matching config section.
(II) UnloadModule: ivtvdev
(EE) Device(s) detected, but none match those in the config file.
What can I do to solve the problem?
Beste regards
TheNop
John Harvey wrote:
Attached is a pre-compiled version
I think you need the patch I posted at the end of last week.
Or else opening and closing /dev/video16 should work
cat small.mpg /dev/video16
Before starting X where small.mpg is a small mpg file.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED]
saa7127;
modprobe tuner; modprobe lirc_dev; modprobe lirc_i2c;}; /sbin/modprobe
--ignore-install ivtv;
remove ivtv { modprobe -r lirc_i2c lirc_dev msp3400 saa7115 saa7127
tuner; }; /sbin/modprobe -r --ignore-remove ivtv;
On Fri, 14 Jan 2005 22:17:56 -, John Harvey
[EMAIL PROTECTED
This also feels like a scheduling problem. If this is happening then
presumably we are running out of buffers somewhere. The encoder is stealing
buffers so this means the app isn't taking them fast enough which maybe just
down to scheduling.
Also ivtv now has threads for handling a lot of this
I guess the other thing is to make sure you aren't sharing the interrupt
with something else.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 17 January 2005 20:02
To: ivtv-devel@lists.sourceforge.net
No real idea but if you want to try turning on all debugging and sendming a
short segment from the messages file it may highlight something. Probably
best to send it direct to me or make it available on a web site.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
Can you post the Xorg log file and your config file somewhere and we may
well be able to see what is wrong.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of John Hare
Sent: 26 January 2005 04:02
To: ivtv-devel@lists.sourceforge.net
That's 2 applications in 2 days trying to use dga on a 350.
Maybe I'll investigate adding dga support to the driver as well, but no
promises on a time frame.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of kevin thayer
Sent: 25
Which driver are you using.
Something looks odd here.
I would recommend 0.8 driver and then used the fbdev option.
The ivtv option was an accident that happened a while ago.
If you still have issues post the complete log since theres stuff in there
that will make looking at this quicker than me
:47
To: ivtv-devel@lists.sourceforge.net
Subject: Re: [ivtv-devel] pvr-350, the way to go?
On Mon, 31 Jan 2005 21:36:04 -, John Harvey
[EMAIL PROTECTED] wrote:
Which driver are you using.
Something looks odd here.
I would recommend 0.8 driver and then used the fbdev option.
The ivtv
John Harvey would like to recall the message, [PATCH] pvr-350 performance
patch - simplified.
attachment: winmail.dat
Sorry I meant to send this to the myth-dev
list. But I guess knowing what myth patches are being sent relating to the 350
may be usefull here.
John
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Harvey
Sent: 02 February 2005 22:38
To: ivtv-devel
I dont fully understand whats happening because i
think everyone should suffer this tearing. Basically
the x driver splits large updates into 2 calls to
prep_frame. Each call to prep_frame in the driver
waits for a vsync to occur so we should allways see
tearing.
You could easily modify the
Thanks for the feedback. Some comments below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Jelle
Sent: 06 February 2005 03:23
To: ivtv-devel@lists.sourceforge.net
Subject: [ivtv-devel] [PATCH] Re: Re: Problems with X TV-OUT with
The readme is out of date since it is is now -08.
It is a driver that understands talking to the 350.
It works with XFree Xorg.
There is a pre-compiled version of the driver ivtvdev_drv.o in the directory
as well in case you don't want to build it from source.
John
-Original Message-
It looks like you don't have the ivtv driver in your X load point.
/usr/X11R6/lib/modules/drivers/ivtvdev_drv.o
Should exist (at least that's where it is on FC2).
Copy the file from the utils directory of an ivtv release.
That should be a good starting point if not mail me the Xorg.log file (off
I'm still waiting for feedback from Hauppaugge.
John
--- Sager, Jim [EMAIL PROTECTED] wrote:
I haven't seen any buzz as of late with respect to
YUV decoding. I was just curious as to what state
this is in. Is anyone doing any developing on this?
Thanks,
Jim
Make sure the frame buffer isn't obscuring the video
playback.
Enable globalAlpha
disable localalpha
and set alpha level to 0
John
--- Andrew Kohlsmith [EMAIL PROTECTED]
wrote:
Kernel 2.6.10, driver 0.2.0rc3f. framebuffer works
*great*, capture seems to
work fine and passthrough mode (K1)
/video16 no longer working?
On March 9, 2005 08:11 am, John Harvey wrote:
Make sure the frame buffer isn't obscuring the video
playback.
Enable globalAlpha
disable localalpha
and set alpha level to 0
It's definitely not that; I have the standard fishbone background in X
with
the big
I have a patch for the blank screen when closing EPG which I will try to
finish tonight.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 10 March 2005 07:23
To: ivtv-devel@lists.sourceforge.net
Subject: Re:
Have you tried ivtv 0.2. The behavior of the frame buffer/X is slightly
different that could possibly have an effect on this and it would be
interesting to know if it makes a difference.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of
PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of John Harvey
Sent: Thursday, March 10, 2005 9:33 AM
To: ivtv-devel@lists.sourceforge.net
Subject: RE: [ivtv-devel] Stuttering live tv with program guide
Unfortunately for you i have a fix for the programme
guide issue but not for the stuttering
, 10 Mar 2005, John Harvey wrote:
I have just sent a patch to the myth-dev mailing list to fix the issue
of
the black screen after exiting EPG during live tv.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Sager, Jim
there is a parameter to ivtv (ivtv_std) that defines
the format setting it =2 configures it for PAL i
believe. (I'm at work and this is from memory). That
should help the framebuffer configuration once that's
set properly.
ivtv-osd doesn't support mmap access any more.
I am not sure whether -vo
Yes i think my patch makes this work. In fact i have a
second patch which fixes some other problems but the
FF/REW hang happens every time.
I have been investigating this but haven't made much
progress though i do have some ideas. The real problem
has been time. Anyway i'll spend more time
(that go in libs/libmythtv that
avoid using bltfill and seem to work for me.
Any problems (or success) let me know, and if it all looks good I'll prepare
another patch properly for myth.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of John
that i'll work around at some point.
Those X errors can be ignored and one day i'll remove
them from the X driver.
John
--- Roger James [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of John
Harvey
Sent: 20
That should be fine. I was actually testing
0.0.0-rc3c.
John
--- Roger James [EMAIL PROTECTED] wrote:
I should have said 0.2.0-rc3f :-)
Roger
-Original Message-
From: [EMAIL PROTECTED]
[mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of John
Harvey
Sent: 21 March 2005 18
Chris
I think that vsync wants removing whatever. Since X is currently
doing 2 calls for large screen updates it means that a full screen X update
takes 2 vsync's which is bad.
I think in time it should possibly be an option to the prep frame call to
request a vsync'ed transfer, but for
-devel] Kick-starting PVR-350?
Try this patch, actually anyone with problems
freezing in Myth,
Decoding/OSD interactions. This works off an Idea
from John Harvey, and
maybe will fix problems, since you can trigger the
problem so easily
this is really good to test, please let me know
So presumably you get these problemse when you start X
on the 350?
Stuff that may be usefull to get started
1) Version of ivtv
2) Version of ivtvdev_drv (X driver being used)
copy of the messages file from the start to the end of
the init section and probably the bit after that that
covers
,
_
/-\ ndrew
On 4/14/05, John Harvey [EMAIL PROTECTED] wrote:
So presumably you get these problemse when you start X
on the 350?
Stuff that may be usefull to get started
1) Version of ivtv
2) Version of ivtvdev_drv (X driver being used)
copy of the messages file from the start
Try changing the code in videoout_ivtv.cpp to do PREP_FRAME instead of
BLT_FILL in ClearOSD.c.
Or alternatively apply my patch sent to myth-dev mailing list about 4 weeks
ago that was to fix this and other problems.
I'll chase up what has happened to that patch later tonight,
John
Your busid is illegal. Change
BusID PCI:0:0x8:1
To be the correct busid for your 350 in decimal.
Probably what the error message says
BusID PCI:1:0:0
But if you believe your busid is correct then
BusID PCI:0:8:1
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
gave the options.
John
--- Alan Cox [EMAIL PROTECTED] wrote:
On Fri, Apr 22, 2005 at 07:44:58AM +0100, John
Harvey wrote:
Your busid is illegal. Change
invalid, illegal specifically means prohibited by
law
But if you believe your busid is correct then
BusID PCI:0:8:1
0:8:x
I can't make the yuv stuff work. Not sure what is going on but I'm using PAL
not NTSC which might make a difference though as far as I can see what you
have should work. I'll look into it a bit more tomorrow too see if I can see
what is happening.
John
-Original Message-
From: [EMAIL
I'll donwload 2.6.12-rc3 at some point but and take a look but it is not
high on my list of things to do right now.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of John Andersen
Sent: 24 April 2005 09:13
To:
often, but is stubborn sometimes, hard to predict, but
when it works it is quite cool.
Thanks,
Chris
On Sat, Apr 23, 2005 at 10:23:59PM +0100, John Harvey wrote:
I can't make the yuv stuff work. Not sure what is going on but I'm using
PAL
not NTSC which might make a difference though as far
, and how
an mplayer plugin would be able to input YUV (and convert AVI to YUV
frames)
and PCM together in a way we could properly time them together.
Thanks
Chris
On Sun, Apr 24, 2005 at 10:19:46PM +0100, John Harvey wrote:
Chris
I've now got this working intermittently so it's close
a clue how to fill and play buffers, so possibly a dead end getting
that to ever work (although who knows, I'm hoping someone figures out
more).
Thanks,
Chris
On Sun, Apr 24, 2005 at 10:19:46PM +0100, John Harvey wrote:
Chris
I've now got this working intermittently so it's close but I
Chris
This
fixes problems switching between mpg yuv decoding. The problem was that
the decode thread could still be running and stuck waiting for data so when the
other device is opened it starts by assuming that the data was of the previous
type. This patch makes sure the thread is not
the decoder patch from John Harvey,
with some changes to speed
up Decoder stopping. It helps keep decoder
threads from running into one
another on fast stop/starts and also clears the
buffers upon stop every
time now. Also helps YUV/MPG transitioning too.
#0.3.3z: http://www.ivtv.tv
in it?
Thanks,
Chris
On Tue, May 03, 2005 at 12:43:01PM +0100, John
Harvey wrote:
It looks like part of my patch was missed which
will
have broken some of the decoding stuff.
Chris
The changes to ivtv-ioctl.c are missing so it
still
uses stream-s_flags for the IVTV_F_T_DEC_DONE
mpeg2 if really needed, but that could be
something later if
really
needed. I'm not working on it, really bad at all
this video format
conversion
in the uncompressed domain, so anyone who wants to
do it can, so looking
forward
to anything you can create :-).
John Harvey may have more
what is wrong with something like :-
char buffer[65536];
int fd = open(/dev/video0, O_RDONLY);
int fd1 = open(mympegfile.mpg,O_WRONLY);
while (I_STILL_WANT_TO_READ)
{
read(fd,buffer,65536);
write(fd1,buffer,65536);
};
There are ioctl's you can use to control things but
for capturing something
The attached patch adds a new ioctl that transfers a yuv image to the
display. This is used by the Xdriver to implement Xv support.
The yuv buffer will have been transferred to the display before the ioctl
returns and is done just after the vsync interrupt so there should be no
tearing.
Attached is v1.9 of the xdriver for ivtv.
It has an implementation of Xv which at least here seems to work well with
Xine/mplayer etc.
It has not yet been tested for NTSC but should work.
It requires the patched to ivtv that I sent a while ago before it will work.
These are against
The xdriver does do the conversion so this may be down to a different sized
image from the one I was using and probably a bug in my code.
It currently doesn't centre but actually that would be easy so I will try to
get it to do that. It definitely does not do any scaling and I'm not sure
how easy
No I messed up. New diff attached that should apply.
Sorry
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 15 May 2005 19:18
To: ivtv-devel@lists.sourceforge.net
Subject: RE: AW: [ivtv-devel] [PATCH] YUV
, I used 'mplayer -fs -zoom -framedrop -really-quiet -nojoystick -
vo
xv file'.
BTW, I am in PAL land. Let me know if you would like to get more details
of
my environment.
Martin
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von John
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
John Harvey
Sent: Sunday, May 15, 2005 5:46 PM
The xdriver does do the conversion so this may be down to a
different sized image from the one I was using and probably a
bug in my code.
It currently doesn't centre but actually
Look in your x log file for messages about why Xv didn't start up.
Menu bar I know about and will hopefully fix shortly.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 15 May 2005 20:59
To:
Here's the binary xdriver v0.10.
This fixes non-full height video playback and centers videos with a black
border surrounding them.
It reverts the normal drawing code to exactly the same as 0.8 so should fix
the odd redraw problem.
It is built against XFree86 4.3 so should be usable by most
Also for size limit problems you normally get a reply
saying it is waiting moderators aproval not just
silence so i think something else is going wrong.
John
--- Mat Mrosko [EMAIL PROTECTED] wrote:
On 5/16/05, John Harvey
[EMAIL PROTECTED] wrote:
The limit is ~20k.
huh... my message should
You say your system has a 2 250's yet these problems
occur in playback and DEC_XXX errors would indicate a
350 being used for playback. What is the output device
you are using to playback the recordings?
John
--- Mat Mrosko [EMAIL PROTECTED] wrote:
Here's another try... i'm splitting it up into
!
p.s. Posts to the list are bouncing so I'm cc'ing it to you just in case
On 5/14/05, John Harvey [EMAIL PROTECTED] wrote:
The attached patch adds a new ioctl that transfers a yuv image to the
display. This is used by the Xdriver to implement Xv support.
The yuv buffer will have been
Jelle.
Jelle wrote:
John Harvey wrote:
Here's the binary xdriver v0.10.
This fixes non-full height video playback and
centers videos with a black
border surrounding them.
It reverts the normal drawing code to exactly the
same as 0.8 so
should fix
the odd redraw problem
total
ivtv: Allocate DMA stream 6 using 1024 2048 byte
buffers 1048576 kbytes
total
ivtv: 1000 ms time out waiting for firmware
ivtv: Failed api call 0x0044 with result
0xfff0
Jelle.
Jelle wrote:
John Harvey wrote:
Here's the binary xdriver
It should just work but for some people it seems not to. Attached is a
version of the driver with a little more debugging. Please try this and then
email me the xorg/Xfree86 log file.
Thanks
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On
Writing to /dev/video48 will behave like that. The updates are not (or
weren't when I last looked) synced to the vsync.
The ioctl is synced to the vsync and should be less prone to this.
There is also a reasonably large amount of buffering in the write code which
adds a lag to the display.
The
Mail me the X log file and I'll take a look.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Jeff Simpson
Sent: 20 May 2005 20:28
To: ivtv-devel@lists.sourceforge.net
Subject: Re: [ivtv-devel] xv pvr-350 tvout
Jeff,
My
Can you both let me know which driver version you are using.
4 possible reasons for a lock up
1) Something has got broken in the vsync code
2) There are X/OSD things happening which interfere with the YUV code. I am
intending (when I finish the decorating) to run xperf and mplayer at the
same
No I dont believe its in 18.1 just
in the CVS version of myth.
My patch should apply to 18.1 though since
I dont think there were have been any other changes to videout_ivtv.cpp.
John
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrick de Brabander
I've just added a reminder to this mail. I'll take a look at the -fs -zoom
issue. I suspect it's trying to get my xv driver to do the zooming and for
some reason that is failing. I'll take a look sometime next week.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
I believe this is an NTSC problem that I still need to work out somehow.
JOhn
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Michael Papazoglou
Sent: 22 May 2005 14:11
To: ivtv-devel@lists.sourceforge.net
Subject: RE: [ivtv-devel] xv
I believe the attached patch fixes a problem with the
ivtv yuv ioctl used by the Xv driver.
Can those of you with color problems with NTSC
playback try it and let me know how it changes it. If it doesnt fix it
then a before after picture may be useful. (Probably best sent direct
rather
time but
it can easily transfer less if we are playing back
smaller sized video.
From what you have seen we might also be able to get
the card to do some scaling if we set it up properly.
Let me know if you need any help.
John
--- Matthew Hodgson [EMAIL PROTECTED] wrote:
John Harvey wrote
It should try to work it out properly. I'll add some more debugging to see
if we can work out why it isn't and send you a version of the driver with
that debugging in.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Ian Armstrong
This patch fixes a problem where the close of
/dev/video48 etc. didnt do the full shutdown if only the new ioctl was
used. This means it didnt properly re-initialise on open which causes
the problems people were experiencing switching from yuv - mpeg -yuv.
John
ivtv-0.3.5d.diffs
] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 22 May 2005 23:04
To: ivtv-devel@lists.sourceforge.net
Subject: Re: [ivtv-devel] [PATCH] Possible NTSC Xv/yuv fix
On Sunday 22 May 2005 13:46, John Harvey wrote:
I believe the attached patch fixes a problem with the ivtv yuv
@lists.sourceforge.net
Subject: Re: [ivtv-devel] [PATCH] yuv close fixup
I may try reducing the YUV buffer size, seems this should be helpful, they
probably don't need to be so large.
Thanks,
Chris
On Mon, May 23, 2005 at 10:22:42PM +0100, Matthew Hodgson wrote:
John Harvey wrote:
This patch
2005 23:24, John Harvey wrote:
Attached is v1.9 of the xdriver for ivtv.
It has an implementation of Xv which at least here seems to work well
with
Xine/mplayer etc.
It has not yet been tested for NTSC but should work.
It requires the patched to ivtv that I sent a while ago before
-Original Message-
From: [EMAIL PROTECTED] [mailto:ivtv-devel-
[EMAIL PROTECTED] On Behalf Of Michael Papazoglou
Sent: 24 May 2005 03:02
To: ivtv-devel@lists.sourceforge.net
Subject: Re: [ivtv-devel] [PATCH] Possible NTSC Xv/yuv fix
On Mon, 23 May 2005, Jim Perry wrote:
I
1 - 100 of 239 matches
Mail list logo
