[RFC wayland-protocols v3 1/1] unstable: add color management protocol

Pekka Paalanen ppaalanen at gmail.com
Thu Mar 21 10:05:37 UTC 2019


On Wed, 20 Mar 2019 20:51:36 +0000
Simon Ser <contact at emersion.fr> wrote:

> On Tuesday, March 19, 2019 1:23 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > Removing the initial uncertainty would require quite some more protocol

> > "after binding"?
> >
> > If a client creates a color space object from an ICC profile, there is
> > no need to send the ICC file immediately back to the client.
> >
> > Should sending this event be tied to the request that created this
> > object, or should this object have an explicit request to emit this
> > event?  
> 
> Does the client know in advance what the size of the profile will be?

Why would it need to?

> (Maybe this should be an event, and the request to fill a FD a request)

I meant that the proposed event with fd remains as is, but is never
sent automatically; instead, a new request would be added that simply
triggers sending the event.

A request "please fill in this FD with the data" has a couple of
issues: is the backing storage large enough, and how will the client know
when it is done. These are certainly solvable, but complicate things.

> > I think an explicit request would be better because... it is explicit.
> > It does not add any roundtrips that are not already there. In the cases
> > where a client likely wants to get the ICC file, it has already had to
> > create the color space protocol object itself and sending another
> > request on the object goes in the same message burst as creating it.  


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190321/cea234d7/attachment.sig>


More information about the wayland-devel mailing list