[Mesa-dev] [PATCH] glx: Fix __glXWireToEvent for BufferSwapComplete

[Adam Jackson]

On Tue, 2015-08-04 at 19:38 -0700, Eric Anholt wrote:

> In the Pbuffer path, we get serial from awire.  Why's this one
> different?

Because I copied it from the dri2 path not the pbuffer path. This idiom
is more correct, _XSetLastRequestRead is how you notify xlib of the
advance in serials so it can emit XSync when it approaches wraparound.

> > +      aevent->send_event = (awire->type & 0x80) != 0;
> > +      aevent->display = dpy;
> 
> These look good.  Related: pbuffers don't seem to be setting the
> display, either.  Doesn't have to be fixed in this patch.

The pbuffer case is so deeply idiotic as to be unusable. Consider:

typedef struct {
    int type;
    unsigned long serial;
    Bool send_event;
    Display *display;
    Window window;
} XAnyEvent;

vs.

typedef struct {
    int event_type;
    int draw_type;
    unsigned long serial;
    Bool send_event;
    Display *display;
    GLXDrawable drawable;
    unsigned int buffer_mask;
    unsigned int aux_buffer;
    int x, y;
    int width, height;
    int count;
} GLXPbufferClobberEvent;

And worse, event_type for pbuffers is one of:

#define GLX_DAMAGED                     0x8020
#define GLX_SAVED                       0x8021

So if you expect to ever get a pbuffer clobber event, you need to edit
your event dispatch to know that event_type might be wildly out-of-band
from the X event namespace, and that any time you want one of the
fields from XAnyEvent you need a function call that's aware of the
different struct layouts. Good work SGI.

Fortunately neither Xorg nor nvidia will ever emit clobber events (and
I seriously doubt catalyst will either), so this is all academic unless
someone really wants interop with an Indigo, or we want to defend
against XSendEvent from a meddlesome client. I can fix the pbuffer
path, but the above is why I hadn't even thought to bother.

- ajax