VESA, EDID & flat panels

VESA, EDID & flat panels

[Benjamin Herrenschmidt]

Hi !

Somebody around here has access to the VESA specs ? I'm trying to figure
out if the EDID block, at least on recent flat panels, tells us wether
the panel digital input is 6:6:6 or 8:8:8 ... If it's 6:6:6, we should
enable dithering in drivers like radeon and "nv", while if 8:8:8, we
should not. If not enabling it on a 6 bits panel, we end up with crappy
looking gradients, if enabling it on a 8 bits panel, we basically end up
sending a 6 bits signal to a 8 bits panel, thus reducing the quality.

Ben.

Re: VESA, EDID & flat panels

[Richard Smith]

> Somebody around here has access to the VESA specs ? I'm trying to figure
> out if the EDID block, at least on recent flat panels, tells us wether
> the panel digital input is 6:6:6 or 8:8:8 ... If it's 6:6:6, we should
> enable dithering in drivers like radeon and "nv", while if 8:8:8, we
> should not. If not enabling it on a 6 bits panel, we end up with crappy
> looking gradients, if enabling it on a 8 bits panel, we basically end up
> sending a 6 bits signal to a 8 bits panel, thus reducing the quality.

We have  a copy from a few years ago.  Its not too descriptive if
IIRC.  I'll try to look at it tomorrow.

--
Richard A. Smith


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [Linux-fbdev-devel] VESA, EDID & flat panels

[Benjamin Herrenschmidt]

On Mon, 2005-10-03 at 18:18 -0500, Richard Smith wrote:
> > Somebody around here has access to the VESA specs ? I'm trying to figure
> > out if the EDID block, at least on recent flat panels, tells us wether
> > the panel digital input is 6:6:6 or 8:8:8 ... If it's 6:6:6, we should
> > enable dithering in drivers like radeon and "nv", while if 8:8:8, we
> > should not. If not enabling it on a 6 bits panel, we end up with crappy
> > looking gradients, if enabling it on a 8 bits panel, we basically end up
> > sending a 6 bits signal to a 8 bits panel, thus reducing the quality.
> 
> We have  a copy from a few years ago.  Its not too descriptive if
> IIRC.  I'll try to look at it tomorrow.

I found a lot of stuff on VESA Public site in fact. Looks like we really
need to write some infrastructure to get to the EDID extensions :) They
contain all sort of useful infos, though unfortunately, all of the
panels I've come accross so far didn't seem to implement them =P

Ben.

Re: VESA, EDID & flat panels

[Antonino A. Daplas]

Benjamin Herrenschmidt wrote:
> On Mon, 2005-10-03 at 18:18 -0500, Richard Smith wrote:
>>> Somebody around here has access to the VESA specs ? I'm trying to figure
>>> out if the EDID block, at least on recent flat panels, tells us wether
>>> the panel digital input is 6:6:6 or 8:8:8 ... If it's 6:6:6, we should
>>> enable dithering in drivers like radeon and "nv", while if 8:8:8, we
>>> should not. If not enabling it on a 6 bits panel, we end up with crappy
>>> looking gradients, if enabling it on a 8 bits panel, we basically end up
>>> sending a 6 bits signal to a 8 bits panel, thus reducing the quality.
>> We have  a copy from a few years ago.  Its not too descriptive if
>> IIRC.  I'll try to look at it tomorrow.
> 
> I found a lot of stuff on VESA Public site in fact. Looks like we really
> need to write some infrastructure to get to the EDID extensions :) They
> contain all sort of useful infos, though unfortunately, all of the
> panels I've come accross so far didn't seem to implement them =P
> 

It think it's because the (basic) EDID is retrieved with (basic) DDC
(address 0x50).  If I'm not mistaken, E-EDID is retrieved with E-DDC
(address 0xa0). I don't exactly know the protocol (E-DDDC specs are not
freely available), but try probing your i2c busses with:

i2cdump 0,1,2,etc 0xa0 

and see if you get anything.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Benjamin Herrenschmidt]

> It think it's because the (basic) EDID is retrieved with (basic) DDC
> (address 0x50).  If I'm not mistaken, E-EDID is retrieved with E-DDC
> (address 0xa0). I don't exactly know the protocol (E-DDDC specs are not
> freely available), but try probing your i2c busses with:
> 
> i2cdump 0,1,2,etc 0xa0 
> 
> and see if you get anything.

Are you sure we aren't talking about the same address here ? Address
0xa0 _is_ 0x50 shifted one bit left ... (The low bit of an i2c address
is the RW bit). i2cdump takes shifted addresses, thus you can't pass it
anything above 0x7f, thus passing it 0x50 is what gives you address
0xa0 :)

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Antonino A. Daplas]

Benjamin Herrenschmidt wrote:
>> It think it's because the (basic) EDID is retrieved with (basic) DDC
>> (address 0x50).  If I'm not mistaken, E-EDID is retrieved with E-DDC
>> (address 0xa0). I don't exactly know the protocol (E-DDDC specs are not
>> freely available), but try probing your i2c busses with:
>>
>> i2cdump 0,1,2,etc 0xa0 
>>
>> and see if you get anything.
> 
> Are you sure we aren't talking about the same address here ? Address
> 0xa0 _is_ 0x50 shifted one bit left ... (The low bit of an i2c address
> is the RW bit). i2cdump takes shifted addresses, thus you can't pass it
> anything above 0x7f, thus passing it 0x50 is what gives you address
> 0xa0 :)
> 

Yeah, I just realized that :-)

Tony


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Antonino A. Daplas]

Benjamin Herrenschmidt wrote:
>> It think it's because the (basic) EDID is retrieved with (basic) DDC
>> (address 0x50).  If I'm not mistaken, E-EDID is retrieved with E-DDC
>> (address 0xa0). I don't exactly know the protocol (E-DDDC specs are not
>> freely available), but try probing your i2c busses with:
>>
>> i2cdump 0,1,2,etc 0xa0 
>>
>> and see if you get anything.
> 
> Are you sure we aren't talking about the same address here ? Address
> 0xa0 _is_ 0x50 shifted one bit left ... (The low bit of an i2c address
> is the RW bit). i2cdump takes shifted addresses, thus you can't pass it
> anything above 0x7f, thus passing it 0x50 is what gives you address
> 0xa0 :)
> 
> Ben.
> 
> 
> 

Here's a snippet from the HDMI specs. Not sure how helpful this is

"8.4.3 Segment pointer
 Enhanced DDC allows access of up to 32 Kbytes of data. This is accomplished
 using a combination of the 0xA0/0xA1 address pair and a segment pointer. For
 each value of the segment pointer, 256 bytes of data are available at the
 0xA0/0xA1 address pair. An unspecified segment pointer references the same
 data as when the segment pointer is zero. Each successive value of the
 segment pointer allows access to the next two blocks of E-EDID (128 bytes
 each). The value of the segment pointer register cannot be read since it is
 reset at the completion of each command."

Tony



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Benjamin Herrenschmidt]

> Here's a snippet from the HDMI specs. Not sure how helpful this is
> 
> "8.4.3 Segment pointer
>  Enhanced DDC allows access of up to 32 Kbytes of data. This is accomplished
>  using a combination of the 0xA0/0xA1 address pair and a segment pointer. For
>  each value of the segment pointer, 256 bytes of data are available at the
>  0xA0/0xA1 address pair. An unspecified segment pointer references the same
>  data as when the segment pointer is zero. Each successive value of the
>  segment pointer allows access to the next two blocks of E-EDID (128 bytes
>  each). The value of the segment pointer register cannot be read since it is
>  reset at the completion of each command."

Yes, I have that. The problem is that the "primary" (old style) EDID
block is supposed to contain in byte 0x7e, a value that indicates if
there are extended stuffs available... Actually, it should contain:

 0 - no extended infos
 1 - one more 128 bytes extension (basically to be read from the same
0xa0 address, as each i2c address can actually return up to 256 bytes of
data)
 3 - more extension blocks. The EEDID spec then talks about a "map" of
the segments but I'm not sure where that is to be found.

The problem is that so far, all EDID blocks I've seen have this bit
clear. Also, on the couple of machines i've tested, the additional 128
bytes at address 0xa0 aren't there neither.

So I wonder how widespread really is that EEDID stuff... I'm afraid the
reason a lot of monitors come with a windows install CD is that they do
_not_ provide those infos via EDID, but windows has a database with
per-monitor infos (as Apple actually has in OS X) and we should probably
do something similar. (but not in the kernel)

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Antonino A. Daplas]

Benjamin Herrenschmidt wrote:
>> Here's a snippet from the HDMI specs. Not sure how helpful this is
>>
>> "8.4.3 Segment pointer
>>  Enhanced DDC allows access of up to 32 Kbytes of data. This is accomplished
>>  using a combination of the 0xA0/0xA1 address pair and a segment pointer. For
>>  each value of the segment pointer, 256 bytes of data are available at the
>>  0xA0/0xA1 address pair. An unspecified segment pointer references the same
>>  data as when the segment pointer is zero. Each successive value of the
>>  segment pointer allows access to the next two blocks of E-EDID (128 bytes
>>  each). The value of the segment pointer register cannot be read since it is
>>  reset at the completion of each command."
> 
> Yes, I have that. The problem is that the "primary" (old style) EDID
> block is supposed to contain in byte 0x7e, a value that indicates if
> there are extended stuffs available... Actually, it should contain:
> 
>  0 - no extended infos
>  1 - one more 128 bytes extension (basically to be read from the same
> 0xa0 address, as each i2c address can actually return up to 256 bytes of
> data)
>  3 - more extension blocks. The EEDID spec then talks about a "map" of
> the segments but I'm not sure where that is to be found.

