I doubt it's related to this patch, but after applying and updating the git repositories, I get:

-   using xcbproto version 1.5-5-g4f4d43e */
+   using xcbproto version 1.6-3-g3c75db3 */
 /* $Id$ */
 
 /*
@@ -25,4801 +25,6 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
  */
 
-#include "x11-glx-render-enum.h"

Should that include file now be removed?  It ends up a huge diff which means it may take a while to review:

chopin [~/Projects/wireshark/source2/epan/dissectors/]> svn diff |diffstat 
 packet-x11.c                   |   14 
 x11-declarations.h             | 4026 +++++++++----
 x11-enum.h                     |  208 
 x11-extension-errors.h         |   11 
 x11-extension-implementation.h |12540 +++++++++++++++++++++++++----------------
 x11-register-info.h            | 4026 +++++++++----
 6 files changed, 13595 insertions(+), 7230 deletions(-)

(In reply to comment #1)
> I doubt it's related to this patch, but after applying and updating the git
> repositories, I get:
> 
> -#include "x11-glx-render-enum.h"
> 
> Should that include file now be removed?

No. It looks like you regenerated the dissector without mesa (== GLX extension support).

Awww, nuts. Looks like the mesa guys rearranged their repo. I'll work on a patch to detect the new API definition location.

(February 22, commit f437a6737 in case you were wondering why I didn't notice that before I sent this patch on February 10)

>  It ends up a huge diff which means it
> may take a while to review:

Using an older mesa, my diffstat is similar, although it doesn't contain most of the lines deleted:

 epan/dissectors/packet-x11.c                   |   14 
 epan/dissectors/x11-declarations.h             | 2821 +++++++++
 epan/dissectors/x11-enum.h                     |  208 
 epan/dissectors/x11-extension-errors.h         |   11 
 epan/dissectors/x11-extension-implementation.h | 7743 ++++++++++++++++++++++++-
 epan/dissectors/x11-glx-render-enum.h          |    7 
 epan/dissectors/x11-register-info.h            | 2821 +++++++++
 tools/process-x11-xcb.pl                       |  323 -
 8 files changed, 13809 insertions(+), 139 deletions(-)

(using xcbproto version 1.6-3-g3c75db3 and using mesa version mesa_7_6_1_rc1-3328-gaeb34b2 -- "git checkout aeb34b2" in the mesa dir to reproduce this state)

The point of generating all of this automatically from upstream protocol descriptions is so you don't have to review every single line. The X11 protocol isn't small, and it isn't shrinking.

The manual changes amount to:

 epan/dissectors/packet-x11.c |   14 +
 tools/process-x11-xcb.pl     |  323 ++++++++++++++++++++++++++++---------------
 2 files changed, 228 insertions(+), 109 deletions(-)

Which should be a lot easier to review, in theory.

Created attachment 4437 [details]
Patch to support new XCB features and relocated mesa directory

diffstat including mesa_7_6_1_rc1-6420-g98b4e7a:

~/wireshark$ svn diff |diffstat
 epan/dissectors/packet-x11.c                   |   14 
 epan/dissectors/x11-declarations.h             | 2821 +++++++++
 epan/dissectors/x11-enum.h                     |  208 
 epan/dissectors/x11-extension-errors.h         |   11 
 epan/dissectors/x11-extension-implementation.h | 7743 ++++++++++++++++++++++++-
 epan/dissectors/x11-glx-render-enum.h          |    8 
 epan/dissectors/x11-register-info.h            | 2821 +++++++++
 tools/process-x11-xcb.pl                       |  335 -
 8 files changed, 13819 insertions(+), 142 deletions(-)

Created attachment 4438 [details]
Interdiff -- just the mesa part

This is the diff of just the parts in the new version of the patch that aren't in the old version of the patch.

(In reply to comment #2)
> The point of generating all of this automatically from upstream protocol
> descriptions is so you don't have to review every single line. The X11 protocol
> isn't small, and it isn't shrinking.
> 
> The manual changes amount to:
> 
>  epan/dissectors/packet-x11.c |   14 +
>  tools/process-x11-xcb.pl     |  323
> ++++++++++++++++++++++++++++---------------
>  2 files changed, 228 insertions(+), 109 deletions(-)
> 
> Which should be a lot easier to review, in theory.

True, but that supposes I understand the Perl code (and/or the upstream stuff) well enough to predict what it'll generate ;-).

For example, this code here isn't great because we could loop many, many times without throwing an exception (if count is very large):

+static void struct_KeyName(tvbuff_t *tvb, int *offsetp, proto_tree *root, int little_endian, int count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+       proto_item *item;
+       proto_tree *t;
+
+       item = proto_tree_add_item(root, hf_x11_struct_KeyName, tvb, *offsetp, 1, little_endian);
+       t = proto_item_add_subtree(item, ett_x11_rectangle);
+       listOfByte(tvb, offsetp, t, hf_x11_struct_KeyName_name, 4, little_endian);
+    }
+}

(note the lack of an offset increment which would otherwise save us)

Other than that, the patch looks good.

Comment on attachment 4437 [details]
Patch to support new XCB features and relocated mesa directory

Need to do something about the for loop without an offset increment

(In reply to comment #5)
> 
> (note the lack of an offset increment which would otherwise save us)

The offset increment is inside "listOfByte".

> Other than that, the patch looks good.

Thanks.

Comment on attachment 4437 [details]
Patch to support new XCB features and relocated mesa directory

Looks like this was OK after all.  Checked inrev 32520.

Right you are, sorry 'bout that.

And thanks for the (continued) contribution!

FYI, Wireshark says one of the X11 requests in x11-composite.pcap (on SampleCaptures) is malformed: frame 117.