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().
> /* 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 ?
The MGA driver is a good sample for shared entities, I even took that
as a base to do it for the Glint driver too.
> 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.
Alan.
-------------------------------------------------------
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://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
