You are sort-of correct. Mark and I actually had some discussions about
making a more expanded version of it or another API that was more
generic.
In the implementation for i810 You can allocate XvMC surfaces and then,
if you know where to look. You can access the surfaces directly as
they are map
Is this in a Desktop or a Laptop?
If it is a laptop or using a DVI Flat Panel then you are likely suffering
from the same problem discussed over the last few days on this list under
the
"Correction for i810 driver" subject.
I think Egbert Eich was looking into committing a fix for the issue.
If yo
bject: proof-reader's report on RE: [Xpert]!! Correction for i810
driver !!
On Wed, 16 Oct 2002, Sottek, Matthew J wrote:
This proof-reader suggests:
sed -e s/temp/tv_htotal/g
> File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
> Somewhere near line
t;CrtcHDisplay - 32;
}
-Original Message-
From: Egbert Eich [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 5:44 AM
To: [EMAIL PROTECTED]
Cc: Sebastien BASTARD
Subject: RE: [Xpert]!! Correction for i810 driver !!
Hi Matthew,
thanks for following up on this.
Sottek, Ma
ber 15, 2002 10:44 AM
To: [EMAIL PROTECTED]
Subject: RE: [Xpert]!! Correction for i810 driver !!
Sottek, Matthew J writes:
> Actually...
> I am not sure that reg 0x6 will be set in all cases. I may only be
> programmed if there is a TVout controller present in the system. Doing
Actually...
I am not sure that reg 0x6 will be set in all cases. I may only be
programmed if there is a TVout controller present in the system. Doing
it this way is safer. Maybe someone looking for a task can make a diff out
of this and submit it to the patches list?
-Matt
File : xc/progr
Michael,
I posted a small patch for this sometime back. Here is a web
cvs link to the log. Looks like 1.69 or later of this file is
needed.
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/i810
/i810_driver.c
-Matt
-Original Message-
From: Michael Cardenas [mail
There was some discussion of this problem on this list a while back. There
is a separate set of overlay->fb alignment registers that are programmed
relative to the timings being used. When you boot to a TV device the
timings are not as programmed in the CRTC registers so the overlay is not
proper
>> I don't think there are any issues with the blit engine at 16 bit.
>Is there an i810 blitter bug at 24bpp? (and that's what the author of the
>code was referring to?)
Yes, I believe there is a 24bpp problem. Most of the i810 only runs at 16bit
so the normal use case has always been 16bit.
I don't think there are any issues with the blit engine at 16 bit. I think
the problem has something to do with the way multi-line pixmap cache's are
stored in the offscreen memory. The pitch in the Xaa functions is set to be
the same pitch as the framebuffer, which may not be the case.
If you c
David,
You may want to consider changing the alloc_page to use
pci_alloc_consistent()
as is done in Alan Cox's version of the drm's. I changed the i810 one to do
that
in a patch sent to the drm list a couple weeks ago (Doesn't seem to be
applied,
I thought Jens was applying it). It looks like
e 845 trying to do 848x480
Sottek, Matthew J wrote:
> Tom,
> The 830M and 845G chipsets drivers do mode setting through the video
> bios in order to support the 3rd party Flat Panel and TV encoders that may
> be present in the systems. This probably prevents you from getting the
Tom,
The 830M and 845G chipsets drivers do mode setting through the video
bios in order to support the 3rd party Flat Panel and TV encoders that may
be present in the systems. This probably prevents you from getting the
mode you want.
The i810 and i815 systems program their modes directly, s
Guys,
I've been thinking about the KDE problem some more. I was
playing with KDE a few weeks ago (I never even install it on
my own systems which is why I never see this bug) and was
able to make some observations about the bug.
#1 The errors are really in the framebuffer. They can be captured
Keith,
There is a MEMMODE |= 4 in I810Save which gets called from
ScreenInit before any mode setting. Someone added that quite a
long time ago as I recall.
BTW: I'm pretty sure the KDE issue is a real error and not some
FIFO underun/Watermark problem. It can actually be captured in
a screen s
I don't know how the /tmp dir is related to this problem, but the
error message comes when the graphics engine is locked up. You will
need to power down to get it back... Perhaps boot into run level 3
instead and then "startx", you will at least have a usable console
while you fix the problem.
O
Andrea,
You have mismatched your Kernel DRM and your X server. Do not use the
RPM's from the Intel website. This is very old information from before our
driver was merged into XFree86.
I believe there was an "old DRM" option made available by Alan Cox to make
the latest 2.4.x kernels work wit
I was going to do this but never finished it. Perhaps someone could go back
through the archives and refresh our memory as to exactly what the spec was
going to be. And then they could make an updated Xv spec. At lease then it
is on paper and drivers could implement it as they get time.
-Matt
Jon,
XVideo on an i815 does not have any known picture
stability issues. I noticed from your log that you are
running at 1280x1024x24bit@75hz (at least some of the time)
At this resolution with overlay running and doing an
extra CPU copy (as is necessary with Xv) you are probably
out of memory b
Christer,
You have the idea right but there are a couple incorrect
ideas in your answer. Here is some clarification and a way
that will probably work to fix this for everyone.
>The i815 has an extended set of registers that allows
>control of the digital output timing independently from
>the nor
This isn't XFree related but since it is of general interest
to some people here I thought I would post it for reference.
This is a driver framework for the DVO (Digital Video Out)
port on Intel 810 and 815 chipsets. Also included is a
binary driver for the Chrontel 7007 TV encoder which is foun
Stuart,
This is a watermark issue. The watermark is the set of delays etc.
that control the flow of data into and out of a FIFO that feeds the
dac. Your FIFO is probably running out of data when memory bandwidth
isn't available to fill the screen and blit at the same time.
Your video mode is pr
This fixes the broken direct rendering problem seen by several people
on the XFree list and tracked to XvMC by Mike Harris. The issue
doesn't seem to actually be XvMC or XFree at all. As far as I can
tell XFree does correctly have direct rendering working. For some
reason the zero sized drmMap th
Is there a CVS module to just grab the DRM sources from the
tree.
I am looking for something like this:
cvs -d:pserver:[EMAIL PROTECTED]:/cvs co drm
Since people need to get the latest DRM sources for XFree86 4.2.0
it might make things easier, plus going forward it wouldn't be hard
to make a l
t;>16) - 31;
i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31;
-Matt
-Original Message-
From: Christer Palm [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 18, 2002 6:06 PM
To: [EMAIL PROTECTED]
Cc: Sottek, Matthew J
Subject: Re: [Xpert]i815 overlay output revisited
OK, I no
I just verified that the -32 is the correct algorithm that is
used on all supported Operating Systems. Are you using an XFree86
built-in Modeline or one that you (or your distribution) created?
Please send me your Modeline so I can see if it happens on other
Ch7007 based systems.
-Matt
-O
>As far as the bus stuff goes, the computer is a compactPCI. Not
>sure if you're familiar with this, but basicallly its a different
>pinout for the PCI bus for ruggedized computers.
Ahh yes, I read too quickly. I thought you said "Compaq"... the bus
converter makes more sense now.
>It doesn't
g in the PCI Brooktree board.
I should note that I had no trouble using "xvinfo" with the 815 until I
installed the brooktree board
If you would like any more information please let me know.
Mark
----- Original Message -
> From: "Sottek, Matthew J" <[EMA
Mark,
I just verified that xvinfo does in fact work correctly on the
815. (I had never used that command, but I've used many Xv applications)
In fact my personal desktop at home is an i815 with a Brooktree, and
I have had no stability issues whatsoever.
Can you provide some information about th
Let me summarize the options you've discussed and comment on each.
Assume 59.94 video.
Option 1: Run the display at 59.94. This is what you were attempting to do
by inserting modelines I presume? Using this method you don't
introduce any more judder than already existed in the video sequence.
T
Adds support for both IA44 and AI44 subpictures.
Corrects the palette order to match the exposed values.
Removes IA44 from the list of XvImages supported.
Removes IA44 fourcc definition from I810 header in favor
of adding it to the common fourcc.h
Any current clients will have to reverse the
Wait...
I think this is going to be i815M specific. You'll probably have
to check the chip revision to be sure. Do something like
if(pI810->PciInfo->chipRev == ) {
i810Reg->OverlayActiveStart = mode->CrtcHTotal - 16;
i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 16;
}
else {
i810Reg-
Markus,
I suspect that the video is actually shifted relative to the framebuffer.
The OVRACT register accounts for a shift that is
applied to keep the overlay and framebuffer in line when the LCD
or TV timings are in use.
Open a gimp and paint the window the exact color of blue that you
see on
Louis,
I am unsure of what you mean by Video blending. Do you mean
alpha blending for subpicture(#1), like in a DVD? or are you
specifically asking about the Overlay constant alpha feature
of the hardware(#2).
#1 requires use of the XvMC API. It can blend subpictures
into video frames in hardw
The i810/i815 can do 720 width YUV input with 2 line buffers. It
can do up to 1024 width with 1 line buffer. I have not tested the
> 720 width version but the code was committed a few months ago
and was working for the author. The Output size is limited only
by the resolution of the desktop and a
This patch fixes the advertised surfaces in the i810 HWMC driver,
and makes use of the new XVMC_INTRA_UNSIGNED surface flag.
-Matt
xfree.diff
> I wasn't expecting clients to call XV_HOLD then Put and not
>display it afterwards. There seem to be two feasible implemenations:
>
>1) XV_HOLD stays into effect until it is displayed. If a second
>Put comes along before the display the new Put overrides the
>first.
>
>2) XV_HOLD g
>If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD,
>and then, sometime later, I set the atom to XV_FRAME, what kind of
>latency would I be looking at before that held buffer would show up?
>Is setting atoms a synchronous call? Would I be certain the frame is
>on the screen whe
>"Sottek, Matthew J" wrote:
>>
>> Here is the proposal again, if there are on complaints I'll
>> implement it this way.
>>
>> #define XV_HOLD 0x0
>> #define XV_TOP_FIELD0x1
>> #define XV_BOTTOM_FIELD 0x2
>> #define X
In light of ReputImage(), which I was unaware of. I think the first
proposal was best. I can make ReputImage() work without copying all
the data all the time.
Rather than copy the visible part of the XvImage to the offscreen
memory starting as the top left of the offscreen buffer, I'll copy
th
> Note that this introduces some slight uncertainty in the
> display since the overlay might not correspond to the window
> location when it comes time to actually display. But that's
> not going to be a big deal since the times are short and you
> get a delay now anyhow due to the overlay not g
Mark, Billy,
I was just about to implement this but after giving it some thought
I'm not sure what it is that you want.
> 2) For interlacing, I like the idea of an XV_FRAME_TYPE attribute:
>0 == frame, 1 == top field, 2 == bottom field. I'm worried about
>the DRI API possibly not suppo
> Also, an annoyance. I see alot of thin little green horizontal
>lines that flicker all over the overlay surface. Any thoughts
>as to what those might be, or any reason they might be happening?
> I suspect it's some hardware defect and I should go buy another
>video card. If you like I can t
> Personally, I'd like to see as little intelligence as possible
>in X, but I do admit that it is unfortunate so many apps which
>currently use Xv just do it directly.
Not the X server, the X libs. It isn't any different doing it in
the libs than doing it in SDL.
> Still, I really wouldn't wan
> Such a capability needs to be in the client side, since different
>applications have different needs regarding the accuracy of the
>Y'CbCr->RGB conversion for optimization. So, really here we just
>need a method where Xv can tell a client 'I only support one
>overlay at a time'.
Then make th
Michael,
I Think some of the other replies have given the correct
information, but I'll try to sum it up.
First, when you do Xv you are not drawing to the screen as
you know it as all. The data goes into a totally different
buffer. This area is then "overlaid" on top of the normal
framebuffer b
This patch includes Matthieu Herrb's fix for building the i810 driver
when DRI isn't being built, and fixes the sign errors in the XvMC
driver.
-Matt
xfree.diff
Sending this to the list without the patch attached. It
is too big (gzipped) to get past the size limit. Whoever
moderates this list can send the one through with the
patch attached. It has been sent to the patch queue as well
and is number 4946.
-Matt
-
This patch adds support to the
Section 16.3.1 of that same document details the contents of the
Watermark registers. The register name is FW_BLC.
-Matt
-Original Message-
From: Pontus Lidman [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 1:16 AM
To: ext Harald Koenig
Cc: [EMAIL PROTECTED]
Subject: Re: [
49 matches
Mail list logo
