ReadEDID

Thanks Doug. I think the missing modes here are all from the restrictions of the BeagleBoard’s graphics driver. The highest mode described is the one that gives you the blank screen – Jeffrey what is the limit for pixel_rate on a Beagle? Is that last mode outside the possible range for a Beagle?. Do you have another machine to test on to see if you get the full range (the Pi being ideal for testing but you should get all those modes on a Pandaboard)?

William

All the modes show up on the Iyonix.

Couple of odd things in that:

An EDID generated on the Iyonix has no Monitor title text so manually added it.

800×600 75Hz has a black vertical bar to the right of the screen. 60Hz is OK.

640 × 480 60 & 75Hz have a black bar to the left.

Both 800×600 and 640 × 480 display OK on the Beagleboard.

Gainward FX5200 graphics card installed.

I have a Pi , attached to a lapdock, and will try that on Sunday.

OK. something to consider.. I was sent some o/p this morning, and the data in the second block was corrupt. more reads came ok. mdf follows. note bad maths for bound on the 1920×1080 173MHz mode (this edid was not corrupted)

# Monitor description file for IPS 2701
# Created by ScrModes 0.43
# (EDID specified modes only, no calculated modes)

# Max Viewable H 60 cm 
# Max Viewable V 34 cm
# Line rate:     15 - 99kHz
# Frame rate:    23 - 76Hz
# Max Dot rate: 250MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use CVT timing rules
#
file_format:1
monitor_title:IPS 2701

# Mode:  640 x 480 @ 75Hz
# Bounds: H  37.50kHz, V 75.00, DClock 31.50MHz
startmode
 mode_name:640 x 480
 x_res:640
 y_res:480
 pixel_rate:31500
 h_timings:64,120,0,640,0,16
 v_timings:3,16,0,480,0,1
 sync_pol:3
EndMode

# Mode:  640 x 480 @ 60Hz
# Bounds: H  31.47kHz, V 59.94, DClock 25.17MHz
startmode
 mode_name:640 x 480
 x_res:640
 y_res:480
 pixel_rate:25175
 h_timings:96,40,8,640,8,8
 v_timings:2,25,8,480,8,2
 sync_pol:3
EndMode

# Mode:  720 x 480 @ 60Hz
# Bounds: H  31.47kHz, V 59.94, DClock 27.00MHz
startmode
 mode_name:720 x 480
 x_res:720
 y_res:480
 pixel_rate:27000
 h_timings:62,60,0,720,0,16
 v_timings:6,30,0,480,0,9
 sync_pol:3
EndMode

# Mode:  800 x 600 @ 75Hz
# Bounds: H  46.88kHz, V 75.00, DClock 49.50MHz
startmode
 mode_name:800 x 600
 x_res:800
 y_res:600
 pixel_rate:49500
 h_timings:80,160,0,800,0,16
 v_timings:3,21,0,600,0,1
 sync_pol:0
EndMode

# Mode:  800 x 600 @ 72Hz
# Bounds: H  48.08kHz, V 72.19, DClock 50.00MHz
startmode
 mode_name:800 x 600
 x_res:800
 y_res:600
 pixel_rate:50000
 h_timings:120,64,0,800,0,56
 v_timings:6,23,0,600,0,37
 sync_pol:0
EndMode

# Mode:  800 x 600 @ 60Hz
# Bounds: H  37.88kHz, V 60.31, DClock 40.00MHz
startmode
 mode_name:800 x 600
 x_res:800
 y_res:600
 pixel_rate:40000
 h_timings:128,88,0,800,0,40
 v_timings:4,23,0,600,0,1
 sync_pol:0
EndMode

# Mode:  1024 x 768 @ 75Hz
# Bounds: H  60.02kHz, V 75.03, DClock 78.75MHz
startmode
 mode_name:1024 x 768
 x_res:1024
 y_res:768
 pixel_rate:78750
 h_timings:96,176,0,1024,0,16
 v_timings:3,28,0,768,0,1
 sync_pol:0
