gnome-control-center: no devices supporting color management detected

526 views
Skip to first unread message

scruss

unread,
Mar 13, 2012, 10:04:41 PM3/13/12
to colorhug-users
I get this message on my rather elderly Thinkpad R51 and the livecd.
As gnome seems to be running in a fallback mode, I'm guessing I'm out
of luck running it on this computer?

thanks,
Stewart

--
73 de VA3PID

Richard Hughes

unread,
Mar 14, 2012, 4:23:02 AM3/14/12
to colorhu...@googlegroups.com
On 14 March 2012 02:04, scruss <scr...@gmail.com> wrote:
> I get this message on my rather elderly Thinkpad R51 and the livecd.
> As gnome seems to be running in a fallback mode, I'm guessing I'm out
> of luck running it on this computer?

No, not out of luck at all. First an easy to answer question; are you
running with the nvidia binary blob? If you're not, its probably
because you've got a messed up EDID and no DMI data, so we can just
create a dummy device with just enough metadata for the purposes of
calibration.

Richard

Tom Hughes

unread,
Mar 14, 2012, 4:36:19 AM3/14/12
to colorhu...@googlegroups.com
On 14/03/12 08:23, Richard Hughes wrote:

> No, not out of luck at all. First an easy to answer question; are you
> running with the nvidia binary blob? If you're not, its probably
> because you've got a messed up EDID and no DMI data, so we can just
> create a dummy device with just enough metadata for the purposes of
> calibration.

Interesting. My EeePC 900 also doesn't list it's display among the
colour managed devices and I just assumed that meant it didn't support
colour management but it sounds like I might have been wrong?

The graphics is the Intel 915GM chipset so nvidia issues obviously don't
come into it in my case.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

Richard Hughes

unread,
Mar 14, 2012, 4:57:06 AM3/14/12
to colorhu...@googlegroups.com
On 14 March 2012 08:36, Tom Hughes <t...@compton.nu> wrote:
> Interesting. My EeePC 900 also doesn't list it's display among the colour
> managed devices and I just assumed that meant it didn't support colour
> management but it sounds like I might have been wrong?

Yes :)

If you do from a terminal on the LiveCD:

killall gnome-settings-daemon
killall gnome-settings-daemon
(press alt-f4 to clear the fail-whale)
/usr/libexec/gnome-settings-daemon --debug

And then capture all the output. It's probably going to say something
about not finding the EDID or the EDID being corrupted. We probably
need to be a bit less strict on that if that's the case.

Richard.

Chris Lilley

unread,
Mar 14, 2012, 10:58:52 AM3/14/12
to scruss, colorhug-users
On Wednesday, March 14, 2012, 3:04:41 AM, scruss wrote:

s> I get this message on my rather elderly Thinkpad R51 and the livecd.

I get this message too, on OpenSUSE 12.1. Which was surprising, as

- the same hardware running the liveCD (Fedora) *does* detect the monitor
- using a KDE session rather than Gnome, the monitor is also detected.

As the monitor is the same in all cases the EDID is presumably OK, but maybe is not being read correctly?

--
Chris Lilley Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups

scruss

unread,
Mar 14, 2012, 7:50:17 PM3/14/12
to colorhug-users
On Mar 14, 4:23 am, Richard Hughes <hughsi...@gmail.com> wrote:
>
> No, not out of luck at all. First an easy to answer question; are you
> running with the nvidia binary blob?

No, I'm not.

thanks,
Stewart

Richard Hughes

unread,
Mar 15, 2012, 5:15:01 AM3/15/12
to colorhu...@googlegroups.com, scruss, Tom Hughes
On 14 March 2012 14:58, Chris Lilley <ch...@w3.org> wrote:
> I get this message too, on OpenSUSE 12.1. Which was surprising, as
> - the same hardware running the liveCD (Fedora) *does* detect the monitor
> - using a KDE session rather than Gnome, the monitor is also detected.
> As the monitor is the same in all cases the EDID is presumably OK, but maybe is not being read correctly?

This looks odd indeed. In g-s-d we just read the EDID from the "EDID"
or "EDID_DATA" properties on the correct output. It seems this isn't
being set properly for some people, or the check to see if the EDID is
a multiple of 128 bytes long is failing.

Could anyone affected by the missing device please try to compile the
attached program and reply with the results please. It should return
results like:

[LVDS1]
connected: 1
laptop: 1
primary: 1
id: 65
edid: 128 bytes [0:255:255:255]
[VGA1]
connected: 0
laptop: 0
primary: 0
id: 66

Thanks,

Richard.

test-gnomerr.c

Michal Čihař

unread,
Mar 15, 2012, 6:13:24 AM3/15/12
to colorhu...@googlegroups.com
Hi

Dne Thu, 15 Mar 2012 09:15:01 +0000
Richard Hughes <hugh...@gmail.com> napsal(a):

> Could anyone affected by the missing device please try to compile the
> attached program and reply with the results please. It should return
> results like:
>
> [LVDS1]
> connected: 1
> laptop: 1
> primary: 1
> id: 65
> edid: 128 bytes [0:255:255:255]
> [VGA1]
> connected: 0
> laptop: 0
> primary: 0
> id: 66

For me it is:

[VGA1]
connected: 0
laptop: 0
primary: 0

id: 65
[DVI1]
connected: 1


laptop: 0
primary: 0
id: 66

edid: 128 bytes [0:255:255:255]

Having no screens to calibrate in g-c-m (openSUSE 12.1).

--
Michal Čihař | http://cihar.com | http://blog.cihar.com

signature.asc

Richard Hughes

unread,
Mar 15, 2012, 6:16:25 AM3/15/12
to colorhu...@googlegroups.com
On 15 March 2012 10:13, Michal Čihař <mic...@cihar.com> wrote:
>        edid: 128 bytes [0:255:255:255]

Hmm, do you also get the "failed to get edid: unable to get EDID for
output" error from GSD too?

Richard.

Michal Čihař

unread,
Mar 15, 2012, 8:25:11 AM3/15/12
to colorhu...@googlegroups.com
Hi

Dne Thu, 15 Mar 2012 10:16:25 +0000
Richard Hughes <hugh...@gmail.com> napsal(a):

> On 15 March 2012 10:13, Michal Čihař <mic...@cihar.com> wrote:

No errors from GSD, but errors in kernel log:

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 152 Raw EDID:
00 ff ff ff ff ff ff 00 30 ae 51 11 01 01 01 01
14 12 01 03 80 2f 1e 78 ee e6 85 a8 50 35 ac 25
14 50 54 ad cf 00 81 80 95 00 95 0f b3 00 a9 40
01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
36 00 da 28 11 00 00 1a 00 00 ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

signature.asc

Tom Hughes

unread,
Mar 15, 2012, 8:38:31 AM3/15/12
to colorhu...@googlegroups.com
On 15/03/12 12:25, Michal Čihař wrote:

> No errors from GSD, but errors in kernel log:
>
> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 152 Raw EDID:
> 00 ff ff ff ff ff ff 00 30 ae 51 11 01 01 01 01
> 14 12 01 03 80 2f 1e 78 ee e6 85 a8 50 35 ac 25
> 14 50 54 ad cf 00 81 80 95 00 95 0f b3 00 a9 40
> 01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
> 36 00 da 28 11 00 00 1a 00 00 ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Interesting. In my case X seemed be accepting the EDID which it doesn't
normally do when the checksum is invalid (I used to have a monitor which
returned EDID like that...) but I'll check my kernel log when I next
have the laptop on and see if mine is doing the same.

What does your X log say about the EDID?

Richard Hughes

unread,
Mar 15, 2012, 10:58:19 AM3/15/12
to colorhu...@googlegroups.com
On 15 March 2012 12:38, Tom Hughes <t...@compton.nu> wrote:
> Interesting. In my case X seemed be accepting the EDID which it doesn't
> normally do when the checksum is invalid (I used to have a monitor which
> returned EDID like that...) but I'll check my kernel log when I next have
> the laptop on and see if mine is doing the same.

I've added this to g-s-d in git master:

commit 46e5d828e1e8252a147bd49a0164eace622d22e7
Author: Richard Hughes <ric...@hughsie.com>
Date: Thu Mar 15 10:32:29 2012 +0000

color: Create a color device even if the device has an invalid EDID

A lot of laptops have invalid EDIDs, but it doesn't matter as we prefer the
DMI data anyway.

:100644 100644 ad2b8c1... f424813... M plugins/color/gsd-color-manager.c

commit 090a145236e9c73af1f8c79dce75daebf3d63f9c
Author: Richard Hughes <ric...@hughsie.com>
Date: Thu Mar 15 10:31:40 2012 +0000

color: Apply the color profile even if the device has an invalid EDID

It appears quite a lot of real-world hardware returns bad EDID data.

:100644 100644 5377220... ad2b8c1... M plugins/color/gsd-color-manager.c

Richard.

Richard Hughes

unread,
Mar 15, 2012, 1:12:08 PM3/15/12
to colorhu...@googlegroups.com
On 15 March 2012 14:58, Richard Hughes <hugh...@gmail.com> wrote:
> On 15 March 2012 12:38, Tom Hughes <t...@compton.nu> wrote:
>> Interesting. In my case X seemed be accepting the EDID which it doesn't
>> normally do when the checksum is invalid (I used to have a monitor which
>> returned EDID like that...) but I'll check my kernel log when I next have
>> the laptop on and see if mine is doing the same.
>
> I've added this to g-s-d in git master:

I've also built this as a F16 package:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3898220

You can install this on the livecd and then just restart g-s-d. I'll
respin a new LiveCD next week with all the latest goodies included.

Richard.

Michal Čihař

unread,
Mar 20, 2012, 6:14:40 AM3/20/12
to colorhu...@googlegroups.com
Hi

Dne Thu, 15 Mar 2012 12:38:31 +0000
Tom Hughes <t...@compton.nu> napsal(a):

For example:

[ 30.699] (II) intel(0): EDID (in hex):
[ 30.699] (II) intel(0): 00ffffffffffff0030ae511101010101
[ 30.699] (II) intel(0): 14120103802f1e78eee685a85035ac25
[ 30.699] (II) intel(0): 145054adcf0081809500950fb300a940
[ 30.699] (II) intel(0): 010101010101283c80a070b023403020
[ 30.699] (II) intel(0): 3600da281100001a000000fd00324b1e
[ 30.699] (II) intel(0): 4b11000a202020202020000000fc004c
[ 30.699] (II) intel(0): 454e204c3232307877430a20000000ff
[ 30.699] (II) intel(0): 00564c2d35323235300a2020202000e7

So it looks like sometimes second half of EDID is corrupted.

signature.asc

Lorrin Nelson

unread,
Apr 21, 2012, 3:26:30 AM4/21/12
to colorhu...@googlegroups.com
I just installed Pascal's PPA on my Ubuntu Oneiric box. I seem to have the same symptoms described in this thread:
* System Settings -> Color only shows printers
* colormgr get-devices lists only printers
* killall gnome-settings-daemon and then restarting with gnome-settings-daemon --debug shows:
(gnome-settings-daemon:18646): color-plugin-WARNING **: failed to get edid: unable to get EDID for output

I don't see anything about bad EDIDs in kernel.log or Xorg.*.log though. Is this an expected symptom of using the nVidia binary drivers?

BTW, per earlier discussion, xcalib works fine to load ICCs generated using the Live-CD. And it looks like running dispcal manually works, though I haven't yet sorted out what a good set of parameters is.

Cheers
-Lorrin

Pascal de Bruijn

unread,
Apr 21, 2012, 8:59:02 AM4/21/12
to colorhu...@googlegroups.com
On Sat, Apr 21, 2012 at 9:26 AM, Lorrin Nelson <l...@lorrin.org> wrote:
> I just installed Pascal's PPA on my Ubuntu Oneiric box. I seem to have the
> same symptoms described in this thread:

The version in my Oneiric PPA is already a tad old, as new
dependencies prevent me from pushing newer versions. It should still
be better than the version that got shipped with Oneiric.

I'd highly recommend moving to Precise (among other things there are
some important bug fixes for GNOME Settings Daemon's color module
there too).

Regards,
Pascal de Bruijn

Richard Hughes

unread,
Apr 22, 2012, 12:10:27 PM4/22/12
to colorhu...@googlegroups.com
On 21 April 2012 13:59, Pascal de Bruijn <pmjde...@pcode.nl> wrote:
> I'd highly recommend moving to Precise (among other things there are
> some important bug fixes for GNOME Settings Daemon's color module
> there too).

Yes, I spent a lot of time fixing gsd to work with invalid EDIDs. I'll
make a new LiveCD at the end of the week that has all the latest
packages and fixes.

Richard
Reply all
Reply to author
Forward
0 new messages