So, now the extension isn't advertised on drivers that do support it. :(  That's no good.

As far as I can tell by looking at dri_interface.h, __DRI_DRI2_VERSION only goes up to 3.  There is no version 4.

(In reply to comment #2)
> As far as I can tell by looking at dri_interface.h, __DRI_DRI2_VERSION only
> goes up to 3.  There is no version 4.

Yea, you're right I was hoping the DRI2INFOREC_VERSION is propagated through it. It's the  drivers supporting DRI2InfoRec::version >= 4 that implement it. 
We don't have access to either DRI2InfoRec::version or DRI2HasSwapControl both of which are used on server side, without them I actually don't know how Jesse, you and Kristian envisioned it to be tested for on this side. So the big question is: how did you want it to be tested for?

(In reply to comment #3)
> (In reply to comment #2)
> > As far as I can tell by looking at dri_interface.h, __DRI_DRI2_VERSION only
> > goes up to 3.  There is no version 4.
> 
> Yea, you're right I was hoping the DRI2INFOREC_VERSION is propagated through
> it. It's the  drivers supporting DRI2InfoRec::version >= 4 that implement
> it. 
> We don't have access to either DRI2InfoRec::version or DRI2HasSwapControl
> both of which are used on server side, without them I actually don't know
> how Jesse, you and Kristian envisioned it to be tested for on this side. So
> the big question is: how did you want it to be tested for?

libGL only advertises the extension if both the client library and the server advertise it.  If I'm reading this correctly, it sounds like the server is advertising the extension when it possibly shouldn't.  If that's correct, we should revert this patch from Mesa and apply some sort of fix in the xserver.

(In reply to comment #4)
> libGL only advertises the extension if both the client library and the
> server advertise it.  If I'm reading this correctly, it sounds like the
> server is advertising the extension when it possibly shouldn't.  If that's
> correct, we should revert this patch from Mesa and apply some sort of fix in
> the xserver.

Yea, reporting of this extension is completely broken. Given all the moving pieces and that enabling it for drivers that don't support completely breaks desktop environments (the entire desktop just hangs because the swap event they're waiting for never gets there), I'd be really happy if we just disabled this extension completely at least for the stable 9.0.x series until this can be resolved.

Jesse's initial patch to the server even had a fixme for properly reporting it. (http://cgit.freedesktop.org/xorg/xserver/commit/glx/glxdri2.c?id=84956ca43b087600d9db297cffd62e960c516d9e) then he removed it without actually fixing it http://cgit.freedesktop.org/xorg/xserver/commit/?id=165a4a9c7de0fcc6ef6a6421736b412ccb35965e , then someone realized that it breaks drivers so he manually disabled it for software rasterizers and then when Owen fixed reporting of this extension in Mesa everything broke. 

I'm ok with whatever that would make Fedora 18 not hang on startup and while this needs to be fixed in the Xserver I have no idea what are the Xserver release cycles nowadays and this is quite urgent.

Zack, as a temporary hack, could we just look if the driver == "vmwgfx" in the client side glx code and disable the extension there?

(In reply to comment #6)
> Zack, as a temporary hack, could we just look if the driver == "vmwgfx" in
> the client side glx code and disable the extension there?

Yea, that's actually a pretty good idea. I'm not sure if any drivers are using the xorg state trackers which only supports dri2inforec version 3, or whether any other drivers also don't support version 4, but I'd be happy with having that hack in until we implement support for swap_event or/and the extension is fixed.
Ian, are you ok with that?

Fixed on master by the following commit.  This commit has also been cherry picked to the 9.1 branch (as commit bdffccf)

commit 076403c30d9f5cc79374e30d9f6007b08a63bf2d
Author: Zack Rusin <zackr@vmware.com>
Date:   Thu Feb 14 20:39:36 2013 -0800

    DRI2: Don't disable GLX_INTEL_swap_event unconditionally
    
    GLX_INTEL_swap_event is broken on the server side, where it's
    currently unconditionally enabled. This completely breaks
    systems running on drivers which don't support that extension.
    There's no way to test for its presence on this side, so instead
    of disabling it uncondtionally, just disable it for drivers
    which are known to not support it. It makes sense because
    most drivers do support it right now.
    We'll be able to remove this once Xserver properly advertises
    GLX_INTEL_swap_event.
    
    Note: This is a candidate for stable branch branches.
    
    Signed-off-by: Zack Rusin <zackr@vmware.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60052
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Tested-by: Ian Romanick <ian.d.romanick@intel.com>

Verified it on mesa master and 9.1 branch.

Cherry-picked to the 9.0 branch: f84fe6aa2eac6984b77ca6da0c7e5a571b425827

It will be available in Mesa 9.0.3.