[PATCH xserver] Pass ClientPtr to FlushCallback

[Adam Jackson]

On Tue, 2016-08-02 at 17:40 -0700, Eric Anholt wrote:

> Note: Mesa's DRI2 is (supposed to be) doing XSync() during glXWaitX() to
> ensure that the server has processed the client's X requests and flushed
> its batchbuffers, so that the kernel serializes the batchbuffer from X
> before the next rendering by Mesa.

This is a bit incorrect. For direct contexts, DRI2's WaitX becomes
DRI2CopyRegion from real-front to fake-front. That _does_ generate a
reply, but whether it flushes the X rendering queue appears to be up to
the driver's CopyRegion{,2} hook; at least ms doesn't do anything
special for that case, although presumably glamor's Flush in
BlockHandler will fire. (DRI3 does something similar, although
apparently uses core X CopyArea to do it instead of present? Sigh.)

Both the DRI2 and DRI3 paths are broken, in fact, since they will only
emit the copy if there's a current context (per spec) and drawable
(maybe implied by spec but questionable), and only for that drawable
(definitely wrong). They ought to emit a real GLXWaitX request
unconditionally, which the server then ought to have enough context to
handle correctly since it keeps track of current drawables globally
(and knows about all the different DRIs). Getting this right isn't
hard, but as with pretty much everything else about multiple GL
clients, people have historically decided it was too difficult to want
to care about, thus ensuring it gets even more difficult to fix over
time...

The WaitX man page and GLX spec are wrong to mention XSync at all,
which is just GetInputFocus on the wire and AFAIK no DDX ever has
interpreted that as a hint to flush rendering; a future GLX spec update
will remove this language.

- ajax