RE: [Xpert]Re: But *why* no vblank?

[Sottek, Matthew J]

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 mapped into your memory space via DRM. You can then just use
the XvMCPutSurface() to get the surface displayed on the overlay, complete
with Top surface/Bottom Surface functionality and very small latency.

The problem is that while I implemented XvMC by mapping the surfaces
into the clients memory, there is no requirement to do so, and no
generic way to access the surfaces. Plus there is no good way for DRM
to dynamically handle adding and removing mappable areas. So you are
left with a fixed amount of video surface memory mappable by all
clients all the time.

If you actually wanted a direct rendered video solution here is a short
list of missing parts (or at least they were missing last time I looked)

1) Completly dynamic DRM maps. I.e. at any time a video memory area can
be added as a mappable region to the DRM and removed later without
having fixed offsets/ids etc.

2) XvMC(ish) API to allow creation of Video "context" that hides all the
DRM related stuff. Needs to allow you to allocate surfaces by type and
size. Get direct access to the surfaces, and use the surfaces with some
sort of video display device.

I think #1 is the hard one. Last time I checked the DRM drivers were
allocating fixed memory chunks at init rather than dynamically
sharing memory with the rest of the X server at runtime.

-Matt



-Original Message-
From: Michel Dänzer [mailto:michel@;daenzer.net]
Sent: Wednesday, November 06, 2002 2:53 PM
To: Billy Biggs
Cc: [EMAIL PROTECTED]; Elladan
Subject: [Xpert]Re: But *why* no vblank?


On Mit, 2002-11-06 at 17:39, Billy Biggs wrote:
> Michel Dänzer ([EMAIL PROTECTED]):
> 
> > > It would be preferable in general for video apps, though, to provide
> > > a DRM-based api to use the overlay buffer, too.  Like, a DRM-Xv.
> > > For desktop use, the X11 context switch may be fairly acceptable
> > > with something like XSYNC, but to achieve really excellent quality
> > > (eg, suitable for output to a TV/broadcast/etc.) in, say, a video
> > > player, a direct API would be nicer.
> > 
> > If I'm not mistaken that's what XvMC is for.
> 
>   No, XvMC is an API to hardware motion compensation, basically for
> hardware MPEG decoding.

Don't let the name mislead you. Sure, motion compensation was probably
the initial motivation, but my understanding from reading posts about it
on Xpert (Mark or someone please correct me if I'm wrong) is that it
supports non-MC surfaces, so it's basically a beefed up Xv which
supports MC and direct rendering.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i815 trouble

[Sottek, Matthew J]

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 can build from CVS, you can test the results of that fix when
he has integrated it.

As for why it changed from one version to another? I can't really say
however perhaps one of the earlier patches made it in to SuSE's sources
and didn't resolve the issue.

-Matt


-Original Message-
From: Torsten Bergander [mailto:virtualizer@;v2w.de]
Sent: Thursday, October 17, 2002 12:07 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]i815 trouble


Dear all,

when playing back movies using the Xv extensions I get a "blue screen" 
insted off the visual part of the movie. I used mplayer and xine under 
linux to investigate this issue. 

Histrory:
All worked fine with SuSE 8.0 and their Xfree version (4.2.0). The full 
screen output had a small blue vertical bar on the right side. I used 
mplayer in -vo xv as well as -vo sdl output mode.

Now:
I am using SuSE 8.1 and their Xfree version (4.2.0). The small vertical 
bar has grown to fill the complete screen. No matter what player I am 
using. Interesting this is, that if I do use mplayer and its -vo sdl in 
fullscreen I do see 1/6 of the actual movie on the left side wile there 
rest is "covered" with a blue rectangle.

Things I did:
I updated to the latest dripkg, hoping for the issue to be resolved. No 
success. Also I played around with different color depths. Didn't help. I 
recompiled mplayer and xine. Read through tons of list mail.
The only thing that worked (but unacceptably slow) is using x11 (shared 
mem (?)) output method.
After hours of IRC discussions I feel out of options of where to look 
next. E.g. is there a way of turning overlay of, or is that not a good 
idea? 

Hints:
It seems that the only relevant difference is that SuSE 8.1 is built with 
gcc 3.2 whereas the 8.0 was built with 2.95 (or so).
Furthermore, it is said to be a YUV overlay problem of the xfree driver.

Specs:
Sony Vaio PCG-SRC41P
00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics
Controller] (rev 11)
Attached the Xfree log and xvinfo/xdpyinfo output


Thanx for your input.
/TB



-- 
Torsten Bergander
R&D Senior Consultant
[wearLab]@TZI and Xybernaut Europe
+49-178-4486203
GPGkeyID: 0x4EBA7462

IMPORTANT. ANTIDISCLAIMER.
This e-mail is not and cannot, by its nature, be confidential. En route
from me to you, it will pass across the public Internet, easily readable
by any number of system administrators along the way. If you have received
this message by mistake, it would be ridiculous for me to tell you not to
read it or copy to anyone else, because, let's face it, if it's a message
revealing confidential information or that could embarrass me intensely,
that's precisely what you'll do. Who wouldn't?

Likewise, it is superfluous for me to claim copyright in the contents,
because I own that anyway, even if you print out a hard copy or
disseminate this message all over the known Universe. I don't know why so
many corporate mail servers feel impelled to attach a disclaimer to the
bottom of every e-mail message saying otherwise. If you don't know either,
why not e-mail your corporate lawyers and system administrators and ask
them why they insist on contributing so much to the waste of bandwidth.


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: proof-reader's report on RE: [Xpert]!! Correction for i810 driver !!

[Sottek, Matthew J]

Yup
If this isn't proof that we should always just code it up, compile test and
diff, then I don't know what is :)
I started out with "I don't have time but I'll put in my $0.02" and now
we've spent more time writing email code than it would have taken in the
first place... oh well, best intentions sometimes don't work out.

 -Matt


-Original Message-
From: Dr Andrew C Aitchison [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 9:36 AM
To: '[EMAIL PROTECTED]'
Cc: Sebastien BASTARD; '[EMAIL PROTECTED]'
Subject: 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 1522
>  
>  unsigned int lcdtv_c=0;
>  unsigned int tv_htotal=0;
>   
>  /* OVRACT Register */
>  lcdtv_c = INREG(0x60018);
>  tv_htotal = INREG(0x6);
>  
>  if((lcdtv_c & 0x8000) &&
> (~lcdtv_c & 0x2000) &&
> (tv_htotal)) {
>i810Reg->OverlayActiveStart = (temp>>16) - 31; 

>i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31;
  
>  } else {
>i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
>i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
>  }



-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]!! Correction for i810 driver !!

[Sottek, Matthew J]

I'll try to summarize.

The OVRACT register controls how the overlay lines up with the TV/LCD
output.
This alignment needs to be calculated based on the horizontal timings being
used on the TV.

On an i810/i815 the video bios will program the timings for the TV
controller
if it is used as the primary output device. The CRT timings are then
centered
in the TV timings which allows XFree to display on the TV using one, fixed,
TV resolution that was chosen by the vbios.

Since this mechanism was designed for compatibility with VGA, DOS etc, the
vbios is not programming the OVRACT register... this register was being set
in Set Mode which made it work for at least one TV controller in at least
one mode.

If we base the OVRACT register programming on the sync timings set by the
vbios you can probably make it work for everyone.

If the TV is active:
   Regs 0x6-0x60023 control the timings in use by the GMCH is bit 28
in lcdtv_c is 0 (This is usually the case). The CRTC timings are
centered in these values if bit 29 is 1 (usual case)
   OVRACT needs to be programmed off the TV regs if they are in use.
If the TV is not active
   CRTC regs control the timings
   OVRACT needs to be programmed off the CRTC regs

For an LCD the vbios may or may not be using the LCD/TV timings depending
on the capabilities of the LCD device. I suggest checking bit 28 of
lcdtv_c to make sure that the TV regs are in use. The centering probably
doesn't matter because the end timings are still those in the TV regs.

At this point, if this works for both of you, I suggest committing it and
asking for lots of testing. You will have a lot of permutations of
LCD encoders, LCD displays, and TV encoders that may all behave
differently. Only widespread testing will indicate if it is an
improvement.

Egbert,
  Wherever you end up putting this you can probably replace any other
