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;
 }
 

Reply via email to