HDR support in Wayland/Weston

Simon Ser contact at emersion.fr
Mon Mar 4 08:32:45 UTC 2019


On Monday, March 4, 2019 8:13 AM, Graeme Gill <graeme2 at argyllcms.com> wrote:
> And the current favorite is "blue light filter" effects, for which numerous
> applications are currently available. They tweak the white point
> of the display by arbitrarily modifying the hardware per channel LUTs.
> (i.e. f.lux, Redshift, SunsetScreen, Iris, Night Shift, Twilight etc.)
>
> Such applications have their place for those who like the effect, but
> ideally such usage would not simply blow color management away.

FWIW wlroots has a protocol for this [1]. GNOME and KDE have this feature
directly integrated in their compositor.

> In order of desirability it would be nice to:
>
> 3) Have the hardware Luts restored after an application that uses them
>    exits (i.e. like OS X handles it).

Agreed. This is done in our protocol and there's no such issue when builtin in
the compositor.

> 2) Implement virtual per channel LUTs, with the compositor combining them
>    together in some way, and have some means of the color management applications
>    being aware when the display is being interfered with by another application,
>    so that the user can be warned that the color management state is invalid.

Is there a "good way" to combine multiple LUTs?

> 1) A color managed API that lets an application shift the display white point
>    using chromatic adaptation, so that such blue light filter applications
>    can operate more predictably, as well as some means of the color management
>    applications being aware of when this is happening.

How should this look like? Disclaimer: I have no idea how these applications
work and I know nothing about color management.

I'm guessing this is a restriction of the "change the whole LUTs" API. Are there
any features the "blue light filter" app won't be able to implement when
switching to this API? Would the compositor part become complicated (judging
from [2] it seems different "blue light filter" apps may compute LUTs
differently)?

Since many compositors (GNOME, KDE, wlroots, maybe more) implement a way to
apply a "blue light filter", I think it's important to be able to notify color
management applications that they don't have exclusive access. Or maybe this
should just be handled internally by the compositor? (Display a warning or
something?)

Thanks,

[1]: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-gamma-control-unstable-v1.xml
[2]: https://github.com/jonls/redshift/blob/master/README-colorramp

--
Simon Ser
https://emersion.fr



More information about the wayland-devel mailing list