"Keith Packard" <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
