Add persistent mode

[haarp]

On my machine with nvidia graphics, the currently loaded profile gets reset at most opportunities, such as opening nvidia-settings, changing resolution, launching certain programs which muck with the gamma, etc. Afterwards, I am stuck with the default profile.

xiccd could use a mode which detects these changes and reloads the colord profile. Currently I'm using a cludge with a script that calls xcalib every 3 seconds...

[agalakhov]

On Mon, 09 Dec 2013 13:24:28 -0800
haarp notifications@github.com wrote:

On my machine with nvidia graphics, the currently loaded profile gets
reset at most opportunities, such as opening nvidia-settings,
changing resolution, launching certain programs which muck with the
gamma, etc. Afterwards, I am stuck with the default profile.

xiccd could use a mode which detects these changes and reloads the
colord profile. Currently I'm using a cludge with a script that calls
xcalib every 3 seconds...

Thank you for the report. Do you know how exactly these changes appear
as X events? I'll make small test patches for you tomorrow.

Regards,
Alex

[agalakhov]

Ok, could you please tell what are the programs that corrupt your gamma table? nvidia-settings is one, what are the others?

I'm searching for the best solution right now. While it is possible to restore gamma immediately after it's changed by a third party, this may interfere with Argyll's dispcal as dispcal does not interact with colord right now. It just changes the gamma table. Either you'll have to disable color correction by hand while using dispcal or I'll have to patch Argyll.

I have to make sure that restoring gamma automagically does not harm existing software as nobody else does so.

Regards,
Alex

P.S. Are you familiar with C? Could you add a couple of extra printf() to see what's going on?

[hughsie]

dispcal does not interact with colord

It does, it dlsyms colordcompat.so at runtime.

does not harm existing software

I think just fixing the nvidia driver (i.e. by filing a bug upstream) is the best thing to do. GCM used to reapply the gamma table at resume and stuff like that, but it was easier just to fix things in the kernel.

Richard.

[agalakhov]

does not harm existing software

I think just fixing the nvidia driver (i.e. by filing a bug upstream)
is the best thing to do. GCM used to reapply the gamma table at
resume and stuff like that, but it was easier just to fix things in
the kernel.

Richard.

I also think that restoring "corrupted" gamma is a good idea anyway.
We expect to have always the correct gamma setting. If the gamma is
changed by any (broken) third-party software directly without blocking
color management first, we have either to undo the change (effectively
blocking such a change) or to embed the change into a display profile.
The first solution seems to be the correct one. Sadly, X does not have
such thing as "gamma table ownership grabbing".

Regards,
Alex

[haarp]

@hughsie:
I agree that fixing nvidia's mess would be the preferable solution. But sadly, the reality of the situation is that this just isn't possible. The problem with nvidia-settings has been known for years:
http://www.nvnews.net/vbulletin/showthread.php?t=125017

Of course the actual problem is rooted more deeply, possibly within X. Even if nvidia fixed their settings program, other apps could still mess up the calibration. Among those are:

• Resolution changes (within some apps)
• Many games (Doom 3 comes to mind)
• Many Wine programs, even "innocent" ones such as CPU-Z
• etc.

@agalakhov:
If I ever find a small program that makes it easy to pinpoint, I'll let you know. As of right now, the simplest one I know is CPU-Z within Wine.

And indeed, forcibly restoring calibration would break applications that actually have a business changing the color profile, such as dispwin. It's probably not that easy to figure out what to do in such a situation...

Yes, I know C. What program would you like me to inspect?

[hughsie]

If you Inhibit() the colord device, when you Uninhibit() it the changes get put back to the correct levels. Patching wine and doom3 probably is the right thing to do, although I agree it would be an uphill struggle. Ideas welcome, although polling the display adaptor every few seconds is going to make people on laptops very unhappy.

[agalakhov]

Yes, I know C. What program would you like me to inspect?

There is a event processing loop in xiccd in file randr-conn-private.c
starting at line 296 (while (XPending (conn->dpy))). Could you please
try the following debug printout:

printf("event=%d\n", ev.xany.type - conn->event_base);
switch (ev.xany.type - conn->event_base) {
...
case RRNotify:
printf("sub=%d\n", ((const XRRNotifyEvent_)&ev)->subtype);
switch (((const XRRNotifyEvent_)&ev)->subtype) {

and then try to run nvidia-settings or other broken program? I'm trying
to determine if xiccd has enough information about changing the gamma.
These RandR events seem to depend on hardware :( Thank you in the
advance.

And indeed, forcibly restoring calibration would break applications
that actually have a business changing the color profile, such as dispwin.

I think only very few programs really deal with changing color profiles
and most of them are colord-aware. For the rest (if any) it's possible
just to call colormgr device-inhibit before starting such a beast
(probably from a script).

Regards,
Alex

[agalakhov]

On Tue, 10 Dec 2013 07:42:30 -0800
Richard Hughes notifications@github.com wrote:

Ideas welcome, although polling the display adaptor
every few seconds is going to make people on laptops very unhappy.

Most likely it could be done via RandR events without polling. It
should be enough to check the gamma after RandR change notifications.

Regards,
Alex

[haarp]

Good evening.
Sorry for the delay, I just got around to trying this.

@agalakhov
I do see events when monitors are attached or resolutions changed, but no events are triggered at all for changes to the color profile. :(

[agalakhov]

On Thu, 19 Dec 2013 09:51:01 -0800
haarp notifications@github.com wrote:

Good evening.
Sorry for the delay, I just got around to trying this.

@agalakhov
I do see events when monitors are attached or resolutions changed,
but no events are triggered at all for changes to the color
profile. :(

That's correct. Profile changes aren't X events. Gamma ramp changes by
their own do not generate events too. However it may be possible to
predict gamma changes based on other events. Video tweaking software
usually changes multiple settings at once. I'm looking for any reliable
way to detect if such software was ran.

Regards,
Alex

[haarp]

Then I am afraid that nvidia-settings doesn't offer much in that regard. While it CAN do things that trigger these events, they DON'T trigger just by starting the tool, which is what resets the profile in the first place.
Games also do not necessarily change the resolution anymore (while still messing with color profiles), and other applications don't either.

If you have other ideas for detection, I'm willing to try them. I hope there is a way, as polling would be rather annoying.

[agalakhov]

I just don't understand why the software may want to change the gamma
ramp without changing anything else (and without restoring the original
gamma ramp at exit). If a full-screen game changes the gamma, it's Ok
as long as it restores the original setting then. Everything else just
doesn't mess with the gamma ramp.

If the software is changing just about everything including the
resolution, then the event will be signalled.

[RustoMCSpit]

any update?