On Thu, 2017-10-26 at 19:50 -0700, Alex Goins wrote: > DPCGetWindowDisplayCapabilities > > window: WINDOW > => > output: OUTPUT > colorspace_list: LISTofCOLORSPACEPRIORITY > > Errors: Window > > DPCGetWindowDisplayCapabilities functions identically to > DPCGetDisplayCapabilities, but rather than explicitly specifying an > output, > the user must specify a window. The request then retrieves a list of color > spaces/encodings and their associated scores from the output upon which > the > window is centered.
Does this need to do something special for root windows? Is "whatever the root is centered on" good enough? How do you break ties for a 2x2 grid of identically-sized monitors? ("Pick something" is fine, anyone doing that with four non-identical monitors is kind of being a jerk.) Does it make sense to send an event when this would change, ie, when the window's center crosses outputs? The app is going to want it, it seems silly to require a round trip to get it. If so, does the ordering matter with respect to the associated ConfigureNotify? > DPCOverrideCompositorCapabilities > > output: OUTPUT > colorspace_list: LISTofCOLORSPACEPRIORITY > > Errors: Output, Match > > Used by a composite manager to override the set of possible color > spaces/encodings and associated scores for composition for a given output. > > If used before requesting RedirectSubwindows on the root window, changes > will not take effect until a subsequent redirection of the root window > hierarchy by the requester has completed. Color spaces/encodings > associated > with each output must be identical, but scores may vary. If a composite > manager fails to fulfill these requirements before requesting > RedirectSubwindows on the root window, the server will instead empty the > set > of capabilities on each output, generating a DPCCompositorChangeNotify > event > for each. > > If used after the root window hierarchy has been redirected by the > requester, changes take effect immediately. The set of color > spaces/encodings specified must match those of other outputs on the > screen, > or a Match error results. Scores, however, may differ from other outputs. > > DPCCompositorChangeNotify events will be generated on the appropriate root > window when the compositor capabilities are changed by this request. If > applicable, the changes do not take effect until after the subsequent > redirection of the root window hierarchy has completed, thereby delaying > the > generation of the event. I think this request should take a list of { output, colorspace_list } tuples so the request can complete atomically. Once you've redirected the root window there's no reasonable way for the server to defer sending the CompositorChangeNotify events, so updating the scores for every output could generate one event per output, clients would need to guess how many more colorspace changes are coming before re-rendering, or else do redundant, possibly racy work. > DPCCompositorChangeNotify > > requester: WINDOW window requesting notification > output: OUTPUT output affected by change > colorspace_list: LISTofCOLORSPACEPRIORITY updated compositor > capabilities Likewise I think this event should return a list. - ajax _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel