[Mesa-dev] [PATCH] DRI2: check DRI2 protocol version before advertising swap related extensions

Owen Taylor otaylor at redhat.com
Fri Apr 30 13:55:31 PDT 2010

On Mon, 2010-04-26 at 11:19 -0700, Jesse Barnes wrote:
> -      /* FIXME: if DRI2 version supports it... */
> -      __glXEnableDirectExtension(psc, "INTEL_swap_event");
> +      if (dri2_major == 1 && dri2_minor >= 2) {
> +	 __glXEnableDirectExtension(psc, "GLX_SGI_video_sync");
> +	 __glXEnableDirectExtension(psc, "GLX_SGI_swap_control");
> +	 __glXEnableDirectExtension(psc, "GLX_MESA_swap_control");
> +	 __glXEnableDirectExtension(psc, "INTEL_swap_event");

We discussed this a bit on private mail and I pointed out that doing it
like this is a bit weird... the X server already has code to report
GLX_SGI_video_sync/GLX_MESA_swap_control/GLX_MESA_swap_control only when
it actually can do them and the DRI2 direct rendering situation is
straightforward - these methods are just delegated directly to the X

So this seem like a standard situation of:

 glx_extensions = client_glx_extensions & server_glx_extensions

and it shouldn't require special hacks like this. The reason that
it doesn't fully work is that some of these extensions - 
GLX_SGI_video_sync and GLX_MESA_swap_control are marked as direct_only
in glxextensions.c.

And in fact doing this is also more accurate - right now the server
makes a distinction:

 * It reports a dri minor of 2 if the DDX driver has a inforec versio
   of 4 or greater. (And the ATI driver, at least, will have that if
   its simply been compiled against a newer xserver)

 * It only reports the extensions if the DDX driver actually has
   the necessary operations (ScheduleSwap, GetMSC)

When I dug into changing glxextensions some more there are some issues -
the Mesa codebase still contains dri1 implementations of the above
functionality for various drivers (radeon, matrox, unichrome) though it
has been stripped out for Intel.

So, the problem is that the direct_only flag in glxextensions.c would
have to be different for DRI1 and DRI2. (It seems this situation is
already there for DRI vs. AppleGL, except that AppleGL is a compile-time
thing so is just handled with a bunch of messy #ifdefs)

What's the right thing to do here? Hacking the client extensions only
seems to be workable if the X server is changed to have a direct
relationship between DRI2 version and capabilities.

- Owen

More information about the mesa-dev mailing list