Bug 28843 - [EDID] failure to retrieve EDID when monitor is off
Summary: [EDID] failure to retrieve EDID when monitor is off
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Jesse Barnes
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2010-06-30 03:24 UTC by Akim
Modified: 2017-07-24 23:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg.log when monitor switched on (28.32 KB, text/plain)
2010-06-30 04:07 UTC, Akim
no flags Details
Xorg.log when monitor swiched off (23.12 KB, text/plain)
2010-06-30 04:10 UTC, Akim
no flags Details
drm framework for flexible edid fetch (12.56 KB, patch)
2010-07-20 14:22 UTC, Jesse Barnes
no flags Details | Splinter Review
add gmbus edid fetch (8.68 KB, patch)
2010-07-20 14:22 UTC, Jesse Barnes
no flags Details | Splinter Review

Description Akim 2010-06-30 03:24:48 UTC
If the monitor was switched off at boot time, the refresh rate is wrong (resolution is correct)

$ xrandr 
 
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 
   1360x768       59.8   
   1024x768       60.0*  
   800x600        60.3     56.2   
   848x480        60.0   
   640x480        59.9     59.9   

If the monitor was switched on at boot:

$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 310mm x 230mm
   1024x768       85.0*+   85.0     75.1     70.1     60.0  
   1280x1024      60.0  
   1152x864       75.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     72.8     75.0     66.7     60.0  
   720x400        87.8     70.1  

/etc/X11/xorg.conf not used.
Comment 1 Julien Cristau 2010-06-30 03:31:26 UTC
Please attach X logs for both cases.  Clear the NEEDINFO keyword when that's done.

Thanks.
Comment 2 Akim 2010-06-30 04:07:47 UTC
Created attachment 36631 [details]
Xorg.log when monitor switched on
Comment 3 Akim 2010-06-30 04:10:13 UTC
Created attachment 36632 [details]
Xorg.log when monitor swiched off
Comment 4 Akim 2010-06-30 04:11:48 UTC
(In reply to comment #1)
> Please attach X logs for both cases.  Clear the NEEDINFO keyword when that's
> done.
> 
> Thanks.

done

WBR
Comment 5 Julien Cristau 2010-06-30 04:20:32 UTC
Weird, the driver doesn't seem to get EDID from the monitor when it's off...  Reassigning to intel drm.
Comment 6 Jesse Barnes 2010-07-20 14:22:10 UTC
Created attachment 37251 [details] [review]
drm framework for flexible edid fetch

First patch
Comment 7 Jesse Barnes 2010-07-20 14:22:32 UTC
Created attachment 37252 [details] [review]
add gmbus edid fetch

Second patch
Comment 8 Jesse Barnes 2010-07-20 14:23:02 UTC
Can you try the two patches I just attached?  Apply them in order of first, second.  Hopefully the EDID that comes back will be correct in both cases.
Comment 9 Akim 2010-07-20 23:43:07 UTC
(In reply to comment #8)
> Can you try the two patches I just attached?  Apply them in order of first,
> second.  Hopefully the EDID that comes back will be correct in both cases.

Which kernel version shall I apply the patches to?
Comment 10 Akim 2010-07-20 23:46:53 UTC
(In reply to comment #8)
> Can you try the two patches I just attached?  Apply them in order of first,
> second.  Hopefully the EDID that comes back will be correct in both cases.

Which kernel version shall I apply the patches to?
Comment 11 Jesse Barnes 2010-07-21 08:21:29 UTC
On Tue, 20 Jul 2010 23:46:53 -0700 (PDT)
bugzilla-daemon@freedesktop.org wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=28843
> 
> --- Comment #10 from Akim <administrator@makc.san.ru> 2010-07-20 23:46:53 PDT ---
> (In reply to comment #8)
> > Can you try the two patches I just attached?  Apply them in order of first,
> > second.  Hopefully the EDID that comes back will be correct in both cases.
> 
> Which kernel version shall I apply the patches to?

I generated it against the drm-intel-next branch of Eric's git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git).

But it will probably apply to 2.6.35-rc5 as well.
Comment 12 Jesse Barnes 2010-09-10 12:58:40 UTC
Any news?
Comment 13 Akim 2010-09-17 13:33:12 UTC
(In reply to comment #12)
> Any news?

I'm sorry, I was busy and to be honest, I forgot :((.


News.

I tried to patch 2.6.32 kernel (from repo - Ubuntu Lucid), unsucsessfully.

Whith 2.6.35 i'll try soon. It is need to say, these mashines are in the office and I don't have much time to use them not for a work. I plan to finish at this weekend.

One more thing. Is it possible, that trouble is not in the driver, but monitors? I got a new monitor (LCD) and this bug is absent; the refresh rate is the same (60 and 75 Hz) when monitor switched off or swithed on at boot time. Other CRT monitor I dont have yet.

Sorry my language :)
Comment 14 Akim 2010-09-19 10:25:38 UTC
(In reply to comment #12)
> Any news?

Well, I'm finished. And patches are working! Congratulations!

Now, after booting it is possible set any refresh rate other than 60 Hz. But the refresh rate by default is still 60 Hz, and it is need to set another one every time you boot with the switched off monitor (not a driver problem?)
Comment 15 Chris Wilson 2010-09-20 00:27:15 UTC
Excellent news! I spent sometime this week rewriting those patches for -next (and will push them as soon as I am home and able to boot test them on a couple more machines). As soon as that branch is available, I'll ask you test drm-intel-next and then we can be confident that the issue will be fixed in 2.6.37.

The drm driver will choose a mode that is suitable for all outputs connected on boot, you can override this with the video= boot parameter (iirc).
Comment 16 Chris Wilson 2010-09-22 09:35:38 UTC
Marking fixed as the GMBus patches have landed in -next. (And hopefully I've ironed out all the regressions...)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.