programming of OVRACT. Just make sure that if you switch away or change
modes for any reason that you read the timings again. A stand alone TV
driver could have changed them.


 -Matt


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;
  
 /* OVRACT Register */
 lcdtv_c = INREG(0x60018);
 tv_htotal = INREG(0x6);
 
 if((lcdtv_c & 0x8000) &&
(~lcdtv_c & 0x2000) &&
(tv_htotal)) {
   i810Reg->OverlayActiveStart = (temp>>16) - 31; 
   i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
 } else {
   i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
   i810Reg->OverlayActiveEnd = mode->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, Matthew J writes:
 > Egbert,
 >   Actually... I'm thinking there is a problem with this way too. We need
 > another "if" in there. i.e.
 > 
 > if((tv is on) && (vbios left a set of TV timings for us)) {
 >use TV regs;
 > } else {
 >use crt regs;
 > }
 > 
 > Otherwise we might end up using the TV timings even when the display is
not
 > on
 > the TV (depending on what the vbios does when using CRT in a system that
has
 > a TV controller).


Yes, I suspected something like this. 

 > 
 > Check the LCDTV_C register (offset 0x60018) bit 31. If it is set then
 > the TV is in use. So try this one:
 > 
 > 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;
 >  
 > /* OVRACT Register */
 > lcdtv_c = INREG(0x60018);
 > tv_htotal = INREG(0x6);
 > 
 > if((lcdtv_c & 0x8000) && (tv_htotal)) {
 >   i810Reg->OverlayActiveStart = (temp>>16) - 31; 
 >   i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
 > } else {
 >   i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
 >   i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
 > }
 > 
 > 

We may need more changes than that.

It is still not clear to me if the change in
the OverlayActiveStart and OverlayActiveEnd settings
will do on an LCD. 
In the end we are just reducing the ActiveStart and
ActiveEnd registers by 31. I don't see why we need to
do this.
Also we read out the values in SetMode. When this function
gets called the values of these regsiters may not be the
original ones set by the BIOS any more as SetMode()
may be called several times.
We need to grab the value in PreInit() - or if the
BIOS may change them behind our back - save and compare
the value we have set and ref

RE: [Xpert]!! Correction for i810 driver !!

[Sottek, Matthew J]

Egbert,
  Actually... I'm thinking there is a problem with this way too. We need
another "if" in there. i.e.

if((tv is on) && (vbios left a set of TV timings for us)) {
   use TV regs;
} else {
   use crt regs;
}

Otherwise we might end up using the TV timings even when the display is not
on
the TV (depending on what the vbios does when using CRT in a system that has
a TV controller).

Check the LCDTV_C register (offset 0x60018) bit 31. If it is set then
the TV is in use. So try this one:

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;
 
/* OVRACT Register */
lcdtv_c = INREG(0x60018);
tv_htotal = INREG(0x6);

if((lcdtv_c & 0x8000) && (tv_htotal)) {
  i810Reg->OverlayActiveStart = (temp>>16) - 31; 
  i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
} else {
  i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
  i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
}


-Original Message-
From: Egbert Eich [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 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
 > 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?

I've checked with the docs and it looks like this patch may be 
correct. I'll test it in my i810 and submit it if I don't see
any side effects.

Thanks to both Sebastien and matt!

Regards,
Egbert.

 > 
 > -Matt
 > 
 > 
 > File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
 >   Somewhere near line 1522
 > 
 > 
 >   unsigned int temp=0;
 > 
 >/* OVRACT Register */
 >temp = INREG(0x6);
 >if(temp) {
 >  i810Reg->OverlayActiveStart = (temp>>16) - 31; 
 >  i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
 >} else {
 >  i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
 >  i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
 >}
 > 
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]!! Correction for i810 driver !!

[Sottek, Matthew J]

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/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
  Somewhere near line 1522


  unsigned int temp=0;

   /* OVRACT Register */
   temp = INREG(0x6);
   if(temp) {
 i810Reg->OverlayActiveStart = (temp>>16) - 31; 
 i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
   } else {
 i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
 i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
   }




-Original Message-
From: Sebastien BASTARD [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 2:50 AM
To: <
Subject: [Xpert]!! Correction for i810 driver !!


Hello,

I have a i810 controller with crontel 7007 out tv. With the lastest
Xfree 4.2.1, the Video Direct Render didn't work correctly.
In 640x480, the Video Direct Render print half image on the screen. And
with 800x600, i hadn't picture.

While 3 weeks, i searched a solution. I find one on a e-mail (but i
forgot the name of the person who posting the test solution).
I tested, and it work great !

I don't how it work (the solution), but it works.

I tested in 640x480, and 800x600 resolution, 24 bits and 16 bits.

Someone can modify the CSV driver 810 file ?

File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c

removed (line 1522):

   /* OVRACT Register */
   i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
   i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 

added (1476) :

  unsigned int temp=0;

added (line 1522) :

  temp = INREG(0x6);
  i810Reg->OverlayActiveStart = (temp>>16) - 31; 
  i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 

P.S : Sorry for my bad english ... and sorry because i didn't used the
diff program
French programmer

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]dri on the intel i810

[Sottek, Matthew J]

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 [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 02, 2002 6:48 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]dri on the intel i810


Hello everyone. If you respond, please cc me as I'm not subscribed. 

Attach: /root/XFree86.0.log.fail xfree86 log

I'm an engineer at Lindows.com and we're trying to ship xfree86 4.2.0
with our next release. In testing, our qa dept discovered that the
intel i810 card no longer has dri acceleration since moving from 4.1.0
to 4.2.0. 

I found that we were not using the updated kernel modules required for
dri, so I added those to our kernel. 

Unfortunately, the i810's are still not accelerated. From looking at
/var/log/XFree86.0.log, everything seems to be fine, and it says
"direct rendering enabled", but glxinfo says "direct rendering: no". 

I'm trying really hard to debug this problem and any suggestions as to
what the problem is, or how to debug it, would be greatly appreciated. 

Attached are the output of glxinfo and xfree8.0.log.

thank you,

  michael


-- 
michael cardenas
lead software engineer
lindows.com
.
hyperpoem.net
.
"Be the change you want to see in the world."
-Mahatma Gandhi
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]RE: Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers?

[Sottek, Matthew J]

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
properly aligned. The vBois put the timings in the TV timings regs and it
is different depending on the 3rd part TV encoder used on your system.

I thought that someone had provided a fix that programmed that register
by looking at the TV timings (If the TV was being used) The register
is called OVRACT, you may want to search the archives for some
discussion of that register.

 -Matt



-Original Message-
From: Sebastien BASTARD [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 12:46 AM
To: [EMAIL PROTECTED]
Subject: Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers?


Hello,

When i use xine to see the film in Xv mode, I have the screen film
shift on the left (everage 16 pixels).
If i set the resolution to 800x600, i have a blue screen (color_key).

Is it the same problem about you talk when i use the Xv ouput on i810
?

Configuration :

- XFree 4.2.1
- i810
- Resolution : 640x480x24

Thanks for all

>>> [EMAIL PROTECTED] 26/09/2002 00:07 >>>
Hola,

This is just a hunch but I'm wondering if this could be a
previously
undetected problem in the XFree86 memory manager.  I want you people
who can
reproduce the problem to try the above patch and tell me if it works. 
I
unfortunately no longer have access to an i810 or i815 (or i830 or i845
for
that matter.)  So I can't test this to see if it works.  If it does
there is
a problem with the memory manager using the leftover bit of memory on
the
side of the screen.  Its probably very rare to hit the path and
probably
just a small calculation thats off somewhere.  If this patch works it
gives
you a good data point at any rate, one thing which is not causing the
problem.
You might also try building the i810 driver with the #define
XF86DRI not
defined because that will make the pitch and the width always be the
same.
That will give you an additional data point to help you track down the
problem.

-Jeff
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]KDE3/i810 corruption - source pointers?

[Sottek, Matthew J]

>> 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 if your theory is correct, and the source pitch was wildly incorrect,
>wouldn't nearly all blits be corrupted?

No, blits from the Framebuffer to the Framebuffer would be correct. Blits
from
the pixmap cache to the framebuffer that are only 1 line would also be
correct.

>One silly thing I noticed is that the code used to write the blitter
>source pitch to the ring buffer in I810SubsequentScreenToScreenCopy:
>
> OUT_RING( pI810->BR[13] & 0x );
>
>should really only write 13 bits, 14-32 are reserved according to my copy
>of the specs.  Does the i810 get cranky about its reserved bits?

That isn't a problem. Bits like that are usually reserved to make room for
larger values in possible future chipsets without having to move bits
around.
I'm sure it is fine.


I checked the code again and I'm still thinking the problem is with the data
getting stored into the cache. That seems to be in the Xaa code, not the
i810 code so it is possible that the pitches are not in sync.

-Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]KDE3/i810 corruption - source pointers?

[Sottek, Matthew J]

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 can track down the code that puts the cached pixmaps in the offscreen
memory you can probably determine how they are being arranged in that
memory. Perhaps that code is unaware of the pitch != width case.  (Is Xaa
used to blit from on-screen locations to the offscreen cache?)

 -Matt


-Original Message-
From: Bill Soudan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 9:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]KDE3/i810 corruption - source pointers?



On Wed, 25 Sep 2002, Bill Soudan wrote:

> http://www.xfree86.org/pipermail/xpert/2002-June/018208.html

Why changing the resolution to 24bpp 'solves' the problem:

xc/programs/Xserver/hw/xfree86/drivers/i810/i810_accel.c:

   /* There is a bit blt bug in 24 bpp.  This is a problem, but
  at least without the pixmap cache we can pass the test suite */
   if(pScrn->depth != 24)
  infoPtr->Flags |= PIXMAP_CACHE;

I believe this indicates to the Xserver that the driver can't do a pixmap 
cache, which has the same effect as enabling the XaaNoPixmapCache flag.

Maybe this is actually a hardware bug then (ugh)?  More pronounced at
24bpp but still exists at the other depths?  Maybe I'll remove the check
and try 24bpp with a pixmap cache just to see what happens...

Bill

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i830/i845G updates

[Sottek, Matthew J]

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 the alloc_page was reworked,
but the pci_alloc_consistent() seems a cleaner way to go. (And potentially
more correct, as I know that Alan changed it for a reason)

I don't know how far back the pci* functions go. Might be a compatibility
issue.

 -Matt


-Original Message-
From: David Dawes [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 6:33 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]i830/i845G updates


I've just committed a major rework of the i830/i845G support in the i810
driver.  It's available from the XFree86 CVS trunk.  If you had problems
with the previous version, try this one.

This version works best with the 2.4.19 kernel (or later).  I've also
done a little testing of this driver on FreeBSD with an 845G.  FreeBSD's
agp kernel module needs some patching to work with the 830 and 845G.
I've got some further information about this at
.

David
-- 
David Dawes
Release Engineer/Architect  The XFree86 Project
www.XFree86.org/~dawes
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i810 driver on the 845 trying to do 848x480

[Sottek, Matthew J]

The vbios belongs to the graphics engine. Since Intel graphics chips are
part of the chipset our vbios is integrated into the system bios. Any PCI
card will have it's own vbios and as long as you choose one that is capable
of supporting the 848x480 mode you should be fine.
 Also, if the chipset is an 845G (not 845GL) you probably have an agp slot
as well. An AGP card that supports 848x480 would work as well.

 -Matt


-Original Message-
From: Tom Fishwick [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 12:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]i810 driver on the 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 
> mode you want.
>   The i810 and i815 systems program their modes directly, so they have a 
> much wider set of available modes.
> 
>   It may be possible for your system provider to make a custom vbios that 
> supports the 848x480 mode you are seeking, but as far as I know there is 
> no configuration changes you could make to solve the problem. (I am not an

> expert on the 830/845 driver so there may be other options available that 
> I am not aware of)

thanks for the response Matt. If I use a pci graphics card, will that 
still have to go through the vbios? Is there a pci card out there that 
can program the mode directly or is this always going to be a 
restriction by the 845 system? I need something quick to work now :-(.


damn

>  -Matt
> 
> 
> 
> -Original Message-
> From: Tom Fishwick [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 15, 2002 9:12 AM
> To: [EMAIL PROTECTED]
> Subject: [Xpert]i810 driver on the 845 trying to do 848x480
> 
> 
> Hi there,
> 
> I am in some rather desperate need of help. I am trying to get the i810
> driver to drive an i845 board at 848x480 (for a plasma screen) and
> am getting the message that no matching modes are found in my config
> file, and then it shows a list of modes that bios supports.
> 
> Is there some way that I can force the use of a modeline? ignore the
> bios?  I don't really know X in depth... but the i810 driver worked with
> the i815 and i810 board with X 4.1 at 848x480 with a modeline I
> constructed. I'm hoping the capability is there, it's just some config
> stuff.
> 
> Anyhow, this is critical to our business to work.  Any help would be 
> greatly appreciated.
> 
> thanks,
> Tom
> 
>   
> 
> 
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
> 
> 



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i810 driver on the 845 trying to do 848x480

[Sottek, Matthew J]

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, so they have a 
much wider set of available modes.

  It may be possible for your system provider to make a custom vbios that 
supports the 848x480 mode you are seeking, but as far as I know there is 
no configuration changes you could make to solve the problem. (I am not an 
expert on the 830/845 driver so there may be other options available that 
I am not aware of)

 -Matt



-Original Message-
From: Tom Fishwick [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 9:12 AM
To: [EMAIL PROTECTED]
Subject: [Xpert]i810 driver on the 845 trying to do 848x480


Hi there,

I am in some rather desperate need of help. I am trying to get the i810
driver to drive an i845 board at 848x480 (for a plasma screen) and
am getting the message that no matching modes are found in my config
file, and then it shows a list of modes that bios supports.

Is there some way that I can force the use of a modeline? ignore the
bios?  I don't really know X in depth... but the i810 driver worked with
the i815 and i810 board with X 4.1 at 848x480 with a modeline I
constructed. I'm hoping the capability is there, it's just some config
stuff.

Anyhow, this is critical to our business to work.  Any help would be 
greatly appreciated.

thanks,
Tom




___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i810 + KDE display corruption

[Sottek, Matthew J]

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
in a screen shot and they do not disappear simply by moving the
windows around etc. You actually have to cause a repaint to
clear up the corrupted area. This means it is NOT related to
the MEMMODE/Watermark problems that we see from time to time.
Those are just FIFO underruns that cause corruption on the screen
but not in the framebuffer.

#2 It happened during a few different resolutions. I didn't do a
formal test of all of the modes but some modes that should not
have been bandwidth limited were impacted.  Also, it only happens
on KDE... if it were bandwidth etc. we would see it all the time.

#3 The only place I could make it happen on a regular basis was
when changing focus between windows with a konqueror(sp?) open.
The title bar for the window that lost focus would get blitted
with a new pixmap and would result in a corrupted title bar. Causing the
same title bar to get repainted on a little by little basis (by partially
occluding and exposing it) would make it repaint correctly. So I am pretty
sure that the pixmap is fine, but the blit is fetching incorrect data.

#3 Dirk Narrowed it down to these Xaa functions:

> On my system, any one of the three options
> Option   "XaaNoOffscreenPixmaps"
> Option   "XaaNoPixmapCache"
> Option   "XaaNoScreenToScreenCopy"

Looks like whenever offscreen pixmaps are used and those get used by the
blitter the problem will show up.

This is where my knowledge of X runs out. I need some help. When X stores a
pixmap in offscreen memory what is the pitch of that pixmap? Does it keep
the same framebuffer pitch? Does Xaa
break this blit into single scanlines?

I was thinking that perhaps the fact that our pitch != width
causes a problem with doing multi-scanline blits from offscreen
pixmap caches. And perhaps something about the way KDE is using
the pixmaps makes this more likely to happen.

Any thoughts?


Dirk,
  If you are up for some more testing try this: Run at 1024x768.
In this mode the framebuffer pitch == width. This is the only mode
that has this property. If the problem goes away as a result then
that helps narrow the search.

 -Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i810 + KDE display corruption

[Sottek, Matthew J]

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 shot so it is actually corruption in the framebuffer.

 -Matt


-Original Message-
From: Keith Whitwell [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 7:20 AM
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]i810 + KDE display corruption


Paul Matthias Diderichsen wrote:
> Hi,
> 
> [EMAIL PROTECTED] wrote:
> 
>>3. i810 + KDE display corruption (Dirk =?ISO-8859-1?Q?St=F6ffler?=)
> 
> 
> A year ago, I had the severe version of the problem you describe. I was 
> able to (almost - once in a while there are a few stribes) cure it by 
> upgrading the bios of my IBM netvista 866 MHz P3. I'm afraid I can't 
> help you with an URL to the bios-upgrade, but I remember that I found it 
> somewhere on the IBM's site.
> 
> Probably this will only help you, if you've got an IBM netvista, but 
> otherwise you may add the pointer to your (already) quite impressive list.
> 
> Kind regards,
> 
> 

See also


www.ekf.de/c/ccpu/cc5/firmware/wmi810.html

I received mail from these guys a while ago but promptly forgot about it.
I'm 
integrating their code now.

Keith

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]X server not able to start.

[Sottek, Matthew J]

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 the /tmp issue. Did you recreate /tmp correctly? You need to do
a "chmod o+t /tmp" when making tmp... don't know how it could be
connected to the lockup but worth a try if you didn't do it already.

-Matt


-Original Message-
From: Leela Krishna Poola [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 03, 2002 11:57 AM
To: [EMAIL PROTECTED]
Subject: [Xpert]X server not able to start.


Hi,

 I have a problem with xserver. Its not able to start as I start the
system. The monitor flashes at intervals with the folowwing message on the
screen:

   [drm:i810_flush_queue] *ERROR* lockup

Once I deleted the /tmp directory and then again created it. This problem
started only after that. Can some one shud some light on this.

regards,
leela Krishna


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i810 chipset

[Sottek, Matthew J]

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 XFree 4.0.x. You probably want to look
around for that.

or you can upgrade your XFree so that it works with the DRM from your new
kernel. This is a much harder task and only recommended it you really know
what you are doing.

-Matt


-Original Message-
From: Andrea Bertoldi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 15, 2002 6:24 AM
To: [EMAIL PROTECTED]
Subject: [Xpert]i810 chipset



Hi,

I've just recompiled the kernel of my Linux system, and X does not work
anymore. But some details more:

1. my system runs a RedHat7.1 with kernel release 2.4.2 and XFree86
version 4.0.3 without problems.

2. I compiled the 2.4.9 kernel with RTAI-2.4.6a patch

The system now works, except for graphic interface. Following I add the
full ouput of the X server, when invoked by "startx" from runlevel 3.

One thing more: I looked on intel site, as regards with my chipset. I
tried without success what they suggest to do with the two rpm files that
can be downloaded ( i810gtt-0.2-4.src.rpm and xfcom_i810-1.2-3.i386.rpm).

###
#X SERVER OUTPUT###
###

XFree86 Version 4.0.3 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 16 March 2001
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems.  (See http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.17-8smp i686 [ELF]
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Wed May 15 14:37:46 2002
(==) Using config file: "/etc/X11/XF86Config-4"
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "Anaconda Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Intel 815"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc102"
(**) XKB: model: "pc102"
(**) Option "XkbLayout" "it"
(**) XKB: layout: "it"
(**) FontPath set to "unix/:7100"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(WW) Cannot open APM
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.1
XFree86 Video Driver: 0.3
XFree86 XInput driver : 0.1
XFree86 Server Extension : 0.1
XFree86 Font Renderer : 0.2
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
compiled for 4.0.3, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.2
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
compiled for 4.0.3, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.3
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x281e, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,1130 card 8086,4541 rev 02 class 06,00,00 hdr
00
(II) PCI: 00:02:0: chip 8086,1132 card 8086,4541 rev 02 class 03,00,00 hdr
00
(II) PCI: 00:1e:0: chip 8086,244e card , rev 01 class 06,04,00 hdr
01
(II) PCI: 00:1f:0: chip 8086,2440 card , rev 01 class 06,01,00 hdr
80
(II) PCI: 00:1f:1: chip 8086,244b card 8086,4541 rev 01 class 01,01,80 hdr
00
(II) PCI: 00:1f:2: chip 8086,2442 card 8086,4541 rev 01 class 0c,03,00 hdr
00
(II) PCI: 00:1f:3: chip 8086,2443 card 8086,4541 rev 01 class 0c,05,00 hdr
00
(II) PCI: 00:1f:4: chip 8086,2444 card 8086,4541 rev 01 class 0c,03,00 hdr
00
(II) PCI: 01:07:0: chip 1274,1371 card 8086,4541 rev 08 class 04,01,00 hdr
00
(II) PCI: 01:0b:0: chip 109e,036e card bd11,1200 rev 11 class 04,00,00 hdr
80
(II) PCI: 01:0b:1: chip 109e,0878 card bd11,1200 rev 11 class 04,80,00 hdr
80
(II) PCI: 01:0c:0: chip 10b7,9055 card 10b7,9055 rev 30 class 02,00,00 hdr
00
(II) PCI: End of PCI scan
(II) LoadModule: "scanpci"
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
compiled for 4.0.3, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.3
(II) UnloadModule: "scanpci"
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(II) Host-to-PCI bridge:
(II) PCI-to-ISA bridge:
(II) PCI-to-PCI bridge:
(II) Bus 0: bridge is at (0

RE: [Xpert]Using Xv to display odd/even fields from a TV camera

[Sottek, Matthew J]

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


-Original Message-
From: Mark Vojkovich [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 10, 2002 11:14 AM
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Using Xv to display odd/even fields from a TV camera



   We talked about some standardized method within the current API
for telling the drivers to display fields.  This was done through
PortAttributes.  I'm not sure if anyone actually implemented this
in their drivers though. 


Mark.


On Fri, 10 May 2002, Paul Robertson wrote:

> I have some software which uses Xv to render images acquired from a TV
> camera in something like realtime.
> Currently we only capture even fields, and we scale the image vertically
by
> 200%. It looks OK.
> 
> Now we need to start working with both odd and even fields. If we do that
> with our current software, the picture wobbles up and down.
> If I write some code to adjust the position of the odd field, the picture
> still looks wrong, particularly if nothing is moving in the picture.
> If I write code to reconstitute a full frame by interlacing the odd and
even
> fields, then I see nasty artefacts when there is horizontal motion in
front
> of the camera.
> 
> We actually use ATI Rage and the r128 driver at the moment, but a while
ago
> we evaluated the i815 graphics controller.  I remember that it supported a
> number of different hardware scaling methods including "Up interpolation"
> and "Down interpolation", and I wondered if I could use these modes to get
a
> better quality picture.
> 
> Has anyone had to deal with these kind of issues?
> 
> I should say that CPU time is scarce, as the TV fields are compressed in
> hardware and have to be decompressed in software.
> --
> Paul Robertson
> 
> 
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
> 

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]Jumpy picture with Xv and i810

[Sottek, Matthew J]

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 bandwidth, causing poor performance.

  Does the issue happen when running at lower bandwidth
modes? (i.e. Smaller Resolution and/or Lower Refresh)

  You are probably would be better off running at 16 bit
depth, that will save you quite a bit of bandwidth and the
i815 is really at 16 bit chip anyway (the is no 3d in the
24 bit mode)

  Also, I can't tell from the logs if you have PC100 or PC133
memory. You want the latter.

 -Matt



-Original Message-
From: Jon Forsberg [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 24, 2002 11:51 AM
To: [EMAIL PROTECTED]
Subject: [Xpert]Jumpy picture with Xv and i810


Hi, 
Xvideo is practically useless because the overlaid picture is very jumpy and
unstable. What can I do about this? Attached are my XF86Config-4 and X
startup
messages. I use Linux kernel 2.4.18 and XFree86 4.1.0 (also tried 4.2.0 with
the same result). Tested programs are vlc (VideoLAN) and xine.
Hardware: Asus CUSL2 motherboard with i815 chipset and i810 video.

Please CC me. Thanks in advance,
--zzed
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]Re: i815 overlay output

[Sottek, Matthew J]

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 normal analog output.

They are not really "independent"...

>The XFree driver is only aware of the normal analog
>registers, and so the registers controlling the digital
>output remain at whatever values were put in there by the
>BIOS at system initialization.

This is correct. You should only change the digital timings
if you know how to change the encoder on the other end of
the dvo. They work as a pair.

>This is a nice feature which basically allows the i815 to
>output both digital and analog video at the same time,
>with different timing parameters (although they will
>both display the same framebuffer).

This isn't correct. The i815 has only one display pipe and
cannot send analog and digital at the same time with different
timings. When the dvo part is active the entire i815 is running
off a clock provided by the dvo device (the TV encoder). The
digital timings are used in this case. Also, when you are
using centering mode, the output will center the Analog timings
inside the digital timings. This allows vga compatibility
(through centering) while using the TV as your display.

So why is there a problem?

The issue is that the bios set up some timings that work best
for displaying vga on the TV. These timings are obviously not
the same for all TV encoders (or flatpanels) as the video bios
has separate, vendor supplied, modules to set of the dvo 
device. For some combinations of dvo devices and vbioses the
timings set up by XFree do not match the timings set up on the
dvo device. XFree sets the OVRACT regs based on the timings
that it set (the analog ones), but the digital ones don't seem
to like those values.

What we need to do is to set the OVRACT values based on the
values programmed into the digital timings set. (Apparently
this is not set up by the vbios since vga clients would not
be using the overlay)  It should be an easy fix if someone
wants to take a shot at it. Just convert from using the analog
HSYNC etc. to using the digital HSYNC... if the digital set
hasn't been set up it shouldn't matter since in that case the
dvo device isn't in use anyway.

 -Matt

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Intel 810/815 TV Driver

[Sottek, Matthew J]

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 found
on many 810 and 815 systems. Using this code and driver such
systems can control the features of the TV encoder such as
mode setting. This framework can also be used to write drivers
for any other TV encoders for which documentation can be
obtained.

This driver is not part of XFree, it is a stand alone utility
that can be run in interactive or command line mode with or
without a running X server. It was designed in this manner
specifically to support all embedded and desktop applications.
For this reason I would appreciate that this NOT be included
into the XFree driver, rather it remain as a stand alone
application. The code is divided into an interface (control.c)
a library (ldvo.c) and a driver (ch7007.o) such that any
interface can be used to access the library.

Note that this driver does not contain any code to control Macrovision
features of the Chrontel 7007 encoder. The
framework can support such features but they have been removed
from this public version.

It should compile with a simple "make"

Usage: (See help output for complete options list)
 control --tv_mode 3 --tv_enable
 control --help

 control --interactive
 >list_modes
 >tv_mode 3
 >tv_brightness 20
 >tv_enable
 >crt_enable
 ...
 >exit

This driver only supports Chrontel 7007 encoders, and has
only had limited testing on TV formats other than NTSC (US).

This driver is not supported by Intel, it is for reference
only.

-Matt




i810_tv.tar.gz
Description: Binary data

RE: [Xpert]i810, XFree86: vertical bars on screen

[Sottek, Matthew J]

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 probably to blame. Either run at a lower refresh
rate, or a smaller resolution. Additionally there were some systems
that had a incorrect bios setting in the MEMMODE register. This was
fixed in XFree sometime recently but I don't recall when. If your
system suffers from that issue upgrading to 4.2.0 may provide better
results.
 Additionally if you are using a non standard Modeline in XF86Config...
don't do that.

-Matt


-Original Message-
From: Stuart Lamble [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 19, 2002 8:27 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]i810, XFree86: vertical bars on screen


Greetings.

I am currently running XFree86 4.1.0 on Linux 2.4.17 (Debian unstable).
My system is based around the Intel 815 chipset (Pentium 3, 933 MHz).
Afterstep window manager, with a 16 bit color depth.

Every so often, I get vertical bars appearing on my screen when I move
a window around. These bars are 12 pixels wide, and tend to be separated
by 116 pixels (hmm. Interesting figures...) Depending on where the window
being moved is, the location at which the bars appear may move across 64
pixels. (Sorry, I can't tell you the offset from the side of the screen.
Oops.)

The bars do *not* appear automagically -- they appear only when I move
a window around on screen (or move to a different part of the virtual
screen provided by AfterStep) -- and not even all the time then. It
*seems* to be related to having a large number of gtk-based windows
open, but I can't swear to that; I can't reliably reproduce the problem.
:-(

Does anybody have any suggestions? Or am I going to end up spending
a couple of hundred (Australian) dollars on a new (better :) video
card?

Oh, and a final note: I'm aware that XFree 4.2.0 is out. I'd prefer not
to have to download and install the binaries myself -- I'd prefer to stick
with the Debian package system. If, however, it can be stated with
certainty that this problem is resolved in 4.2, I'll look into it. (There
doesn't *seem* to be anything in the changelog, though.)

Thanks,

Stuart.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]PATCH: Fix for broken direct rendering on i810 with XvMC disabled

[Sottek, Matthew J]

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 that occurs when XvMC is disabled
(since the drm has hardcoded maps I figured it was wise to keep
the placeholder) confuses the direct rendering portion of the
OGL/GLX libs.  I haven't bothered to track this further because
the fix is easier in XFree. I only create the maps when there are 
surfaces to be used.

This is the /proc/dri/card/0/vm output when in the broken state:

slot offset   size type flagsaddress mtrr
   0 0xf800 0x  AGP  0x00 0x2
   1 0xf9e7d000 0x1000  AGP  0x00 0x2
   2 0xf832 0x01a0  AGP  0x00 0x2
   3 0xf830 0x0001  AGP  0x00 0x2
   4 0xf9d7d000 0x0010  AGP  0x00 0x2
   5 0xfb00 0x00182000  AGP  0x00 0x2
   6 0xfb80 0x00182000  AGP  0x00 0x2
   7 0xffa8 0x0008  REG  0x00 0xc8a58000 none
   8 0xf800 0x0018   FB  0x00 0xc88d7000 none
   9 0xc88d4000 0x2000  SHM  0x20 0xc88d4000 none

This is the same with XvMC surfaces enabled:

slot offset   size type flagsaddress mtrr
   0 0xfa90 0x0070  AGP  0x00 0x2
   1 0xf9e7d000 0x1000  AGP  0x00 0x2
   2 0xf832 0x01a0  AGP  0x00 0x2
   3 0xf830 0x0001  AGP  0x00 0x2
   4 0xf9d7d000 0x0010  AGP  0x00 0x2
   5 0xfb00 0x00182000  AGP  0x00 0x2
   6 0xfb80 0x00182000  AGP  0x00 0x2
   7 0xffa8 0x0008  REG  0x00 0xc8a58000 none
   8 0xf800 0x0018   FB  0x00 0xc88d7000 none
   9 0xc88d4000 0x2000  SHM  0x20 0xc88d4000 none

Note the first map is zero size in the broken version and has a
valid size in the non-broken version. The X log output is nearly
identical and indicates that DRI is working in both cases. glxinfo
reports that DRI is NOT working in the first case.

Anyone who is experiencing the problem can either put
Option "XvMCSurfaces" "6"
in the device section of their XF86Config file or apply this patch.
Using the patch is recommended since XvMC does use 7-8MB of memory.

-Matt




xfree.diff.gz
Description: Binary data

[Xpert]DRM sources from the CVS tree

[Sottek, Matthew J]

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 little script that automatically gets the latest cvs
DRM's and compiles/installs them.

 -Matt

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i815 overlay output revisited

[Sottek, Matthew J]

Christer,
I think you have correctly identified the issue. The timings in the 
LCD/TV registers don't match the timings that are being used to 
calculate the Overlay Active offsets.

Try this it should work

unsigned int temp = INREG(0x6);
i810Reg->OverlayActiveStart = (temp>>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 now understand (I think) why this (and other related things) 
doesn't work as I expect...

I now realize that the i815 has a separate set of registers for the 
digital out timing. The i810 driver never touches those registers, so 
they will be left at the default 800x600 mode programmed by the BIOS at 
system initialization. This also explains why I at all get a picture on 
the TV regardless of the X11 modeline, even though the driver never 
talks to the TV chip, which has puzzled me for a while.

I'm adding this stuff to the driver right now. My goal is to keep the 
TV-out chip stuff generic, so that it could be used with other 
drivers/TV-out chips as well. Suggestions and wish-list items are welcome!

-- 
Christer Palm
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i815 overlay output revisited

[Sottek, Matthew J]

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


-Original Message-
From: Christer Palm [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 16, 2002 2:44 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Xpert]i815 overlay output revisited


Hi!
I'm using an i815 chipset with a Chrontel 7007 TV-out chip, and I'm 
seeing the same "blue bar at the right hand" video overlay centering 
problems as previously described in the following posts:

http://www.xfree86.org/pipermail/xpert/2001-November/013424.html
http://www.xfree86.org/pipermail/xpert/2001-November/013425.html
http://www.xfree86.org/pipermail/xpert/2001-November/013467.html

However, I obviously have a very different offset... I get the Xv output 
  centered in the output window when using:

   i810Reg->OverlayActiveStart = mode->CrtcHTotal + 104;
   i810Reg->OverlayActiveEnd = mode->CrtcHDisplay + 104;

The chipset is identified as "Intel i815 rev 4" by the PCI scan, and I'm 
working with the 4.1.99.4 CVS head.

This leads me to believe that the initialization of these registers is 
probably not taking all necessary parameters into consideration. At this 
stage, however, I'm not familiar enough with the guts of the i815 
overlay engine to come up with any good suggestions on how to fix it. 
Perhaps someone already sits on a good answer?

-- 
Christer Palm

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]Intel I815 and Xv

[Sottek, Matthew J]

>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 that the brooktree and i815 ranges overlap
>(but they're close.).

Looking at your logs again... they don't overlap even in the XFree
output. It is difficult text to parse and I misread it. They are
close but this isn't a problem.

I looked into the pci scanning code and looked at the logs from some
other i815's. They all have Bus -1 output for the ISA bridge. It
probably isn't causing any problems, and may just be the result of
having an ISA bridge but not using it for anything.

It does seem that ScreenInit() is getting called twice on your
system, you could try and track that down and find out why.

Does XFree work when the brooktree card is plugged in, but the v4l
module is NOT loaded in the XF86Config?

 -Matt

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]Intel I815 and Xv

[Sottek, Matthew J]

Mark,
  I see a couple problems. The first ones are trivial, #4 seems to
be the real issue.

#1 You are running at 24 bit depth. This isn't a real problem, just
be aware that the i815 is not capable of running 3d and therefore
DRI at 24 bit depth. 16 bit depth is recommended unless you are only
using 2d.

#2 I think you have either no VideoRam option in your device section
of XF86Config, or it is set to 8192. Running with video at 24 bit
depth you'll probably want to use more ram. Set it to 16Megs to be
safe.

#3 The really odd thing is that the device seems to get initialized
twice. Note the "I810(0):" messages, they seem to repeat at the end
of the file. This is probably a symptom of something worse...


#4 XFree is having trouble with your busses. Look at this:

(II) Bus 3 prefetchable memory range:
[0] -1  0xe600 - 0xe60f (0x10) MX[B]
(--) PCI:*(0:2:0) Intel i815 rev 4, Mem @ 0xe000/26, 0xe610/19
(--) PCI: (3:15:0) BrookTree unknown chipset (0x036e) rev 17, Mem @
0xe600/12

Seems like the i815 is getting mapped to the same place as your
brooktree? Might be the bios' fault. Look at /proc/pci and see
if it really looks like they are mapped to the same memory range.

There is also this in your log:
(II) Bus -1: bridge is at (0:31:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set)

I don't know what Bus -1 means, perhaps someone with some knowledge
of the bus probing code can comment on what is happening here.


You might have some luck trying another slot for your brooktree.
Did you say you were plugging that card into a bus converter? Like
an ISA->PCI converter?

 -Matt


-Original Message-
From: Mark Cuss [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 09, 2002 1:59 PM
To: [EMAIL PROTECTED]
Subject: Fw: [Xpert]Intel I815 and Xv



 Hi Matthew

 Attached is the XFree.0 log file from the problem machine.  I am runnning
 stock RedHat 7.2 with the included 4.1.0-3 X Server.  The machine is a
 CompactPCI computer board equipped with a Mobile PIII 733. I am using a bus
 adaptor to allow me to plug 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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, January 09, 2002 2:49 PM
> Subject: RE: [Xpert]Intel I815 and Xv
>
>
> > 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 the OS and some log files.
> > (You attached what appears to be a Microsoft shortcut, not the
> > actual log)
> >
> > -Matt
> >
> > -Original Message-
> > From: Mark Cuss [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 09, 2002 12:37 PM
> > To: [EMAIL PROTECTED]
> > Subject: [Xpert]Intel I815 and Xv
> >
> >
> > Hello All
> >
> > I am working with the Intel 815 graphics chip and a brooktree-based
video
> > capture card (works OK with video4linux).
> >
> > The XVideo extension supports and will operate video4linux devices (I've
> > done this on other machines in the past).  However, when the i815 is my
> > graphics chip, my XServer restarts when I query the XVideo extension for
> the
> > adaptor information (ie - using the "xvinfo" command).  I've checked the
> log
> > file I can't spot the reason why it died, I was hoping one of you could
> help
> > me shed some light on this.
> >
> > Thanks in Advance,
> >
> > Mark
> > ___
> > Xpert mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/xpert
> >
>
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]Intel I815 and Xv

[Sottek, Matthew J]

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 the OS and some log files.
(You attached what appears to be a Microsoft shortcut, not the
actual log)

-Matt

-Original Message-
From: Mark Cuss [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 09, 2002 12:37 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]Intel I815 and Xv


Hello All

I am working with the Intel 815 graphics chip and a brooktree-based video
capture card (works OK with video4linux).

The XVideo extension supports and will operate video4linux devices (I've
done this on other machines in the past).  However, when the i815 is my
graphics chip, my XServer restarts when I query the XVideo extension for the
adaptor information (ie - using the "xvinfo" command).  I've checked the log
file I can't spot the reason why it died, I was hoping one of you could help
me shed some light on this.

Thanks in Advance,

Mark
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]Fixing XF86VidMode extension

[Sottek, Matthew J]

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.

The issue I have here is that you are inserting unknown modelines.
Really the only one with any right to determine the available modelines
is the graphics driver. The driver usually has (On other OS's, XFree
is a little different) a set of canned timings and then may par them
down or add a few more after talking it over with the monitor. XFree
moved most of this up into the device independent portion since most
drivers make use of the same canned timings. This isn't ideal but it
works most of the time. Allowing user defined modelines in XF86Config
is bad enough, but having Apps insert modelines on the fly is really
scary.  The ideal solution here would be to let the driver have a
set of "available" timings as well as the set of "active" ones (The
ones that are in use in the CTRL-ALT+- list) Then your app could
query for a driver supported set of timings, even when the user isn't
actively using them. At least this way the driver has the ability to
provide a "table" of known good timings.

Option 2: Run the display really fast and hope nobody notices. This is
the easiest and probably works pretty well. The faster the refresh the
smaller the added judder, go fast enough and it just doesn't matter
anymore.

Option 3: Work on the video stream to make the judder go away. This is
very hard but this seems to be the goal of your deinterlacer anyway
right?  The video you are getting at 59.94 may be the result of 3:2
pulldown so it may already have judder. You have to detect this and
get back to the 24fps to get rid of the judder. Plus you may have to
timeshift half the fields to get rid of the jaggies. Is it really
that absurd to add in the additional step of weighting the pixels as
was described in your link? Seems like that would produce excellent
results. This also has another advantage, it scales up with faster
processors.
For example assume infinite processor power. If your video is 59.94
with 3:2 pulldown you've got 24fps of real video. Assume your display
is going at 100hz. You could display 100fps by linearly weighting and
blending the pixels of your 24fps video to generate 100fps of unique
video. Basically this is motion blur for video.

The link you gave also suggests that flat panels with their "always on"
type pixels are not idea for video because the eye can detect the
judder more easily than with a crt's "flashing" pixels. Blurring the
video would probably produce better results at high speed than would
be produced with clean pixels.

I vote for #3, let me know when you're done :)

-Matt


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]PATCH: i810 XvMC Fixes

[Sottek, Matthew J]

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 UV in their
subpicture palette in order to be correct.

 -Matt





xfree.diff
Description: Binary data

RE: [xpert]i815 - overlay output

[Sottek, Matthew J]

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->OverlayActiveStart = mode->CrtcHTotal - 32;
   i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32;
}


I'll do some testing and see if this problem really only happens on
the i815M or if it will happen on all i810/i815 with an LCD. The
test above should at least be safe until we know for sure.

 -Matt


i finally got it i applied the patch to i810_driver.c
Thanks Matt for the hint :) 

--- i810_driver-unpatched.cThu Nov 29 19:40:28 2001
+++ i810_driver.c   Thu Nov 29 19:40:01 2001
@@ -1452,8 +1452,8 @@
}

/* OVRACT Register */
-   i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32;
-   i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32;
+   i810Reg->OverlayActiveStart = mode->CrtcHTotal - 16;
+   i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 16;


/* Turn on interlaced mode if necessary */


You can get the binary at http://shell.dnload.com/i810_drv.o
Markus
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i815 - overlay output

[Sottek, Matthew J]

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 the right side. Put that window under the mplayer window on
the left side. If the video is actually shifted you'll the see the
portion of the video that is outside the window on the left side.
(The overlay will only draw on pixels that are blue, since that is
what the colorkey is set to.)

If that is determined to be the problem we can look into a value for
the OVRACT register that works for the i815M without issue.

FYI: OVRACT = 0x6001c offset from mmio base. and bits 26:16 are
the overlay active end, bits 11:0 are the start.

BTW: How did you get that screenshot? Did you photograph the
screen?

 -Matt


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 20, 2001 6:12 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]i815 - overlay output


