HDR support in Wayland/Weston

[Carsten Haitzler (The Rasterman)]

On Mon, 04 Mar 2019 08:32:45 +0000 Simon Ser <contact at emersion.fr> said:

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

apps should not have exclusive access. we're re-doing the whole horrid "install
colormap" thing from the x days of 256 color (or paletted/colormapped displays).

> 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
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com