[RFC] DeepColor Visual Class Extension

[Adam Jackson]

On Mon, 2017-08-14 at 19:17 -0700, Alex Goins wrote:
> We brainstormed all of the suggestions amongst ourselves, and have a revised
> version of the spec. It also includes some changes of our own.
> 
> Unfortunately, we weren't able to bottom out on everything (most notably the
> masquerading DeepColor/TrueColor visuals), but the suggestions we haven't yet
> implemented in the spec are included in the issues section, along with our
> outstanding concerns. We will likely need more discussion over email or at XDC
> to make sure that these suggestions are fully fleshed out.

There was a very productive discussion about this at XDC, so for the
benefit of those who were unable to attend - and to ensure we're all on
the same page - here's a quick summary.

1) No new visual class. The risk of client incompatibility is
unacceptable. DeepColor visuals will appear to be TrueColor in the core
protocol, but rendering to them with the core protocol is essentially
undefined. To be precise, GetImage and PutImage must do something
reasonable (though the exact transfer function is an implementation
detail), and if any other core rendering is attempted, the expectation
is as if one did GetImage to a pixmap, performed the rendering there,
and PutImage'd the result back. Rendering that crosses visuals is
already undefined in the protocol.

2) No window properties. Equivalent state and transitions will be
encoded as new requests in the DeepColor extension itself.

3) Clients will be protected from accidentally selecting a DeepColor
visual in the usual way, by returning those visuals later in the list
than real TrueColor visuals. The Composite extension had difficulty
with some clients that opted for the visual with the most rgb bits, but
as the new visuals will appear indistinguishable to the core protocol
this should not arise, and the "pick the first one that matches"
heuristic in most toolkits should continue to do the right thing.

4) We can add a hack to libX11 a la XLIB_SKIP_ARGB_VISUALS to forcibly
conceal DeepColor visuals from buggy clients. We will not do so for
libxcb, which is a direct protocol binding not an application
interface; you asked for it, you got it.

5) DeepColor visuals will not have a corresponding GLX visual. The GLX
spec very carefully allows fbconfigs to have more r/g/b bits than any
visual they might point to, so apps that want to do HDR GL will need to
select by fbconfig; this should be no burden, as this is what you
already have to do for float pbuffers. The existing visual select group
mechanism can be used to ensure non-HDR clients do not accidentally
select an HDR visual.

6) GLX requires that the context's rendering type match the drawable's
fbconfig. This might have made some sense for color index vs. RGBA, but
GLX_ARB_fbconfig_float defines "float RGBA" as yet a third type. For
modern implementations this is a fairly daft limitation, since they can
usually render to arbitrary formats for non-window-system FBOs. So
rather than require a compositor to use multiple contexts and somehow
pass resources between them, we can port the EGL_KHR_no_config_context
extension to GLX. A draft spec for this, should anybody besides Xorg
shipping a GLX implementation wish to review it, is here:

https://github.com/KhronosGroup/OpenGL-Registry/pull/102

- ajax