Hey,

I bought an Acer Travelmate 612TX with an Intel i815 graphic chip.
All movie players show up a blue bar on the right side
(http://shell.dnload.com:5/overlay.jpg) Does someone know how to fix
that problem?
If anyone needs more information please let me know :)

Markus
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i81x Video Overlay (blending) function?

[Sottek, Matthew J]

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 hardware, but requires the Mpeg decode
also be done with the hardware. (Some slight hacking can
do away with the Mpeg requirement) Look through the
archives on this list for a post of the XvMC API by
Mark Vojkovich.

#2 Isn't supported, but wouldn't be a hard thing to do. The
i810 can blend the overlay with the framebuffer at a constant
rate within an alpha window. Xv doesn't have an interface to
set this up but adding a few more attributes like
XV_CONSTANT_ALPHA
XV_ALPHA_TOP_RIGHT
XV_ALPHA_WIDTH_HEIGHT
could give you a crude way of doing it. This hasn't been done
since the actual use cases for such a feature are not common.

-Matt

-Original Message-
From: Louis Lu [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 26, 2001 3:15 PM
To: [EMAIL PROTECTED]
Subject: [Xpert]i81x Video Overlay (blending) function?


Hi:

   I am using RH7.2 with Intel i810e, so far, for the graphics 
driver, it works fine to me.  However, I just wondering whether or
not someone is familiar with the video overlay (blending) function?
what is the method to call video blending function of the driver?
 I also appreciate if someone can point me out whether to find 
related information of this question?

Thanks a lot.
Louis

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]XvShmCreateImage

