[RFC] DeepColor Visual Class Extension
Alex Goins
agoins at nvidia.com
Fri Oct 27 02:50:06 UTC 2017
Here is an updated version of the spec based on the recent feedback, also
including a couple new issues that came up.
Diff is followed by full text.
Thanks,
Alex
diff --git a/deepcolorproto.txt b/deepcolorproto.txt
index 7406762..87fbf2d 100644
--- a/deepcolorproto.txt
+++ b/deepcolorproto.txt
@@ -44,10 +44,16 @@ Andy Ritger, NVIDIA Corporation <aritger at nvidia.com>
1.2. External Extension Dependencies
-This extension references the RandR extension for interaction with outputs
-using the OUTPUT protocol type and Output error, the Composite extension for
-interaction with RedirectSubwindows and UnredirectSubwindows, and the Render
-extension for use of the FIXED protocol type.
+This extension references the RandR extension for interaction with outputs using
+the OUTPUT protocol type, RROutputChangeNotify event, and Output error.
+
+The Composite extension is referenced for interaction with RedirectSubwindows
+and UnredirectSubwindows.
+
+The Present extension is referenced for interaction with the PresentPixmap
+request.
+
+The Damage extension is referenced for interaction the DamageNotify event.
Events are delivered via the Generic Event Extension.
@@ -55,9 +61,9 @@ Events are delivered via the Generic Event Extension.
DeepColor visuals appear as ordinary TrueColor visuals to the core protocol,
appearing to make use of the TrueColor visual class and relevant fields of the
-XVisualInfo structure as one would expect of an ordinary TrueColor visual.
-Rendering to DeepColor windows using the core protocol, however, is loosely
-defined.
+XVisualInfo structure as one would expect of an ordinary TrueColor visual. The
+exact content resulting from rendering to DeepColor windows using the core
+protocol, however, is up to the implementation.
The true format of the visual and window is defined by the extension, with
additional requests provided by the extension to determine relevant attributes
@@ -66,8 +72,10 @@ non-DeepColor aware core protocol rendering with the true format of the
window.
GetImage and PutImage requests must read and write pixels using a transfer
-function between the core protocol exposed TrueColor format and the true format
-of the window. The exact transfer function used, however, is determined by the
+function between the core protocol exposed TrueColor format and the actual
+DeepColor format of the window. The transfer function must be bijective -- that
+is, a pixel value must remain the same when transformed to the DeepColor format
+and back. The exact transfer function used, however, is determined by the
implementation, meaning that results should be "reasonable" but are essentially
undefined.
@@ -85,6 +93,10 @@ The DeepColor extension does not define any new errors.
4. Protocol Types
+FLOAT32
+
+ A 32-bit value in IEEE floating point format.
+
PIXELFORMAT { FP_R16G16B16A16
UINT_R16G16B16A16
UINT_A2R10G10B10
@@ -115,6 +127,11 @@ COLORSPACETYPE { Undefined
given DeepColor window. Some need an additional gamma specification to be
complete in their description of the encoding.
+ The OETF (Optical Electric Transfer Function), or inverse EOTF, defines the
+ encoding of optical intensities to stored values. A commonly known OETF is
+ that used by sRGB, typically referred to as "gamma." OETFs referred to here
+ are analogous to that used by sRGB, albeit often more complex and varied.
+
Undefined is a sentinel value in the event that a color space/encoding could
not be specified.
@@ -163,12 +180,13 @@ COLORSPACETYPE { Undefined
an FP16 pixel format.
COLORSPACE { type: COLORSPACETYPE
- gamma: FIXED }
+ gamma: FLOAT32 }
A pairing of a color space/encoding type with a gamma value. Some color
space/encoding types require an associated gamma value to fully define the
- encoding. If 'type' is a color space/encoding type that does not require a
- gamma value, 'gamma' is undefined.
+ encoding, in which case 'gamma' must be a value > 1.0. If 'type' is a color
+ space/encoding type that does not require a gamma value, 'gamma' is
+ undefined.
COLORSPACEPRIORITY { colorspace: COLORSPACE
score: CARD32 }
@@ -210,21 +228,19 @@ The name of this extension is "DEEP-COLOR".
If 'enable' is DPCDisplayChangeNotifyMask, DPCDisplayChangeNotify events
will be sent when the capabilities of a display associated with the screen
- change. DPCDisplayChangeNotify events may also be sent when this request
- executes if the display capabilities have changed since the client
- connected, to avoid race conditions.
+ change. DPCDisplayChangeNotify events will be sent when this request
+ executes to avoid potential race conditions when a client connects.
If 'enable' is DPCCompositorChangeNotifyMask, DPCCompositorChangeNotify
events will be sent when the capabilities of the compositor associated with
- the screen changes. DPCCompositorChangeNotify events may also be sent when
- this request executes if the compositor capabilities have changed since the
- client connected, to avoid race conditions.
+ the screen changes. DPCCompositorChangeNotify events will be sent when this
+ request executes to avoid potential race conditions when a client connects.
If 'enable' is DPCWindowChangeNotifyMask, DPCWindowChangeNotify events will
be sent when the color space/encoding being used for rendering into the
- requested window changes. DPCWindowChangeNotify events may also be sent when
- this request executes if the color space/encoding being used for rendering
- has changed since the client connected, to avoid race conditions.
+ requested window changes. DPCWindowChangeNotify events will be sent when
+ this request executes to avoid potential race conditions when a client
+ connects.
DPCGetVisualInfo
@@ -257,8 +273,9 @@ The name of this extension is "DEEP-COLOR".
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
- A composite manager must use a color space/encoding supported by the
- display(s) when compositing into the target window.
+ A composite manager should use a color space/encoding supported by the
+ display(s) when choosing a color space/encoding to use for composition into
+ the target window, or the contents may not be displayed accurately.
DPCGetWindowDisplayCapabilities
@@ -284,9 +301,9 @@ The name of this extension is "DEEP-COLOR".
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
-
- A composite manager must use a color space/encoding supported by the
- display(s) when compositing into the target window.
+ A composite manager should use a color space/encoding supported by the
+ display(s) when choosing a color space/encoding to use for composition into
+ the target window, or the contents may not be displayed accurately.
DPCGetCompositorCapabilities
@@ -308,9 +325,9 @@ The name of this extension is "DEEP-COLOR".
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
- An application must use a color space/encoding supported by the compositor
+ An application should use a color space/encoding supported by the compositor
when choosing a color space/encoding to use for rendering into a DeepColor
- window.
+ window, or the contents may not be composited accurately.
DPCGetWindowCompositorCapabilities
@@ -334,9 +351,9 @@ The name of this extension is "DEEP-COLOR".
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
- An application must use a color space/encoding supported by the compositor
+ An application should use a color space/encoding supported by the compositor
when choosing a color space/encoding to use for rendering into a DeepColor
- window.
+ window, or the contents may not be composited accurately.
DPCOverrideCompositorCapabilities
@@ -344,26 +361,30 @@ The name of this extension is "DEEP-COLOR".
output: OUTPUT
colorspace_list: LISTofCOLORSPACEPRIORITY
- Errors: Output
+ Errors: Output, Match
- Used by a composite manager to override the set of color spaces/encodings
- and associated scores for composition for a given output before using
- RedirectSubwindows on the root window. Changes will not take effect from a
- client perspective until a subsequent redirection of the root window
- hierarchy has completed.
+ Used by a composite manager to override the set of possible color
+ spaces/encodings and associated scores for composition for a given output.
- DPCCompositorChangeNotify events will be generated on the appropriate root
- window when the compositor capabilities are changed by this call. The
- changes do not take effect until after the subsequent redirection of the
- root window hierarchy has completed, so the event will also not be generated
- until then.
+ 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.
- The set of outputs represented in 'overrides' must be complete, and the set
- of color spaces/encodings associated with each of them must be identical or
- the capabilities will be cleared instead of updated to the new set, still
- generating a DPCCompositorChangeNotify event.
+ 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.
- The associated scores may vary from output to output.
+ 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.
DPCGetWindowColorspace
@@ -390,21 +411,58 @@ The name of this extension is "DEEP-COLOR".
Sets the color space/encoding being used for rendering into a specified
DeepColor window.
- For applications, this must be an option supported by the compositor, and
- must be updated in response to DPCCompositorChangeNotify events. Rendering
- using options not supported by the compositor will result in undefined
- graphical behavior.
+ For applications, this should be an option supported by the compositor, and
+ should be updated in response to DPCCompositorChangeNotify events.
+ Rendering using options not supported by the compositor will produce results
+ that may not be composited accurately.
+
+ Composite managers are expected to use this request to indicate to the
+ server which color space is being used for rendering into the target window.
+ In this case, the option should be supported by the display. Rendering using
+ options not supported by the display will produce results that may not be
+ displayed accurately.
+
+ 'window' must be a DeepColor window or a Match error results.
+
+ If 'colorspace' includes a 'colorspacetype' that makes use of the 'gamma'
+ field, and 'gamma' is not a value > 1.0, a Match error results.
+
+ DPCWindowChangeNotify events will be generated on the window when the color
+ space/encoding is changed by this request.
+
+
+ DPCSetNextPresentColorspace
+
+ window: WINDOW
+ colorspace: COLORSPACE
+
+ Errors: Window, Match
+
+ Sets the color space/encoding being used for rendering into a specified
+ DeepColor window, deferred until atomically updated when the next
+ PresentPixmap presentation completes.
+
+ If the Present extension is not present, the changes from this request will
+ not take effect.
+
+ For applications, this should be an option supported by the compositor, and
+ should be updated in response to DPCCompositorChangeNotify events.
+ Rendering using options not supported by the compositor at any given time
+ will produce results that may not be composited accurately.
Composite managers are expected to use this request to indicate to the
server which color space is being used for rendering into the target window.
- In this case, the option must be supported by the display. Rendering using
- options not supported by the display will result in undefined graphical
- behavior.
+ In this case, the option should be supported by the display. Rendering using
+ options not supported by the display will produce results that may not be
+ displayed accurately.
'window' must be a DeepColor window or a Match error results.
+ If 'colorspace' includes a 'colorspacetype' that makes use of the 'gamma'
+ field, and 'gamma' is not a value > 1.0, a Match error results.
+
DPCWindowChangeNotify events will be generated on the window when the color
- space/encoding is changed by this call.
+ space/encoding is changed by this request.
7. Extension Events
@@ -447,10 +505,21 @@ The name of this extension is "DEEP-COLOR".
manager failing to properly override the compositor capabilities before
redirecting the root window hierarchy.
- Applications must listen to this event and change which color space/encoding
- they are using for rendering if their current selection is no longer
- supported. They may choose a more favorable color space/encoding even if
- their current selection is still supported.
+ If a new output is added to the screen, the server will initialize the
+ compositor capabilities for the new output to be identical to those of
+ existing outputs (or empty if none existed prior). If a composite manager
+ has overridden the compositor capabilities, the scores will be initialized
+ to 0, otherwise the server may choose. It will then generate a
+ DPCCompositorChangeNotify event after the associated RROutputChangeNotify
+ event.
+
+ Applications should listen to this event and change which color
+ space/encoding they are using for rendering if their current selection is no
+ longer supported. They may choose a more favorable color space/encoding even
+ if their current selection is still supported.
+
+ Composite managers may listen to this event in order to override scores of
+ new outputs with more accurate selections.
DPCWindowChangeNotify
@@ -462,10 +531,13 @@ The name of this extension is "DEEP-COLOR".
This event is generated whenever the color space/encoding being used for
rendering into a requested window changes.
- Composite managers must listen to this event to accurately adjust their
+ If the Damage event is present, only future contents as indicated by
+ DamageNotify events should be interpreted with the new color space/encoding.
+
+ Composite managers should listen to this event to accurately adjust their
composition of application windows into the target window. Failure to adjust
- in response to DPCWindowChangeNotify events could result in undefined
- graphical behavior.
+ in response to DPCWindowChangeNotify events could result in inaccurate
+ composition.
8. Protocol Encoding
@@ -506,7 +578,7 @@ encoding document.
COLORSPACE
4 COLORSPACETYPE
- 4 FIXED gamma
+ 4 FLOAT32 gamma
COLORSPACEPRIORITY
@@ -666,6 +738,15 @@ encoding document.
4 WINDOW window
8 COLORSPACE colorspace
+
+ DPCSetNextPresentColorspace
+
+ 1 CARD8 opcode
+ 1 10 DPC opcode
+ 2 4 request length
+ 4 WINDOW window
+ 8 COLORSPACE colorspace
+
8.3 Protocol Events
DPC is the major opcode for the extension, as returned by XQueryExtension.
@@ -714,27 +795,40 @@ DPC is the major opcode for the extension, as returned by XQueryExtension.
9. Issues
-This spec does not address the suggestion that window color space/encoding
-should reflect that of the next frame. It is difficult to determine what the
-"next frame" is without the Present extension, and a concrete solution has yet
-to be found.
- * Perhaps this functionality could be the domain of an interaction between
- the Present extension and DeepColor-aware clients, where clients hand off
- the responsibility for finalizing the color space/encoding of a window to
- the Present extension, which would atomically update it with the
- presentation of the next frame before generating DPCWindowChangeNotify.
+Should SMPTE 2086 metadata be included, e.g. color primaries, white point, and
+luminance range of the mastering display, in order to tune tonemapping at the
+target HDR10 display? An additional request could be added to optionally
+associate such metadata with a window.
+
+See also:
+https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_surface_SMPTE2086_metadata.txt
+https://raw.githubusercontent.com/KhronosGroup/Vulkan-Docs/1.0/doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt
+
+Similarly, formats such as Dolby Vision and HDR10+, neither of which are
+currently included in this spec, require SMPTE 2094 dynamic metadata, which can
+change from frame to frame. This could be updated with a new request similar to
+DPCSetNextPresentColorspace.
+
+In the case of a mismatch between capabilities and a color space/encoding being
+used, there is a suggestion to restrict the image presented on the screen to the
+precision of the associated core visual, but the mechanism with which this could
+be done is not clear.
10. References
+[DAMAGE]
+ Packard, Keith and Eric Anholt, "The DAMAGE Extension", 2007-01-08,
+ https://cgit.freedesktop.org/xorg/proto/damageproto/plain/damageproto.txt
+
[RANDR]
Gettys, Jim and Keith Packard, "The X Resize, Rotate and Reflect Extension",
2009-10-05,
- http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
+ https://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
[COMPOSITE]
Packard, Keith and Deron Johnson, "Composite Extension", 2007-07-03,
- https://www.x.org/releases/current/doc/compositeproto/compositeproto.txt
+ https://cgit.freedesktop.org/xorg/proto/compositeproto/plain/compositeproto.txt
-[RENDER]
- Packard, Keith, "The X Rendering Extension", 2009-07-15,
- http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
+[PRESENT]
+ Packard, Keith, "The Present Extension", 2013-06-06,
+ https://cgit.freedesktop.org/xorg/proto/presentproto/plain/presentproto.txt
-----
DeepColor Extension
Version X.X
2017-XX-XX
Alex Goins
agoins at nvidia.com
NVIDIA Corporation
1. Introduction
The DeepColor Extension provides a means to expose visuals suitable for use with
formats that are incompatible with the existing visuals that make use of the
core X visual classes: StaticGray, StaticColor, TrueColor, GrayScale,
PseudoColor, and DirectColor.
These visual classes as defined by the core X11 protocol are insufficient for
visuals that require a greater than 32 bit depth, or non-integer formats. As
such, they are not suitable for many HDR formats.
In order to remediate this limitation without breaking existing applications,
the DeepColor extension provides visuals that appear to the core protocol as
standard TrueColor visuals, but utilize additional requests as defined by the
DeepColor extension to determine extended properties defining the actual format
of the associated window, including pixel format and color space/encoding.
Facilities are also provided for determining the capabilities and preferences of
the compositor and displays.
Visuals exposed via this extension will hereby be referred to as "DeepColor
visuals," and their associated windows will be referred to as "DeepColor
windows."
1.1. Acknowledgements
Zach Angold, NVIDIA Corporation <zangold at nvidia.com>
Gary Demos, <garyd at alumni.caltech.edu>
Adam Jackson, Red Hat, Inc. <ajax at nwnk.net>
James Jones, NVIDIA Corporation <jajones at nvidia.com>
Robert Morell, NVIDIA Corporation <rmorell at nvidia.com>
Keith Packard, Hewlett-Packard Company <keithp at keithp.com>
Aaron Plattner, NVIDIA Corporation <aplattner at nvidia.com>
Andy Ritger, NVIDIA Corporation <aritger at nvidia.com>
1.2. External Extension Dependencies
This extension references the RandR extension for interaction with outputs using
the OUTPUT protocol type, RROutputChangeNotify event, and Output error.
The Composite extension is referenced for interaction with RedirectSubwindows
and UnredirectSubwindows.
The Present extension is referenced for interaction with the PresentPixmap
request.
The Damage extension is referenced for interaction the DamageNotify event.
Events are delivered via the Generic Event Extension.
2. DeepColor Core Protocol Behavior
DeepColor visuals appear as ordinary TrueColor visuals to the core protocol,
appearing to make use of the TrueColor visual class and relevant fields of the
XVisualInfo structure as one would expect of an ordinary TrueColor visual. The
exact content resulting from rendering to DeepColor windows using the core
protocol, however, is up to the implementation.
The true format of the visual and window is defined by the extension, with
additional requests provided by the extension to determine relevant attributes
for use with external graphics APIs. The server is responsible for reconciling
non-DeepColor aware core protocol rendering with the true format of the
window.
GetImage and PutImage requests must read and write pixels using a transfer
function between the core protocol exposed TrueColor format and the actual
DeepColor format of the window. The transfer function must be bijective -- that
is, a pixel value must remain the same when transformed to the DeepColor format
and back. The exact transfer function used, however, is determined by the
implementation, meaning that results should be "reasonable" but are essentially
undefined.
If any other core rendering is attempted, the expectation is as if one used
GetImage to read from the window into a pixmap, performed the rendering there,
and then used PutImage to write the results back.
DeepColor visuals are returned later in the connection block than real TrueColor
visuals, with the intent of reducing the chance that existing applications
choose them by mistake and incurring unnecessary overhead.
3. Errors
The DeepColor extension does not define any new errors.
4. Protocol Types
FLOAT32
A 32-bit value in IEEE floating point format.
PIXELFORMAT { FP_R16G16B16A16
UINT_R16G16B16A16
UINT_A2R10G10B10
UINT_A2B10G10R10 }
These values are used to indicate a pixel format/memory layout associated
with a given DeepColor visual.
VISUALINFO { core_visual_id: VISUALID
pixel_format: PIXELFORMAT }
A pairing of a VISUALID with a PIXELFORMAT, used for returning the pixel
format of a queried DeepColor visual.
COLORSPACETYPE { Undefined
scRGB_Linear
BT2020_Linear
BT2020_PQ
BT2020_HLG
DCI_P3_D60_Linear
DCI_P3_D65_Linear
DCI_P3_D60_Gamma
DCI_P3_D65_Gamma
ACES_AP0_Linear
ACES_AP1_Linear }
These values are used to indicate a color space/encoding associated with a
given DeepColor window. Some need an additional gamma specification to be
complete in their description of the encoding.
The OETF (Optical Electric Transfer Function), or inverse EOTF, defines the
encoding of optical intensities to stored values. A commonly known OETF is
that used by sRGB, typically referred to as "gamma." OETFs referred to here
are analogous to that used by sRGB, albeit often more complex and varied.
Undefined is a sentinel value in the event that a color space/encoding could
not be specified.
scRGB_Linear describes an scRGB color space with linear OETF. scRGB uses the
same primaries and white point as sRGB, and the linear encoding is best used
with an FP16 pixel format.
BT2020_Linear describes a BT.2020 color space with linear OETF. BT.2020
defines its own primaries with a D65 white point, and the linear encoding is
best used with an FP16 pixel format.
BT2020_PQ describes a BT.2020 color space with SMPTE ST.2084 Perceptual
Quantizer (PQ) OETF, also known as HDR10. BT.2020 defines its own primaries
with a D65 white point, and the nonlinear encoding is best used with an
unsigned integer pixel format.
BT2020_HLG describes a BT.2020 color space with ARIB STD-B67 Hybrid
Log-Gamma (HLG) OETF, also known as HLG10. BT.2020 defines its own primaries
with a D65 white point, and the nonlinear encoding is best used with an
unsigned integer pixel format.
DCI_P3_D60_Linear describes a DCI-P3 color space with D60 white point and
linear OETF. DCI-P3 defines its own primaries, and the linear encoding is
best used with an FP16 pixel format.
DCI_P3_D65_Linear describes a DCI-P3 color space with D65 white point and
linear OETF. DCI-P3 defines its own primaries, and the linear encoding is
best used with an FP16 pixel format.
DCI_P3_D60_Gamma describes a DCI-P3 color space with D60 white point and
gamma OETF. DCI-P3 defines its own primaries, and the nonlinear encoding is
best used with an unsigned integer pixel format. The exact gamma value
varies and is specified separately.
DCI_P3_D65_Gamma describes a DCI-P3 color space with D65 white point and
gamma OETF. DCI-P3 defines its own primaries, and the nonlinear encoding is
best used with an unsigned integer pixel format. The exact gamma value
varies and is specified separately.
ACES_AP0_Linear describes an ACES colorspace with AP0 primaries and linear
OETF. ACES uses a D60 white point, and the linear encoding is best used with
an FP16 pixel format.
ACES_AP1_Linear describes an ACES colorspace with AP1 primaries and linear
OETF. ACES uses a D60 white point, and the linear encoding is best used with
an FP16 pixel format.
COLORSPACE { type: COLORSPACETYPE
gamma: FLOAT32 }
A pairing of a color space/encoding type with a gamma value. Some color
space/encoding types require an associated gamma value to fully define the
encoding, in which case 'gamma' must be a value > 1.0. If 'type' is a color
space/encoding type that does not require a gamma value, 'gamma' is
undefined.
COLORSPACEPRIORITY { colorspace: COLORSPACE
score: CARD32 }
A pairing of a color space/encoding with an associated score, used for
prioritizing color spaces/encodings when represented in a list.
DPCSELECTMASK { DPCDisplayChangeNotifyMask,
DPCCompositorChangeNotifyMask,
DPCWindowChangeNotifyMask }
5. Extension Initialization
The name of this extension is "DEEP-COLOR".
DPCQueryVersion
client-major-version: CARD32
client-minor-version: CARD32
=>
major-version: CARD32
minor-version: CARD32
The client sends the highest supported version to the server and the server
sends the highest version it supports, but no higher than the requested
version. Major versions changes can introduce incompatibilities in existing
functionality, minor version changes introduce only backward compatible
changes. It is the clients responsibility to ensure that the server
supports a version which is compatible with its expectations.
6. Extension Requests
DPCSelectInput
window: WINDOW
enable: SETofDPCSELECTMASK
Errors: Window, Value
If 'enable' is DPCDisplayChangeNotifyMask, DPCDisplayChangeNotify events
will be sent when the capabilities of a display associated with the screen
change. DPCDisplayChangeNotify events will be sent when this request
executes to avoid potential race conditions when a client connects.
If 'enable' is DPCCompositorChangeNotifyMask, DPCCompositorChangeNotify
events will be sent when the capabilities of the compositor associated with
the screen changes. DPCCompositorChangeNotify events will be sent when this
request executes to avoid potential race conditions when a client connects.
If 'enable' is DPCWindowChangeNotifyMask, DPCWindowChangeNotify events will
be sent when the color space/encoding being used for rendering into the
requested window changes. DPCWindowChangeNotify events will be sent when
this request executes to avoid potential race conditions when a client
connects.
DPCGetVisualInfo
visual_list: LISTofVISUALID
=>
per_visual_info: LISTofVISUALINFO
Non-DeepColor visuals specified in LISTofVISUALID will not be returned in the
resulting LISTofVISUALINFO.
DPCGetDisplayCapabilities
output: OUTPUT
=>
colorspace_list: LISTofCOLORSPACEPRIORITY
Errors: Output
DPCGetDisplayCapabilities retrieves a list of color spaces/encodings
and their associated scores from a given output, representing the
capabilities and preferences of the display as determined by the server.
Every color space/encoding represented in colorspace_list must be supported
by the display corresponding to the output, but those with higher associated
scores are preferred. The set of color space/encodings represented in
colorspace_list cannot change after server initialization, but the
associated scores may change. Although the set of color spaces/encodings
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
A composite manager should use a color space/encoding supported by the
display(s) when choosing a color space/encoding to use for composition into
the target window, or the contents may not be displayed accurately.
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.
Every color space/encoding represented in colorspace_list must be supported
by the display corresponding to the output, but those with higher associated
scores are preferred. The set of color space/encodings represented in
colorspace_list cannot change after server initialization, but the
associated scores may change. Although the set of color spaces/encodings
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
A composite manager should use a color space/encoding supported by the
display(s) when choosing a color space/encoding to use for composition into
the target window, or the contents may not be displayed accurately.
DPCGetCompositorCapabilities
output: OUTPUT
=>
colorspace_list: LISTofCOLORSPACEPRIORITY
Errors: Output
DPCGetCompositorCapabilities retrieves a list of color spaces/encodings and
their associated scores from a given output, representing the capabilities
and preferences of composition (whether provided by a composite manager or
in-server compositing).
The set of color spaces/encodings represented in colorspace_list must be
supported by the compositor, but those with higher associated scores are
preferred for a given output. Although the set of color spaces/encodings
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
An application should use a color space/encoding supported by the compositor
when choosing a color space/encoding to use for rendering into a DeepColor
window, or the contents may not be composited accurately.
DPCGetWindowCompositorCapabilities
window: WINDOW
=>
output: OUTPUT
colorspace_list: LISTofCOLORSPACEPRIORITY
Errors: Window
DPCGetWindowCompositorCapabilities functions identically to
DPCGetCompositorCapabilities, 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.
The set of color spaces/encodings represented in colorspace_list must be
supported by the compositor, but those with higher associated scores are
preferred for a given output. Although the set of color spaces/encodings
returned for every output must be identical at any given time, the
associated scores may vary from output to output.
An application should use a color space/encoding supported by the compositor
when choosing a color space/encoding to use for rendering into a DeepColor
window, or the contents may not be composited accurately.
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.
DPCGetWindowColorspace
window: WINDOW
=>
colorspace: COLORSPACE
Errors: Window, Match
Retrieves the color space/encoding being used for rendering into a specified
DeepColor window.
'window' must be a DeepColor window or a Match error results.
DPCSetWindowColorspace
window: WINDOW
colorspace: COLORSPACE
Errors: Window, Match
Sets the color space/encoding being used for rendering into a specified
DeepColor window.
For applications, this should be an option supported by the compositor, and
should be updated in response to DPCCompositorChangeNotify events.
Rendering using options not supported by the compositor will produce results
that may not be composited accurately.
Composite managers are expected to use this request to indicate to the
server which color space is being used for rendering into the target window.
In this case, the option should be supported by the display. Rendering using
options not supported by the display will produce results that may not be
displayed accurately.
'window' must be a DeepColor window or a Match error results.
If 'colorspace' includes a 'colorspacetype' that makes use of the 'gamma'
field, and 'gamma' is not a value > 1.0, a Match error results.
DPCWindowChangeNotify events will be generated on the window when the color
space/encoding is changed by this request.
DPCSetNextPresentColorspace
window: WINDOW
colorspace: COLORSPACE
Errors: Window, Match
Sets the color space/encoding being used for rendering into a specified
DeepColor window, deferred until atomically updated when the next
PresentPixmap presentation completes.
If the Present extension is not present, the changes from this request will
not take effect.
For applications, this should be an option supported by the compositor, and
should be updated in response to DPCCompositorChangeNotify events.
Rendering using options not supported by the compositor at any given time
will produce results that may not be composited accurately.
Composite managers are expected to use this request to indicate to the
server which color space is being used for rendering into the target window.
In this case, the option should be supported by the display. Rendering using
options not supported by the display will produce results that may not be
displayed accurately.
'window' must be a DeepColor window or a Match error results.
If 'colorspace' includes a 'colorspacetype' that makes use of the 'gamma'
field, and 'gamma' is not a value > 1.0, a Match error results.
DPCWindowChangeNotify events will be generated on the window when the color
space/encoding is changed by this request.
7. Extension Events
Events are delivered via the Generic Event Extension. If the Generic Event
Extension is not present, the events specified here will not be delivered.
DPCDisplayChangeNotify
requester: WINDOW window requesting notification
output: OUTPUT output affected by change
colorspace_list: LISTofCOLORSPACEPRIORITY updated display capabilities
This event is generated whenever the capabilities of a display associated
with the screen change. Note that the set of color spaces/encodings
represented in colorspace_list cannot change after server initialization,
but the associated scores may change. The set of color spaces/encodings
supported between the outputs must be identical, but the scores may vary.
Separate events will be received for each output.
Composite managers may choose to listen for this event to choose a more
favorable color space/encoding for rendering into the target window.
DPCCompositorChangeNotify
requester: WINDOW window requesting notification
output: OUTPUT output affected by change
colorspace_list: LISTofCOLORSPACEPRIORITY updated compositor capabilities
This event is generated whenever the capabilities of the compositor
associated with the screen change. Note that the capabilities of all outputs
associated with the screen change at the same time, and that the set of
color spaces/encodings supported between them must be identical, but the
scores may vary. Separate events will be received for each output.
This event may be generated if a composite manager overrides the in-server
compositing capabilities via DPCOverrideCompositorCapabilities, if the
server takes over again after the root window hierarchy has been
unredirected, or after the capabilities have been cleared due to a composite
manager failing to properly override the compositor capabilities before
redirecting the root window hierarchy.
If a new output is added to the screen, the server will initialize the
compositor capabilities for the new output to be identical to those of
existing outputs (or empty if none existed prior). If a composite manager
has overridden the compositor capabilities, the scores will be initialized
to 0, otherwise the server may choose. It will then generate a
DPCCompositorChangeNotify event after the associated RROutputChangeNotify
event.
Applications should listen to this event and change which color
space/encoding they are using for rendering if their current selection is no
longer supported. They may choose a more favorable color space/encoding even
if their current selection is still supported.
Composite managers may listen to this event in order to override scores of
new outputs with more accurate selections.
DPCWindowChangeNotify
requester: WINDOW window requesting notification
window: WINDOW window affected by change
colorspace: COLORSPACE updated color space/encoding
This event is generated whenever the color space/encoding being used for
rendering into a requested window changes.
If the Damage event is present, only future contents as indicated by
DamageNotify events should be interpreted with the new color space/encoding.
Composite managers should listen to this event to accurately adjust their
composition of application windows into the target window. Failure to adjust
in response to DPCWindowChangeNotify events could result in inaccurate
composition.
8. Protocol Encoding
This document uses the same syntactic conventions as the core X protocol
encoding document.
8.1 Common Types
PIXELFORMAT
0x00000000 FP_R16G16B16A16
0x00000001 UINT_R16G16B16A16
0x00000002 UINT_A2R10G10B10
0x00000003 UINT_A2B10G10R10
VISUALINFO
4 VISUALID
4 PIXELFORMAT
COLORSPACETYPE
0x00000000 Undefined
0x00000001 scRGB_Linear
0x00000002 BT2020_Linear
0x00000003 BT2020_PQ
0x00000004 BT2020_HLG
0x00000005 DCI_P3_D60_Linear
0x00000006 DCI_P3_D65_Linear
0x00000007 DCI_P3_D60_Gamma
0x00000008 DCI_P3_D65_Gamma
0x00000009 ACES_AP0_Linear
0x0000000a ACES_AP1_Linear
COLORSPACE
4 COLORSPACETYPE
4 FLOAT32 gamma
COLORSPACEPRIORITY
8 COLORSPACE
4 CARD32 score
4 unused
DPCSELECTMASK
0x0001 DPCDisplayChangeNotifyMask
0x0002 DPCCompositorChangeNotifyMask
0x0004 DPCWindowChangeNotifyMask
8.2 Protocol Requests
DPCQueryVersion
1 CARD8 major opcode
1 0 DPC opcode
2 3 request length
4 CARD32 client-major-version
4 CARD32 client-minor-version
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 CARD32 major-version
4 CARD32 minor-version
DPCSelectInput
1 CARD8 major opcode
1 1 DPC opcode
2 3 request length
4 WINDOW window
2 SETofDPCSELECTMASK enable
2 unused
DPCGetVisualInfo
1 CARD8 opcode
1 2 DPC opcode
2 2+n request length
4 n number of VISUALIDs in list
4n CARD32 VISUALIDs
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 2v reply length
4 v number of VISUALINFOs in list
20 unused
8v LISTofVISUALINFO items
DPCGetDisplayCapabilities
1 CARD8 opcode
1 3 DPC opcode
2 2 request length
4 OUTPUT output
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 4c reply length
4 c number of COLORSPACEPRIORITYs in list
20 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCGetWindowDisplayCapabilities
1 CARD8 opcode
1 4 DPC opcode
2 2 request length
4 WINDOW window
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 4c reply length
4 OUTPUT output
4 c number of COLORSPACEPRIORITYs in list
16 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCGetCompositorCapabilities
1 CARD8 opcode
1 5 DPC opcode
2 2 request length
4 OUTPUT output
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 4c reply length
4 c number of COLORSPACEPRIORITYs in list
20 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCGetWindowCompositorCapabilities
1 CARD8 opcode
1 6 DPC opcode
2 2 request length
4 WINDOW window
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 4c reply length
4 OUTPUT output
4 c number of COLORSPACEPRIORITYs in list
16 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCOverrideCompositorCapabilities
1 CARD8 opcode
1 7 DPC opcode
2 4+4c request length
4 OUTPUT output
4 c number of COLORSPACEPRIORITYs in list
4 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCGetWindowColorspace
1 CARD8 opcode
1 8 DPC opcode
2 2 request length
4 WINDOW window
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 reply length
8 COLORSPACE colorspace
DPCSetWindowColorspace
1 CARD8 opcode
1 9 DPC opcode
2 4 request length
4 WINDOW window
8 COLORSPACE colorspace
DPCSetNextPresentColorspace
1 CARD8 opcode
1 10 DPC opcode
2 4 request length
4 WINDOW window
8 COLORSPACE colorspace
8.3 Protocol Events
DPC is the major opcode for the extension, as returned by XQueryExtension.
DPCDisplayChangeNotify
1 35 (GenericEvent) type
1 DPC extension
2 CARD16 sequence number
4 4c length
2 0 evtype
2 unused
4 WINDOW requester
4 OUTPUT output
4 c number of COLORSPACEPRIORITYs in list
8 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCCompositorChangeNotify
1 35 (GenericEvent) type
1 DPC extension
2 CARD16 sequence number
4 4c length
2 1 evtype
2 unused
4 WINDOW requester
4 OUTPUT output
4 c number of COLORSPACEPRIORITYs in list
8 unused
16c LISTofCOLORSPACEPRIORITY colorspace_list
DPCWindowChangeNotify
1 35 (GenericEvent) type
1 DPC extension
2 CARD16 sequence number
4 0 length
2 2 evtype
2 unused
4 WINDOW requester
4 COLORSPACE colorspace
12 unused
9. Issues
Should SMPTE 2086 metadata be included, e.g. color primaries, white point, and
luminance range of the mastering display, in order to tune tonemapping at the
target HDR10 display? An additional request could be added to optionally
associate such metadata with a window.
See also:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_surface_SMPTE2086_metadata.txt
https://raw.githubusercontent.com/KhronosGroup/Vulkan-Docs/1.0/doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt
Similarly, formats such as Dolby Vision and HDR10+, neither of which are
currently included in this spec, require SMPTE 2094 dynamic metadata, which can
change from frame to frame. This could be updated with a new request similar to
DPCSetNextPresentColorspace.
In the case of a mismatch between capabilities and a color space/encoding being
used, there is a suggestion to restrict the image presented on the screen to the
precision of the associated core visual, but the mechanism with which this could
be done is not clear.
10. References
[DAMAGE]
Packard, Keith and Eric Anholt, "The DAMAGE Extension", 2007-01-08,
https://cgit.freedesktop.org/xorg/proto/damageproto/plain/damageproto.txt
[RANDR]
Gettys, Jim and Keith Packard, "The X Resize, Rotate and Reflect Extension",
2009-10-05,
https://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
[COMPOSITE]
Packard, Keith and Deron Johnson, "Composite Extension", 2007-07-03,
https://cgit.freedesktop.org/xorg/proto/compositeproto/plain/compositeproto.txt
[PRESENT]
Packard, Keith, "The Present Extension", 2013-06-06,
https://cgit.freedesktop.org/xorg/proto/presentproto/plain/presentproto.txt
On Thu, 19 Oct 2017, Alex Goins wrote:
> On Sun, 15 Oct 2017, Keith Packard wrote:
>
> > Alex Goins <agoins at nvidia.com> writes:
> >
> > > Thanks, Adam.
> > >
> > > Here's an updated version of the spec:
> >
> > This is looking very good. I don't have any architectural concerns at
> > this point, just some editorial comments.
>
> Thanks, that's good to hear.
>
> > > Rendering to DeepColor windows using the core protocol, however, is loosely
> > > defined.
> >
> > It seems to be actually fairly well defined to me. If core pixel values
> > could be 'round-tripped' through the deep storage, then core rendering
> > would be exact. That seems pretty simple with the UINT* formats when
> > used with a non-linear colorspace -- just use an identity mapping.
>
> Core rendering would be exact relative to core operations e.g. GetImage, but
> relative to the HDR format it would be more loosely defined. Probably just a
> matter of wording.
>
> Using the identity mapping for UINT* formats would work, as long as we don't
> care about an accurate representation of the SDR content when interpreted by HDR
> consumers. With a more accurate transfer function, SDR content could look
> correct even for HDR consumers. The spec leaves that up to the server, however,
> hence it being "loosely defined."
>
> > For a linear color space using FP format, I wonder if you could define a
> > function that would result in reliably transferring 256 levels in and
> > out of each primary?
>
> I don't see why not, but the same points about HDR consumers apply.
>
> > The principle reason I ask is that if pixel values can be reliably
> > stored in deep visuals, then the existing testing infrastructure can be
> > used to validate the implementation.
>
> Good point. The only part that really matters there is that there is a fixed 1:1
> mapping between the SDR pixel values and a set of HDR pixel values. As to
> whether the pixel values correspond to similar shades in both formats shouldn't
> matter to core operations, but would to the HDR display.
>
> The point about the 1:1 mapping between pixel values isn't very explicit in the
> current wording of the spec, but could be included as an explicit contraint on
> the server's transfer function.
>
> I could see that complicating things slightly for implementations that want to
> preserve accurate color both when displayed as HDR and when interpreted as SDR,
> but it shouldn't be unachievable, especially since the former case would only be
> about looking correct, rather than perfect accuracy.
>
> > > scRGB_Linear describes an scRGB color space with linear OETF. scRGB uses the
> > > same primaries and white point as sRGB, and the linear encoding is best used
> > > with an FP16 pixel format.
> >
> > I think you should define "OETF" in the spec; most people reading this
> > will not know where to start looking for a definition.
>
> Yes, I can do that.
>
> > > COLORSPACE { type: COLORSPACETYPE
> > > gamma: FIXED }
> >
> > Could you just use a FLOAT here? glx uses IEEE floats all over its
> > protocol, so it wouldn't be a new type on the wire. I'm a bit sorry to
> > not have used floats for Render; that was done when many smaller
> > embedded systems still lacked floating point hardware and we were
> > concerned about the performance implications of floats in the rendering
> > path. For this extension, there's no performance impact here, and using
> > a real float would be better. Heck, if you like, use a 64-bit IEEE float.
>
> Yeah, I chose FIXED because I was using Render as a reference and wasn't aware
> of the possibility of using floats in protocol. I agree that that is better.
>
> > > DPCSelectInput
> > >
> > > window: WINDOW
> > > enable: SETofDPCSELECTMASK
> > >
> > > Errors: Window, Value
> >
> > Either this request should always deliver an event or never deliver an
> > event. Having it 'sometimes' deliver events seems messy. I'd suggest
> > just having it always deliver one of each of the events selected; it's
> > easy to implement and, as you say, avoids race conditions when the
> > developer combines this with the query in the wrong order. That's
> > actually a nice cleanup compared with similar functionality in existing
> > functions.
>
> Fair enough.
>
> > > A composite manager must use a color space/encoding supported by the
> > > display(s) when compositing into the target window.
> >
> > What error is returned if this isn't done? And wouldn't a regular
> > application, running in non-composited mode, also have the same
> > requirement? After all, a compositing manager is just a regular client
> > drawing to a regular window.
>
> The wording should probably be changed to "should." As written, there is no
> error if a composite manager chooses something not supported by the display,
> just no expectation that the results will be displayed accurately. The
> capabilities of the display aren't allowed to change, only the preferences (the
> expectation being that the server will convert internally anything that doesn't
> match perfectly to the mode on a given display), so there's no excuse for a
> compositor to choose an option that the display doesn't support.
>
> An application, running in non-composited mode, does have the same requirement.
> However, in this case, the server is responsible for "compositing." The
> "compositor" properties don't apply only to composite managers, they also apply
> to the server's capabilities when no compositor is running.
>
> The reason for separating "compositor" and "display" capabilities is to solve
> the problem of a composite manager overriding the "compositor" capabilities and
> then having no visibility into what the server supports or prefers.
>
> If an application is not a composite manager, i.e. does not redirect the root
> window hierarchy and does not override compositor capabilities, it would look at
> the compositor capabilities regardless of whether or not a composite manager is
> running. An application shouldn't have to care if a composite manager is running
> or not, it just checks the "compositor" capabilities with the understanding that
> they are subject to change. Whether that's because the in-server
> compositor/composite manager changed capabilities/preferences, or because a
> composite manager started where there wasn't one before, is irrelevant to the
> application.
>
> > > DPCOverrideCompositorCapabilities
> >
> > > The set of outputs represented in 'overrides' must be complete, and the set
> > > of color spaces/encodings associated with each of them must be identical or
> > > the capabilities will be cleared instead of updated to the new set, still
> > > generating a DPCCompositorChangeNotify event.
> >
> > I think this means the compositing manager is required to emit one of
> > these requests for each output? If so, why not simply place all of those
> > in a single request so that we can verify that the compositing manager
> > did the right thing?
>
> The scores associated with the color spaces could vary between outputs (say, if
> the outputs are driving different HDR modes and the compositor wants to indicate
> to applications that a certain output prefers a certain input, since
> applications don't pay attention to the display capabilities), and representing
> that in one request would require a variable length list of variable length
> lists, screwing up the encoding.
>
> I actually just noticed that there is an artifact from when I originally wrote
> this request as you described, the last paragraph referencing 'overrides', which
> was originally a list of capabilities for each output. I must have missed that.
>
> > What happens when another output is added to the screen?
>
> Good question. I suppose that the composite manager (if applicable, otherwise
> it's all handled by the server anyway), would have to listen for
> RROutputChangeNotify and then use DPCOverrideCompositorCapabilities on that
> display, but that would still result in a transient state in between.
>
> Maybe the server could initialize the capabilities to a list of colorspaces
> identical to the other outputs (since they are required to be identical other
> than score), with all of the scores set to 0 until the composite manager
> overrides it.
>
> In any case the new output would be expected to have the same capabilities of
> the existing outputs, based on existing constraints. The capabilities, after
> all, have more to do with what the composite manager understands as input than
> anything specific to particular outputs. The reasoning for different
> capabilities per output is simply so that an application can intelligently pick
> an option based on the preferences of each output and the current location of
> the window.
>
> > > For applications, this must be an option supported by the compositor, and
> > > must be updated in response to DPCCompositorChangeNotify events. Rendering
> > > using options not supported by the compositor will result in undefined
> > > graphical behavior.
> >
> > I'd really rather this be 'should' and not 'must'. Given that we have
> > reasonable well-defined behaviour for conversion to core pixel values,
> > any colorspace not directly supported by the compositing manager can be
> > supported using core/render operations, leaving clients still functional
> > even with a mismatch between their colorspace and the compositing
> > manager colorspace.
>
> Given prior discussion, I agree. "Must" should probably be something enforced
> by the protocol, as this is not. Applications "should" use options supported by
> the compositor just as composite managers "should" use options supported by the
> display, since there's no expectation of accuracy otherwise.
>
> Since color space/encoding as this spec is concerned is orthogonal to actual
> storage format, choosing incorrectly should never be catastrophic, just probably
> won't look right (albeit probably still recognizable).
>
> > In its current form, this places a higher burden on applications than
> > compositing managers here -- they *must* support whatever colorspace the
> > compositing manager offers, while the compositing manager is free to
> > support only those it likes.
>
> Well, it's kind of a given that the producer must produce output that the
> consumer can take as input, in all cases, with the server down stream from the
> composite manager (if applicable) and the composite manager down stream from the
> applications.
>
> I agree that the requirement should be loosened from a protocol perspective, all
> of this should just be about helping each stage of the pipeline negotiate a
> desirable configuration with the later stage of the pipeline, and indicating
> their configuration so their output can be consumed accuracy.
>
> The exception is pixel format, which has to be explicit, but the lack of
> flexibility there means it isn't so complex.
>
> > > Composite managers are expected to use this request to indicate to the
> > > server which color space is being used for rendering into the target window.
> > > In this case, the option must be supported by the display. Rendering using
> > > options not supported by the display will result in undefined graphical
> > > behavior.
> >
> > I'm not happy with 'undefined' behaviour here. We've got three moving
> > pieces here (display, compositor, app) and things only work right when
> > they all follow the rules, and those rules are subject to arbitrary
> > change as you start/stop compositing managers and connect/disconnect
> > displays.
> >
> > I think a simple requirement is that the application be allowed to
> > choose any colorspace it likes and that, at worst, the image presented
> > on the screen will have been restricted to the associated core visual
> > precision. That's well defined by the spec and will mean that
> > incompatibilities between applications, compositing manager and display
> > will only result in lower-fidelity images, not 'undefined' results.
>
> That is something to consider, but how would you do that? Restricting to SDR is
> easy when we're only talking about core rendering being read by core operations,
> but what about output produced by HDR graphics APIs?
>
> How does the server know how to restrict the output of the composite manager to
> SDR if it doesn't understand the format the output is in? The same issue occurs
> between the compositor and the application.
>
> Later stages in the pipeline have no way to force earlier stages to put a
> certain format of pixels into their buffers, they can only make it clear which
> formats are supported.
>
> They could make a best effort, but that's really no better than "undefined."
>
> > > 9. Issues
> > >
> > > This spec does not address the suggestion that window color space/encoding
> > > should reflect that of the next frame. It is difficult to determine what the
> > > "next frame" is without the Present extension, and a concrete solution has yet
> > > to be found.
> > >
> > > * Perhaps this functionality could be the domain of an interaction between
> > > the Present extension and DeepColor-aware clients, where clients hand off
> > > the responsibility for finalizing the color space/encoding of a window to
> > > the Present extension, which would atomically update it with the
> > > presentation of the next frame before generating
> > > DPCWindowChangeNotify.
> >
> > Yup. Should work fine. This should be done using a separate request so
> > that applications can still set the colorspace without using
> > Present. Essentially, the application would do
> >
> > SetNextPresentColorspace
> > PresentPixmap
> >
> > and the colorspace seen by the compositor when it receives the
> > associated damage will be the new one. Hrm. It will receive that in an
> > event, presumably directly before the Damage event. The compositor would
> > be wise to look for a damage event when it receives the new colorspace
> > information, or perhaps it could infer that only future contents as
> > indicated by Damage events should be interpreted in the new colorspace?
>
> That makes sense.
>
> Seems it could be handled either way, the understanding just being that all
> future damage after receiving a DPCWindowChangeNotify event would be in the new
> color space. Not a bad convention to go by even without use of the Present
> extension, it just wouldn't be guaranteed without it.
>
> Thanks,
> Alex
>
> >
> > --
> > -keith
> >
>
More information about the xorg-devel
mailing list