[RFC] Visual Class for On-Screen HDR Drawables

[Adam Jackson]

(accidentally sent only to Alex, resending so the list gets it too)

On Thu, 2016-12-22 at 19:43 -0800, Alex Goins wrote:

> > One option would be to expose the drawables with existing visuals
> > through the core protocol, then provide an extension which provides
> > extended information. That would make everything cross-compatible and
> > allow new applications to work with existing compositing managers,
> > although the result would be limited to core X capabilities.
> > 
> > I'm pretty uncomfortable with the notion that X can't actually interpret
> > the pixels as that will make lots of existing software fail, including
> > many accessibility solutions.
> 
> That's a good point regarding the accessibility issue, hadn't considered that.
> 
> I actually like this idea. One of the main reasons why I was shying away from
> the idea of actually covering the new formats with new visual class was that I
> didn't want us to have to propose revisions to the core protocol every time
> there's a new format. Using an extension to query extended attributes gets
> around that.
> 
> Would it be worthwhile to still add a new visual class, defined as a visual
> class for visuals whose extended attributes are queried through the extension,
> so that applications don't have to use it for every existing visual?

Either we add a visual class or we retcon the spec for TrueColor.
Currently the spec says:

"The red-mask, green-mask, and blue-mask are only defined for
DirectColor and TrueColor. Each has one contiguous set of bits set to 1
with no intersections. Usually each mask has the same number of bits
set to 1."

The masks are 32-bit integers, so they're not big enough for FP16. I
don't know if the shared-exponent formats are display formats for this
purpose, but if they were you could also argue that the exponent should
be set in all the maks... maybe.

Likewise X11 defines colors as 32-bit integers. For DeepColor visuals
we'd probably need to reinterpret those as if they were TrueColor
representations of the sRGB subset; which is a little weird, since for
all the other visual formats the "color" is the literal pixel value, so
again, pretty sure we want a new visual class.

The same "convert to/from sRGB" approach is probably sufficient for
GetImage/PutImage? I don't think libX11 is set up to handle >32bpp
pixels correctly, so that might be the best we can do. Given that
GetImage users are expecting unorm8 anyway...

Finally, the rop and planemask parts of the GC really don't make sense
for floats. I'd be inclined to define the new visual class such that
only GXcopy with planemask ~0 is defined.

- ajax