[PATCH xserver] present: Only send PresentCompleteNotify events to the presenting client

[Keith Packard]

"Keith Packard" <keithp at keithp.com> writes:

> I'm *not* saying this isn't a good patch in practice, I just want to
> understand whether the system was designed wrong, or if we've
> implemented it wrong.

I spent some time this afternoon on IRC chatting with Pierre-Loup. Valve
has an application (vrcompositor in 'extended' mode) which is using
multiple display connections and selecting for Present events on all of
them. I thought for a while that this was doing precisely what we didn't
think reasonable -- expecting PresentCompleteNotify events generated
from a PresentPixmap request sent by client 'A' to be delivered via an
event selection by client 'B'. Nope, they're using the Vulkan
presentation API (which eventually sends PresentPixmap) on connection
'A', and PresentNotifyMSC on connection 'B'. The only events connection
'B' is interested in are those generated by the PresentNotifyMSC, not
those generated by the PresentPixmap sent on connection 'A'.

Thinking about this some more, I believe we can look at CopyArea and
GraphicsExposure events as a good analog -- in that case, the
GraphicsExposure events are *only* delivered to the client who sent the
CopyArea request. I think the Present extension is badly designed in
this area; it shouldn't have bothered to place event selection on the
window, and should have instead made it part of the generating request,
just like CopyArea does (well, it's part of the GC state, which is
effectively part of the request, not part of the drawable state).

I think we should still figure out why the application was failing, but
I'm more in favor of changing the implementation to deliver events only
to the client submitting the request which caused them to be generated.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171020/ca0bc759/attachment.sig>