EndMode

# Mode:  1024 x 768 @ 60Hz
# Bounds: H  48.36kHz, V 60.00, DClock 65.00MHz
startmode
 mode_name:1024 x 768
 x_res:1024
 y_res:768
 pixel_rate:65000
 h_timings:136,160,0,1024,0,24
 v_timings:6,29,0,768,0,3
 sync_pol:3
EndMode

# Mode:  1152 x 864 @ 75Hz
# Bounds: H  67.50kHz, V 75.00, DClock 108.00MHz
startmode
 mode_name:1152 x 864
 x_res:1152
 y_res:864
 pixel_rate:108000
 h_timings:128,256,0,1152,0,64
 v_timings:3,32,0,864,0,1
 sync_pol:0
EndMode

# Mode:  1280 x 720 @ 60Hz
# Bounds: H  44.77kHz, V 12502.88, DClock 74.50MHz
startmode
 mode_name:1280 x 720
 x_res:1280
 y_res:720
 pixel_rate:74500
 h_timings:128,192,0,1280,0,64
 v_timings:5,20,0,720,0,3
 sync_pol:0
EndMode

# Mode:  1280 x 720 @ 60Hz
# Bounds: H  45.00kHz, V 60.00, DClock 74.25MHz
startmode
 mode_name:1280 x 720
 x_res:1280
 y_res:720
 pixel_rate:74250
 h_timings:40,220,0,1280,0,110
 v_timings:5,20,0,720,0,5
 sync_pol:0
EndMode

# Mode:  1280 x 720 @ 50Hz
# Bounds: H  37.50kHz, V 50.00, DClock 74.25MHz
startmode
 mode_name:1280 x 720
 x_res:1280
 y_res:720
 pixel_rate:74250
 h_timings:40,220,0,1280,0,440
 v_timings:5,20,0,720,0,5
 sync_pol:0
EndMode

# Mode:  1280 x 1024 @ 75Hz
# Bounds: H  79.98kHz, V 75.02, DClock 135.00MHz
startmode
 mode_name:1280 x 1024
 x_res:1280
 y_res:1024
 pixel_rate:135000
 h_timings:144,248,0,1280,0,16
 v_timings:3,38,0,1024,0,1
 sync_pol:0
EndMode

# Mode:  1280 x 1024 @ 60Hz
# Bounds: H  63.98kHz, V 60.02, DClock 108.00MHz
startmode
 mode_name:1280 x 1024
 x_res:1280
 y_res:1024
 pixel_rate:108000
 h_timings:112,248,0,1280,0,48
 v_timings:3,38,0,1024,0,1
 sync_pol:0
EndMode

# Mode:  1440 x 900 @ 60Hz
# Bounds: H  55.93kHz, V 59.89, DClock 106.50MHz
startmode
 mode_name:1440 x 900
 x_res:1440
 y_res:900
 pixel_rate:106500
 h_timings:152,232,0,1440,0,80
 v_timings:6,25,0,900,0,3
 sync_pol:1
EndMode

# Mode:  1680 x 1050 @ 60Hz
# Bounds: H  65.29kHz, V 59.95, DClock 146.25MHz
startmode
 mode_name:1680 x 1050
 x_res:1680
 y_res:1050
 pixel_rate:146250
 h_timings:176,280,0,1680,0,104
 v_timings:6,30,0,1050,0,3
 sync_pol:1
EndMode

# Mode:  1920 x 1080 @ 60Hz
# Bounds: H  67.16kHz, V 4076.35, DClock 173.00MHz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:173000
 h_timings:200,328,0,1920,0,128
 v_timings:5,32,0,1080,0,3
 sync_pol:0
EndMode

# Mode:  1920 x 1080 @ 60Hz
# Bounds: H  67.50kHz, V 60.00, DClock 148.50MHz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:148500
 h_timings:44,148,0,1920,0,88
 v_timings:5,36,0,1080,0,4
 sync_pol:0
