xiccd
xiccd copied to clipboard
agalakhov
Add persistent mode
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...
On Mon, 09 Dec 2013 13:24:28 -0800 haarp [email protected] 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
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?
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.
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
@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?
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.
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
On Tue, 10 Dec 2013 07:42:30 -0800 Richard Hughes [email protected] 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
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. :(
On Thu, 19 Dec 2013 09:51:01 -0800 haarp [email protected] 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
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.
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.
