--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-07-14 at 00:34, Alex Deucher wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Sat, 2003-07-12 at 00:24, Alex Deucher wrote:
> > > > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > > > > 3D seems to work pretty well in mergedfb mode, but there
> are a
> > > few 
> > > > > > little issues, 
> > > > > 
> > > > > Can you elaborate on these?
> > > > 
> > > > They are mentioned here:
> > > >  http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=276
> > > > but I'll elaborate.
> > > > 
> > > > If you are running in mergedfb clone mode, and start an opengl
> app,
> > > the
> > > > framebuffer on crtc1 shifts to the left a few pixels, as such
> the
> > > > cursor does line up properly with where it should be.  crtc2 is
> > > fine. 
> > > > closing the app and switching a away from the mode and then
> back
> > > fixes
> > > > the shift.
> > > > 
> > > > The other issue is that if you place a 3D app right between the
> two
> > > > heads so half is on one head and half is on the other and then
> > > switch
> > > > modes, crtc2 flickers badly and shows corruption almost like
> the
> > > sync
> > > > is off.  moving the app to one head or the other and switching
> > > modes
> > > > then switching back again seems to fix it.
> > > 
> > > Sounds like bugs in the CRTC register handling, I suppose these
> only
> > > happen with page flipping enabled?
> > 
> > Yes this only happens when pageflipping is enabled.  swapping the
> order
> > of the crt2_base code in RADEONDoAdjustFrame() as you mention later
> > fixes the corruption on CRTC2 when you have pageflipping enabled
> and
> > you change modes, 
> 
> Cool, thanks for testing this.

No problem.  Thanks for finding it.

> 
> > 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 be applied with or with out
swapping the two if statements in RADEONDoAdjustFrame()?  I assume
with?  Also what does radeon_state.c end up being linked into?  the
kernel module? I'll recompile and give it a test.

> 
> > One other issue, while I'm thinking of it, when you are using a
> side by
> > side mode in mergedfb, when the cursor is about 1/3 of the way
> across
> > crtc2, the cursor shows up on the far left side of crtc1,
> everywhere
> > else works fine.
> 
> No idea about this, I'd ask Hui Yu or Kevin E. Martin.

Yeah, I'll shoot them an email.

> 
> 
> > > > I'm trying to understand how this would work. with the driver
> as it
> > > is 
> > > > now, if you create a single 3D window greater than 2048 in
> either 
> > > > dimension, it will only display up to 2048.  now, again with
> the
> > > driver 
> > > > as it is now, if you displayed two 3D windows with a total size
> of 
> > > > greater then 2048 in one dimension would/should it work?
> > > 
> > > That's what someone needs to find out. :) If that works, then the
> > > cliprect split trick should work as well.
> > 
> > Alas, it doesn't work.  If run two apps side by side both display
> fine
> > up to 2048.  if you cross the 2048 boundry, the 3D window that
> crosses
> > it goes blank.  :(  looks like we may not be able to go above 2048
> for
> > 3D.
> 
> It's not clear to me what exactly you have tried, please describe in
> more detail.

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.

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

Reply via email to