EndMode

# Mode:  1920 x 1080 @ 30Hz
# Bounds: H  33.75kHz, V 30.03, DClock 74.25MHz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:74250
 h_timings:44,148,0,1920,0,88
 v_timings:5,15,0,540,0,2
 sync_pol:0
 interlaced
EndMode

# Mode:  2560 x 1440 @ 60Hz
# Bounds: H  88.79kHz, V 59.95, DClock 241.50MHz
startmode
 mode_name:2560 x 1440
 x_res:2560
 y_res:1440
 pixel_rate:241500
 h_timings:32,80,0,2560,0,48
 v_timings:5,33,0,1440,0,3
 sync_pol:1
EndMode
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  10 ed 01 27  00 00 00 00
# 2f 17 01 04  80 3c 22 78  fe ee 95 a3  54 4c 99 26
# 0f 50 54 a5  cb 00 71 4f  81 c0 81 80  95 00 b3 00
# d1 c0 01 01  01 01 56 5e  00 a0 a0 a0  29 50 30 20
# 35 00 55 50  21 00 00 1a  00 00 00 ff  00 44 47 4d
# 31 32 33 31  30 30 30 31  0a 20 00 00  00 fd 00 17
# 4c 0f 63 19  00 0a 20 20  20 20 20 20  00 00 00 fc
# 00 49 50 53  20 32 37 30  31 0a 20 20  20 20 01 ae
# 02 03 1f f1  4c 01 02 03  04 05 07 90  12 13 14 16
# 1f 23 09 07  07 83 01 00  00 65 03 0c  00 10 00 02
# 3a 80 18 71  38 2d 40 58  2c 45 00 fe  1f 11 00 00
# 1e 01 1d 80  18 71 1c 16  20 58 2c 25  00 fe 1f 11
# 00 00 9e 01  1d 00 72 51  d0 1e 20 6e  28 55 00 fe
# 1f 11 00 00  1e 8c 0a d0  8a 20 e0 2d  10 10 3e 96
# 00 fe 1f 11  00 00 18 01  1d 00 bc 52  d0 1e 20 b8
# 28 55 40 e8  12 11 00 00  1e 00 00 00  00 00 00 07
#
#End

I think the missing modes here are all from the restrictions of the BeagleBoard’s graphics driver.

Correct. Beagle pixel rate limit is 100MHz, and of course there’s no support for interlaced modes due to it being DVI output and not true HDMI.

I’m not sure why 1152 × 864 @ 60Hz wouldn’t producing a picture. The numbers look fine, apart from that odd issue with the vertical rate being incorrect in the comment. Unfortunately my BB-xM is busy at the moment (annoying soak test bug), and I can’t test that mode on my BB due to older OMAP chips having tighter restrictions on the porch/sync values. The mode works fine on my Pandaboard, but that doesn’t really say much since there are a few differences in how the video clocks are generated between OMAP3 & OMAP4.

I’ll try and track down where those dodgy values are coming from in the bounds comments.

OK. something to consider.. I was sent some o/p this morning, and the data in the second block was corrupt. more reads came ok.

Which version of ScreenModes was the corrupt output from? 0.43 is the first version where reading extension blocks actually works.

Dodgy vertical bounds values should now be fixed; if the code was generating modes using GTF/CVT then there were a couple of mode variables which weren’t being initialised (would have affected the MDF comment and the way the modes are sorted into a list)

Regarding the bug I mentioned with the framerate sometimes being off by one when loading an EDID-derived MDF: it looks like this is down to differences in how framerates are being rounded to the nearest Hz. ScreenModes generally rounds to nearest, except for when it uses mode timings from the DMT spec, in which case it uses the integral Hz value defined in the spec. So for 640×480×72Hz, the DMT doc says it’s 72Hz, but the actual value is 72.809Hz, so when an MDF containing that mode gets loaded back in it will result in the displayed value being rounded up to 73Hz.