One of the specs describes this map, should not be too difficult to parse.

> 
> The problem is that so far, all EDID blocks I've seen have this bit
> clear. Also, on the couple of machines i've tested, the additional 128
> bytes at address 0xa0 aren't there neither.
> 

Me too.  I've never encountered a display with extended blocks. I had
plans to write a parser for these blocks, but their rarity makes it
not worth the effort.
 
> So I wonder how widespread really is that EEDID stuff... I'm afraid the
> reason a lot of monitors come with a windows install CD is that they do
> _not_ provide those infos via EDID, but windows has a database with
> per-monitor infos (as Apple actually has in OS X) and we should probably
> do something similar. (but not in the kernel)

Yes, I agree.

Tony





-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Richard Smith]

> So I wonder how widespread really is that EEDID stuff... I'm afraid the
> reason a lot of monitors come with a windows install CD is that they do
> _not_ provide those infos via EDID, but windows has a database with
> per-monitor infos (as Apple actually has in OS X) and we should probably
> do something similar. (but not in the kernel)

Our experience agrees with you that the EEDID stuff is not well used. 
We make some LCD driver products and I'm pretty sure we didn't include
the EEDID info.

I gave the specs a quick look and I don't see anything in (thats
obvious) there that would allow you to see if the panel is 666 or 888.
The specs are somewhat less than clear in several cases so I'll be
happy to review any sections closer if you think one might be a
possibility.

--
Richard A. Smith


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Benjamin Herrenschmidt]

On Tue, 2005-10-04 at 07:35 -0500, Richard Smith wrote:
> > So I wonder how widespread really is that EEDID stuff... I'm afraid the
> > reason a lot of monitors come with a windows install CD is that they do
> > _not_ provide those infos via EDID, but windows has a database with
> > per-monitor infos (as Apple actually has in OS X) and we should probably
> > do something similar. (but not in the kernel)
> 
> Our experience agrees with you that the EEDID stuff is not well used. 
> We make some LCD driver products and I'm pretty sure we didn't include
> the EEDID info.
> 
> I gave the specs a quick look and I don't see anything in (thats
> obvious) there that would allow you to see if the panel is 666 or 888.
> The specs are somewhat less than clear in several cases so I'll be
> happy to review any sections closer if you think one might be a
> possibility.

Look at the EDID EXTENSIONS spec. Extension 0x40 contains the panel
component bit definition iirc. I found so far only one monitor that
implemented that extended block (the Apple 23" Cinema HD display) but
the content seem to be junk =P

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Antonino A. Daplas]

Benjamin Herrenschmidt wrote:
> Hi !
> 
> Somebody around here has access to the VESA specs ? I'm trying to figure
> out if the EDID block, at least on recent flat panels, tells us wether
> the panel digital input is 6:6:6 or 8:8:8 ... If it's 6:6:6, we should
> enable dithering in drivers like radeon and "nv", while if 8:8:8, we
> should not. If not enabling it on a 6 bits panel, we end up with crappy
> looking gradients, if enabling it on a 8 bits panel, we basically end up
> sending a 6 bits signal to a 8 bits panel, thus reducing the quality.
> 

The main 128-byte block of EDID version 1.x does not carry information for
that.  However, EDID version 1.3 and later support extended 128-byte blocks,
and one of them, DI-EXT may carry the information you need. Specifically,
section 3.4.5 of this doc might help:

http://www.vesa.org/public/EDID%20EXTENSIONS/DIEXT.pdf

You will still need to know how to get these extended blocks from i2c.
I think vesa's site also has public docs on how to do that.

EDID version 2 (which is 256 bytes in size) may also have that information,
but I don't know if the specs are freely available.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: VESA, EDID & flat panels

[Egbert Eich]

Benjamin Herrenschmidt writes:
 > Hi !
 > 
 > Somebody around here has access to the VESA specs ? I'm trying to figure
 > out if the EDID block, at least on recent flat panels, tells us wether
 > the panel digital input is 6:6:6 or 8:8:8 ... If it's 6:6:6, we should
 > enable dithering in drivers like radeon and "nv", while if 8:8:8, we
 > should not. If not enabling it on a 6 bits panel, we end up with crappy
 > looking gradients, if enabling it on a 8 bits panel, we basically end up
 > sending a 6 bits signal to a 8 bits panel, thus reducing the quality.
 > 

This information is encoded in EDID Version 2 (not to be confused with
the revisions of version 1).
Currently we have no code in X to read out this information. 

Cheers,
	Egbert.




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl