I've discussed this offline with Keith P., but I wanted to get additional input, particularly from anyone who might have a deep knowledge of how the GLX extension interacts with Mesa.

I develop a high-performance X proxy (TurboVNC) based on X.org.  As with all Xvnc implementations, mine interfaces with X.org through the DDX interface, with the VNC-specific code contained in hw/vnc.  In the process of updating my source tree from xorg-server 1.17.4 to 1.19.5, I noticed that indirect OpenGL stopped working properly.  The symptoms are that, when an application is using indirect OpenGL, any timer callbacks I created with SetTimer() in the VNC server code are not invoked until the OpenGL application exits or is killed.  Thus, the rendered images from the OpenGL application are not sent to the VNC viewer in real time, since it relies on an X.org timer to determine when to send those images.  This doesn't seem to be related to the rate at which the application is rendering.  The problem occurs both with non-interactive applications (e.g. GLXgears or GLXspheres) and interactive applications that render only in response to mouse movement.  This may also not be specific to indirect OpenGL.  It may simply be that Mesa is grabbing the X server or doing something else that triggers the bug when indirect rendering is enabled.  It may also be that other code that relies on SetTimer() will experience similar problems under certain circumstances.  I'm not entirely sure, since I don't fully understand why the problem is occurring.

I did, however, bisect the X.org source tree, which led me to this commit:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=0b2f30834b1a9f4a03542e25c5f54ae800df57e2

and I confirmed that reverting the commit while leaving the rest of the 1.19.5 source tree in tact fixes the problem.  I examined the logical differences introduced by the commit and discovered that it left out a timer check in one conditional branch.  I was able to restore the logic with this patch:

diff --git a/os/WaitFor.c b/os/WaitFor.c
index 613608f..45b2aa6 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -238,8 +238,18 @@ WaitForSomething(Bool are_ready)
         } else
             are_ready = clients_are_ready();
 
-        if (InputCheckPending())
-            return FALSE;
+        if (i > 0) {
+            if (InputCheckPending())
+                return FALSE;
+
+            if ((timer = first_timer()) != NULL) {
+                now = GetTimeInMillis();
+                if ((int) (timer->expires - now) <= 0) {
+                    DoTimers(now);
+                    return FALSE;
+                }
+            }
+        }
 
         if (are_ready) {
             were_ready = TRUE;

This eliminated the issue on the surface.  I could also eliminate the issue on the surface by calling TimerCheck() within a block handler, but in both cases, this created performance problems in other areas.  Basically, doing the above messed with the smart scheduler in such a way that it became necessary to revert to the old scheduling parameters from prior X.org releases (SMART_SCHEDULE_DEFAULT_INTERVAL=20, SMART_SCHEDULE_MAX_SLICE=200) in order to get decent image drawing performance in general.  However, doing this also somehow affected direct rendering, which became significantly slower than indirect rendering.

I'm hoping for some insight into how to fix this.  So far, the configurations that seem to partially work are:

1. Default xorg-server-1.19.5 code
   - Except that indirect rendering locks up the server in such a way that it stops responding to any of my timers until the OpenGL application exits-- i.e. the bug described in this report.

2. xorg-server-1.19.5 with the above patch and SMART_SCHEDULE_DEFAULT_INTERVAL=20, SMART_SCHEDULE_MAX_SLICE=200
   - Indirect rendering works properly (and at full speed), but direct rendering is now 2x slower than it should be.

Ideally I want to support both direct and indirect rendering at full speed.  Since VNC servers have to use a virtual framebuffer in main memory, DRI2 or DRI3 are non-starters, so the only way to use Mesa with direct rendering is swrast.  That doesn't work when the nVidia drivers are installed unless the system has a glvnd-enabled build of Mesa, so unfortunately I need to continue supporting indirect rendering until glvnd becomes the norm in Linux distributions.