HDR support in Wayland/Weston

[Pekka Paalanen]

On Fri, 18 Jan 2019 09:05:53 +0530
"Sharma, Shashank" <shashank.sharma at intel.com> wrote:

> On 1/17/2019 5:33 PM, Pekka Paalanen wrote:
> > On Wed, 16 Jan 2019 09:25:06 +0530
> > "Sharma, Shashank" <shashank.sharma at intel.com> wrote:
> >  
> >> On 1/14/2019 6:51 PM, Pekka Paalanen wrote:  
> >>> On Thu, 10 Jan 2019 20:32:18 +0530
> >>> "Sharma, Shashank" <shashank.sharma at intel.com> wrote:
> >>>  
> >>>> Hello All,
> >>>>
> >>>> This mail is to propose a design for enabling HDR support in
> >>>> Wayland/Weston stack, using display engine capabilities, and get more
> >>>> feedback and input from community.  

> > In summary, rather than dynamically allow or not allow, a compositor
> > needs to live by its promise on what works. It cannot pull the rug from
> > under a client by suddenly hiding the window or showing it corrupted.
> > That is the baseline in behaviour.  
> Makes a lot of sense, and sounds like a stable design too.
> As per this design policy, while coming up, compositor can analyze the 
> static environment conditions like:
> - HW support for HDR
> - Kernel support for HDR
> 
> and based on these two it can decide to advertise the HDR capabilities 
> via the protocol, and once it does so, it has to make sure that it lives 
> up-to expectation.
> Now, the only variable in the environment is a hot-pluggable monitor, 
> which might/might not support HDR playback, and that needs to be handled 
> at runtime by:
> - Doing H2S tone mapping, if monitor can't support HDR playback.
> - and REC2020->REC709 conversion using CSC.
> - using GL blending as fallback if we are not able to prepare a plane 
> only state.
> 
> Does it seem like correct interpretation of your suggestions ?

Yes, it does.

Mind, in the future Weston may very well also support GPU hotplug for
additional sinks, which means that the kernel and graphics card support
becomes variable as well. But handling that is no different from
handling monitor variability.

> > Then we can have some mechanisms in place to inform clients about
> > changed conditions, like sending HDR content becomes useful or stops
> > being useful. The first mechanism here is the wl_surface.enter/leave
> > events: if the wl_surface enters the first HDR output, or leaves the
> > last HDR output, the client will know and may adapt if it wants to.  
> Again, sounds like a good idea.

As discussed with Graeme, the mechanism here might well be the
"prioritised output" protocol yet to be invented.


> > This means that you need to avoid interface name conflicts between
> > weston and wayland-protocols extensions.  
> Got it, I think you are suggesting something like the way how we 
> implemented aspect-ratio protocol in weston.

Well, aspect ratio did not have any protocol in the end. :-)


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/20190121/a8ea95bc/attachment.sig>