> 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
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
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
On Thu, 2017-10-26 at 19:50 -0700, Alex Goins wrote:
> DPCGetWindowDisplayCapabilities
>
> window: WINDOW
> =>
> output: OUTPUT
> colorspace_list: LISTofCOLORSPACEPRIORITY
>
> Errors: Window
>
> DPCGetWindowDisplayCapabilities functions
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
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
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
>
Thanks, Adam.
Here's an updated version of the spec:
DeepColor Extension
Version X.X
2017-XX-XX
Alex Goins
ago...@nvidia.com
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
>
> 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
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
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
>>
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
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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo