A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

On Thu, 15 Dec 2016 20:26:30 +0100
Kai-Uwe <ku.b-list at gmx.de> wrote:

> Am 15.12.2016 um 18:06 schrieb Mattias Andrée:
> > On Thu, 15 Dec 2016 17:51:48 +0100
> > Kai-Uwe <ku.b-list at gmx.de> wrote:
> >   
> >> Am 15.12.2016 um 16:15 schrieb Mattias Andrée:  
> >>> On Thu, 15 Dec 2016 13:18:17 +0100
> >>> Kai-Uwe <ku.b-list at gmx.de> wrote:    
> >>>> libcoopgamma is GPL. A really unacceptable choice
> >>>> for a API, which shall be used by everyone to reach
> >>>> the goal of a more structured / disciplined gamma
> >>>> access.    
> >>>
> >>> libcoopgamma is just one implementation, anyone can
> >>> choose make there library with whatever license they
> >>> want.    
> >>
> >> from the libcoopgamma README:
> >>         more importantly, all programs that
> >> 	use libcoopgamma can change the gamma ramps
> >> without overriding each others changes
> >>
> >> Nice statement. However the chance is high, that your
> >> code path will be ignored by other color configuration
> >> systems and thus the user experience is irritating at
> >> best.  
> > 
> > I'm not sure I understand what you are trying to say.  
> 
> Your above expressed intention from the README is likely
> to fail. If a different system tries to bring effects
> into the desktop appearance and uses ramps like your
> library does or simply restores the calibration state
> (gamma ramps) of a given ICC monitor profile, the
> libcoopgamma effects are likely to be destroyed.

Yes, if a program uses e.g. libgamma instead of libcoopgamma
it override what all libcoopgamma-applications have done.
I didn't think this is necessary to clarify, it should be
obvious. However, programs do not need to use libcoopgamma,
the can talk directly with coopgammad or, if the display
server implements cooperative gamma, the directly with the
display server.

> 
> >> Maybe a configuration scheme is a better path then.
> >> Different programs can then implement that scheme.  
> 
> > Can you give an example of what you mean.  
> 
> Writing the effects into a easily parseable (say JSON)
> configuration file in a XDG config path along with a
> signaling mechanism about the change would certainly help.

I don't think it's a good idea to have the display server
using files for this, but I would not object to a cg-file
and a cg-filed in cg-tools. An advantage with having this
as separate daemon is that it could be suspended while
editing the files if the daemon uses inotify.

I do not think using just the file system is enough because
it complicates support for running two display servers at
the same time.

I assume that you with “signaling mechanism” mean a way
to signal the daemon to reload the files.

> 
> > Do you mean
> > support for arbitrary colour mapping (a large lookup
> > table of all colours) and multiplication with
> > matrices?  
> 
> ICC abstract profiles can be much more expressive and can
> easily be integrated into other systems too. The gamma
> ramps can be computed from the profiles by a CMM like
> lcms. The advantage would be that it might easily
> integrate into the wayland way of color management, which
> so far offers no gamma access. At the same time can
> profiling tools temporarily disable the effects in order
> to measure device behaviour. Support for more use cases
> becomes possible.

I have not addressed temporarily disabling add effects,
but it's possible to do by sending a signal to coopgammad
to disconnect from the display, use libgamma to reset the
ramps, and when done, send a signal to coopgammad to
reconnect to the display.

When implementing this in Wayland, it have to be solved
by the compositor, or Wayland can choose to add a protocol
for it. In my display server, there isn't really a need
for this, because the profiler can read and block all
communication between the coopgamma server and the gamma
server, read the current ramps, reset the ramps, and
when done, restore the ramps, or the last change the
coopgamma server tried to send to the gamma server, and
then exit. (The display server doesn't really need that
many protocols when given a multi-server architecture.)

> 
> ICC color correction works with CLUT tables in display
> servers or color servers in some traditional GL enabled
> window managers. ICC abstract profiles can be easily
> chained during CLUT creation.
> 
> >> best regards
> >> Kai-Uwe
> >>
> >> PS: please feel invited to the [OpenICC list][1] round
> >> the corner. I really would like to see a convergence of
> >> desktop color configuration, as it makes much sense to
> >> users. Redshift and friends are certainly welcome.
> >>
> >> [1]:
> >> https://lists.freedesktop.org/mailman/listinfo/openicc  

-------------- 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/xdg/attachments/20161215/d2afad1c/attachment-0001.sig>