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?
/* 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.
One of the next things I plan on doing is cleaning up the AdjustFrame()
mess. As has been discussed on Xpert, there should really be a separate
function for CloneMode, and I'm not sure if the other calls in the
driver should be to pScrn->AdjustFrame() or RADEONAdjustFrame()
directly. Opinions?
> I've tagged the trunk before I started with the tag 'trunk-20021022' and
> after the merge with 'X_4_2_99_2-20021023-merge' for those who
> need to diff.
That was very useful, thanks for doing the merge!
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. ;)
--
Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
-------------------------------------------------------
This sf.net emial 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
