This works only temporary on my X230

[nemanjan00]

Hello,

When I run this command xcalib -i -a screen gets inverted for second and then it gets fixed.

I have no idea how to debug this since I have no ideas how it works.

Any suggestions?

---

Edit:

This is output I get:

Warning - Unable to get display calibration

---

Edit 2:

I do not see anything under Xorg log related to this.

---

Edit 3:

Laptop: Thinkpad X230

Graphics: HD 4000

OS: Arch

WM: i3wm

Composer: Compton

---

Edit 4:

Just to note that I do not have any problems on T430 with same CPU and almost the same software setup.

[rthardy]

You have got some other software continuously (1/second) adjusting the gamma ramps. For me it would be KDE with Redshift, which I have to disable/stop before adjusting ramps with xcalib. Redshift is a command line program that can be used with a variety of WMs or none at all. There is also Gnome/Nightlight, various color managers, etc. I don't know Compton, but anyway, find out who is responsible and get them to stop.

xcalib is just a one-shot.

[nemanjan00]

Yeah, it is xflux. :D

Thank you!

Edit:

Is there maybe something that does same thing as flux, but, also works nice with xcalib?

[beku]

Handling of gamma is not managed inside X. Every client can mess with gamma without enough information. As these APIs are set in stone, there is no change to be expected.

However, it would be good that clients can register to take over handling of gamma. xcalib should be able to take ownership of gamma from redshift or other clients. (Keep this open as a feature request until a according API comes up and xcalib can support it.)

[nemanjan00]

I think another good solution would be to get the same functionality with xcalib as with redshift/xflux/anything else?

Can I use xcalib to set same filter as with redshift?

Maybe I can write wrapper around xcalib to handle when filter should be applied, so you guys do not have to support it inside xcalib?

Edit:

---

Or maybe I could just kill xflux when I enable invert and again, start it when I disable it...

What do you guys think is better solution?

I think there is a lot of people using xcalib to invert colors and also some kind of flux software...

Maybe it would be good to document this somehow?

[beku]

I think another good solution would be to get the same functionality with xcalib as with redshift/xflux/anything else?

That might be possible, but is as well some work. (I've wrote the oyranos-monitor-white-point cli for color adaption to night-and day light @ geographic location for use in a ICC compatible color server.
https://github.com/oyranos-cms/oyranos/blob/master/src/tools/oyranos-monitor-white-point.c )

Can I use xcalib to set same filter as with redshift?

man xcalib # says:
-red <gamma> <brightness-percent> <contrast-percent>
-green <gamma> <brightness-percent> <contrast-percent>
-blue <gamma> <brightness-percent> <contrast-percent>

It could work like:

• detect the monitor ICC profile
• extract the white point
• compute a ramp
  • from source white point
  • to target white point (selectable in Kelvin, as printed on light bulb packages)
  • keep the ICC profiles VCGT working, which better integrates with color management
  • add fancy effect, like invert ...

That could be implemented inside xcalib, an other tool or script on top of xcalib or inside oyranos-monitor-white-point. (Any of these tools would help as well color management in the case where no ICC color server can color convert on the GPU.)

[nemanjan00]

Ok, thank you for info!

I will try to figure out it myself, so I do not take much of your time. :)

I think you gave me enough pointers :)

[rthardy]

Would it be possible for color managers to simply declare any profiles in effect, e.g. by environment variable or by keeping a "current.icc" in some known location?

[beku]

Currently the Oyranos CMS just takes a bunch of options from ~/.config/color/settings/openicc.json and applies them. The display profile is located in the _ICC_DEVICE PROFILE(_XXX) or _ICC_PROFILE(_XXX) atoms. That is indeed not simple. Passing of that information to the outside is difficult, as some data my be only in memory. E.g. the monitor profile might be a in memory profile only.

The oyranos-monitor tool could be extended to obtain

• a option to dump a complete color transform sRGB->effects->white point->...->monitor to memory or file.
  • needs xcalib to handle the color conversion by lcms or other tools
• allow to specify monitor, bit depth and ramp size and get a RGB PPM to fill the ramp
  • xcalib needs extra code to handle that
• write a (fake?) profile with VCGT tag
  • xcalib reads VCGT already

xcalib side:

• allow to query the ramp parameters
  • bit depth
  • count (usually 256, but can be different)
  • max value
• eventually for the PPM case above: take a linear PPM and apply to gamma ramp
  • check width == count &&
  • height == 1
  • check bit depth == 256 || 65535

[rthardy]

I wasn't ready to think beyond the capabilities of xcalib, but I will spell them out as I see them, just to see if I am correct.

xcalib has two ways to put the ramps into a defined state; one is the '-clear' switch, and the other is to load a VCGT tag. Every other xcalib manipulation is relative to the current state of the ramps. I already use the clear switch, but that will undo and lose any pre-applied calibration. My only other thought was that if the current profile were available, it could be reloaded instead.

I hope that makes sense.

Well, a third way: If you can keep track of all the manipulations it does, you can calculate and apply an inverse. How many significant digits can it handle? Simple case: '-gc 1.43' will approximately undo '-gc 0.7'

A fourth: if xcalib could snapshot the current calibration, that snapshot could be reapplied.

[beku]

Indeed undoing a particular calibration state needs a notion of the stack. My take was to use one daemon at a time. It is then responsible to track that state.

(E.g. the oyranos-monitor-white-point daemon stores the stack and state information along others bits inside ~/.config/color/settings/openicc.json . XCalib could adopt a flat file storage. Perhaps others prefere SQL, DAV, DBus or whatever to their like ;)

[beku]

Oyranos git uses now a separate daemon to keep the calibration curves + white point adjustments and possibly a effect working. xcalib is only used as a tool to load the curves into the graphic cards 1D RGB gamma ramps. The feature on Oyranos is functional and can be followed here:
https://github.com/oyranos-cms/oyranos/projects/2

That feature I implemented in Oyranos, because there are ICC color transforms involved for the effects and white point adjustments. It works as well together with a color server in a compositor if needed.

[baongoc124]

@nemanjan00 I think in your case, you can use redshift instead of xflux. It has the option to preserve gamma so it works well with xcalib.