ReadEDID

Jeffrey: I think the code that went up wasn’t necessarily the very latest we had (for starters much of the formatting was fixed, and the two changes above were things you had spotted and IIRC had corrected).

Yeah, I was wondering why those things weren’t fixed, but didn’t want to start pointing fingers!

The filtering identical modes thing is an interesting question: how do you decide which gets filtered? If you have a normal and a reduced blanking version at the same frequency and resolution, we would probably want to prefer the reduced blanking version for example. However, there may be hardware reasons we only want to choose one of those two options.

I think we’ll have to rely on the GraphicsV driver to take care of any ‘hardware reasons’ when it does the mode vet. So when ScreenModes builds its internal mode list it would probably want to sort all ‘identical’ modes so that the most favourable one comes first (e.g. prefer progressive over interlaced, prefer low pixel rate over high pixel rate, don’t care about sync polarity). Then within the enumerate loop, as soon as mode_valid reports that one of the modes within a block is valid, it can skip any ‘identical’ modes which follow it.

Having the list sorted by preference means that when it comes to do the mode change, all it needs to do is run through the list of identical modes until it finds the first one which works

One side effect of the new ROM relates to PreDesk display – ie. the phase from “RISC OS 2048Mb” through til (presumably) LoadModeFile. I no longer get any display on the monitor (out of range).

Previously, I have left *configure mode on “auto” rather than *configure mode 32 which I’d normally do, but this has happily displayed a (fairly high res) display for the last year. Indeed, all shipping ARMX6 machines are configured this way and appear fine.

Now, with this new ROM, Predesk phase is “out of range” unless I forcibly *configure mode 32 (I suspect 27, 28, 31 or 32 would all be valid choices).

This suggests to me that something is messing around somewhere even when EDID reading is not enabled (I don’t use *ReadEDID in Predesk). If I had to guess, it would be the ScreenModes module doing some kind of probing during module init?

This effectively means that the new ScreenModes isn’t a drop-in replacement in terms of “no new behaviour unless you do *ReadEDID” which creates support headaches in the field. I appreciate I can issue new CMOS settings, but that’s not really viable when “AUTO” is the CMOS default.

PS, interestingly the “list of module inits” does display fine – it is only when the screen clears for the first time after that (after service_postinit) that the display drops “out of range”.

Andrew: It shouldn’t do. We don’t have any code in init, and the code is effectively a parallel code path to *LoadModeFile – so we do no probing unless asked! I’ll have a think about that one tonight.

Hi.. 1. The x384 mode is an interlaced one. I couldn’t see easily how that got reported in the mdf, hence no report.
2. Other than that and the DPMS state reporting, the mdf reflects fully, I believe, what is captured in the relevant structures being fed into the ‘loadmodefile back end’.
3. The output is intentionally an MDF that could be used directly or amended (as Dave Pitt indeed did.. see earlier).
4. Yes, adding the hex dump of the edid code could be helpful.. commented out, of course (see 3 above)

Hi.. 1. The x384 mode is an interlaced one. I couldn’t see easily how that got reported in the mdf, hence no report.
2. Other than that and the DPMS state reporting, the mdf reflects fully, I believe, what is captured in the relevant structures being fed into the ‘loadmodefile back end’.
3. The output is intentionally an MDF that could be used directly or amended (as Dave Pitt indeed did.. see earlier).
4. Yes, adding the hex dump of the edid code could be helpful.. commented out, of course (see 3 above)5. Andrew’s comments about activity in early boot stages. It is evident with scrmodes in the rom that a readedid is done (looks like maybe even twice) during and after rom boot. Hence if the readedid preferred mode is undisplayable, => no display till desktop reached. The iMx6 rom installed a default mdf as part of the rom bootup. this is being overridden or preempted by scrmodes readedid. Ergo, we need a means of preventing the readedid during rom boot, otherwise you’ll end with a plethora of punter’s machines that are difficult to set sensibly.

ReadEDID does check for Service DisplayChanged_Changing (for hot plug support). Would that be being triggered?

Yes, Service_DisplayChanged will be issued when the first GraphicsV driver registers.

the imxvideo module does a loadmodefile with the default builtin mdf – I think that is all?.. I did notice that the readedid command function is triggered as part of the module init sequence – if you remember you told me about the fpemulator needing to be in rom before scrmodes – without it the rom module init phase crashed at scrmodes, hence your s/w. (module init sequence – the series of messages that come to screen on the monitor on an odd numbered rom release, before (in out case anyway) the RiscOS 2048M message.)

ah… just seen jeffrey’s message – that’ll be the hal based graphicsv driver that the kernel uses as a default

I’ve uploaded the debug output and edid block here. The data was generated on a Raspberry Pi 2.

I also noticed the BootFX screen goes wrong. The screen mode changes twice before entering the desktop.

In the real world many monitors do not provide well matched modes via EDID, so tuned MDF files will be around for a good while. What do people think of the proposition that scrmodes does not do any edid activity from boot until it has received the readedid command, after which it could continue as now. So where the boot system does the loadmodefile, if that is replaced by readedid we should achieve practical behaviour. Or do we need a cmos on/off setting?
( I propose this as so far I have at least 2 different monitors where boot time readedid activity has left us with non displaying monitors. it isn’t the scrmodes module’s fault.. it is just that (as experience shows) edid content is often a bit of fabrication!!)

I think that the *Configure Mode Auto versus *Configure Mode 32 (say) already provides a screen setting for the pre desktop (i.e. RISC OS 2048k etc bit).

It is unfortunate that the ‘Auto’ setting (now that EDID is being read) relies upon good monitor design for usable mdf data.

If you set *con. mode 32 then edid activity before LoadModeFile is (presumably) suppressed anyway.

I remember posting some years ago in a newsgroup that I thought that we could handle monitors better during boot-up, and that I could foresee the day when the low resolution that some machines output during boot-up would be outside the range that some more recent monitors can handle.

One possibility is to store video parameters in an extended “CMOS” file, which can be supported by all machines from BeagleBoard onwards. There is no particular size limit to the file.

Something else to consider is machines that boot up when connected to a video switch. A give machine may not be able to read an EDID until some time after boot-up, so please let’s think of a solution that keeps on looking periodically until it finds an EDID.

Indeed. This monitor here has an Iyonix connected to analogue input, and a Panda and RaPi connected to the HDMI input via a switch. The machines are normally all on at the same time. If I manage to crash one, then the monitor immediately switches to an alternate if there is one not in screen saver mode. Will the rebooting machine pick up the EDID info if there is another active monitor connected?

Even the Iyo is a bit hit and miss on pressing ‘Y’ to softload when you can’t see the output!

John: I guess that depends upon where we think the ‘Roadmap’ objective is for this work? It raises as many questions as it solves I suspect.

The quick solution for you is disable hot-plugging – comment out the service call response. But clearly that costs you hot plugging support on the device (which was a Bounty objective).

My thoughts are we should be aiming for a RISC OS ROM image that if you put on a board, you could connect it up to a display (before or after booting) and get an image, without a Boot sequence or pre-install configuration.

The Roadmap definitely includes having an unspecified number of displays – from which I presume that number may be 0 at startup (which could be tricky), or lots (if you wanted to attach external USB-based displays for example). We can’t therefore assume that there is a display on startup (or indeed should we assume there even is a graphics driver???)

So – mitigating thoughts:

- Firstly, the EDID standard (and the HDMI standard as HDMI mandates EDID 1.4a compliance) mandates that devices support 640X480X60Hz. Therefore, that would make sense to be the mode that a RISC OS machine should start up in until other modes are available: even if the mode definitions are reset 640X480X60 should still be there.

- Some people may want ‘additional’ modes to those that are recognised by EDID. That may be that the monitor can handle reduced blanking but hasn’t declared it for example. I think the solution there may be to add an *AddModeFile command which appends mode definitions rather than overwrites what already exists. The intent would be that a machine would read the EDID and add user preferences, rather than trample over them. This would reduce the MDF ‘tweaking’ described. It remains less than ideal.

Bear in mind MDFs in general are a bad idea in a multi-head setup: take the Panda with its physically-identical HDMI ports. Plug two different monitors into them. Then swap them over. Add a USB-based display into a random USB port. How do we know which one we’re dealing with and where? IMHO MDFs don’t work well on the multi-head roadmap.

- The next question is about ‘extra modes’: Hopper being a prime example. We now have the calculations available to build modes to specification, and the Pi (and likely other devices) have the ability to scale displays. So – if there isn’t a pre-defined mode, we should try to use what we have available to build a mode. This could be by letter boxing the mode to the nearest fitting mode. Or we could use hardware scaling to scale the mode a la Pi. But the basic idea would be that if you request a resolution, you get it (providing it’s smaller than the largest available). You may not get the whole screen, and you may not get the frequency you wanted – but you should get the resolution.

- The next issue is unavailable modes. It isn’t acceptable to assume that any mode is available any more (except 640X480 per above), even if one was configured in the previous session. We may also have selected a mode, and then hot plug a different monitor which doesn’t support that mode. Or we were using a USB display which has since been removed. So if we’re requesting a mode, there should be the expectation that the mode request may fail. If it does, we need to decide what to do – do we throw an error? Do we use a fallback mode (of 640X480)? Do we ask the OS to pick the best fallback?

In answer to Chris: there is clearly a case for an equivalent of ROL’s VideoGuard module (the OS needs to cope with no configured displays). However, as soon as your monitor is detected, Service Display_DisplayChanging gets called per above and the monitor should be configured. Clearly if the above is disabled, that would be lost (but it would be easier to configure at startup).

William: good and well thought reply. Comments on multihead appreciated. I agree about 640×480. All I can say with certainty is that a machine that ONLY does auto modeing will be a real headache to deploy. I already have examples of real world monitors recently built that do not respond correctly in their ‘native’ display mode, and of many adaptor cables etc that actually do not pass the edid signalling wires.

What I’ll do for now is:
1) remove the readedid call on module initialisation .. this was the bit that ‘blew things’ until I had put the fpem module earlier in the rom.
2) insert a flag defaulting to off that keeps to the old behaviour until a readedid command is issued. There is nothing to stop a video driver issuing this where the platform or product is prepared to risk ‘dark screens’.
3) this flag is toggled on by the readedid command with no parameters, and toggled off by the loadmodefile command, which permits legacy support and enables clean behaviour with real world monitors. Please bear in mind that there are an awful lot of monitors still out there that run with inappropriate, incomplete or earlier edid specs.

This will allow the scrmodes module to be safely incorporated in real world roms. It does not affect the bounty aims, just moderates potential mega support problems. (I have nothing to do with the bounty BTW)

I have added reading of additional edid blocks (your TODO) and will add hex printout of the edid block buffer used at the end of the mdf (commented out of course).

I’ll check this back in later today. If there are any mods that should have made it into the code, and if you would like me to add them, please feel free to shove them my way. Of course, if your ‘path’ to cvs is sorted, so be it.

Many thanks
John

Thanks John – much appreciated.

I do have a code suggestion which may help here. I think the errors that are generated are generated within the ReadEDID function.

What about if the error was generated into an error block, and the *command was instead called from a parent function which then called _os_kernelerror *readEDID() etc, returning an error block. The parent function then displays the error if one has occurred.

Service_DisplayChanging can calls the same readedid function, but can now fail silently if an error occurs and importantly without trashing the existing defined modes.

This should mean only a display with a faulty EDID block would fail (ie. valid header and checksum but wrong data): no EDID / unable to read EDID should be fine.

No time to make those code changes for a few days (but I think what is proposed isn’t a particularly difficult change).

Also be mindful that the syntax of *ReadEDID will in future need to change to become *ReadEDID display_number.

Hi

Syntax: it is currently *ReadEDID [file]. file is optional. I guess it’ll become *ReadEDID [file] and if no parameters, then default to display num 0? For now I’ll leave it just taking the filename parameter, and defaulting internally to display 0.

readedid function can return errors. e.g. failed edid read.. I’ll make sure service_displaychanging can tolerate errors returned from readedid

(later)
In fact it will tolerate errors as it only goes to parseedid if there have been no errors so far. Whilst an error block is returned, it goes nowhere in the service call.

John: Could we compile ‘failing’ EDIDs somewhere with a description of how they may have not quite delivered what we expect? Personally I’d still prefer a test directory in source (but would need ROOL agreement): to which we can then throw things that may break the setup.

This code hasn’t really been changed since July, and is mostly >1yr old – so I’ve not properly looked at it for a while now. But the aim would be to go through the EDID data, compare versus your output, and try to find cases where we think the EDID code could have done better. Obvious exclusions are where ScreenModes says ‘yes’ but GraphicsV says ‘no’. Or where we are following the specs but the monitor doesn’t quite do what it says on the tin. The reports that some modes don’t appear correctly just makes me think we may have a bit of tweaking to do somewhere.

Did your Apple display now behave? Any others you are aware of?

Hi William.
do you have a copy of the currently committed sources, or should I send you one.. ditto the standalone module?

The resultant mdf it produces contains a hex dump of the edid file read. In that form dubious descriptors can easily be ‘transported’. ‘My output’ – is purely a mdf formatted dump of the data parseedid() generates. If there is a file name presented it is saved there rather than going through to a mode change.

My Apple monitor:. yes it does report as expected, IF, (logically) it is connected through a cable and adaptors as needed that really do pass the edid wires – I appear to have many convertors that are sparsely wired!!! The edid reports precisely 2 modes.. 1280×800 at 71 MHz and 2560×1600 at 268MHz (which would need to be dual link). It reports as 1.3 spec, but does not include 640×480

As for failing EDIDs, certainly a few years ago there was one manufacturer who put the same edid rom in all monitors – BUT – not all monitors are equal! In other words, it isnt usually that the contents are mis interpreted, but rather that they mis represent the real hardware.

Other issues arose due to some attempted reads that failed, but left the monitor in a peculiar state – the apple monitor was a good example.

Before I get too uppety about this I will need, now I more or less trust the output, to confirm that the reported mode settings are correctly applied in the video driver here. I suspect they are, but need to confirm, which is why this was a hot topic.. I had just got to the point where I had read in and checksummed the whole edid block when your stuff became available!!

FWIW my imxvideo module provides a default mdf via resourcefs. I had anticipated that in future this would be essentially the mdf generated from the edid. That is now possible. However I suspect most deployment on this and (possibly except Pi) most other platforms will start with this edid data, but extend to other more customised modes for local reasons. I know for example that most of the mode def files provided in the panda and beagle based armini machines have been customised, typically by reducing the refresh rate, to make better use of the display channel. That may also require a better way for the platform to accept/tweak/reject modes.

Again, a huge thanks for your work, as it has saved me a lot.

John: apologies for the delay in it – it has bounced between the ROOL team, Jeffrey and myself for well over 18 months, much of the last year languishing in an effectively complete state!

Definitely need to have a look at the Apple EDID as that would be ‘unusual’. Having spent quite a bit of time studying I still find EDID very esoteric – I may still have missed nuances of the spec and things. I would be surprised and disappointed if the Apple monitor couldn’t do 640X480. Being 1.3 may make a difference (I only used 1.3 specs but unless I missed part of the compatibility that shouldn’t be an issue).

Hi

It is very definite.. to do the 640×480 it’ll need to do pixel repetition.. the screen is really simple.. 2650×1600 or 1280×800 .. up to the user ‘mdf’ to do the rest.
I’ll forward the edid

BTW 1 fault in what is currently in cvs .. the keyword interlaced, if used, has a spurious colon appended.. will deal with it in due course

herewith the apple cinema 30 generated mdf

# Monitor description file for Cinema HD
# Created by ScrModes 0.41
# (EDID specified modes only, no calculated modes)

# Max Viewable H 64 cm
# Max Viewable V 40 cm
# Line rate:     48 - 48kHz
# Frame rate:    32 - 23Hz
# Max Dot rate: 320MHz (rounded down)
# Uses Specific frequency pixel clocks
# Use GTF timing rules
#
file_format:1
monitor_title:Cinema HD

# Mode:  1280 x 800 @ 60Hz
# Bounds: H  49.31kHz, V 60.00, DClock 71.00MHz
startmode
 mode_name:1280 x 800
 x_res:1280
 y_res:800
 pixel_rate:71000
 h_timings:32,80,0,1280,0,48
 v_timings:6,14,0,800,0,3
 sync_pol:1
EndMode

# Mode:  2560 x 1600 @ 60Hz
# Bounds: H  98.53kHz, V 60.00, DClock 268.00MHz
startmode
 mode_name:2560 x 1600
 x_res:2560
 y_res:1600
 pixel_rate:268000
 h_timings:32,80,0,2560,0,48
 v_timings:6,37,0,1600,0,3
 sync_pol:1
EndMode
# EDID block dump
#
# 00 ff ff ff  ff ff ff 00  06 10 32 92  28 00 00 02
# 31 0f 01 03  80 40 28 78  28 fe 87 a3  57 4a 9c 25
# 13 50 54 00  00 00 01 01  01 01 01 01  01 01 01 01
# 01 01 01 01  01 01 bc 1b  00 a0 50 20  17 30 30 20
# 36 00 81 91  21 00 00 1a  b0 68 00 a0  a0 40 2e 60
# 30 20 36 00  81 91 21 00  00 1a 00 00  00 ff 00 43
# 59 35 34 39  30 31 36 55  47 31 0a 00  00 00 00 fc
# 00 43 69 6e  65 6d 61 20  48 44 0a 00  00 00 01 40
# 00 30 00 00  01 00 00 00  01 00 00 00  3c 55 6e 74
# 69 74 6c 65  64 3e 0d 00  00 00 00 00  57 4a 9c 25
# 13 50 54 00  00 00 01 01  01 01 01 01  01 01 01 01
# 01 01 01 01  01 01 bc 1b  00 a0 50 20  17 30 30 20
# 36 00 81 91  21 00 00 1a  b0 68 00 a0  a0 40 2e 60
# 30 20 36 00  81 91 21 00  00 1a 00 00  00 ff 00 43
# 59 35 34 39  30 31 36 55  47 31 0a 00  00 00 00 fc
# 00 43 69 6e  65 6d 61 20  48 44 0a 00  00 00 01 40
#
#End

(after following post suggestions!)

(I had to put a \ at line start to protect the #
I’d welcome guidance as to how to get the # at the line start )

Like this :-

# Monitor description file for Cinema HD
# Created by ScrModes 0.41
# (EDID specified modes only, no calculated modes)

Wrap the MDF within <pre></pre> tags, and leave an empty line between preceding text and the initial <pre> otherwise huge spacing erupts. See Forum Tests.

Or just use

#line with a hash

Thanks both .. the ‘pre’ tags will serve well. .. as amended earlier.

There is 1 bug in the output.. if the ‘interlaced’ keyword is used, it currently has a ‘:’ appended.. this is incorrect.. will be sorted later.