This year I never got around to using my annual holiday. To use up some of the time that I cannot transfer over to next year I took the last 4 days off work to put up Christmas lights, buy a Christmas tree and create a new bit of shared infrastructure for calibrating displays.
I’ll describe how we calibrated displays in GNOME 3.4 and GNOME 3.6:
- User opens the color control panel and clicks on the device, then “Calibrate”
- We spawn the gcm-calibrate executable with the colord device-id as an argument
- The user goes through a GTK wizard, and we calibrate the display to a target whitepoint and then characterize the display.
To do the last bullet point involved spawning dispcal and dispwin in a VTE widget and screen-scraping the output from ArgyllCMS. This would break every release and was really fragile. Also, dispwin and dispcal would show it’s own GL window with the sample window, so we’d have bugs where the window was on the wrong output (as argyllcms sometimes didn’t match the xorg display numbering) and also where the sample window was covering up the instructions in the GtkWizard. And if either of the tools crashed or the sensor was removed before finishing, then undefined things happened, ranging from a crash to a disastrous hang where the user couldn’t even click the Quit button. And to top it all off, there was no sensible progress completion support, so the user basically didn’t know if the calibration was taking a long time, had crashed or was waiting for input in the (hidden) VTE widget.
Basically, it was a hack, and just not good enough.
KDE did something similar. So much so, it used the same gcm-calibrate binary. This meant you switched from the native KCM in KDE and were popped into a GtkWizard with the same separate GL window issues. This meant you had to install quite a few of the GNOME libraries just to be able to calibrate your display in KDE.
So, not good enough, squared.
So I did three things in the last week or so:
- Added a “spotread” sensor type in colord. This sandboxes the argyllcms spotread process and abstracts out any undesirable behavior. You can read more about it here.
- Added a CdSampleWidget object to libcolord-gtk for simplicity (e.g. cursor hidden at the right time)
- Created a colord-session D-Bus activated process (that only gets started when a display gets calibrated and quits as soon as the caller quits or calibration finishes). This does all the heavy lifting in the session.
The latter has signals like ::UpdateSample() to update the color sample on the screen and ::UpdateGamma() to update the 2D LUTs which allows a small D-Bus wrapper to show any kind of GUI it likes. This lets us implement the new GNOME design mockups designed by Allan which look a lot less scary than the old UI. We can also pass a device-id and sensor-id to the new Start() method which means the calibration window gets shown on the right screen 100% of the time, and also means we can support machines that have more than one sensor installed, for instance laptops with an inexpensive internal color sensor and an external expensive ColorMunki.
So, all we have to do to take advantage of this is write the 100 lines of GDBus code in gnome-control-center and the few lines of QtDBus code for the color KCM for KDE.
So where do we go from here? I’ve still got to polish up the colord-session code and do a first release. Then it needs to be added to jhbuild and Fedora 19. Then I need to patch gnome-control-center to use the new service for displays rather than calling out to the old gcm-calibrate helper. Daniel has to do the same for colord-kde.
Color calibration in GNOME 3.8 has just got sexy.