I’m not sure what the best option is there. One would be to ignore the Hz values specified in the DMT doc and always calculate the value ourselves. The other would be to change ScreenModes to round down instead of rounding to nearest. But then we’d (theoretically) end up with 50% of modes being reported as off by one compared to what they were before!

Doug:

William

All the modes show up on the Iyonix.

Couple of odd things in that:

An EDID generated on the Iyonix has no Monitor title text so manually added it.

800×600 75Hz has a black vertical bar to the right of the screen. 60Hz is OK.

640 × 480 60 & 75Hz have a black bar to the left.

Both 800×600 and 640 × 480 display OK on the Beagleboard.

It’s not too surprising that there’ll be borders on some of the modes when using VGA. For VGA there’s no data enable signal, so the monitor has to guess for itself where the picture is. There are also only a few parameters which the monitor can use to identify modes (pixel rate, vsync period, and hsync period). In theory, if you take a monitor which is fresh out of the factory and use it with modes derived from EDID, the picture will be in the exact place the monitor expects it to be. But if you’ve been using this monitor with your Iyonix before, and the MDF wasn’t generated from EDID, then chances are that you (or your Acorn dealer!) has adjusted the picture settings of your monitor so that the modes will display correctly with the MDF you’ve been using. If any of those modes have the same basic parameters (pixel rate, vsync period, and hsync period) as the EDID modes then the monitor won’t be able to tell the difference between them and so will end up using your hand-tweaked picture settings instead of the factory preset ones. Just hit the ‘auto adjust’ button and it should sort itself out (although you might want to place a window over the bottom of the iconbar, to avoid the black border at the bottom confusing the monitor and causing it to chop it off)

For DVI & HDMI this is generally a non-issue since there’s an explicit data enable signal, and so the monitor always knows where the bounds of the image are.

Jeffrey

Thought as much but thought I would mention it just in case and thanks for the full explantion.

Will let you know how it works on the Pi and Lapdock

Doug

William/Jeffr

I tried have ReadEDID with the Pi/Lapdock combination and it produces a MDF but no resolution or frame rates are shown.

The MDF is as per below:

# Monitor description file for MotoAttach
# Created by ScrModes 0.44
# (EDID specified modes only, no calculated modes)

# Max Viewable H 26 cm 
# Max Viewable V 14 cm
# Line rate:     30 - 85kHz
# Frame rate:    50 - 75Hz
# Max Dot rate: 150MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:MotoAttach

# Mode:  1366 x 768 @ 63Hz
# Bounds: H  50.33kHz, V 62.92, DClock 75.50MHz
startmode
 mode_name:1366 x 768
 x_res:1366
 y_res:768
 pixel_rate:75500
 h_timings:56,64,0,1366,0,14
 v_timings:3,28,0,768,0,1
 sync_pol:0
EndMode

# Mode:  1366 x 768 @ 60Hz
# Bounds: H  48.00kHz, V 60.00, DClock 72.00MHz
startmode
 mode_name:1366 x 768
 x_res:1366
 y_res:768
 pixel_rate:72000
 h_timings:56,64,0,1366,0,14
 v_timings:3,28,0,768,0,1
 sync_pol:0
EndMode

# Mode:  1366 x 768 @ 60Hz
# Bounds: H  48.00kHz, V 60.00, DClock 72.00MHz
startmode
 mode_name:1366 x 768
 x_res:1366
 y_res:768
 pixel_rate:72000
 h_timings:56,64,0,1366,0,14
 v_timings:3,28,0,768,0,1
 sync_pol:0
