On 20/10/17 11:45 PM, Keith Packard wrote: > "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).
Note that this patch only changes the behaviour for PresentCompleteKindNotifyMsc events specifically. In contrast to those, with PresentCompleteKindPixmap I can at least imagine a use for seeing events from other clients, e.g. so multiple clients can consistently count the number of presentations performed to a window. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
