-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
This works only temporary on my X230 #4
Comments
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. |
Yeah, it is xflux. :D Thank you! Edit: Is there maybe something that does same thing as flux, but, also works nice with xcalib? |
Fix false: Warning - Unable to get display calibration It was mentioned in issue #4.
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.) |
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? |
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.
man xcalib # says: It could work like:
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.) |
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 :) |
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? |
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
xcalib side:
|
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. |
The bug appeared in preparation of the xcalib -i -a effect simulation inside oyranos-monitor. oyranos-cms/oyranos#34 OpenICC/xcalib#4
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 ;) |
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: 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. |
@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. |
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:
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.
The text was updated successfully, but these errors were encountered: