On Thu, 15 Dec 2016 20:26:30 +0100 Kai-Uwe <[email protected]> wrote: > Am 15.12.2016 um 18:06 schrieb Mattias Andrée: > > On Thu, 15 Dec 2016 17:51:48 +0100 > > Kai-Uwe <[email protected]> wrote: > > > >> Am 15.12.2016 um 16:15 schrieb Mattias Andrée: > >>> On Thu, 15 Dec 2016 13:18:17 +0100 > >>> Kai-Uwe <[email protected]> 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
pgpHA5QISIUMD.pgp
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
