[Intel-gfx] [PATCH] Submit batch buffers from flush callback chain

[Kristian Høgsberg]

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>
---
 src/intel_driver.c |   33 ++++++++++++++++++++++++---------
 1 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/src/intel_driver.c b/src/intel_driver.c
index 7761ccf..d09c432 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -678,16 +678,8 @@ I830BlockHandler(int i, pointer blockData, pointer pTimeout, pointer pReadmask)
 	intel->BlockHandler = screen->BlockHandler;
 	screen->BlockHandler = I830BlockHandler;
 
-	if (scrn->vtSema) {
-		/* Emit a flush of the rendering cache, or on the 965 and beyond
-		 * rendering results may not hit the framebuffer until significantly
-		 * later.
-		 */
-		intel_batch_submit(scrn,
-				   intel->need_mi_flush ||
-				   !list_is_empty(&intel->flush_pixmaps));
+	if (scrn->vtSema == TRUE)
 		drmCommandNone(intel->drmSubFD, DRM_I915_GEM_THROTTLE);
-	}
 
 	intel_uxa_block_handler(intel);
 	intel_video_block_handler(intel);
@@ -787,6 +779,24 @@ int intel_crtc_to_pipe(xf86CrtcPtr crtc)
 	return drmmode_get_pipe_from_crtc_id(intel->bufmgr, crtc);
 }
 
+static void
+intel_flush_callback(CallbackListPtr *list,
+		     pointer user_data, pointer call_data)
+{
+	ScrnInfoPtr scrn = user_data;
+	intel_screen_private *intel = intel_get_screen_private(scrn);
+
+	if (scrn->vtSema) {
+		/* Emit a flush of the rendering cache, or on the 965
+		 * and beyond rendering results may not hit the
+		 * framebuffer until significantly later.
+		 */
+		intel_batch_submit(scrn,
+				   intel->need_mi_flush ||
+				   !list_is_empty(&intel->flush_pixmaps));
+	}
+}
+
 static Bool
 I830ScreenInit(int scrnIndex, ScreenPtr screen, int argc, char **argv)
 {
@@ -955,6 +965,9 @@ I830ScreenInit(int scrnIndex, ScreenPtr screen, int argc, char **argv)
 	intel->BlockHandler = screen->BlockHandler;
 	screen->BlockHandler = I830BlockHandler;
 
+	if (!AddCallback(&FlushCallback, intel_flush_callback, scrn))
+		return FALSE;
+
 	screen->SaveScreen = xf86SaveScreen;
 	intel->CloseScreen = screen->CloseScreen;
 	screen->CloseScreen = I830CloseScreen;
@@ -1114,6 +1127,8 @@ static Bool I830CloseScreen(int scrnIndex, ScreenPtr screen)
 		intel->front_buffer = NULL;
 	}
 
+	DeleteCallback(&FlushCallback, intel_flush_callback, scrn);
+
 	intel_batch_teardown(scrn);
 
 	if (IS_I965G(intel))
-- 
1.7.2