On Mon, 04 Mar 2019 08:32:45 +0000 Simon Ser <cont...@emersion.fr> said:
> On Monday, March 4, 2019 8:13 AM, Graeme Gill <grae...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
