[RFC] DeepColor Visual Class Extension
Alex Goins
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!
Thanks,
Alex Goins
NVIDIA Linux Driver Team
--
DeepColor Extension
Version X.X
2017-XX-XX
Alex Goins
agoins at nvidia.com
NVIDIA Corporation
1. Introduction
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
events.
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.
1.1. Acknowledgements
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
be 0.
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
as HDR10,
_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:
_DEEPCOLOR_COMPOSITOR_COLORSPACES, ATOM[]
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
applicable:
_DEEPCOLOR_COLORSPACE, ATOM
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.
4. Requests
Please refer to the X11 Protocol Encoding document as this section uses
syntactic conventions and data types established there.
DPCGetVersion
client_major_version: CARD8
client_minor_version: CARD8
=>
server_major_version: CARD8
server_minor_version: CARD8
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).
DPCGetVisualInfo
visual_list: LISTofVISUALID
=>
per_visual_info: LISTofVISUALINFO
where:
VISUALINFO: [ core_visual_id: VISUALID
pixel_format: CARD32 ]
- pixel_format is an enumeration of pixel formats:
FP_R16G16B16A16 = 0,
UINT_R16G16B16A16,
UINT_A2R10B10G10,
UINT_A2B10G10R10,
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.
6. Encoding
The name of this extension is "DEEP-COLOR".
This document uses the same conventions as those used for the core X11 Protocol
Encoding.
DPCGetVersion
1 CARD8 opcode
1 0 DPC opcode
2 2 request length
2 CARD16 client_major_version
2 CARD16 client_minor_version
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 length
2 CARD16 server_major_version
2 CARD16 server_minor_version
20 unused
DPCGetVisualInfo
1 CARD8 opcode
1 1 DPC opcode
2 unused
4 n number of VISUALIDs in list
4n CARD32 VISUALIDs
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 m number of VISUALINFOs in list
24 unused
8m LISTofVISUALINFO items
VISUALINFO
4 VisualID core_visual_id
4 CARD32 pixel_format
7. Issues
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
mailing list