Version: 3.5.7 (using KDE KDE 3.5.7) Installed from: Gentoo Packages Compiler: gcc 4.1.2 tock gentoo compiler OS: Linux When I open Control Ceneter -> Peripherals -> Display my video card gamma table is clobbered and there is no way to recover the gamma table in the Monitor Gamma tab because the reset button is gray. I also suspect that the software does not even know what the gamma tables looked like before it reset them to the default values and would not be able to restore the gamma table even if the "Reset" button is not gray. Possible solutions include: 1. Grabbing the existing video card gamma table when the display applet is opened and allowing the user to select "Reset" to restore the gamma table. This is just barely acceptable. 2. Have a setting somewhere that allows to users to tell the system that this machine is color managed. If the machine is color managed then either the Monitor Gamma tab is not enabled or is hidden and the display applet does not do anything to the gamma tables. There may be other approaches that will solve this problem but of the two I have listed I prefer #2. In other words any user who has bothered to purchase calibration equipment and gone to the effort to actually calibrate their displays likely wants this little applet to not do anything. Also please keep in mind that after this type of calibration is applied the video card gamma table are likely not normal gamma table shapes since these will also compensate for non-linearities in the display system. For example the bottom of the red curve could be displaced to correct for the dark end of the tone curve being too red or not red enough or there could be inflections in the middle of the curves for one or more color channels.
I see that this is still listed as unconfirmed. Is there anything I can do to help you confirm the existence of this bug? OK lets make this easy. First install xcalib. This is a gamma table loader (in case you didn't know this) and it comes with a number of test ICC profiles with various gamma tables embedded in them. Some of these test profiles will have a significant impact on how things are rendered (IE. everything will get much lighter or much darker). Use xcalib to load one of these making sure that it is one that causes a pronounced change in how things are rendered and then open Control Center -> Peripherals -> Display and you will see the display rendering change again. This is clearly a bug or design flaw that needs to be fixed. This applies to all 3.x versions of KDE. I don't know about 4.x.
I see that this is still listed as unconfirmed. Is there anything I can do to help you confirm the existence of this bug? OK just in case here is how this can be reproduced. First install xcalib see http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/ . This small program is a video card gamma table loader and it comes with a number of test ICC profiles with various gamma tables embedded in them (IE. they contain a Video Card Gamma Tag - VCGT - with the new LUT data). Some of these test profiles will have a significant impact on how things are rendered (IE. everything will get much brighter or much darker). Use xcalib to load one of these making sure that it is one that causes a pronounced change in how things are rendered and then open Control Center -> Peripherals -> Display and you will see the display rendering change again. Since there is no way to prevent this from happening this is clearly a bug or design flaw that needs to be fixed. Once a user has calibrated the display and loaded a custom video card gamma table the video card gamma tables belong to the color management system and should not be modified in any way by other software unless that software immediately restores the gamma tables to their prior state. This bug is in all 3.x versions of KDE. I don't know about 4.x.
I have not been able to test this in KDE4 because of bug #157549 https://bugs.kde.org/show_bug.cgi?id=157549 so I do not know if this bug has been fixed in KDE4 yet. But I suspect that it has not been. This comment is KDE4 specific. Last summer the OpenICC sponsored a Google Summer of Code project to create a KDE4 color management system settings applet. The result was named KolorManager and this is now in the playground section of KDE SVN. Amung other things this has support for setting up the display profiles for a system and it uses Oyranos and xcalib to set the video card gamma table(s) and the X11 _ICC_PROFILE atom(s) for the displays on a system. More OpenICC mentored work funded by GSoC on KolorManger (for printing) will be part of the 2009 program. Now that a proper system settings utility exists for color managing the displays there needs to be integration setup between kolormanager and the display applet to correctly handle the video card gamma tables. Specifically if kolormanager has configured a display with an ICC profile the display applet should disable all operations that affect the video card gamma table for that display and let control of this be handled by the color management system.
I just tested this in KDE4 since the display controls are not working in KDE 4.3. The behavior seems to be better as it does not clobber the gamma unless the gamma control is selected. However it still does not have any way to restore the gamma to what it was when the user opened the Gamma dialog and the dialog will clobber the gamma table with out even asking the user if this is OK. For example if I open the Gamma dialog it clobbers the existing gamma tables but does not enable the "Apply" button even though the video card gamma tables have been changed by the dialog. The correct behavior would be to first get the gamma tables from the video card and then check to see if this is different from what the Gamma widget will apply. If it is it should enable the "Apply" button and keep a copy of the gamma tables. If the user does not choose to "Apply" the new gamma setting the widget should restore the tables to what these when the user opened the dialog. Better yet would be if the Display dialog checked to see if the X11 _ICC_PROFILE atom has been set for each display and if it is set it should disable the Gamma button since this indicates that the display gamma has been calibrated and should not be changed by a non-ICC profile aware utility like the current Display -> Gamma dialog. Here is a small snippet of code for testing for the existence the _ICC_PROFILE atom: // Stuff needed to get the X11 _ICC_PROFILE atom #include <QtGui/QX11Info> #include <X11/Xlib.h> #include <limits.h> #include <X11/Xatom.h> bool atomExists(int screen) // pass in the desktop -> screenNumber() // for the screen of interest { Atom ICCatom = 0; Atom atomType = 0; int format; QString atomString; unsigned long atomSize = 0; unsigned long bytesAfter = 0; LPVOID profileAtomBuffer; QDesktopWidget* desktop = new QDesktopWidget(); if (desktop -> numScreens() == 1 || screen == 0) atomString = "_ICC_PROFILE"; else atomString = QString("_ICC_PROFILE_%1").arg(screen); ICCatom = XInternAtom( QX11Info::display (), atomString.toLatin1(), False ); return ( XGetWindowProperty ( QX11Info::display (), QX11Info::appRootWindow(-1), ICCatom, 0, INT_MAX, False, XA_CARDINAL, &atomType, &format, &atomSize, &bytesAfter, (unsigned char **) &profileAtomBuffer) == Success) }
> The behavior seems to be better as it does not clobber the gamma unless the gamma control is selected. This is actually a bug (see bug 218668). With the recent merge of color management into KWin, hopefully the gamma correction can be combined with color correction, and these issues could be solved better.
Calibration is a manipulation of device behaviour. Thus they affect the characterisation contained in ICC profiles. As soon as ICC profiles are loaded they bring their own calibration and load them using xcalib or similar tools. In my tests kcm_kgamma is restoring the internal stored gamma, which is clearly interfering with the ICC calibration. That is no good fit to ICC colour management.
*** Bug 339557 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!