[colord] Using spotread in colord

[Richard Hughes]

Hey all. I've just merged this commit:

commit 178069e11b29c57f5d8cd104c250afea5256ca6d
Author: Richard Hughes <richard at hughsie.com>
Date:   Thu Nov 29 22:11:52 2012 +0000

    Use spotread when there is no native sensor driver

    The downside is this requires ArgyllCMS to be installed. The
upside is that we
    can support many more sensors than we have native drivers for
(huey & colorhug).

    The idea is that we launch spotread in the daemon first when the
use uses Lock()
    to get the device capabilities, and also to work out what color sensor to
    connect to. This instance gets killed as we don't yet know what display type
    we're going to be profiling.

    When the user first calls GetSample() we spawn spotread and get
the value from
    the sensor. Any subsequent calls to GetSample() re-use the same
instance, and
    the sub-process is kept alive until the user calls Unlock(). This ensures we
    only calibrate devices like the ColorMunki once per Lock()/Unlock() cycle.

    This has been tested on a ColorMunki and a DTP94, although we
probably need to
    detect more strings to make this work for all devices. If you have a problem
    with 'colormgr get-sensor-reading' reporting that spotread timed out then
    please send a verbose daemon log to the mailing list and I'll fix things.

    On another point, clients will now have to handle errors like
    org.freedesktop.ColorManager.Sensor.RequiredPositionCalibrate by
showing some
    kind of UI and then resubmitting the GetSample() request.

---

If you've got a colorimeter (not huey, colorhug, dtp94 or colormunki),
I'd appreciate it if you could give it a go with colord from git
master. Just do 'colormgr get-sensor-reading' and check it gives a
valid reading.

Thanks!

Richard