monitors giving bad EDID info

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

hello,
i was curious about how common it is to have Monitors that return back
bad EDID information
also is it true that monitors with blue or black video connector cable
end point mean they support DDC/EDID?

regards
Taha

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"M Taha Masood" <m.tahamasood@gmail.com> wrote in message
news:a350f7d.0410041337.39d81f2a@posting.google.com...
> hello,
> i was curious about how common it is to have Monitors that return back
> bad EDID information
> also is it true that monitors with blue or black video connector cable
> end point mean they support DDC/EDID?
>
> regards
> Taha

The blue colored connector is supposed to indicate VESA compliance.
A black colored connector does NOT imply lack of compliance, nor does
a blue one guarantee compliance. There is presently no official compliance
policing method (nor is there likely to be one). So, the connector cover
color
it is not something you should count on. Also, over the years, the EDID
standard has been revised, so you really need to read the entire file
content,
including the revision level, and interpret it according to that revision.
It is not common for a monitor to return "bad" information, but it is
entirely
possible that the information returned may not accurately represent the full
capability of the monitor. You should depend on the monitor specification
more than the EDID content, especially in older units, to understand the
monitor's capabilities. The whole intention of EDID is to facilitate
Plug-n-Play
connectivity that will use as much of the monitors capabilities as possible.
But
not all graphics systems nor operating systems use the information
effectively,
especially when it comes to non-standard pixel formats and/or refresh rates.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

thanks,
however i was wondering if anyone has seen monitors returning 0x80 as
the first byte and all the rest 127 bytes as 0xff in the 128 bytes
EEDID data , when queried over DDC

regards
Taha

"Not Gimpy Anymore" <nospamREMOVplease@msn.net> wrote in message news:<hyk8d.487410$OB3.21514@bgtnsc05-news.ops.worldnet.att.net>...
> "M Taha Masood" <m.tahamasood@gmail.com> wrote in message
> news:a350f7d.0410041337.39d81f2a@posting.google.com...
> > hello,
> > i was curious about how common it is to have Monitors that return back
> > bad EDID information
> > also is it true that monitors with blue or black video connector cable
> > end point mean they support DDC/EDID?
> >
> > regards
> > Taha
>
> The blue colored connector is supposed to indicate VESA compliance.
> A black colored connector does NOT imply lack of compliance, nor does
> a blue one guarantee compliance. There is presently no official compliance
> policing method (nor is there likely to be one). So, the connector cover
> color
> it is not something you should count on. Also, over the years, the EDID
> standard has been revised, so you really need to read the entire file
> content,
> including the revision level, and interpret it according to that revision.
> It is not common for a monitor to return "bad" information, but it is
> entirely
> possible that the information returned may not accurately represent the full
> capability of the monitor. You should depend on the monitor specification
> more than the EDID content, especially in older units, to understand the
> monitor's capabilities. The whole intention of EDID is to facilitate
> Plug-n-Play
> connectivity that will use as much of the monitors capabilities as possible.
> But
> not all graphics systems nor operating systems use the information
> effectively,
> especially when it comes to non-standard pixel formats and/or refresh rates.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"M Taha Masood" <m.tahamasood@gmail.com> wrote in message
news:a350f7d.0410051240.2950ddf8@posting.google.com...
> thanks,
> however i was wondering if anyone has seen monitors returning 0x80 as
> the first byte and all the rest 127 bytes as 0xff in the 128 bytes
> EEDID data , when queried over DDC
>
> regards
> Taha
>
OK, now the question is more understandable. Can't say I have experienced
this
personally - but then it's been a while since I was actively reading and
approving
EDID content.

Anybody else out there reading EDIDs lately?

If you do see that, it could indicate a memory corruption problem - or it
could
just be that the factory never plugged in any data. Some designs may have
not
protected against possible "rewriting" of the data, but in that case you'll
more likely
see scrambled data, not a bunch of zeros. All zeros tends to indicate data
was
never written.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

thanks for the suggestions

"Not Gimpy Anymore" <nogimpREMOV@msn.com> wrote in message news:<hPJ8d.668734$Gx4.389287@bgtnsc04-news.ops.worldnet.att.net>...
> "M Taha Masood" <m.tahamasood@gmail.com> wrote in message
> news:a350f7d.0410051240.2950ddf8@posting.google.com...
> > thanks,
> > however i was wondering if anyone has seen monitors returning 0x80 as
> > the first byte and all the rest 127 bytes as 0xff in the 128 bytes
> > EEDID data , when queried over DDC
> >
> > regards
> > Taha
> >
> OK, now the question is more understandable. Can't say I have experienced
> this
> personally - but then it's been a while since I was actively reading and
> approving
> EDID content.
>
> Anybody else out there reading EDIDs lately?
>
> If you do see that, it could indicate a memory corruption problem - or it
> could
> just be that the factory never plugged in any data. Some designs may have
> not
> protected against possible "rewriting" of the data, but in that case you'll
> more likely
> see scrambled data, not a bunch of zeros. All zeros tends to indicate data
> was
> never written.