Re: [RFC] Visual Class for On-Screen HDR Drawables

On Tue, 2017-02-28 at 19:23 -0800, Alex Goins wrote: > > FYI - it's only the texture_from_pixmap texture target attributes that they > base > off of the root window, e.g. GLX_TEXTURE_2D_EXT, GLX_TEXTURE_RECTANGLE_EXT, > GLX_TEXTURE_FORMAT_RBGA_EXT. They get the fbconfig from the X pixmap's

Re: [RFC] Visual Class for On-Screen HDR Drawables

Pinging in case this got buried. Thanks, Alex On Wed, 1 Mar 2017, Alex Goins wrote: > Thanks Adam. Inline - > > On Fri, 10 Feb 2017, Adam Jackson wrote: > > > On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote: > > > Any input? > > > > Inline below... > > > > > > Would it be a major

Re: [RFC] Visual Class for On-Screen HDR Drawables

Thanks Adam. Inline - On Fri, 10 Feb 2017, Adam Jackson wrote: > On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote: > > Any input? > > Inline below... > > > > Would it be a major problem for automatic redirection to destroy HDR? > > > Compositors could disable automatic redirection for

Re: [RFC] Visual Class for On-Screen HDR Drawables

On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote: > Any input? Inline below... > > Would it be a major problem for automatic redirection to destroy HDR? > > Compositors could disable automatic redirection for DeepColor windows, and > > redirect themselves with preserved HDR. It's not a

Re: [RFC] Visual Class for On-Screen HDR Drawables

Any input? Thanks, Alex On Wed, 25 Jan 2017, Alex Goins wrote: > >Either we define the interaction with Render, or automatic redirection > >(and backing store) don't work. But again we're painted into a bit of a > >corner: > > > >typedef struct { > >CARD16 red B16; > >CARD16

Re: [RFC] Visual Class for On-Screen HDR Drawables

>Either we define the interaction with Render, or automatic redirection >(and backing store) don't work. But again we're painted into a bit of a >corner: > >typedef struct { >CARD16 red B16; >CARD16 redMask B16; >CARD16 green B16; >CARD16 greenMask B16; >

Re: [RFC] Visual Class for On-Screen HDR Drawables

On Tue, 2017-01-03 at 19:27 -0800, Keith Packard wrote: > > Adam Jackson writes: > > 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. > >

Re: [RFC] Visual Class for On-Screen HDR Drawables

Fredrik Höglund writes: > The purpose of the masks would then be to describe this conversion, > while the actual memory format would be obtained through the > extension. Sure, although in practice, I'd imagine we'd only bother to expose them only as 8-bit components (so you'd

Re: [RFC] Visual Class for On-Screen HDR Drawables

Adam Jackson writes: > 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

Re: [RFC] Visual Class for On-Screen HDR Drawables

On Monday 02 January 2017, Adam Jackson wrote: > (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

Re: [RFC] Visual Class for On-Screen HDR Drawables

(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

Re: [RFC] Visual Class for On-Screen HDR Drawables

> >> To allow for scRGB visuals, as well as others with arbitrarily large color > >> components, we'd like to propose a new visual class that is opaque to X > >> rendering, but allows for drawables with arbitrary attributes to be used > >> for > >> on-screen rendering and compositing via GLX.

Re: [RFC] Visual Class for On-Screen HDR Drawables

> > VoidColor is a visual class defined to have a static colormap of 0 > > elements.  It > > is incapable of receiving X rendering, but is compatible with any GLX > > drawable > > of the correct depth regardless of other attributes. The idea is that you > > could > > pass any GLX fbconfig to

Re: [RFC] Visual Class for On-Screen HDR Drawables

Adam Jackson writes: > On Fri, 2016-12-16 at 18:44 -0800, Alex Goins wrote: > >> To allow for scRGB visuals, as well as others with arbitrarily large color >> components, we'd like to propose a new visual class that is opaque to X >> rendering, but allows for drawables with

Re: [RFC] Visual Class for On-Screen HDR Drawables

On Fri, 2016-12-16 at 18:44 -0800, Alex Goins wrote: > To allow for scRGB visuals, as well as others with arbitrarily large color > components, we'd like to propose a new visual class that is opaque to X > rendering, but allows for drawables with arbitrary attributes to be used for > on-screen

[RFC] Visual Class for On-Screen HDR Drawables

Hello all, For those who aren't aware, Andy Ritger gave a talk at XDC 2016 about what the advent of HDR displays means for the Linux ecosystem: https://www.x.org/wiki/Events/XDC2016/Program/ritger_hdr/. To make a long story short, displays capable of displaying HDR content mean that we need to