ReadEDID

Hi John – interesting. The base EDID is as described. However, there is an extension block provided which may include some other things that we haven’t declared (including potentially extra modes). It’s a bit of a sprawling spec – I’ve incorporated CEA-861-D extensions but don’t have docs for some of the others. Not quite sure at this stage what that extension block actually has in it… (Apple in ’using non-standard technology shocker…)

On the Raspberry Pi 2.
Monitor is 1680×1050
Module is: Screen Modes 0.41 (11 Feb 2015)
All the below is using the previously saved ReadEDID MDF, ReadEDID is not in PreDesk.

Startup sequence.

*st. Mode
Mode Auto
*

1. Mod init list completes in 1680*1050
2. Then Mode changes into some low definition letter box Mode.
3. Banner at Resources:$.Resources.BootFX.1920×1080 displays in this letterbox Mode.
4. The screen clears and the RISC OS startup messages continue in the letterbox Mode.
5. The progess bar is a right mess in the middle of nowhere.
6. Desktop starts in the configured Mode.

Before the ReadEDID updates the BootFX banner was displayed at full screen, the startup messages were confined to a small window within the banner with the progress bar sensibly placed and very pretty.

*st. Mode
Mode 32
*
Works as expected, banner and startup messages are in that Mode, the progress bar is still hanging around in fresh air.

On the Iyonix with Mode configured to Auto the startup is similar except that after the softload it is in some pillar box mode. Configuring the Mode to 32 works as expected.

P.S. Installing ReadEDID in PreDesk does not change the above.

As per David Pitt’s report, my findings with latest ROM are that the “predesk” phase is still affected in a way that didn’t occur previously, despite recent changes to neuter ScreenModes. For me (and a couple of other testers) it the predesk goes “out of range” on the monitor, rather than letterboxed as above, but either way I think it is indicitive of a problem.

Hm. Today’s ROM on the RPi2, for me, makes a mess pretty much as David Pitt describes, then stiffs completely.

Interesting.
The reason why there is a blank period is because with auto monitor and auto mode, unless you look at the monitor and interrogate it (readedid)? the OS will give you mode 15, a 1 bit black and white mode in tv monitor mode.

So workaround is either to let readedid be invoked during boot, and at least set something useful from it, or to configure monitor 4 and configure mode e.g. 27

the basic test code, called !Boot

a%=MODE
if a%<256 THEN
a$="echo "+STR$(MODE)+" { > $.modeatboot }"
ELSE
a$="mem. "+STR$~(MODE)+" { > $.modeatboot }"
ENDIF
OSCLI(a$)
*settype $.modeatboot text
*desktop

This begs a question. Should readedid be called in a very basic manner at module init to detect whether the monitor is ‘modern’, and I guess the hardware, even if using normal loadmodefile behaviour? result could be to ‘predispose’ riscos to selecting mode 27 or mode 28 as the minimum mode possible, hence being pretty certain to produce at least SOME basic display.
‘Modern’ being implied by the monitor responding to edid request and reporting at least edid1.3 version

Or should we just force mode 27 minimum and let the few legacy machines (with legacy tv monitors) need a little more configuration at startup.

Any thoughts?

If you do nothing, please at least

*configure monitor 4

and

*configure mode 27

or

*configure mode 32

as some people suggest

this should result in more favourable display using 640*480, which I believe is the only mandated common display standard (though not possible on the apple cinema 30!!)

It’s ScreenModes which is misbehaving. I’m working on fixing it, but there are many bugs, far too many for me to fix tonight. Some of these are bugs that I’ve fixed before, last July, but for whatever reason it’s this older version of ScreenModes that made its way into CVS. Other bugs are new.

For a variety of reasons, I’m not happy.

the OS will give you mode 15, a 1 bit black and white mode in tv monitor mode.

When did that change? Mode 15 used to be the 256 colour version of mode 12.

For a variety of reasons, I’m not happy.

Ouch! That’s understandable, doing the same work twice. Isn’t it possible to revert to the fixed version, then ask whoever submitted the older code to base their work on the current version, not an older one?

Any thoughts?

If we can get reading an EDID to work reliably in every case, reading it at boot-up would be good.

Another possibility is to use an extended “CMOS” file to store video parameters and set the monitor up from there. It would, of course, be possible to have a setting there to either use EDID or to use parameters from the “CMOS”.

We would need a method to get a suitable set of values in the “CMOS” file, of course. I see no reason why we shouldn’t put the configured mode parameters in there from the Configure Screen app.

I’m working on the assumption that RISC OS can be persuaded to reach some visible state in the very first place, of course.

Mode 15, I would never has guessed that.

*co. mode 32

Done that. And got rid of the untidy progress bars with Unset Boot$Progress* in !Boot.Utils.BootRun.

the OS will give you mode 15, a 1 bit black and white mode in tv monitor mode.

When did that change? Mode 15 used to be the 256 colour version of mode 12.

It hasn’t changed.

For a variety of reasons, I’m not happy.

Ouch! That’s understandable, doing the same work twice. Isn’t it possible to revert to the fixed version, then ask whoever submitted the older code to base their work on the current version, not an older one?

I’ll be able to merge everything together myself, it’s obviously just a bit of a hassle, especially since some of the bugs I originally fixed have now been fixed by other people (and not always correctly). Then there’s the fun of testing it on X different platforms with Y different monitors. Then at some point I need to dig up all the relevant information on how the OS handles picking screen modes, as it looks like there’s a lack of knowledge in that area. Plus I should probably put together a list of things which I know are missing/incomplete with regards to the EDID work, just to remind everyone (the last list would have probably been in July, and I’m guessing everyone involved has forgotten considering that the bounty appears to have been stuck in limbo up until now)

Jeffrey, If there is help I can give here, please ask
Thanks

Fixed version of ScreenModes now in CVS.

I’m seeing a couple of minor discrepancies in the MDF output (incorrect framerate in the comments for some modes, and displayed framerate off by one for some modes compared to EDID when loading the MDF), but other than that everything seems to be working correctly now.

Fixed version of ScreenModes now in CVS.

And now on my RPi2. *configure Mode Auto is good again, startup splash screen, and progress bars, properly displayed. Many thanks.

Looking good here too.

Thanks for taking the time to fix this!

Good work everyone! Thanks for contributing to this. :) One thing we’d like to get sorted out before we can put this into a ‘stable’ ROM is to replace all of the floating point maths used in the EDID code – there’s no real need for it; it was only used for convenience initially. If this could be recoded using fixed point maths, even working in millihertz (!) a 64 bit int is good to pixel clocks faster than the speed of light…

Any particular reason you want to get rid of the floating point? Accuracy concerns? FPEmulator dependency?

Saying that floating point was used “for convenience” isn’t really any different to saying that C was “used for convenience”. Maybe we should rewrite everything in assembler, or maybe assembler is too convenient and we should write machine code directly using a hex editor ;-)

The floating point was used because the GTF and CVT specs used floating point calculations, as does the VESA calculators you can use to cross-check against. There are four sets of calculations in there with quite a bit of overlap: equally it could be possible to simplify that down to a single set of entry calculations which branch later which would make more efficient code. However when writing it we had to be sure the calculations were right and it felt safer to clearly show the calculation path with some repetition rather than make it simpler but less easy to follow.

I had a go at converting it to fixed point – but it has to be undertaken carefully and my attempts this far just led to wrong calculations. A small rounding error early on magnifies later and can be difficult to find.

Steve / Jeffrey: the Apple display has an extension block starting 0×00. This far I have been unable to find a spec which supports that. Do either of you know of one? I suspect there are extra modes in there which may broaden our compatibility a little.

Steve / Jeffrey: the Apple display has an extension block starting 0×00. This far I have been unable to find a spec which supports that. Do either of you know of one? I suspect there are extra modes in there which may broaden our compatibility a little.

If that hex dump was produced using the code which went into CVS, then it’s completely bogus, as reading of extension blocks was broken in that version (Note how it’s only the first 32 bytes of the two blocks that differ from each other). It was realloc’ing the EDID block and then not reading into it (your original TODO NOW READ EXTENSION BLOCKS HERE comment was in a rather silly place). The checksum code was in the wrong place as well, which I guess is how it missed initial testing.

The weird 115 Mhz MDF has disappeared now and without trying the definitions look reasonable for the DELL 1505FP. Only oddity is that the last definition occurs twice. Don’t know if that’s of any interest.

# Monitor description file for DELL 1505FP
# Created by ScrModes 0.43
# (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:  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

So presumably if that is a CEA block we should now be OK (my testing of CEA blocks came only from the extracted EDID blocks we were using). If it’s not, we can have a look and see what it is.

Thanks Frederick: so in that one the same mode is being defined twice in the EDID. Once in the Established Timings and once (I think) as the ‘preferred mode’. In the other EDIDs I’ve seen that would only get defined once.

There are five or six different ways a mode can be defined in a monitor. Up to now the code has been sequential (start at byte 0 and works forwards). To follow the spec more accurately we should use the prioritisation, and then before committing a new mode check if it hasn’t been defined already.

I’ll see if I can get some time to re-order it now we read all the things defined so that it reads them in the ‘prioritisation order’ and rejects duplicates.

That is what the manual describes as the ‘Optimal preset resolution’.

One mode additional to the MDF in the manual is;

OK – having a look at the monitor definitions again now. I have noticed we don’t support CVT 3-byte definitions but no-one has submitted an example EDID block which contains them yet to test against. If anyone has a monitor with missing modes I’m looking for one which has the value &F8 in bytes 0×4b, 0×5d or 0×6F could they drop the EDID dump chunk of the MDF on here (see earlier in this thread) with a summary of which modes are missing (X,Y, framerate).

Also – would it be possible to summarise from testers so far whether Jeffrey’s changes last night have now given you all the missing modes, and if you have modes which are accessible on a PC/Mac but not on RISC OS a copy of the EDID.

I have a LG M2380d tv/Monitor that shows only 5 modes in the display manager using a MDF generated by the latest ROM build.

This is on a Beagleboard -Xm.

The modes that are displayed are:

640 × 480 60Hz and 75Hz
800 × 600 as above
1024 × 768 60, 70 & 75Hz
1152 × 864 60Hz – gives a blank screen
1280 × 720 60Hz

All the other modes are not seen.

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

# Max Viewable H 51 cm 
# Max Viewable V 29 cm
# Line rate:     30 - 83kHz
# Frame rate:    56 - 75Hz
# Max Dot rate: 170MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:M2380D

# 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:  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 @ 70Hz
# Bounds: H  56.48kHz, V 70.07, DClock 75.00MHz
startmode
 mode_name:1024 x 768
 x_res:1024
 y_res:768
 pixel_rate:75000
 h_timings:136,144,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

# Mode:  1152 x 864 @ 60Hz
# Bounds: H  53.70kHz, V 2113.43, DClock 81.62MHz
startmode
 mode_name:1152 x 864
 x_res:1152
 y_res:864
 pixel_rate:81624
 h_timings:120,184,0,1152,0,64
 v_timings:3,27,0,864,0,1
 sync_pol:1
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  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:136,178,0,1280,0,56
 v_timings:5,24,0,720,0,1
 sync_pol:0
EndMode

# Mode:  1280 x 960 @ 75Hz
# Bounds: H  75.15kHz, V 10526.73, DClock 129.86MHz
startmode
 mode_name:1280 x 960
 x_res:1280
 y_res:960
 pixel_rate:129859
 h_timings:136,224,0,1280,0,88
 v_timings:3,38,0,960,0,1
 sync_pol:1
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 @ 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:  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

# 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 @ 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:1
EndMode

# Mode:  1920 x 1080 @ 50Hz
# Bounds: H  56.25kHz, V 50.00, DClock 148.50MHz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:148500
 h_timings:556,148,0,1920,0,16
 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:  1920 x 1080 @ 25Hz
# Bounds: H  28.12kHz, V 25.02, 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,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  1e 6d bc 57  01 01 01 01
# 01 14 01 03  80 33 1d 78  0a c6 65 a0  59 58 9d 27
# 0e 50 54 a5  6f 00 81 80  81 8f 71 40  b3 00 81 4f
# 71 4f 01 01  01 01 02 3a  80 18 71 38  2d 40 58 2c
# 45 00 fd 1e  11 00 00 1a  21 39 90 30  62 1a 27 40
# 68 b0 36 00  56 50 21 00  00 1c 00 00  00 fd 00 38
# 4b 1e 53 11  00 0a 20 20  20 20 20 20  00 00 00 fc
# 00 4d 32 33  38 30 44 0a  20 20 20 20  20 20 01 d2
# 02 03 21 f1  4e 84 05 03  02 20 22 10  11 13 12 14
# 1f 07 16 26  15 07 50 09  07 07 66 03  0c 00 10 00
# 80 01 1d 00  72 51 d0 1e  20 38 88 15  00 56 50 21
# 00 00 1e 01  1d 80 18 71  1c 16 20 58  2c 25 00 56
# 50 21 00 00  9e 01 1d 80  d0 72 1c 16  20 10 2c 25
# 80 c4 8e 21  00 00 9e 02  3a 80 d0 72  38 2d 40 10
# 2c 45 20 06  44 21 00 00  1e 02 3a 80  18 71 38 2d
# 40 58 2c 45  00 56 50 21  00 00 1e 00  00 00 00 ce
#
#End