[RFC] DeepColor Visual Class Extension
agoins at nvidia.com
Tue Jul 18 01:04:18 UTC 2017
This is our latest iteration on the design of the visual class for use with HDR
drawables, handling how colorspace/encoding and pixel format are specified and
interpreted. We've been brainstorming this internally for a while, taking into
consideration comments that came up in the xorg-devel thread several months
back. We've now formalized it as an X extension.
This extension is designed to be flexible as to how HDR drawables are actually
implemented, leaving it up to the server / DDX drivers to decide. It should be
capable of working interchangeably when an external compositor is being used and
when one is not, with the server/driver being responsible for internal
composition in the latter case.
It should be capable of working with GLX, EGL, and Vulkan, keeping track of
colorspace/encoding and pixel format in API-agnostic locations so that
compositors need not rely on API-specific methods for querying these properties.
Supported colorspaces/encodings were chosen as a superset of those supported by
the requisite EGL/Vulkan extensions, with GLX relying entirely on the X
properties for the purpose of determining colorspace/encoding.
Let us know what you think!
NVIDIA Linux Driver Team
agoins at nvidia.com
The DeepColor Extension provides a new visual class, DeepColor, designed for
handling visuals that are incompatible with the existing core X visual classes:
StaticGray, StaticColor, TrueColor, GrayScale, PseudoColor, or DirectColor.
These visual classes provided 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 support a variety of HDR formats or any other formats that are
incompatible with the core X11 visual classes, DeepColor doesn't rely on a
colormap to define the relationship between pixel values and colors. Instead,
windows with DeepColor visuals will rely on a window property to define a
colorspace/encoding, chosen from an enumerated set of colorspaces/encodings
associated with the root window. Compositors may detect changes in the
colorspace/encoding of redirected windows by listening for PropertyNotify
In addition to supporting a variety of colorspaces/encodings, DeepColor visuals
must also support a variety of pixel formats, e.g. FP16 RGBA. The information
provided by the existing XVisualInfo structure is insufficient for
differentiating such formats, so a mechanism must be provided for clients to
determine the pixel formats of DeepColor visuals.
Zach Angold <zangold at nvidia.com>
James Jones <jajones at nvidia.com>
Robert Morell <rmorell at nvidia.com>
Aaron Plattner <aplattner at nvidia.com>
Andy Ritger <aritger at nvidia.com>
2. DeepColor Visual Class
The DeepColor extension defines a new visual class, DeepColor.
DeepColor visuals do not make use of the red_mask, green_mask, blue_mask, or
colormap_size fields of the XVisualInfo structure. Colormap size is defined to
Information pertaining to the pixel format and colorspace/encoding of DeepColor
visuals and associated windows, respectively, must be queried using the
mechanisms defined below.
3. Colorspace/Encoding Window Properties
Windows with DeepColor visuals must rely on window properties, as opposed to
colormaps, to determine the relationship between pixel values and colors. These
properties must specify atoms that correspond to colorspace/encoding pairs.
Possible colorspace/encoding atoms include, but are not limited to:
_DEEPCOLOR_SCRGB_LINEAR - scRGB colorspace with linear OETF,
_DEEPCOLOR_BT2020_LINEAR - BT.2020 colorspace with linear OETF,
_DEEPCOLOR_BT2020_PQ - BT.2020 colorspace with SMPTE ST.2084
Perceptual Quantizer (PQ) OETF, also known
_DEEPCOLOR_DCI_P3_LINEAR - DCI-P3 colorspace with linear OETF,
_DEEPCOLOR_DCI_P3_NONLINEAR - DCI-P3 colorspace with Gamma 2.6 OETF,
_DEEPCOLOR_DISPLAY_P3_NONLINEAR - DCI-P3 colorspace with sRGB-like OETF
Implementations may choose to add additional atoms to this list.
3.1. Root Window Properties
The DeepColor extension defines a root window property for determining the set
of colorspaces/encodings supported by the X server or external compositor:
This is a list of atoms indicating the colorspace/encoding pairs supported by
the compositor. The X server must initialize the property with a list of
colorspaces/encodings supported by its internal compositor, if applicable. If an
external application becomes responsible for compositing, it must override this
property with its own supported colorspaces/encodings. If the connection to the
external compositor is lost, the X server is responsible for restoring the
property to a list of colorspaces/encodings supported by its internal
compositor, if applicable.
It is the application's responsibility to listen for PropertyNotify events to
determine if the set of supported colorspace/encodings changes, and adjust its
rendering accordingly. This could occur due to an external compositor being
launched or killed, or due to a modeset.
3.2. Application Window Properties
The DeepColor extension defines a window property for determining the
colorspace/encoding being used by a window with a DeepColor visual, if
This is the colorspace/encoding pair being used by a window with a DeepColor
visual. The application MUST set this to a colorspace/encoding from
_DEEPCOLOR_COMPOSITOR_COLORSPACES, if non-empty. If undefined, the
colorspace/encoding of the drawable is undefined.
The application may change this window property to any colorspace/encoding from
the applicable set of supported colorspace/encodings at any time. Compositors
must listen for PropertyNotify events to determine if and when an application
changes _DEEPCOLOR_COLORSPACE, and adjust their composition accordingly.
Please refer to the X11 Protocol Encoding document as this section uses
syntactic conventions and data types established there.
If supplied, client_major_version and client_minor_version numbers indicate what
version of the protocol the client wants the server to implement. The
server_major_version and the server_minor_version numbers returned indicate the
protocol this extension actually supports. This might not equal the version sent
by the client. An implementation can (but need not) support more than one
version simultaneously. The server_major_version and server_minor_version allow
the creation of future revisions of the DeepColor extension protocol that may be
necessary. In general, the major version would increment for incompatible
changes, and the minor version would increment for small, upward-compatible
changes. Servers that support the protocol defined in this document will return
a server_major_version of one (1), and a server_minor_version of zero (0).
VISUALINFO: [ core_visual_id: VISUALID
pixel_format: CARD32 ]
- pixel_format is an enumeration of pixel formats:
FP_R16G16B16A16 = 0,
5. Events and Errors
No new events or errors are defined by this extension. Events for
colorspace/encoding changes are handled by the existing PropertyNotify event,
and pixel format cannot change without destroying and re-creating the drawable
with a new visual.
The name of this extension is "DEEP-COLOR".
This document uses the same conventions as those used for the core X11 Protocol
1 CARD8 opcode
1 0 DPC opcode
2 2 request length
2 CARD16 client_major_version
2 CARD16 client_minor_version
1 1 reply
2 CARD16 sequence number
4 0 length
2 CARD16 server_major_version
2 CARD16 server_minor_version
1 CARD8 opcode
1 1 DPC opcode
4 n number of VISUALIDs in list
4n CARD32 VISUALIDs
1 1 reply
2 CARD16 sequence number
4 m number of VISUALINFOs in list
8m LISTofVISUALINFO items
4 VisualID core_visual_id
4 CARD32 pixel_format
This spec does not address how HDR content should be downsampled to SDR content
for e.g. automatic redirection, XGetImage(), or core X11 / RENDER rendering.
Perhaps the server could handle this transparently without the need for
explicit functionality outlined in the spec.
This spec does not address what should happen to
__DEEPCOLOR_COMPOSITOR_COLORSPACES when an HDR-unaware compositor is started, as
it probably should.
More information about the xorg-devel