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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel