Introducing display calibration using colord-session

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.

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

11 thoughts on “Introducing display calibration using colord-session”

  1. So it’s going to work a bit like libwacom which provides images of devices to whoever reads device id?

    The new design is way better and really more in line with up to date GNOME. Great job!

  2. Awesome, I can use my ColorHug on my W520 then!

    One thing though: the calibration square needs to be moveable and I must be able to setup the machine to keep the screen on and not suspend for that to work ;-)

        1. Surely if we’re using the integrated sensor then we want to fill the whole screen with the color patch? Out of interest, can you grab me the output of “colormgr get-sensors” please. Thanks.

          1. $ colormgr get-sensors
            Object Path: /org/freedesktop/ColorManager/sensors/huey_00
            Type: huey
            State: idle
            Serial number: 1869573999
            Model: 5001
            Vendor: 0765
            Native: Yes
            Locked: Yes
            LCD: Yes
            CRT: Yes
            Printer: No
            Spot: No
            Projector: No
            Ambient: Yes

Comments are closed.