EndMode
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  35 f4 c4 3d  01 00 00 00
# 20 14 01 03  80 1a 0e 78  0a fe 75 92  5b 56 91 27
# 1f 50 54 00  00 00 01 01  01 01 01 01  01 01 01 01
# 01 01 01 01  01 01 20 1c  56 86 50 00  20 30 0e 38
# 13 00 00 90  10 00 00 1e  00 00 00 ff  00 30 30 30
# 30 30 31 0a  0a 0a 0a 0a  0a 0a 00 00  00 fd 00 32
# 4b 1e 55 0f  00 0a 20 20  20 20 20 20  00 00 00 fc
# 00 4d 6f 74  6f 41 74 74  61 63 68 0a  20 20 01 02
# 02 03 16 71  43 01 03 12  23 09 d7 07  83 01 00 00
# 65 03 0c 00  10 00 20 1c  56 86 50 00  20 30 0e 38
# 13 00 00 90  10 00 00 1e  7e 1d 56 86  50 00 20 30
# 0e 38 13 00  00 90 10 00  00 1e 00 00  00 10 00 1c
# 16 20 58 2c  25 00 d7 40  32 00 00 9e  00 00 00 00
# 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
# 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
# 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 1a
#
#End

I suspect it is because of the 1366 in the screen resolution.

Yeah, on the Pi we only allow modes where the width is a multiple of 32 bytes. The hardware can support other modes, but it adds padding between each row to give them 32 byte alignment – something that RISC OS currently isn’t able to deal with (but should hopefully get fixed in the future)

Yeah, on the Pi we only allow modes where the width is a multiple of 32 bytes.

Do you mean generally? Because I am using 1360 × 768 @ 60Hz ATM and can see no problems, and 1360 is 42.5 times 32 bytes, ie a 16 byte multiple. Or have I seriously misunderstood what you’re talking about?

You’re confusing pixels with bytes :-)

1360 is a multiple of 16. So you’ll be able to use it in 16bpp & 32bpp modes but not 8bpp.

You’re confusing pixels with bytes :-)

Thank you for your forebearance!

Just had some tricky monitor troubleshooting with a customer running on a Panasonic television. I sent him the latest EDID ROM to test with, but unfortunately he got the “EDID Channel Communication Error”. We tried with a couple of different cables, but to no avail.

Since my main TV is a Panasonic plasma (I think his was a 32" LCD), I did some experimenting here. Although ReadEDID was happy reading from my AV receiver, it was not happy when connected directly to the Pana. Again, “EDID Channel Communication Error”.

Other devices in the hifi chain have generally been OK reading from the Pana, so I suspect something isn’t quite right at the RISC OS end yet. Suggestions welcomed.

Can it be the lead? Is it a HDMI to HDMI lead or a DVI to HDMI lead? I also get ‘EDID channel communications error’ with my Asus P248 screen and the 11 Feb ROM, connected via a HDMI to DVI lead.

With DVI→HDMI leads, it is possible that not every pin is wired up. However with HDMI cables, it should be OK. In this case, we’ve tried several cables.

I’m still getting the EDID communication failure with the 17th Feb ROM.

Message token SSMDCMF not found.

*help ScreenModes
==> Help on keyword ScreenModes
Module is: Screen Modes    0.46 (16 Feb 2015)

Commands provided:
LoadModeFile    ReadEDID        CreateModeFile
*
*Help CreateModeFile
==> Help on keyword CreateModeFile
*CreateModeFile [path] reads screen mode definitions from the monitor and 
saves them to [path].<monitorname>.
Message token SSMDCMF not found
*

It’s possible the EDID read problems are a bug in RISC OS. If the EDID is longer longer than 256 bytes then it requires a different method to fully read it. The code for doing that exists, but I don’t think anyone’s been able to confirm that it works (lack of monitors to test with).

Try the following bit of BASIC, which should read the blocks one at a time and give a better indication of where any problems may be (Note: untested!):

ON ERROR PRINT REPORT$;" at ";ERL : END
DIM b% 128
block%=0
REPEAT
SYS "OS_CallAVector",(block%*128)+&a10000,b%,128,,14,,,,,42 TO iiccode%,,remain%,,gvcode%
IF gvcode%<>0 THEN PRINT "GraphicsV call failed" : END
IF iiccode%<>0 THEN PRINT "IIC error ";iiccode% : END
IF remain%<>0 THEN PRINT "Failed to read all data" : END
OSCLI("*memory b "+STR$~b%+" + 80")
IF block%=0 THEN count%=b%?126
block%=block%+1
UNTIL block%>count%

Also note that the Pi shouldn’t be affected by this bug, since we get the data second-hand from the GPU. On all the other platforms we drive the IIC bus directly, so any problems there are ours!

Andrew: that EDID will probably turn out to be a good test candidate – both for Jeffrey’s EDID load code and for the EDID interpretation in ScreenModes. There are a few things now that are in for hypothetical displays from the spec but have not been tested on a real device.

If you convert the end of that code to save out the resulting data block that would be useful: you can then also load the block into your machine for testing.

Using the test code (with ; vice +) with ScreenModes 0.43 in ROM, I get IIC error 3

I haven’t had a chance to try Jeffrey’s code (down with a cold) yet, but when I tried Pandaboard on the TV this morning, it hard-locked when ReadEDID was issued. If that was happening at startup…. gulp.

OK, now tried the code, and get IIC error 2, once STR$ added:

IF iiccode%<>0 THEN PRINT "IIC error "+STR$iiccode% : END

(only mentioning this bit in case someone else tries to run that test code in future).

On the Panda with the OS8beta 14 Feb ROM (which has Screen Modes 0.38 in rom) and Screen Modes 0.43 softloaded, I get ‘message token E27 not found’ from *READEDID and IIC error 3 from the test code.

Using the test code with ScreenModes 0.43 in ROM, I get IIC error 3

The IIC error codes are here

An error of ‘busy’ is somewhat unusual. Either something has gone wrong and the IIC driver hasn’t recovered properly from an error, or maybe the IIC lines in the cable are bad and are causing it to look like the bus is busy.

It might also be worth checking different machines if you have them (BB, PB, IMX6, Iyonix) – just in case there are some subtle differences in how the EDID reads have been implemented. E.g. on the BB and Iyonix we’re only clocking the IIC bus at 100kHz, but on the PB it’s running at 400kHz, which may cause issues for EDID due to the long bus length.

Also note that ScreenModes version shouldn’t matter as this code just calls GraphicsV directly. Any ROM from the past few months should do; it was last July when the support for long EDID blocks was added to everything.

[edit]

(with ; vice +)

Ah, yes. Too much Python recently, not enough BASIC ;-) Should be fixed now I think.

On the Iyonix it works OK (softloading RISC OS 5.20 (10-Jun-2013) – I usually use RISC OS 5.16 (18-Jan-2010)) – with the following result and no errors:

>RUN
Address  :  C  D  E  F  0  1  2  3  4  5  6  7  8  9  A  B :    ASCII Data
000090BC : 00 FF FF FF FF FF FF 00 04 69 B1 22 96 AA 00 00 : .ÿÿÿÿÿÿ..i±"–ª..
000090CC : 18 11 01 03 0E 2F 1E 78 2A C7 20 A4 55 49 99 27 : ...../.x*Ç ¤UI™'
000090DC : 13 50 54 BF EF 80 71 4F 81 80 81 40 81 4F 81 CF : .PT¿ï€qO€@OÏ
000090EC : 95 00 90 40 B3 00 21 39 90 30 62 1A 27 40 18 B0 : •.@³.!90b.'@.°
000090FC : 36 40 D9 28 11 00 00 1C 00 00 00 FD 00 38 4C 2F : 6@Ù(.......ý.8L/
0000910C : 54 0F 00 0A 20 20 20 20 20 20 00 00 00 FF 00 37 : T...      ...ÿ.7
0000911C : 36 4C 38 30 34 33 36 37 30 0A 20 20 00 00 00 FC : 6L8043670.  ...ü
0000912C : 00 4D 57 32 32 31 0A 20 20 20 20 20 20 20 00 01 : .MW221.       ..