On Mit, 2002-10-23 at 15:08, Alan Hourihane wrote:
> On Wed, Oct 23, 2002 at 02:59:21PM +0200, Michel D�nzer wrote:
> > On Mit, 2002-10-23 at 01:37, Alan Hourihane wrote:
> > >
> > > I'm committing the final part of the merge now. I have build tested
> > > it and it does build fine, although I've not tested the drivers.
> > >
> > > The radeon was indeed the most difficult in this merge due to
> > > the divergence of the Clone modes in the XFree86 CVS etc. Kevin, is
> > > going to take a closer look at the radeon driver this weekend so that
> > > he's happy with the merge. But if anyone does find problems - please
> > > report them, or the other CVS committers can fix it up as they need.
> >
> > I've committed some fixes that got reverted by the merge as well as
> > other fixes along the same line.
> >
> > I noticed some new FIXME comments:
> >
> > #if X_BYTE_ORDER == X_BIG_ENDIAN
> > /* FIXME: This should be handled elsewhere */
> > {
> > unsigned char *RADEONMMIO = info->MMIO;
> >
> > RADEONWaitForFifo(pScrn, 1);
> > OUTREG(RADEON_RBBM_GUICNTL, RADEON_HOST_DATA_SWAP_NONE);
> > }
> > #endif
> >
> > (in RADEONLeaveVT() and RADEONCloseScreen())
> >
> > How else do you suggest restoring that register before losing control?
>
> That should probably be done in RADEONRestore().
That's currently not called when using fbdevhw, but maybe that should be
changed. I'll look into it.
> > /* FIXME: Figure out why this was added because it shouldn't be! */
> > /* This is needed by the DRI and XAA code for shared entities */
> > pScrn->pScreen = pScreen;
> >
> > (in RADEONScreenInit())
> >
> > I put this there to avoid crashes in the XAA code for shared entities
> > (i.e. when running dualhead on a card with multiple heads), in
> > particular when calling info->accel->Sync(). I've changed this to
> >
> > /* This is needed by the XAA code for shared entities */
> >
> > in my local tree. Or would testing that pointer before calling an XAA
> > function be better? I think that would be pretty error prone.
>
> That certainly shouldn't be needed for shared entities. Where exactly
> was it crashing ?
XAA dereferences pScrn->pScreen to track the state of shared entities.
RADEONScreenInit() calls other radeon driver functions which call
info->accel->Sync(), but the driver independent code only sets pScrn->pScreen
after ScreenInit(). Boom.
> > Something else I've been wondering is if there's any benefit to having
> > non-DRI DDX drivers in our tree. I'd prefer having the new cursors
> > instead. ;)
>
> Yes, someone may want to start a DRI driver for that chipset.
For the fbdev, vesa, vga ... drivers? ;) Seriously though, they could
easily add it back then. I was thinking only keeping the absolute
minimum of drivers might cut down on the work needed for merges
slightly, but maybe that's not the case.
--
Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
