[RFC] DeepColor Visual Class Extension

[Keith Packard]

Alex Goins <agoins at nvidia.com> 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
shouldn't be hard -- all you need is GetImage and PutImage and you'd be
"done" -- GetImage, pixman, PutImage. I don't see this as a terrible burden.

> Moreover, if we reported these visuals as part of the connection setup block,
> they would appear to be identical to the actual TrueColor visuals. How do you
> prevent a non-HDR client from selecting a masquerading 'DeepColor' visual? How
> do you distinguish them without the extended visual information?

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.

> We're brainstorming alternate ideas to handle backwards compatibility, and
> further suggestions are welcome.

I think lamely supporting core rendering would be awesome, and not a
huge burden of time. It fixes all of the corner cases nicely, provides
for simple things like xwd to 'just work'.

> I suppose that as long as we have a reasonable set of colorspaces to begin with
> and new ones don't come up often, that could work, it will just slow things down
> a bit if a new colorspace comes up and applications/compositors want to support
> it ASAP. Maybe that's what we want in order to avoid applications becoming
> reliant on compositor-specific colorspaces.

I think we should try to make this extensible without requiring that the
X server be re-compiled with the latest spec. I guess you've already got
extension requests that provide the set of these spaces which drivers
know about, so maybe that's sufficient?

> The transformation would have to be done implicitly by the server, because if a
> colorspace disappears, it's ostensibly because the compositor doesn't support
> it, so it wouldn't know about how to do the transformation.

Yeah, this just makes me want a well-defined core X definition for the
pixels even more though.

>> Maybe define the property as being what encoding the *next* frame will
>> be?
>
> A problem here is that without the Present extension, the concept of "next
> frame" is poorly defined in X. Specifying what we mean by this in terms of
> damage notifications, etc. would prove to be a challenge. Atomic updates could
> be left to an interaction with the Present extension, and otherwise would have
> to be handled e.g. _NET_WM_SYNC_REQUEST, the same as it is now with regular
> damage+composite "frame" handling.

Is there some way we could label in the protocol stream where the 'next
frame' was supposed to be? Maybe just 'the next request'? Suggestions
welcome, but I'd really like to avoid adding more stuff to X that makes
it hard to present the right pixels at each frame.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170721/bd501f0f/attachment.sig>