[Sottek, Matthew J]

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 available memory bandwidth.

The 720 width version should have better quality than the > 720
width version.

-Matt



-Original Message-
From: Dr Andrew C Aitchison [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 31, 2001 3:22 AM
To: Paul Robertson
Cc: Mark Vojkovich; [EMAIL PROTECTED]
Subject: Re: [Xpert]XvShmCreateImage


On Wed, 31 Oct 2001, Paul Robertson wrote:

> Thanks Mark,
>
> OK, I'll have to live with that limit and undersample my YUV data as
> I copy it into the XvImage.
>
> If you are right about i810 then that could be a problem for me. We were
> hoping to use that GC in our system.
>
> Do you know if there is a way to determine what the XvImage limits are?
> My apologies if this is documented somewhere, I couldn't see it.

xvinfo|grep "maximum XvImage size"

My r128 2048 x 2048 and my i815 reports 720 x 576.

I have watched DVDs on the i815 where both the the window and the
pixel size reported on the DVD box were wider than 720 pixels,
so this many not be a fatal limit.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]PATCH: Bring i810 XvMC driver into compliance with XvMC spec draft 7

[Sottek, Matthew J]

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

RE: [Xpert] Xv hit list

[Sottek, Matthew J]

>   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 canceled after a second put.  I expect 1) is easier
>to implement.

The cleanest concept is to have the client set the 
XV_FRAME_TYPE and not let the driver alter it. The client is then
in total control of the display. The only way the overlay will
change after having been set to XV_HOLD is for the client to set
it to something else. So this isn't really what you describe in #1.
The XV_HOLD stays in effect until the client changes it.
XV_FRAME_TYPE modifies the behavior of XvShmPutImage() but
XvShmPutImage() does not have an effect on XV_FRAME_TYPE.

Let's describe it this way.
When XV_FRAME_TYPE is XV_HOLD all changes to the overlay are held
in a buffer until the XV_HOLD state is removed. This includes all
atoms, data, position and scaling parameters. Only the latest
values will be used when the XV_HOLD state is exited. Further,
the overlay will only display the requested fields when displaying.

When XV_FRAME_TYPE is not XV_HOLD all changes to data, position,
scaling, and atoms are applied as soon as possible. The overlay
will only display the requested fields when displaying.



This is actually really useful. Then you can change a bunch of
attributes and the data during a XV_HOLD. The changes will all
show up at the same time when you remove the XV_HOLD. As it is
now changing an attribute requires an overlay update which may
make your next flip have to wait. That is undesirable.

-Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert] Xv hit list

[Sottek, Matthew J]

>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 when it returns? I don't really care which way as
>long as

I will flip the buffer on the the next vertical retrace. The
XvSetAtom call will return quickly as long as you don't call it
more than once per vertical retrace, then is has to block.

>Can it be required that all XV_HOLD --> !XV_HOLD transitions happen
>in the vblank somewhere? That way I can just worry about setting the
>atom as close to frame display time as I can and not worry about the
>tearing. I guess I am just looking for another way to work around not 
>getting vsyncs at my level.

It would be nice, I'm not sure all hardware can do this.

>Now that I think about it, what effect, if any, will this have on
>drivers that implement their own multi-buffering? 

It shouldn't have any impact. We use double buffers on i810. This
just allow for two things. #1 You can do TOP_FIELD BOTTOM_FIELD
which was not possible before. and #2 There is no longer an unknown
time between when you ask for a flip and the actual flip, or
rather the unknown time is very much shorter since the data copy
has been separated from the display request.

Internal to the driver things are a little more difficult to
understand. My overlay has a buffer#1 and buffer#2 but those
pointers are not necessarily pointing to surface#1 and surface#2.
Like in XvMC I may have 6 or 7 surfaces and I just point the
unused overlay buffer pointer to the next surface I want to
display. This is the same thing with just 2 surfaces.

>Another clarification question, what happens in this case:
>XV_FRAME_TYPE = *|XV_HOLD
>XvShmPutImage()
>...
>XvShmPutImage()
>...
>XvShmPutImage()
>XV_FRAME_TYPE = *&!XV_HOLD

Note: You are a little confused. We are not going with the complicated
proposal with the bitfields. It was just too hard and the reputImage()
function should get me what I was trying to achieve. XV_FRAME_TYPE
can only be 0-3 XV_HOLD,XV_TOP_FIELD,XV_BOTTOM_FIELD,XV_FRAME.
SO your question should go like this:

XV_FRAME_TYPE = XV_HOLD
XvShmPutImage()
...
XvShmPutImage()
...
XvShmPutImage()
XV_FRAME_TYPE = XV_FRAME

The target of the XvShmPutImage will only change when XV_HOLD is
set. (Or if XvShmPutImage is called without XV_HOLD) So however
many XvShmPutImage()'s get called while in XV_HOLD get put in the
same place overwriting each other. Once I get an implementation done
I'll write up some clear documentation.

 -Matt

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert] Xv hit list

[Sottek, Matthew J]

>"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 value will be XV_FRAME right?

Yes, existing Xv clients do not need to change anything. It will
works just like it always has. Clients can query for the
XV_FRAME_TYPE atom to see if the driver supports this new
functionality. I plan on resetting it whenever the Overlay is
turned off.

--greg.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert] Xv hit list

[Sottek, Matthew J]

 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
the visible region to the same x,y coordinates in the offscreen
memory. When the window moves triggering a Reput() either I can
show the newly exposed region as zero'd or clip the overlay to the
area that I actually have data for. Either way it is better than
leaving the overlay in the wrong screen location.

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)

The atom XV_FRAME_TYPE can be set to one of the above values.
XvShmPutImage takes either an interlaced or progressive image
and copies both fields to the offscreen area. If XV_FRAME_TYPE
is not XV_HOLD the overlay is updated with the new data right
away. When it is XV_HOLD the overlay is not updated.

At any time the atom can be set to XV_TOP_FIELD or XV_BOTTOM_FIELD
or XV_FRAME to display the result of the last XvShmPutImage.

Mark, if we make use of Reput() couldn't you then make Blitted video
work? Reput() would just update the position during XV_HOLD but
not make a copy. Then when XV_TOP_FIELD was set the coordinates
would always be correct. Reput() could either do nothing or just
update the valid area when XV_FRAME_TYPE != XV_HOLD.

-Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert] Xv hit list

[Sottek, Matthew J]

> 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 going into effect
> until the retrace on most hardware.  It introduces a larger lag
> between overlay and image when moving windows which isn't going
> to be a big deal.

Right, that delay isn't going to have much of an impact.

>You can't do this for blitted video though. The cliplist is stale
>by the time you display. Not a problem though since blitted video
>are merely fallbacks.

Why not? Use two offscreen buffers to hold the data and blit the
correct one over when the HOLD bit gets unset. Can't you check
the cliplist at the time when the bit is removed?

> So, this breaks when we're paused or showing a still and you move
> the image around.  Ugh.  Are you sure this can't be handled in the
> hardware without the client having to do another put?  Or do you
> expect the client to re-put whenever it moves (which it has to
> now anyways)?

Ok, I slightly modified the idea to take care of this too. I must
say, I really really like this one.

#define XV_TOP_FIELD 0x01
#define XV_BOTTOM_FIELD  0x02
#define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD)
#define XV_HOLD  0x04

Mostly the same behavior as before, but now we really use these as
bitfields. When the XV_HOLD bit is ON, the data is not updated
onscreen at the end of an XvShmPutImage. It has to wait until the
HOLD bit is removed.
Here is the change, Bits 0 and 1 indicate the fields that will be
updated with the next XvShmPutImage. The image position and scaling
information are always updated. Here are some example uses.

Default Case: (Works just like it does now)
XV_FRAME_TYPE = XV_TOP_FIELD | XV_BOTTOM_FIELD (Default)
XvShmPutImage:  Both fields are updated from the XvImage, the data
  is updated asap onscreen since the HOLD bit is not on.

Interlaced Video:
XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD | XV_BOTTOM_FIELD
XvShmPutImage:  The top field and bottom field are updated from the
  XvImage. The position, size and scaling information are updated
  from the call, but the overlay is not updated onscreen.
XV_FRAME_TYPE = XV_TOP_FIELD
  The overlay is updated with the latest information and set to
  show only the top field. The onscreen update happens asap.
XV_FRAME_TYPE = XV_BOTTOM_FIELD
  The overlay is set to show the bottom field and the onscreen update
  happens asap.

Paused Video:
Loop:
 XV_FRAME_TYPE = XV_HOLD
 XvShmPutImage: NO Fields are updated from the XvImage, but the
  position and scaling information are taken from the call. The
  overlay is not updated onscreen.
 XV_FRAME_TYPE = XV_TOP_FIELD
  On Screen changed happen asap.
  goto Loop

Paused Video (Better way):
Loop:
 XV_FRAME_TYPE = 0x0
 XvShmPutImage: NO Fields are updated from the XvImage, the position
  and scaling information are updated. The HOLD bit is not set so
  overlay is updated asap. This means that for a pause you just set
  The frame type to 0 and continue with puts as normal. No data
  copying takes place.
 goto Loop


Field at a Time Interlaced:
XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD
XvShmPutImage: Only the top field is read from the XvImage. This is
  done by taking the first line and then skipping every other line.
  The position, size and scaling are updated from the call.
XV_FRAME_TYPE = XV_TOP_FIELD
  Update on screen happens asap.
XV_FRAME_TYPE = XV_HOLD | XV_BOTTOM_FIELD
XvShmPutImage: Only the bottom field is read from the XvImage.
  Position, size and scaling are updated but not onscreen.
XV_FRAME_TYPE = XV_BOTTOM_FIELD
  Onscreen update happens asap.
Repeat.


-Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]RE: Xv hit list

[Sottek, Matthew J]

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 supporting stride on texture blits (is
>this true?) and I'm not sure how to handle this for DMA
>transfers.

How is this going to work. Are you expecting to make two
XvShmPutSurface() calls, one for the top field and one for the
bottom? Each time providing just one field of data? or providing
an XImage with both fields but only using one?

I don't see how that is different that just doing two
XvShmPutImage's now and doubling the pitch and vertical scaling.
The benefit of the TOP_FIELD BOTTOM_FIELD is that you can provide
a whole image and display only one field at a time. I.e. the data
is interlaced in the XImage but shouldn't be displayed progressive
since it will look like crap.

I have a different idea that might work out better. Define these
four things:

