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
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 you
[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, Matthew J writes:
Egbert,
Actually... I'm thinking there is a problem
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 1522
unsigned int lcdtv_c=0;
unsigned int tv_htotal=0
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 :
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
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
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
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.
But
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
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,
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
mode you want
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
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
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.
On
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 with
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
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
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
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
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 seem
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
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.
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 == Whatever yours is) {
i810Reg-OverlayActiveStart = mode-CrtcHTotal - 16;
i810Reg-OverlayActiveEnd = mode-CrtcHDisplay - 16;
}
else {
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
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
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
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 XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD)
Just to clarify, the default atom
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 gets
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
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
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 by
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 want
34 matches
Mail list logo
