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
> 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/
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.
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
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.
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
Hmm, do you also get the "failed to get edid: unable to get EDID for
output" error from GSD too?
Richard.
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
> 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?
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.
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.
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.
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