xf86-video-ati: Branch 'master' - 2 commits

[Dave Airlie]

 src/radeon_dri2.c |    1 -
 src/radeon_kms.c  |   17 ++++++++++++++++-
 2 files changed, 16 insertions(+), 2 deletions(-)

New commits:
commit e9928fe036e9382fd7bc353f3f05531445f08977
Author: Dave Airlie <airlied at redhat.com>
Date:   Wed Aug 25 10:42:39 2010 +1000

    remove explicit buffer submit from copy region
    
    port of 0be3e95c844247746742805830860ace9f546d99 from intel driver.
    
        Remove explicit batchbuffer submit in DRI2 copyregion
    
        Now that we submit from the flush callback chain, we know we'll always
        submit before the client receives the reply or event that blocks it from
        rendering the next frame.
    
    Signed-off-by: Dave Airlie <airlied at redhat.com>

diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 4cafbc6..4ded9dc 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -347,7 +347,6 @@ radeon_dri2_copy_region(DrawablePtr drawable,
     info->accel_state->vsync = vsync;
 
     FreeScratchGC(gc);
-    radeon_cs_flush_indirect(pScrn);
 }
 
 
commit 9f13049ddf06f6f2138851a548cfb82f12a52f42
Author: Dave Airlie <airlied at redhat.com>
Date:   Wed Aug 25 08:56:37 2010 +1000

    radeon: add correct flushing for direct rendered
    
    this is a port of 69d65f9184006eac790efcff78a0e425160e95aa from the Intel
    driver.
    
        Submit batch buffers from flush callback chain
    
        There are a few cases where the server will flush client output buffers
        but our block handler only catches the most common (before going into select
        If the server flushes client buffers before we submit our batch buffer,
        the client may receive a damage event for rendering that hasn't happened yet
    
        Instead, we can hook into the flush callback chain, which the server will
        invoke just before flushing output.  This lets us submit batch buffers
        before sending out events, preserving ordering.
    
        Fixes 28438: [bisected] incorrect character in gnome-terminal under compiz
        https://bugs.freedesktop.org/show_bug.cgi?id=28438
    
        Signed-off-by: Kristian Høgsberg <krh at bitplanet.net>
    
    Signed-off-by: Dave Airlie <airlied at redhat.com>

diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index ba13071..0d6055d 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -191,8 +191,17 @@ static void RADEONBlockHandler_KMS(int i, pointer blockData,
 
     if (info->VideoTimerCallback)
 	(*info->VideoTimerCallback)(pScrn, currentTime.milliseconds);
+}
+
+static void
+radeon_flush_callback(CallbackListPtr *list,
+		      pointer user_data, pointer call_data)
+{
+    ScrnInfoPtr pScrn = user_data;
 
-    radeon_cs_flush_indirect(pScrn);
+    if (pScrn->vtSema) {
+        radeon_cs_flush_indirect(pScrn);
+    }
 }
 
 static Bool RADEONIsAccelWorking(ScrnInfoPtr pScrn)
@@ -713,6 +722,8 @@ static Bool RADEONCloseScreen_KMS(int scrnIndex, ScreenPtr pScreen)
     if (info->cs)
       radeon_cs_flush_indirect(pScrn);
 
+    DeleteCallback(&FlushCallback, radeon_flush_callback, pScrn);
+
     if (info->accel_state->exa) {
 	exaDriverFini(pScreen);
 	free(info->accel_state->exa);
@@ -949,6 +960,10 @@ Bool RADEONScreenInit_KMS(int scrnIndex, ScreenPtr pScreen,
     pScreen->SaveScreen  = RADEONSaveScreen_KMS;
     info->BlockHandler = pScreen->BlockHandler;
     pScreen->BlockHandler = RADEONBlockHandler_KMS;
+
+    if (!AddCallback(&FlushCallback, radeon_flush_callback, pScrn))
+        return FALSE;
+
     info->CreateScreenResources = pScreen->CreateScreenResources;
     pScreen->CreateScreenResources = RADEONCreateScreenResources_KMS;