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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
