Those affected by the lockups please test this patch against the DRI
trunk. It puts the DRI block in RADEONEnterVT() back first, where it was
in XFree86 4.1, which I understand didn't exhibit this problem (right?).
--
Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: radeon_driver.c
===================================================================
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.20
diff -u -r1.20 radeon_driver.c
--- radeon_driver.c 9 Apr 2002 21:54:52 -0000 1.20
+++ radeon_driver.c 15 Apr 2002 23:05:44 -0000
@@ -4407,6 +4417,13 @@
RADEONTRACE(("RADEONEnterVT\n"));
+#ifdef XF86DRI
+ if (RADEONPTR(pScrn)->directRenderingEnabled) {
+ RADEONCP_START(pScrn, info);
+ DRIUnlock(pScrn->pScreen);
+ }
+#endif
+
if (info->FBDev) {
unsigned char *RADEONMMIO = info->MMIO;
if (!fbdevHWEnterVT(scrnIndex,flags)) return FALSE;
@@ -4418,14 +4435,7 @@
if (info->accelOn)
RADEONEngineRestore(pScrn);
-#ifdef XF86DRI
- if (RADEONPTR(pScrn)->directRenderingEnabled) {
- RADEONCP_START(pScrn, info);
- DRIUnlock(pScrn->pScreen);
- }
-#endif
-
- RADEONAdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
+ pScrn->AdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
return TRUE;
}