XV_TOP_FIELD 0x1
XV_BOTTOM_FIELD  0x2
XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD)
XV_HOLD  0x4

The it works like this. You do an XvShmPutImage() with the
XV_FRAME_TYPE set to XV_HOLD. The image (progressive or
interlaced) is copied to the server but not displayed.
The you can at any time set XV_FRAME_TYPE to be XV_FRAME
(show the image now, both fields) XV_TOP or XV_BOTTOM.

This has the benefit of getting rid of the unknown delay
between the XvShmPutImage and the overlay flip since they
are now separated (as they are in XvMC) plus you can display
just top or just bottom.

The XV_FRAME_TYPE will default to 0x3 (XV_FRAME) which means
that apps using Xv without knowledge of this will just get
a flip when they do an XvShmPutImage.

Here is the process:
get port, etc...
set XV_FRAME_TYPE to XV_HOLD
LOOP:
 XvShmPutImage()
 set XV_FRAME_TYPE to XV_TOP_FIELD
   (Top field shown asap)
 set XV_FRAME_TYPE to XV_BOTTOM_FIELD
   (Bottom field shown asap)
 set XV_FRAME_TYPE to XV_HOLD
   (Nothing happens on screen but the next put() won't flip)
  goto LOOP

Let me know,

 -Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]RE: i810 Xv bugs

[Sottek, Matthew J]

>  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 try to describe them in more
>detail, but it's basically about maybe 30 little single pixel
>high 20 pixel wide green lines that appear randomly about the
>scaled image.

I have never heard of such a problem. What resolution/depth/refresh
are you running at? Perhaps this happens when there isn't sufficient
memory bandwidth? Like maybe 1280x1024@85hz?  It could also be a
bad watermark chosen for the mode. In Linux we have to use a pixel
clock based lookup to get a watermark which isn't always the best
choice for the mode. Other operating systems have a specific
watermark for a specific mode, but of course that only works
when the driver generates the list of available timings.

 In the back of the PRM (Programmers reference manual) there is a
list of modes and the watermarks for those modes. You might compare
X's calculated watermark (It's in the log) against the recommended
value in the PRM. If they are different you could replace the value
in the code with the recommended value to see if your problems go
away.

 -Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]very strange XVideo behaviour (i810)

[Sottek, Matthew J]

>  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 to have my X server wasting its
>time doing scaling.  Ugh.  It's way too expensive to have a
>software fallback.

Exactly, The X protocol (or any driver interface) should be lean,
but there should be a library layer in between the clients and
the protocol to hide the uglies. use libXv.so to hide the uglies
and if you don't want a software fallback then you don't have to
have one.

 -Matt
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]very strange XVideo behaviour (i810)

[Sottek, Matthew J]

>  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 the interface smarter. Pass a flag to force a fail when
the software would be needed. 90% of the apps will just want
consistent behavior and won't want to full with fallback code.
Forcing the client to implement alternate rendering methods is
just going to make for a lot of mostly broken clients that work
for some people some of the time (i.e. what we have now), if
the client is smart enough to have another "better" software
renderer then they should be smart enough to pass another flag.

>I'm curious why the i810 driver would allow his code to get as
>far as he did.
>Sounds like a bug to me.

He probably didn't call XvGrabPort(). Which would have prevented
the second use of Xv.

-Matt

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]very strange XVideo behaviour (i810)

[Sottek, Matthew J]

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 the overlay hardware. This is why your
framebuffer (desktop) is in RGB color but the data you send
to Xv is YUV.  Additionally the overlay can stretch or shrink
the image on the screen without altering the actual data in
memory. This of the overlay as a projector that projects on
the top of your desktop. The projector can change the size of
an image or alter it's colors without changing the input.

Second, XImages and XvImages are client side images. When you
do an XPutImage or XvPutImage you are putting the data into
a server side image. There is no separate copy of each image
inside the X server. So the fact that you are using 2 XImages
means nothing. If the target of your put() is the same then
the data is getting overwritten.  This behavior is a little
different since the i810 double buffers the overlay, but the
point is that the number of XvImages you are using has nothing
to do with what happens inside the server. They are just memory
areas of a specific format.

Third, the i810 only has one overlay engine. Think again of the
projector... it can only project one image to one place. If you
try to use it twice (which you should not be able to do if you
grab the port as you are supposed to do) you make the projector
point to one place then the other, back and forth.

Last, The blue is the colorkey. If the projector is displaying
on top of your desktop then you could never make a window be
"on top" of the projected image. This would make it impossible
to ever cover up a portion of your video window. The solution
is the colorkey. The overlay only projects onto pixels that are
of a specific color. All other pixels will not be covered up.
The default colorkey is blue and when you do an XvPutImage the
X server paints your actual window blue so that the overlay will
draw "on top" of those pixels. When you point the overlay to the
second window the first window still has the blue pixels in it
so that is what you get.

It would be nice to have a software fallback so that you could
do as many Xv's as you wanted (slowly) but that isn't the way
Xv was designed. You'll have to convert the YUV data into RGB
and do a regular XShmPutImage in the second window.

 -Matt



-Original Message-
From: Michael Zayats [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 3:46 AM
To: [EMAIL PROTECTED]
Subject: [Xpert]very strange XVideo behaviour (i810)


well I am trying to draw 2 streams of yuv420 frames to 2 windows

I am doing XvShmPutImage , once to first window and once to another once to
first, once to another etc.

I use separate shared memories for each window.

I am doing it very slowly (usleep(300) between each draw). the strange
thing is that when I draw to one of the windows the second goes BLUE! the
more interesting is that if I get one of the windows behind something such
that clipping eats it all) the second behaves normally and doesn't present
anything blue.


it seems to me that there is some problem in i810_video driver, I just can't
think of anything else!

(First guess was that I get Exposure events and doesn't respond to them, but
after checking I know that I don't get them at all (only when I raise the
window again)).

any thoughs?

Michael


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Further XvMC cleanup

[Sottek, Matthew J]

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

[Xpert]Patch: XvMC Support for i810

[Sottek, Matthew J]

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 i810 driver for the XvMC Motion
Compensation extension and the necessary support libraries.
Currently this builds xc/lib/XvMC/hw/i810/libI810XvMC.*
which any XvMC application would need to link against.
Sometime in the future this will be replaced with a libGL-like
libXvMC.so that it can load the correct hardware library.

Someone more familiar with the Make system may want to
verify the Makefiles to make sure that they are correct.

Features:
  * Implements the HWMC portion of the XvMC protocol. To
accelerate Mpeg1/2 Decode. (i810 does not support iDCT)
  * Support for 6 or 7 YV12 XvMC surfaces up to 720x576.
  * Hardware Overlaid Display.
  * Overlay Flip synced with Vertical retrace.
  * Support for 2 IA44 Subpicture Surfaces.
  * Hardware Alpha Blend.

Limitations:
  * Currently this library is limited to root use only. The
DMA buffer commands are not verified within the kernel
so non-root use has been disabled in this version. This
can easily be enabled for embedded applications with
different security needs.
  * There are no generally available XvMC enabled decoders.
Contact your SW DVD supplier about support, or help
to port an open source decoder of your choice.
  * This patch implements the XvMC draft 6 protocol.
(To be posted here in the near future) Use of Field
pictures slightly differs from Draft 5.
  * Only supports 16 bit depth with DRI enabled.
  * Only supports Linux with 2.4.x based kernels. DRM changes
will need to be ported to other platforms.
  * XvMC Surfaces are preallocated and make 7-8MB of Gtt
memory unavailable for other operations. Using a VideoRAM
setting of 32MB is recommended.

Usage:
  * Add #define SharedLibXvMC YES to your host.def file to
get a xc/lib/XvMC/hw/i810/libI810XvMC.so library. A
static library will be build by default.
  * Compile and use the drm module from this XFree tree.
  * Add Option "XvMCSurfaces" "6" to your XF86Config device
section. By default no memory will be allocated for
surfaces.
  * Verify that 6 surfaces were allocated in your X log, and
use xdpyinfo to verify that XVideo-Motion Compensation
extension is reported.


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

RE: [Xpert]i815/i810 docs for fifo water mark ?

[Sottek, Matthew J]

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: [Xpert]i815/i810 docs for fifo water mark ?


Hello Harald,

> where can I find docs for this register(s) and/or the magic values
> in i810_wmark.c ?  I got i815em data book PDFs but can't find 
> any reference to "water"mark, or mmio register with offset 0x20d8
> or similar.  where should I look for details ?

Watermark settings are listed in 'Appendix A: Mode Parameters' of the
'Intel 815 Chipset: Graphics Controller PRM' document, downloadable in
PDF format from developer.intel.com.

I don't know of any command line utility to tweak the values by hand.

Regards,

Pontus

-- 
Pontus Lidman   Email: [EMAIL PROTECTED]
Nokia Home Communications   Phone: +46 (0)13  4611201
Diskettgatan 11 Fax:   +46 (0)13  4611001
583 35 Linköping, Sweden
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert