mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

RPi ignoring EDID detailed timing

Mon May 14, 2012 4:27 pm

I have a Planar 720p projector connected via an HDMI->DVI cable with the below EDID (decoded). The Raspberry Pi is ignoring the preferred timing (the first detailed timing, 1280x720 ). It instead uses [email protected], the first standard mode, but doesn't display anything. The RPi doesn't seem to allow me to override this or specify 720p, as it is not listed in the Established or Standard timings. What should I do?

Code: Select all

Manufacturer: CLO Model 1c5c Serial Number 35
Made week 52 of 2006
EDID version: 1.3
Digital display
Image size is variable
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
Standard timings supported:
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
Detailed mode: Clock 74.250 MHz, 0 mm x 0 mm
               1280 1390 1430 1650 hborder 0
                720  725  730  740 vborder 0
               +hsync +vsync
Detailed mode: Clock 40.500 MHz, 0 mm x 0 mm
               1024 1036 1076 1296 hborder 0
                576  600  605  625 vborder 0
               +hsync +vsync
Monitor name: DLP HD2+
    Serial number: 0035
        Has 1 extension blocks
Checksum: 0x1e

`tvservice -m DMT` shows:

Code: Select all

                                                  
Group DMT has 14 modes:
           mode 4: 640x480 @ 60Hz, progressive
           mode 5: 640x480 @ 72Hz, progressive
           mode 6: 640x480 @ 75Hz, progressive
           mode 7: 640x480 @ 85Hz, progressive
           mode 8: 800x600 @ 56Hz, progressive
           mode 9: 800x600 @ 60Hz, progressive
           mode 10: 800x600 @ 72Hz, progressive
           mode 11: 800x600 @ 75Hz, progressive
           mode 12: 800x600 @ 85Hz, progressive
           mode 16: 1024x768 @ 60Hz, progressive
           mode 17: 1024x768 @ 70Hz, progressive
           mode 18: 1024x768 @ 75Hz, progressive
           mode 19: 1024x768 @ 85Hz, progressive
           mode 35: 1280x1024 @ 60Hz, progressive
`tvservice -s`:
state 0x120016, 1280x1024 @ 60Hz, progressive

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5414
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 4:46 pm

can you dump your edid for us?
/op/vc/bin/tvservice -d edid.dat
will dump it. You can also use our parser (edidparser) to see what is happening.
You can find the latest versions of these tools here:
https://github.com/raspberrypi/firmware ... opt/vc/bin

It may be worth updating your start.elf too. Hexxeh has a firmware updater that simplifies this procedure.

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 5:02 pm

The EDID block can be found here: http://dropzone.tamu.edu/~mabrowning/edid.dat

Also, though the RPi claims to be outputting [email protected], my display shows 1154x240 VFreq 60Hz HFreq 63kHz.

I have the latest start.elf from https://github.com/raspberrypi/firmware ... aster/boot. Is there somewhere else I should look?

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 5:25 pm

From edidparser, it appears that the RPi reads the detailed timing modes and then ignores them because it doesn't match exactly with a known CEA or DMT mode. That's quite unfortunate. Is this a limitation of the GPU hardware or the firmware, or neither? Is there any way I can force it to use a detailed timing mode instead of a standard mode?

Code: Select all

root ~ # ./edidparser edid.dat                                                                                                               
Parsing edid.dat...
HDMI:EDID version 1.3, 1 extensions, unknown aspect ratio
HDMI:EDID features - videodef 0x80 !standby !suspend !active off; colour encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred format is native; does not support GTF
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is DLP_HD2_
HDMI:EDID found monitor S/N descriptor tag 0xff
HDMI:EDID does not yet know monitor vertical range, setting to default 24 to 120Hz
HDMI:EDID found unknown detail timing format: 1280x720p hfp:110 hs:40 hbp:220 vfp:5 vs:5 vbp:10 pixel clock:74 MHz
HDMI:EDID found unknown detail timing format: 1024x576p hfp:12 hs:40 hbp:220 vfp:24 vs:5 vbp:20 pixel clock:40 MHz
HDMI:EDID established timing I/II bytes are BF EE 00
HDMI:EDID found DMT format: code 4, 640x480p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 5, 640x480p @ 72 Hz in established timing I/II
HDMI:EDID found DMT format: code 6, 640x480p @ 75 Hz in established timing I/II
HDMI:EDID found DMT format: code 8, 800x600p @ 56 Hz in established timing I/II
HDMI:EDID found DMT format: code 9, 800x600p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 10, 800x600p @ 72 Hz in established timing I/II
HDMI:EDID found DMT format: code 11, 800x600p @ 75 Hz in established timing I/II
HDMI:EDID found DMT format: code 16, 1024x768p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 17, 1024x768p @ 70 Hz in established timing I/II
HDMI:EDID found DMT format: code 18, 1024x768p @ 75 Hz in established timing I/II
HDMI:EDID standard timings block x 8: 0x3159 4559 6159 8180 61C0 0101 0101 0101 
HDMI:EDID found DMT format: code 7, 640x480p @ 85 Hz (4:3) in standard timing 0
HDMI:EDID found DMT format: code 12, 800x600p @ 85 Hz (4:3) in standard timing 1
HDMI:EDID found DMT format: code 19, 1024x768p @ 85 Hz (4:3) in standard timing 2
HDMI:EDID found DMT format: code 35, 1280x1024p @ 60 Hz (5:4) in standard timing 3
HDMI:EDID unknown standard timing 1024x576 @ 60 Hz aspect ratio (16:9)
HDMI:EDID skipping over unknown extension tag 0x12
HDMI:Warning EDID must support at least one of 1080i60|50 or 720p60|50
HDMI:EDID filtering formats with pixel clock > 162 MHz or h. blanking > 1023
HDMI:EDID no known preferred format has been set
HDMI:EDID DMT mode (5) 640x480p @ 72 Hz with pixel clock 31 MHz has a score of 22118
HDMI:EDID DMT mode (6) 640x480p @ 75 Hz with pixel clock 31 MHz has a score of 23040
HDMI:EDID best score mode is now DMT (7) 640x480 @ 85 MHz with pixel clock 36 Hz (score 126112)
HDMI:EDID DMT mode (8) 800x600p @ 56 Hz with pixel clock 36 MHz has a score of 26880
HDMI:EDID DMT mode (9) 800x600p @ 60 Hz with pixel clock 40 MHz has a score of 28800
HDMI:EDID DMT mode (10) 800x600p @ 72 Hz with pixel clock 50 MHz has a score of 34560
HDMI:EDID DMT mode (11) 800x600p @ 75 Hz with pixel clock 49 MHz has a score of 36000
HDMI:EDID best score mode is now DMT (12) 800x600 @ 85 MHz with pixel clock 56 Hz (score 140800)
HDMI:EDID DMT mode (16) 1024x768p @ 60 Hz with pixel clock 65 MHz has a score of 47185
HDMI:EDID DMT mode (17) 1024x768p @ 70 Hz with pixel clock 75 MHz has a score of 55050
HDMI:EDID DMT mode (18) 1024x768p @ 75 Hz with pixel clock 78 MHz has a score of 58982
HDMI:EDID best score mode is now DMT (19) 1024x768 @ 85 MHz with pixel clock 94 Hz (score 166846)
HDMI:EDID best score mode is now DMT (35) 1280x1024 @ 60 MHz with pixel clock 108 Hz (score 178643)
HDMI:EDID preferred mode is updated to DMT (35) 1280x1024p @ 60 Hz with pixel clock 108000000 Hz
HDMI:EDID has only DVI support and no audio support
edid_parser exited with code 0

rpi_newbie
Posts: 27
Joined: Tue Apr 17, 2012 10:57 am

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 7:38 pm

Hi,
The detail timing format of 720p does not agree with any defined CEA 720p formats (the blanking periods are not correct). When I match a format, I compare not just the resolution, but also the blanking periods and pixel clock (to distinguish between different variants of 720p). I have noticed a few monitors have incorrect detailed timing formats listed in the EDID, which is unfortunate. I might add a fuzzy format matching algorithm later. However, it is not clear what the source should do if it discovers a format with incorrect blanking periods specified. Should the source try to drive the incorrect format, or the format with the correct blanking?

1024 x 576 is not a pre-defined format. It might be derived from CVT. CVT is not currently supported.

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 7:57 pm

Is there any reason why you don't allow users to specify the full timing information, but limit them to predefined modes?

Or even, why disallow modes that don't appear in the EDID? I understand that you don't want to automatically choose a format which might not work in the default case and you want to play it safe, but I know with 100% certainty that my display will support standard 720p mode, so why prevent me from setting it? I've already taken on the risk of manually forcing a setting, though I realize that some displays can be damaged by incorrect display settings.

Thanks for looking into this.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25435
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 9:38 pm

I think you hit the nail on the head with the last sentence - unsupported modes are not allowed because you could hurt the monitor. Also, setting up timing information is, whilst not complicated, more involved than just resolution - as rpi_newbie said, all sorts of blanking to get right as well. And with the slight possibility of hurting the monitor if you make a mistake.
Remember the Raspi isn't doing anything wrong here, the monitor is.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Mon May 14, 2012 9:51 pm

I'd counter that the monitor isn't doing something wrong, just doing something the RPi isn't expecting or can handle. I'd also point out that the projector costs upwards of $1000, while the Pi costs $35. I'll let you guess which one people will abandon first...

I appreciate your concern for my and others' hardware, but a simple hdmi_send_possibly_damaging_timing=1 configuration option would solve both problems, IMHO, if it allowed me to force a mode which doesn't appear in EDID.

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Tue May 15, 2012 5:32 am

All: While I still think that this is a silly limitation, I have solved by problem by utilizing the onboard I2C port and a custom cable to rewrite my EDID to be CEA conformant.

It now works as expected. Thank God for vendors ignoring the EDID 1.3 EEPROM read-only specification ;)

rpi_newbie
Posts: 27
Joined: Tue Apr 17, 2012 10:57 am

Re: RPi ignoring EDID detailed timing

Wed May 16, 2012 7:35 am

Hi mabrowning,
Where do you get your EDID parser? Did you write it yourself? What platform does it run on?

rpi_newbie
Posts: 27
Joined: Tue Apr 17, 2012 10:57 am

Re: RPi ignoring EDID detailed timing

Wed May 16, 2012 7:37 am

mabrowning wrote:All: While I still think that this is a silly limitation, I have solved by problem by utilizing the onboard I2C port and a custom cable to rewrite my EDID to be CEA conformant.

It now works as expected. Thank God for vendors ignoring the EDID 1.3 EEPROM read-only specification ;)
I think EDID CTS needs some tightening. I have told many vendors off at tests for putting wrong EDIDs in their monitors. :)

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Wed May 16, 2012 7:46 am

There are at least 3 that I know of; I did not write any.

There is the broadcom one that only runs on the RPi here: https://github.com/raspberrypi/firmware ... opt/vc/bin

The freedesktop implementation available in the debian package 'edid-decode' (featured in my first post): http://cgit.freedesktop.org/xorg/app/edid-decode/

Finally, there is perl script as part of lm-sensors: http://www.lm-sensors.org/browser/i2c-t ... unk/eeprom

If you're asking about how I manufactured my correct EDID, I just used the EDID wikipedia page and manually corrected the bytes in the dump, using edid-decode to verify. I used i2cset to write the 2 bytes I needed to.

Is that what you were asking about?

User avatar
Burngate
Posts: 6225
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: RPi ignoring EDID detailed timing

Wed May 16, 2012 3:37 pm

mabrowning wrote:... though I realize that some displays can be damaged by incorrect display settings.
Can they? How?
In the days of CRTs, EHT was generated from the line oscillator, and too high line rate could generate excessive EHT. But few of those had HDMI. Also, generally the line osc. would unlock from the incoming signal before harm was done.
These days with LCDs (and even plasmas) so much goes on between the signal input and the electrons hitting the pixels I would be surprised if very much is dependant on the incoming line rate.

tm314159
Posts: 5
Joined: Sun Apr 29, 2018 7:37 am

Re: RPi ignoring EDID detailed timing

Mon May 07, 2018 8:30 am

This is an old thread, but I'm seeing this problem with one of my monitors as well.
It has a resolution of 1366x768 but the EDID pixel clock is 69.29 Mhz instead of 72 Mhz, so the Raspberry Pi refuses to use this mode.

jamesh wrote:

> I think you hit the nail on the head with the last sentence - unsupported modes are not allowed
> because you could hurt the monitor. Also, setting up timing information is, whilst not
> complicated, more involved than just resolution - as rpi_newbie said, all sorts of blanking to
> get right as well. And with the slight possibility of hurting the monitor if you make a mistake.

I propose a compromise. How about this:

If the value is within some percentage, let's say 5% of the official DMT/CEA values, the value is accepted.

So this allows slightly nonstandard monitors to work, but prevents the Raspberry Pi from destroying monitors that have corrupted EDIDs. Does this sound reasonable?

mabrowning
Posts: 18
Joined: Mon May 14, 2012 4:14 pm

Re: RPi ignoring EDID detailed timing

Mon May 07, 2018 2:16 pm

tm314159, a lot has changed in 6 years. The Raspberry PI foundation finally saw reason and allows you to hardcode an edid using HDMI_IGNORE_EDID and HDMI_EDID_FILE config.txt directives.

https://www.raspberrypi.org/documentati ... t/video.md

tm314159
Posts: 5
Joined: Sun Apr 29, 2018 7:37 am

Re: RPi ignoring EDID detailed timing

Tue May 08, 2018 7:00 am

mabrowning wrote:

> tm314159, a lot has changed in 6 years. The Raspberry PI foundation finally
> saw reason and allows you to hardcode an edid using HDMI_IGNORE_EDID
> and HDMI_EDID_FILE config.txt directives.
>
> https://www.raspberrypi.org/documentati ... t/video.md

This monitor (lapdock 500) works fine on both Ubuntu and Windows 10 without any software kludges. The Raspberry Pi rejecting the slightly different pixel clock is pedantry.

Can you point me to the location in the kernel source where the HDMI EDID configuration is handled so I can attempt to hack a fix?

tm314159
Posts: 5
Joined: Sun Apr 29, 2018 7:37 am

Re: RPi ignoring EDID detailed timing

Tue May 08, 2018 8:18 am

I think I've found the place in the kernel where the EDID info is validated.
This is in kernel/linux/drivers/gpu/drm/drm_edid.c:

static bool
mode_in_range(const struct drm_display_mode *mode, struct edid *edid,
struct detailed_timing *timing)
{
u32 max_clock;
u8 *t = (u8 *)timing;

if (!mode_in_hsync_range(mode, edid, t))
return false;

if (!mode_in_vsync_range(mode, edid, t))
return false;

if ((max_clock = range_pixel_clock(edid, t)))
if (mode->clock > max_clock)
return false;

/* 1.4 max horizontal check */
if (edid->revision >= 4 && t[10] == 0x04)
if (t[13] && mode->hdisplay > 8 * (t[13] + (256 * (t[12]&0x3))))
return false;

if (mode_is_rb(mode) && !drm_monitor_supports_rb(edid))
return false;

return true;
}

The relevant code is this section:

if ((max_clock = range_pixel_clock(edid, t)))
if (mode->clock > max_clock)
return false;

What this code does is it calculates the pixel clock from the EDID (range_pixel_clock(edid,t)) and compares it to the standard clock for the mode (mode->clock).

If the mode clock is greater than the EDID clock, then this returns false.
This looks wrong to me - here's a longer explanation.

To protect an HDMI monitor from being destroyed, the code should be protecting the monitor from too high of a pixel clock. But this code does exactly the reverse. It rejects the mode if the standard mode clock is GREATER than the specified EDID pixel clock, or stated otherwise, if the specified EDID pixel clock is LOWER than the standard mode clock.

So if I understand correctly, the code should read:

if ((max_clock = range_pixel_clock(edid, t)))
if (max_clock > mode->clock)
return false.

Can someone verify this?

Return to “Troubleshooting”