RE: workaround for bogus EDID data

[Guo, Chaohong]

 

-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] 
Sent: Saturday, April 04, 2009 12:42 AM
To: Guo, Chaohong
Cc: dri-devel@lists.sourceforge.net
Subject: Re: workaround for bogus EDID data

On Fri, 3 Apr 2009 15:40:44 +0800
Guo, Chaohong chaohong@intel.com wrote:

 hi,
 
I notice that KMS uses EDID priori to VBT, and  some EDID data
 is not right on some laptops.   
 
 As Jesse added a workaround into intel_bios.c,   we should add
 the same workaround into drm_edid.c  as follows.   Probably,  we
 should merge the calculation made in drm_mode_detailed() and
 parse_panel_data(),  and have the two routines call a common 
 sub-routine ?

Really you've seen bad EDIDs too?  Last time I saw this issue it turned
out to be a parser bug that Linus fixed.


Linus fixed the Vsync issue, but mine is Hsync: hend = 1446,  and htotal = 1443,
You can check the attached EDID data in case that my understanding is not right.


thanks,
-minskey







Yes we should make a common routine, and just make the various
mode_fixup hooks call it.

-- 
Jesse Barnes, Intel Open Source Technology Center
000 00 ff ff ff ff ff ff 00 06 af ec 21 00 00 00 00
020 01 12 01 03 80 22 13 78 0a 57 55 9c 5a 54 9d 26
040 1a 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
060 01 01 01 01 01 01 12 1b 56 43 50 00 26 30 30 20
100 34 00 58 c1 10 00 00 18 00 00 00 0f 00 00 00 00
120 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41
140 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
160 00 42 31 35 36 58 57 30 32 20 56 31 20 0a 00 44
200




header : 00 ff ff ff ff ff ff 00 

Vendor: 
- vendorid:  06 af
- Product :  ec 21
- SerialNo:  00 00 00 00
- Week:  01
- Year   12

Verion: 01 
Revion: 03 
Input:  80 (digital output)
size :  22 13 (
Gamma param: 78


feauture:  0a 
  bit 7:5  for DPMS



Color:(10 bytes)
57 55 9c 5a 54 9d 26 1a 50 54 

Established Timings:
00 00 00 

standard timings:(16 bytes)
1.  01 01 
2.  01 01 
3.  01 01 
4.  01 01 
5.  01 01
6.  01 01
7.  01 01
8.  01 01 

Timings details :(18bytes) 
12 1b 56 43 50 00 26 30 30 20 34 00 58 c1 10 00 00 18 

00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20 

00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 

00 00 00 fe 00 42 31 35 36 58 57 30 32 20 56 31 20 0a


Ext flag:  00 

Checksum: 44

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

workaround for bogus EDID data

[Guo, Chaohong]

hi,

   I notice that KMS uses EDID priori to VBT, and  some EDID data
is not right on some laptops.   

As Jesse added a workaround into intel_bios.c,   we should add
the same workaround into drm_edid.c  as follows.   Probably,  we
should merge the calculation made in drm_mode_detailed() and
parse_panel_data(),  and have the two routines call a common 
sub-routine ?



--- a/drm_edid.c2009-04-03 15:26:30.0 +0800
+++ b/drm_edid.c2009-04-03 15:24:38.0 +0800
@@ -327,6 +327,12 @@
 pt-vsync_pulse_width_lo);
mode-vtotal = mode-vdisplay + ((pt-vblank_hi  8) | pt-vblank_lo);
 
+   /* Some VBTs have bogus h/vtotal values */
+if (mode-hsync_end  mode-htotal)
+mode-htotal = mode-hsync_end + 1;
+if (mode-vsync_end  mode-vtotal)
+mode-vtotal = mode-vsync_end + 1;
+
drm_mode_set_name(mode);
 
if (pt-interlaced)
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

kernel drm module has a little error in drm_edid.c

[Guo, Chaohong]

Hi,  


   The edid_vendor() routine  in drm_edid.c,  

edid_vendor[2] = (edid-mfg_id[2]  0x1f) +  '@';

Should be,

edid_vendor[2] = (edid-mfg_id[1]  0x1f) +  '@';


Since vendor ID has only two bytes only, I am somewhat surprised why gcc 
doesn't complain this ?



thanks,
-minskey
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel