--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-07-14 at 02:59, Alex Deucher wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2003-07-14 at 00:34, Alex Deucher wrote:
> > >
> > > > however, the framebuffer on crtc1 is still shifted a few pixels
> to
> > > > the left when you run an opengl app in clone mode. side by
> side
> > > > modes work fine. everything works fine with pageflipping
> disabled.
> > >
> > > Hmm, for a second I thought I had botched the RADEON_CRTC_OFFSET
> > > calculation in the DRM as well, but it looks to me like it should
> be
> > > identical to that in RADEONDoAdjustFrame(). Agreed?
> >
> > I would think so. Should the patch [...]
>
> I forgot to unattach the patch, it's clearly wrong (if it was
> correct,
> the error would have been significant and on the y axis). Do you
> agree
> that in RADEONDoAdjustFrame() and radeon_cp_dispatch_flip() the same
> value gets written to RADEON_CRTC_OFFSET for the same frame position?
> (Note that pitch = displayWidth * <bytes per pixel>)
no. the order of operations are different. RADEONDoAdjustFrame()
multiplies _all_ of base by 2, 3, or 4 while radeon_cp_dispatch_flip()
only multipies x by the color_fmt.
In RADEONDoAdjustFrame() you have:
Base = y * info->CurrentLayout.displayWidth + x;
switch (info->CurrentLayout.pixel_code) {
case 15:
case 16: Base *= 2; break;
case 24: Base *= 3; break;
case 32: Base *= 4; break;
}
Base &= ~7;
if (pSAREAPriv->pfCurrentPage == 1) {
Base += info->backOffset;
}
reg = RADEON_CRTC_OFFSET;
OUTREG(reg, Base);
in radeon_cp_dispatch_flip() you have:
OUT_RING_REG( RADEON_CRTC_OFFSET, ( ( sarea->frame.y
* dev_priv->front_pitch
+ sarea->frame.x
* ( dev_priv->color_fmt -2 ) ) & ~7 )
+ offset );
(I'm assuming 'offset' and 'info->backOffset' are the equivalent.)
>
>
> >
> > I created a virtual framebuffer of size 2080x480. I then started
> an
> > instance of glxgears and resized the window to about 3/4 of the
> size of
> > the frambuffer. I then started a second instance of glxgears and
> > placed it next to the first instance, then resized it. it resized
> fine
> > until I hit the 2048 boundry, then the window (the one I was
> resizing),
> > went black; the first window was still showed gears. resizing
> smaller,
> > the gears came back when I crossed the 2048 boundry again.
>
> Weird, I don't understand what would cause the window to go blank.
> What
> happens when you enlarge a single window beyond 2048, does it go
> blank
> as well, or is the rendering cropped to 2048? In the latter case I
> suspect this is a different problem.
>
I haven't tried this myself, but see Rich's email. I'll try it
tonight.
Alex
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
