Talk:Extended Display Identification Data
- 1 Conflict between merged articles
- 2 in milimetres, then multiply by 10 ?
- 3 Addition Extensions
- 4 matching format to example
- 5 1280x768? Is this a supported aspect ratio?
- 6 This isn't right...
- 7 Converting a full set of chromaticities (xy for RGB+W) to a full set of triplets (Yxy/XYZ)
- 8 GTF Toggle Value
- 9 Short Audio Descriptor Byte 3 (Bitrate)
- 10 EDID Duration
- 11 Why so specific about computer displays and graphics cards?
- 12 Encoding of "x resolution" in "Standard Timing Information" described incorrectly?
- 13 Inconsistency in Features bitmap of Detailed Timing Descriptor?
- 14 Year of manufacture off by 10 years?
- 15 Where credit is due?
- 16 manufacturer IDs or vendor IDs now assigned by UEFI Forum rather than Microsoft
- 17 Apparent edits without changing header
Conflict between merged articles
The following text appeared on EDID before I merged the two articles:
- The first version of EDID, 1.0, was produced in August 1994. Since then, versions 1.1, 1.2, 1.3 and 2.0 have appeared. An enhanced version EEDID (Extended Display Identification Data) appeared in July, 2001.
This does not agree with the article, which claims 3.0 appeared in 1997. AxelBoldt 10:48, 7 Jul 2004 (UTC)
in milimetres, then multiply by 10 ?
In item 21 where it says "Maximum Horizontal Image Size (in millimetre). Multiply by 10 for actual value." wouldn't it sound a little less silly to say "Maximum Horizontal Image Size (in centimetre)" ? The same goes for item 22.
- I was going to say the same thing. Change made. -Ahruman 09:06, 31 March 2006 (UTC)
Is there some way to include later extensions to the EDID Standard such as Reference for 1.2 and 1.3
Furthermore I'd suggest to give the hex form of the given example along with its translation for developers to check if there implementations do right.
matching format to example
Seems quite confusing to match the format to the example given. Is "10-11: Product ID Code (little endian)" the "Monitor ID EPID775"? And how do you jump from a 2-byte "08-09: Manufacturer ID" to "Monitor Manufacturer: Company Name Envision, Inc."?—Preceding unsigned comment added by 184.108.40.206 (talk • contribs)
- As explained here, Timing Descriptor 3 gives you 13 characters for manufacturer name. Not sure where the extra '.' came from at the end, that may have been the software... -- RevRagnarok Talk Contrib Reverts 14:00, 9 June 2006 (UTC)
1280x768? Is this a supported aspect ratio?
The article states, "Many Wide XGA panels do not advertise their native resolution, instead offering only a resolution of 1280×768." 1280x768 is a 5:3 aspect ratio. It appears from the EDID Data Format that the only supported aspect ratios are: 16:10, 4:3, 5:4, and 16:9. How do they "offer" 1280x768? PRBryson 15:45, 14 June 2007 (UTC)
This isn't right...
in "Limitations: "A major limitation of EDID is that it cannot express the native resolutions of the most common wide screen flat panel displays and liquid crystal display televisions. The number of horizontal pixels must be a multiple of 8. "
Not accurate at all. EDIDs go down to single pixels in their DTD fields.
"The number of vertical pixels is calculated from the horizontal resolution and the selected aspect ratio. To be fully expressible, the size of wide screen display must thus be a multiple of 16×9 pixels. For 1366×768 pixel Wide XGA panels the nearest resolution expressible in the EDID syntax is 1360×765 pixels. Specifying 1368 pixels as the screen width would yield an unnatural screen height of 769.5 pixels."
This is only true in the simple timing descriptor fields.
"Many Wide XGA panels do not advertise their native resolution, instead offering only a resolution of 1280×768. Some panels advertise a resolution only slightly smaller than the native, such as 1360×765. For these panels to be able to show a pixel perfect image, the EDID data must be ignored by the display driver. Special programs are available to override the EDID data; PowerStrip for Microsoft Windows and DisplayConfigX for Mac OS X"
No, they are overriding the graphics card driver limitations. The EDID data is often present in the aforementioned DTD field.
Converting a full set of chromaticities (xy for RGB+W) to a full set of triplets (Yxy/XYZ)
In EDID, the set of RGB-primaries along with white point is encoded with chromaticities only, i. e. 4 xy-pairs for red, green, blue and white. How can this chromaticity set be converted to XYZ- or Yxy-set?
GTF Toggle Value
Byte 64 :: Encoded value should either be 0x000A or 0x200. When reading byte 64, the value returned is 0xA00 (rather than 0x000A) - Is reading of byte 64 just a straightforward extraction of 2 bytes? —Preceding unsigned comment added by Stormshadow 79 (talk • contribs) 15:36, 24 September 2008 (UTC)
Short Audio Descriptor Byte 3 (Bitrate)
In the text it says: "For all other sound formats, bits 7..0 designate the maximium supported bitrate divided by 8kHz."
The PCB bits part is true, and the previous is true for normal compressed bitstreams, but not for High Bit-Rate Audio (HBRA) bitstreams like Dolby TrueHD (MLP) or DTS-HD, at least for those formats it is vendor specific. Can anyone elaborate more on this? —Preceding unsigned comment added by 220.127.116.11 (talk) 15:21, 4 January 2010 (UTC)
Why so specific about computer displays and graphics cards?
EDID is used by all digital displays which use HDMI/DVI connection (almost all TV sets today). This fact seems to be omitted. —Preceding unsigned comment added by 18.104.22.168 (talk) 01:50, 25 June 2010 (UTC)
Encoding of "x resolution" in "Standard Timing Information" described incorrectly?
In the figure "EDID structure, version 1.3", byte 0 of bytes 38-53 is described as "x resolution, less 31, divided by 8 (256-2288 pixels)". I believe this should say "x resolution, divided by 8, less 31...". The the former definition does not allow the value 2288 to be encoded: (255 * 8) + 31 = 2071, while the latter definition does: (255 + 31) * 8 = 2288. Also, using the latter definition causes my program that interprets EDID info from a real display to produce much more sensible values of x and y resolution. — Preceding unsigned comment added by DaveBeal (talk • contribs) 17:00, 3 January 2012 (UTC)
Inconsistency in Features bitmap of Detailed Timing Descriptor?
In the Features bitmap (byte 17) of the "EDID Detailed Timing Descriptor", bits 6-5 say "Stereo mode: 00=No stereo; other values depend on bit 0", but bit 0 says "2-way line-interleaved stereo, if bits 4–3 are not 00." Should the bit 0 description be "2-way line-interleaved stereo, if bits 6-5 are not 00."?
Year of manufacture off by 10 years?
I am using the ST EDID Editor v22.214.171.124 at work and I find a major discrepencay is how the year of manufacture is stored. Byte 17 --> Year of manufacture, less 1980. (1980–2235). If week=255, it is the model year instead. In my example this Byte contains 0x16 which the ST tool says indicates 2012, but if I follow this articles algorithm (0d1980 + 0x16 = 0d2002) I come up with the year 2002.
Thus I think the correct line would be: Year of manufacture, less 1990. (1990–2245). If week=255, it is the model year instead.
But who is right? This article or the ST EDID Editor's implementation?
- I just checked the EDID 1.3 standard, release A, revision 1, and on page 12 it says clearly that "Value stored = (Year of manufacture - 1990)". --DSGalaktos (talk) 13:30, 26 September 2012 (UTC)
Where credit is due?
According to Brian Markwalter, senior vice president, research and standards, CEA, -864F "includes a number of noteworthy enhancements, including support for several new Ultra HD and widescreen video formats and additional colorimetry schemes."
For heavens sake, wouldn't "According to the CEA" be enough for this referenced entry? Was edit made by Mr. Markwalter? — Preceding unsigned comment added by 126.96.36.199 (talk) 19:47, 17 October 2013 (UTC)
manufacturer IDs or vendor IDs now assigned by UEFI Forum rather than Microsoft
The article says that bytes 8-9 of EDID 1.3 data carry a three-letter manufacturer ID assigned by Microsoft. It appears that these IDs are nowadays assigned by UEFI Forum instead. I have not found a secondary source to prove this change; only the following:
- a monitor vendor asking for a PNP ID on a Microsoft forum: https://social.msdn.microsoft.com/Forums/en-US/4b0fc30e-1f26-4b47-b416-d194667ee7d1/how-to-obtain-a-pnp-vendor-id?forum=wdk
- the same vendor asking for a PNP ID on another Microsoft forum; someone from Microsoft referred them to the UEFI Forum: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/10d9ba88-cbbe-4e94-bb51-e3c5749b56d6/how-to-obtain-a-pnp-vendor-id?forum=HardwareBoards
- Microsoft documentation says PNP IDs are requested through UEFI.org: https://msdn.microsoft.com/en-us/library/windows/hardware/dn610887(v=vs.85).aspx
- UEFI Forum says ACPI uses PNP IDs that consist of a 3-letter vendor ID and a 16-bit product ID, and they can assign the vendor ID; they don't explicitly mention EDID though: http://www.uefi.org/PNP_ACPI_Registry
Apparent edits without changing header
In the "EDID 1.3 data format" section there are a couple of edits that change the structure to EDID v1.4 without changing the title and reference. Among others:
Byte 17: week=255 to indicate model year instead of production (this is not allowed in v1.3) Byte 24: Display type. The introduction of digital variant came about in v1.4 — Preceding unsigned comment added by 2001:420:44C1:2578:D485:3B8D:CE2F:73E7 (talk) 07:19, 6 September 2016 (UTC)