Re: [RFC] DeepColor Visual Class Extension

2017-11-10 Thread Alex Goins
> On Fri, 2017-11-03 at 21:04 -0700, Alex Goins wrote: > > > > > DPCCompositorChangeNotify > > > > > > > > requester: WINDOW window requesting notification > > > > output: OUTPUT output affected by change > > > > colorspace_list: LISTofCOLORSPACEPRIORITY

Re: [RFC] DeepColor Visual Class Extension

2017-11-06 Thread Adam Jackson
On Fri, 2017-11-03 at 21:04 -0700, Alex Goins wrote: > > > DPCCompositorChangeNotify > > > > > > requester: WINDOW window requesting notification > > > output: OUTPUT output affected by change > > > colorspace_list: LISTofCOLORSPACEPRIORITY updated compositor

Re: [RFC] DeepColor Visual Class Extension

2017-11-03 Thread Alex Goins
On Thu, 2 Nov 2017, Adam Jackson wrote: > On Thu, 2017-10-26 at 19:50 -0700, Alex Goins wrote: > > > DPCGetWindowDisplayCapabilities > > > > window: WINDOW > > => > > output: OUTPUT > > colorspace_list: LISTofCOLORSPACEPRIORITY > > > > Errors: Window

Re: [RFC] DeepColor Visual Class Extension

2017-11-02 Thread Adam Jackson
On Thu, 2017-10-26 at 19:50 -0700, Alex Goins wrote: > DPCGetWindowDisplayCapabilities > > window: WINDOW > => > output: OUTPUT > colorspace_list: LISTofCOLORSPACEPRIORITY > > Errors: Window > > DPCGetWindowDisplayCapabilities functions

Re: [RFC] DeepColor Visual Class Extension

2017-10-26 Thread Alex Goins
Here is an updated version of the spec based on the recent feedback, also including a couple new issues that came up. Diff is followed by full text. Thanks, Alex diff --git a/deepcolorproto.txt b/deepcolorproto.txt index 7406762..87fbf2d 100644 --- a/deepcolorproto.txt +++ b/deepcolorproto.txt

Re: [RFC] DeepColor Visual Class Extension

2017-10-18 Thread Alex Goins
On Sun, 15 Oct 2017, Keith Packard wrote: > Alex Goins writes: > > > Thanks, Adam. > > > > Here's an updated version of the spec: > > This is looking very good. I don't have any architectural concerns at > this point, just some editorial comments. Thanks, that's good to

Re: [RFC] DeepColor Visual Class Extension

2017-10-15 Thread Keith Packard
Alex Goins writes: > Thanks, Adam. > > Here's an updated version of the spec: This is looking very good. I don't have any architectural concerns at this point, just some editorial comments. > Rendering to DeepColor windows using the core protocol, however, is loosely >

Re: [RFC] DeepColor Visual Class Extension

2017-10-13 Thread Alex Goins
Thanks, Adam. Here's an updated version of the spec: DeepColor Extension Version X.X 2017-XX-XX Alex Goins ago...@nvidia.com

Re: [RFC] DeepColor Visual Class Extension

2017-09-25 Thread 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

Re: [RFC] DeepColor Visual Class Extension

2017-09-20 Thread Jacob Lifshay
> > If we left them out of the connection setup block and relied on a separate > request to get a list of DeepColor visuals it would alleviate that issue, but > then we run into the same issue Aaron pointed out with XGetWindowAttributes. > Non-HDR clients would get what appears to be a bogus

Re: [RFC] DeepColor Visual Class Extension

2017-09-14 Thread Keith Packard
Aaron Plattner writes: >>> 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

Re: [RFC] DeepColor Visual Class Extension

2017-09-14 Thread Aaron Plattner
On 09/11/2017 09:10 AM, Adam Jackson wrote: > On Mon, 2017-08-14 at 19:17 -0700, Alex Goins wrote: > >> 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 >>

Re: [RFC] DeepColor Visual Class Extension

2017-09-11 Thread Keith Packard
Alex Goins writes: > 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. It seems like

Re: [RFC] DeepColor Visual Class Extension

2017-09-11 Thread Adam Jackson
On Mon, 2017-08-14 at 19:17 -0700, Alex Goins wrote: > 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

Re: [RFC] DeepColor Visual Class Extension

2017-08-14 Thread Alex Goins
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

Re: [RFC] DeepColor Visual Class Extension

2017-07-27 Thread Keith Packard
Keith Packard writes: > You can't prevent that, but I wouldn't worry -- it's been a long time > since common clients went looking for a non-default Visual as the > default is 24-bits RGB, which is about as good as you can get. And a day later, I ran 'lxterminal', which goes

Re: [RFC] DeepColor Visual Class Extension

2017-07-27 Thread Adam Jackson
On Fri, 2017-07-21 at 20:18 -0700, Alex Goins wrote: > > What I'd love to see is to have these clients report 'TrueColor' in the > > core, with a 'real' set of red/green/blue masks, such that calling > > GetImage would give you bits in that format. Then you'd offer 'extended > > visual

Re: [RFC] DeepColor Visual Class Extension

2017-07-22 Thread Keith Packard
Alex Goins writes: > In a perfect world with everything fully implemented I like this idea, since > it > makes it obvious where downsampling needs to happen and how to interpret the > downsampled contents. Frankly, the core protocol is easy enough to implement that this

Re: [RFC] DeepColor Visual Class Extension

2017-07-21 Thread Alex Goins
Inline On Wed, 19 Jul 2017, Keith Packard wrote: > * PGP Signed by an unknown key > > Alex Goins writes: > > > 2. DeepColor Visual Class > > > > The DeepColor extension defines a new visual class, DeepColor. > > As Adam says, reporting a new visual class to existing

Re: [RFC] DeepColor Visual Class Extension

2017-07-19 Thread Keith Packard
Alex Goins writes: > 2. DeepColor Visual Class > > The DeepColor extension defines a new visual class, DeepColor. As Adam says, reporting a new visual class to existing clients may well confuse existing applications. What I'd love to see is to have these clients report

Re: [RFC] DeepColor Visual Class Extension

2017-07-18 Thread Aaron Plattner
On 07/18/2017 07:18 AM, Adam Jackson wrote: > On Mon, 2017-07-17 at 18:04 -0700, Alex Goins wrote: >> 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

Re: [RFC] DeepColor Visual Class Extension

2017-07-18 Thread Adam Jackson
On Mon, 2017-07-17 at 18:04 -0700, Alex Goins wrote: > 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

[RFC] DeepColor Visual Class Extension

2017-07-17 Thread Alex Goins
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