HDR support in Wayland/Weston

[Chris Murphy]

On Mon, Mar 4, 2019 at 12:13 AM Graeme Gill <graeme2 at argyllcms.com> wrote:
>
> Chris Murphy wrote:
>
> > A common offender were games. They'd try to access the video card LUT
> > directly for effects, but then not reset it back to what it was,
> > rather reset it to a hardwired assumption the game makes,
>
> 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.)

It's a really good example. I have no idea how they work.  GNOME has
one built-in called "Night Light" and I use it on Wayland. So if
Wayland no longer supports applications altering video hardware LUTs,
then I'm not sure how it does it for every pixel from every
application, both Wayland and XWayland.


> Such applications have their place for those who like the effect, but
> ideally such usage would not simply blow color management away.

I've never been suspicious upon reset but I admit I've never measured
a before and after.


> 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).
>
> 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.
>
> 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.
>

Yep this could be done with the ICC 'color space' class very cheaply,
built on the fly even. And applied in the intermediate color space so
it affects every pixel for every display regardless of source.

As for notification I think it's more practical and useful that we'd
find this in a system UI element, like settings, related to the
display profile and calibration state. Getting messages between
applications is harder, there isn't universal agreement on using dbus,
or even asking colord what the state is. But the system settings,
devices > displays > color panel, could certainly put up a ! in a red
triangle and if you click it or hover you get a notice that the
display state is not calibrated; or some such. It may in fact still be
calibrated, but chromatically adapted with a different white point in
mind, but I think most users will better grok "not calibrated" than
some more technically accurate description.


-- 
Chris Murphy