ReadEDID

Chris: your error from ScreenModes is because the Messages file being used is the one from the (pre-EDID) ROM. As the ROM doesn’t have the full set of messages in it, you get a message token not found error (that error basically reports that the EDID read operation failed – ie. same as you get when running Jeffrey’s code). On the Iyonix of course, you haven’t got an up-to-date copy of ScreenModes installed, so it doesn’t know about the ReadEDID command.

Last night’s build has broadened the support for the various ways of expressing screen modes. If anyone had a display with missing modes which would otherwise be accepted by the graphics driver, try last night’s build. We now look at two further sets of parameters which may be used on newer displays – a shorthand way of expressing screen displays in three bytes, and an ‘extension block’ format which could hold quite large numbers of available screen modes. However, I haven’t yet got data from a ‘real’ monitor which supports them, so it’s untested (written by myself, and cross-checked/corrected by Jeffrey).

NB that the commonest reason you won’t get a display using EDID is either that the EDID isn’t being read at all or that the graphics driver rejects the mode because the bandwidth needed would be too high (or the multiple of 8 issue on the Pi per above).

I’ve just tried “CreateModeFile” on my PandaBoard/Asus PA248. (ROM from the 21st)
The only 1920×1200 mode it showed was the 60Hz in the generated file, so I was expecting it to be no use and get the weird graphics effects.
However after initial testing it seems to work perfectly.
Great work! (still can’t get hopper working due to the 300×256 resolution, which isn’t supported by my monitor – but that’s another battle!)

Great to hear. Did it show all the others you were expecting? (exclude anything >1920 X 1200 because the Panda will reject those due to a lack of bandwidth).

I only really use 1920×1200, but the list seemed complete and all worked OK. My monitor only goes up to 1920×1200, so I’m as happy as Larry!

Just for completeness (I’m not sure what it would be wanted for) CreateModeFile still doesn’t produce the 720 × 400 res that the manual claims for the Dell 1505FP.

The new CreateModeFile command in ScreenModes 0.47 seems to have an issue on my Iyonix as the EDID read does not seem to get a monitor name and thus I am unable to save a file out.

On versions where you could save a file by using ReadEDID followed by direct pathname then this did not matter if it could not read the monitor name but the new CreatModeFile adds in the monitor name to the path by default and thus is not compatible when a monitor name can not be read.

Please can the command be altered so either you can overide the second monitorname element or if it sees a blank in the monitor name that makes the file name “Blank” or something generic.

Doug

Frederick: I know why that is – just need to address it. There are three legacy modes whose parameters aren’t formally defined in the VESA specifications – two of which are at 720X400 (and one at 640X480X67Hz). Currently we skip those three (after all they’re not likely to get used!) BUT – when we think about legacy mode support they may be of more use. The 640X480 may be relevant as John Ballance has a monitor which won’t go to 640X480 at present – and it may be that it doesn’t support a base of 640X480X60 but may support 640X480X67 (VESA puts a note by it with ‘Apple, Mac II’ as the source of it).

We can get it to calculate those values – just need to reorder how things are done. As you say, not particularly useful in day-to-day use. However it may also explain why John Ballance’s Apple monitor didn’t have 640X480 available (PCs used 640X480X60Hz, but the Apple II used 640X480X67Hz as a standard so will place a bet that this is the ‘base’ resolution on an Apple display…)

With ScreenModes 0.47 on the Iyonix with an HP2229h 1680×1050 monitor then calling *ReadEDID from the command line results in a pillar-boxed 1680×1050 occupying only about half af the width of the screen. Using a CreateModeFile saved MDF gives a full size display.

The parameters in the 0.47 saved MDF are the same as those from 0.43. The block dumps do differ.

# Monitor description file for HP 2229h
# Created by ScrModes 0.47
# (EDID specified modes only, no calculated modes)

# Max Viewable H 48 cm
# Max Viewable V 30 cm
# Line rate:     24 - 83kHz
# Frame rate:    48 - 76Hz
# Max Dot rate: 170MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:HP 2229h


# 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:2
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
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  22 f0 52 28  00 00 00 80
# 03 14 01 03  68 30 1e 78  ee dc 55 a3  59 48 9e 24
# 11 50 54 a5  6b 80 81 40  81 80 95 00  a9 00 b3 00
# a9 40 01 01  01 01 21 39  90 30 62 1a  27 40 68 b0
# 36 00 d9 28  11 00 00 1c  00 00 00 fd  00 30 4c 18
# 53 11 00 0a  20 20 20 20  20 20 00 00  00 fc 00 48
# 50 20 32 32  32 39 68 0a  20 20 20 20  00 00 00 ff
# 00 33 43 51  30 30 33 34  32 4a 35 0a  20 20 00 72
#
#End

# Monitor description file for HP 2229h
# Created by ScrModes 0.43
# (EDID specified modes only, no calculated modes)

# Max Viewable H 48 cm
# Max Viewable V 30 cm
# Line rate:     24 - 83kHz
# Frame rate:    48 - 76Hz
# Max Dot rate: 170MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules


# 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:2
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

# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  22 f0 54 28  00 00 00 80
# 03 14 01 03  80 30 1e 78  ee dc 55 a3  59 48 9e 24
# 11 50 54 a5  6b 80 81 40  81 80 95 00  a9 00 b3 00
# a9 40 01 01  01 01 21 39  90 30 62 1a  27 40 68 b0
# 36 00 d9 28  11 00 00 1c  00 00 00 fd  00 30 4c 18
# 53 11 00 0a  20 20 20 20  20 20 00 00  00 fc 00 48
# 50 20 32 32  32 39 68 0a  20 20 20 20  00 00 00 ff
# 00 33 43 51  30 30 33 34  32 4a 35 0a  20 20 01 57
# 02 03 29 f1  23 09 07 07  4f 84 02 03  01 06 07 15
# 16 11 12 10  1f 13 14 05  83 01 00 00  6c 03 0c 00
# 10 00 b8 2d  c0 01 01 01  01 8c 0a d0  8a 20 e0 2d
# 10 10 3e 96  00 d9 0a 11  00 00 18 8c  0a d0 90 20
# 40 31 20 0c  40 55 00 d9  0a 11 00 00  18 01 1d 80
# 18 71 1c 16  20 58 2c 25  00 d9 0a 11  00 00 9e 01
# 1d 80 d0 72  1c 16 20 10  2c 25 80 d9  0a 11 00 00
# 9e 00 00 00  00 00 00 00  00 00 00 00  00 00 00 96
#
#End

David: did you definitely read them from the same socket on the display? They are definitely different EDIDs – all the differences are from byte 7e onwards. 7e is the number of extension blocks, then the checksum byte, and then one of them has an extension block when the other does not. That isn’t something that RISC OS can influence as far as I can see.

There are two modes produced with different sync polarities. Jeffrey and I have been discussing ‘identical’ modes: those two look the same but are not. Could you try deleting one of the modes, and then the other, and seeing if one in particular works?

did you definitely read them from the same socket on the display?

Perhaps not, can’t remember now, of course.

There are two modes produced with different sync polarities.

The sync polarity setting makes no difference at all on either the VGA Iyonix or the HDMI Raspberry Pi.

I’m totally confused now, I had assumed the funky colouring disappearing was due to the new MDF. However if I use the old MDF at 60Hz it works just as well!
I checked my monitor that it is in fact outputting at 60Hz and it is.
So situation normal ;-)
Maybe there was some other ROM fix that has sorted it?
Still, it’s nice the CreateModeFile works so well!

David, Frederick: would you mind testing the latest changes to ScreenModes (0.47): not sure if they will be in today’s ROM or in tomorrow’s. The fixes are aimed at addressing both the issues you described. Thanks.

ScrModes 0.48

The good news is that on the Iyonix *ReadEDID now works with the 1680×1050 mode displayed properly in fullscreen.

There are still two entries for 1680×1050 but they now both have the same sync polarity.

# Monitor description file for HP 2229h
# Created by ScrModes 0.48
# (EDID specified modes only, no calculated modes)

# Max Viewable H 48 cm
# Max Viewable V 30 cm
# Line rate:     24 - 83kHz
# Frame rate:    48 - 76Hz
# Max Dot rate: 170MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:HP2229h EDID Iyo048

# 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:  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
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  22 f0 52 28  00 00 00 80
# 03 14 01 03  68 30 1e 78  ee dc 55 a3  59 48 9e 24
# 11 50 54 a5  6b 80 81 40  81 80 95 00  a9 00 b3 00
# a9 40 01 01  01 01 21 39  90 30 62 1a  27 40 68 b0
# 36 00 d9 28  11 00 00 1c  00 00 00 fd  00 30 4c 18
# 53 11 00 0a  20 20 20 20  20 20 00 00  00 fc 00 48
# 50 20 32 32  32 39 68 0a  20 20 20 20  00 00 00 ff
# 00 33 43 51  30 30 33 34  32 4a 35 0a  20 20 00 72
#
#End

Yes, now get the last 720×400 definition. Not a mode to be advertised :-)

# Monitor description file for DELL 1505FP
# Created by ScrModes 0.48
# (EDID specified modes only, no calculated modes)

# Max Viewable H 30 cm 
# Max Viewable V 23 cm
# Line rate:     30 - 61kHz
# Frame rate:    56 - 76Hz
# Max Dot rate:  80MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:DELL 1505FP

# 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 400 @ 70Hz
# Bounds: H  29.19kHz, V 70.00, DClock 26.15MHz
startmode
 mode_name:720 x 400
 x_res:720
 y_res:400
 pixel_rate:26154
 h_timings:72,88,0,720,0,16
 v_timings:3,13,0,400,0,1
 sync_pol:1
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 @ 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:  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
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  10 ac 07 40  57 53 41 47
# 1f 0f 01 03  80 1e 17 78  ee b4 a5 a1  58 4e 97 26
# 16 50 54 a5  4a 00 01 01  01 01 01 01  01 01 01 01
# 01 01 01 01  01 01 64 19  00 40 41 00  26 30 18 88
# 36 00 30 e4  10 00 00 18  00 00 00 ff  00 59 34 32
# 38 37 35 37  50 47 41 53  57 0a 00 00  00 fc 00 44
# 45 4c 4c 20  31 35 30 35  46 50 0a 20  00 00 00 fd
# 00 38 4c 1e  3d 08 00 0a  20 20 20 20  20 20 00 6d
#
#End

Great – thanks for checking that out for me. Yes – we still need to remove duplicates – but as it stands it’s not particularly harmful to have the definition doubly defined.

Frederick: you say that 720X400 isn’t particularly useful (and certainly for desktop use it isn’t) but it does have some advantages. The main one is its low pixels and aspect ratio would make it be best suited if letter-boxing is needed for low resolution modes (such as mode 9/13). Hardware scaling would probably be preferable for such modes – but it was a couple of lines of code difference to add that support in.

I used *CreateModeFile on my PI3 (Screen Modes 0.57), with the intention to improve the manually written MDF of my BenQ GW2260 of my RISC PC. So here are my remarks on the generated file:
- !MakeModes didn’t like the file because of the use of “EndMode” instead of “endmode” and because of “interlace” so I fixed the “endmode” and removed the interlaced modes which I think are an OS 5 addition.
- there are a lot of duplicates in this MDF with the exact same each pixel rate, timings and sync polarity (duplicate definitions from different EDID sections?). A little cleanup pass to remove these duplicates would be welcome.
- the third “720 × 480 @ 60Hz” entry has the same timings but a slightly different pixel rate. Could it be a calculation error in the handling one of these sections?
- Starting from IIRC 800×600, none of modes managed to sync correctly. Transferring a part or the totality of the front porch to the right border (with sometimes a little from the back porch) does the trick. From !MakeModes I can tell that there are some minimal sizes of (front porch + sync) to respect, but looks like the monitor doesn’t like too large values too. I wonder if this is defined in the standard or a limitation of the monitor for the analog D-SUB side?
- the monitor think of the 720×480 mode as 640×480 or as 800×480 depending of how I shuffle values around so I guess that particular problem is entirely the monitor’s fault.

# Monitor description file for BenQ GW2260
# (EDID specified modes only, no calculated modes)

# Max Viewable H 48 cm 
# Max Viewable V 27 cm
# Line rate:     30 - 83kHz
# Frame rate:    50 - 76Hz
# Max Dot rate: 170MHz(rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:BenQ GW2260
DPMS_state:3

# Mode:  640 x 480 @ 60Hz
startmode
 mode_name:640 x 480
 x_res:640
 y_res:480
 pixel_rate:25200
 h_timings:96,48,0,640,0,16
 v_timings:2,33,0,480,0,10
 sync_pol:3
EndMode

# Mode:  640 x 480 @ 60Hz
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
startmode
 mode_name:720 x 480
 x_res:720
 y_res:480
 pixel_rate:27027
 h_timings:62,60,0,720,0,16
 v_timings:6,30,0,480,0,9
 sync_pol:3
EndMode

# Mode:  720 x 480 @ 60Hz
startmode
 mode_name:720 x 480
 x_res:720
 y_res:480
 pixel_rate:27027
 h_timings:62,60,0,720,0,16
 v_timings:6,30,0,480,0,9
 sync_pol:3
EndMode

# Mode:  720 x 480 @ 60Hz
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:  720 x 576 @ 50Hz
startmode
 mode_name:720 x 576
 x_res:720
 y_res:576
 pixel_rate:27000
 h_timings:64,68,0,720,0,12
 v_timings:5,39,0,576,0,5
 sync_pol:3
EndMode

# Mode:  720 x 576 @ 50Hz
startmode
 mode_name:720 x 576
 x_res:720
 y_res:576
 pixel_rate:27000
 h_timings:64,68,0,720,0,12
 v_timings:5,39,0,576,0,5
 sync_pol:3
EndMode

# Mode:  800 x 600 @ 60Hz
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 @ 60Hz
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:  1280 x 720 @ 60Hz
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 @ 60Hz
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 @ 60Hz
startmode
 mode_name:1280 x 720
 x_res:1280
 y_res:720
 pixel_rate:74480
 h_timings:136,192,0,1280,0,56
 v_timings:3,22,0,720,0,1
 sync_pol:1
EndMode

# Mode:  1280 x 720 @ 50Hz
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 800 @ 60Hz
startmode
 mode_name:1280 x 800
 x_res:1280
 y_res:800
 pixel_rate:83500
 h_timings:128,200,0,1280,0,72
 v_timings:6,22,0,800,0,3
 sync_pol:1
EndMode

# Mode:  1280 x 1024 @ 60Hz
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:  1600 x 900 @ 60Hz
startmode
 mode_name:1600 x 900
 x_res:1600
 y_res:900
 pixel_rate:118997
 h_timings:168,264,0,1600,0,96
 v_timings:3,28,0,900,0,1
 sync_pol:1
EndMode

# Mode:  1680 x 1050 @ 60Hz
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
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 @ 60Hz
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 @ 60Hz
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 @ 60Hz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:172798
 h_timings:208,328,0,1920,0,120
 v_timings:3,34,0,1080,0,1
 sync_pol:1
EndMode

# Mode:  1920 x 1080 @ 50Hz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:148500
 h_timings:44,148,0,1920,0,528
 v_timings:5,36,0,1080,0,4
 sync_pol:0
EndMode

# Mode:  1920 x 1080 @ 30Hz
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:  1920 x 1080 @ 60Hz
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:  1920 x 1080 @ 50Hz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:74250
 h_timings:44,148,0,1920,0,528
 v_timings:5,15,0,540,0,2
 sync_pol:0
 interlaced
EndMode
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  09 d1 c4 78  45 54 00 00
# 0f 17 01 03  80 30 1b 78  2e 9a d5 a3  55 55 9f 27
# 0c 50 54 21  08 00 81 80  81 c0 81 00  a9 c0 b3 00
# d1 c0 01 01  01 01 02 3a  80 18 71 38  2d 40 58 2c
# 45 00 dd 0c  11 00 00 1e  00 00 00 ff  00 41 34 44
# 30 32 31 39  35 30 31 39  0a 20 00 00  00 fd 00 32
# 4c 1e 53 11  00 0a 20 20  20 20 20 20  00 00 00 fc
# 00 42 65 6e  51 20 47 57  32 32 36 30  0a 20 01 c9
# 02 03 22 f1  4f 90 1f 05  14 04 13 03  12 07 16 15
# 01 06 11 02  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 dd 0c
# 11 00 00 1f  01 1d 80 18  71 1c 16 20  58 2c 25 00
# dd 0c 11 00  00 9f 01 1d  00 72 51 d0  1e 20 6e 28
# 55 00 dd 0c  11 00 00 1e  8c 0a d0 8a  20 e0 2d 10
# 10 3e 96 00  dd 0c 11 00  00 18 00 00  00 00 00 00
# 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 7b
#
#End

- there are a lot of duplicates in this MDF with the exact same each pixel rate, timings and sync polarity (duplicate definitions from different EDID sections?). A little cleanup pass to remove these duplicates would be welcome.

Agreed that removing duplicates would be nice. Apart from the same mode appearing in different sections, it’s also possible that they’re the result of extra attributes which ScreenModes isn’t making use of yet (colour space, aspect ratio, etc.)

- the third “720 × 480 @ 60Hz” entry has the same timings but a slightly different pixel rate. Could it be a calculation error in the handling one of these sections?

60Hz vs. 59.94Hz. An important distinction for video playback, but not very useful to us at this point in time (no way of specifying fractional refresh rates with most RISC OS APIs, so I’m not sure which of the two would get selected if you tried switching to that mode)

- Starting from IIRC 800×600, none of modes managed to sync correctly. Transferring a part or the totality of the front porch to the right border (with sometimes a little from the back porch) does the trick. From !MakeModes I can tell that there are some minimal sizes of (front porch + sync) to respect, but looks like the monitor doesn’t like too large values too. I wonder if this is defined in the standard or a limitation of the monitor for the analog D-SUB side?

Possibilites I can think of:

• The monitor supports different modes for the different inputs (I’m assuming the Pi was connected to a HDMI or DVI input on the monitor, while the RiscPC will be connected to VGA).
• A bug in the RiscPC video driver. E.g. when switching between RISC OS 3.7 and RISC OS 5 on my RiscPC I’ve had problems with the “same” mode displaying differently. But I’m not sure if I actually checked to make sure the exact same MDF was in use in both cases (I’ve been swapping out my entire boot sequence when switching OS version, so there’s a good chance it wasn’t the same MDF)
• If you’ve been using a custom MDF in the past then remember you’ll need to reset the monitor’s presets or trigger an auto-adjust in order to get it to forget any adjustments that you/it had made for the custom modes (but it sounds like the monitor isn’t syncing at all, which would suggest it’s a different issue)
• Fussy VIDC + fussy monitor
• ScreenModes bug

- the monitor think of the 720×480 mode as 640×480 or as 800×480 depending of how I shuffle values around so I guess that particular problem is entirely the monitor’s fault.

Yeah, for analogue video the monitor basically has to guess what the horizontal resolution and aspect ratio is, by looking at the sync polarity and timings.

From Feb 14 2015

Only oddity is that the last definition occurs twice. Don’t know if that’s of any interest.

Which it still does with SaveModeFile. Other than that it produces a very nice MDF including the modes I previously added manually.

Ignore that. Just realised how it works. It’s regurged my settings and tidied up as designed. Only creates anew if there is no valid MDF. Doh!

Could whoever has been working on the EDID stuff recently please get in touch privately. There are a number of things we need to discuss because there have been some (probably unintended) side effects of the changes made recently. I suspect some of it may require changes at our end, but we need to discuss things a bit if that’s OK.