[RFC] DeepColor Visual Class Extension

[Alex Goins]

On Thu, 2 Nov 2017, Adam Jackson wrote:

> 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?

Good points. For root windows, maybe it should return the result for the primary
output? Similarly, ties could prefer the primary output, followed by "pick
something."

Having an associated event makes sense. I don't think ordering should matter
much, as the info is just a suggestion to the application that it might want to
pick a different color space. It doesn't even have to do it, as it's expected
that supported colorspaces are supported on all outputs, albeit posssibly with
necessary conversion.

Ordering matters more when the application actually makes the change.

> >     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.

My initial reason for not having a list was that it would result in a list of
lists. Is there a precedent for this? It seems like it would complicate the
encoding unless the nested list is fixed length.

Thanks,
Alex

> - ajax
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel