HDR support in Wayland/Weston

[Harish Krupo]

Hi Arnaud,

Thank you for the comments, please find mine inline.

Arnaud Vrac <rawoul at gmail.com> writes:

> On Thu, Jan 17, 2019 at 4:26 AM Sharma, Shashank
> <shashank.sharma at intel.com> wrote:
>>
>> > The proposal is missing many important bits like negotiation of the
>> > supported output features with the client, double buffering the new
>> > colorspace related surface properties, using more of the hardware
>> > capabilities, performance issues, etc...
>>
>> > Also, the added protocols are
>> > probably too simple as far as color management is concerned.
>> Agree, there are two reasons for that:
>> - This proposal is a very high level design focusing the changes
>> required only to drive HDR video playback, in the real implementation,
>> you would see many of those mentioned. I think its too early to talk
>> about performance as we are still in design stage.
>> - As we have been discussing in parallel threads, HDR is too big a
>> feature, and we don't want to add too much of code in a single shot, and
>> create unwanted regressions and maintenance nightmares, rather, the aim
>> is to create small, modular, scalable, easy to review and test kind of
>> feature set, which might be targeting a very specific area, and
>> gradually complete this feature.
>>
>> But I would like to hear more about double buffering of the new
>> colorspace related surface properties if you can please elaborate more ?
>
> The colorspace related properties should be applied atomically when
> commiting the wl_surface. This is not done in Ville's patches, so
> there might be some rendering glitches when changing the colorspace
> while the surface is displayed.
>

Yes, both the colospace property and the hdr metadata for a surface are
double buffered and are applied only on wl_surface.commit. This should
be clear once we start posting our patches.

Thank you
Regards
Harish Krupo