ReadEDID

John: Ideally (and if Steve is agreeable to it) we could do with a Test directory in the source tree to store challenging EDID data in the ScrModes source itself so anyone that wishes to make changes to the code in future has a set of different displays to check against (such as if we managed to do away with the FP code in there).

John: having a quick look at this before work. The fact the error has occurred would suggest that there is an EDID block and a checksum, both of which have been passed, but that one or more of the values is not what is being expected…

One of two likely errors:
- The v_timings value is > 0×10000
- The sync_polarity is >3.

Haven’t had chance to look at why either of those values may be large – would you know whether I’m right about either of those?

There are some terrifyingly large displays being connected to RISC OS kit on this thread!

Is it identifying the 2560X modes but the graphics driver for the Pandaboard is rejecting it as being out of spec? We validate all identified modes so if the driver won’t support it it will be rejected.

I may well be getting hold of the wrong end of the stick but I would hope that ReadEDID would report all the modes the monitor supported even if the computer hardware your on, can’t output them all. It would be nice if those not supported by the computer hardware were some how marked ‘*’ ?

When we did some EDID test as part of the A9home project we found many monitors who’s EDE did not reflect reality. Some monor like Monitor model number but also some missing the native resolution!

With an HP2229a monitor both the Raspberry Pi 2 and Iyonix fail :-

*ReadEDID
EDID checksum is incorrect (block 0 of 0 failed) - cannot read monitor settings
*

This is to be expected due to :-

Line 2739 of Sources/Video/UserI/ScrModes/c/ScrModes – change the ‘0×79’ to ‘0×80’. I think that is off by one. The line above the should read (if you would rather search for it): res = swix(OSCallAVector …

I cannot find any such line in BCM2835Dev.castle.RiscOS.Sources.Video.UserI.ScrModes.c.ScrModes

David: I think Textile ate the underscores in that post to make italics . Look up CallAVector – that should do it.

Chris: I hope the spec has matured in that time – many new monitors from then will be landfill now! Also there are some differences on how the systems work. On RISC OS 5 the graphics driver has the power of veto on modes. If someone wants to run outside the spec for the display hardware they should trick the driver to pass the modes. If you want to persuade the monitor to do something outside its spec you need to either edit the EDID (clearly preferably using a tool to do so) or write an MDF. The alternative is being complicit in allowing less OS-savvy users potentially overdriving the display or graphics driver (and no doubt being surprised when it doesn’t work).

It’s not enforced – people can always use MDFs in preference.

From a support perspective, with live machines in the field, I’d like to second John’s request/suggestion for the ability to produce a non-debug MDF dump. I can imagine instances where end users would enable EDID and be presented with blank screens or other such problems, and the only way to diagnose this would be to have some output file that could then be sent off for study.

I’m not exactly sure how one would best do this, but perhaps an additional *CreateMDFfromEDID filename would be in order? This would also allow one-off creation of MDFs, to reduce the time spent reading/creating at boot time. I can also imagine a situation where a user might wish to auto-generate the MDF, but select other modes within it.

For example, take the scenario of a chap with poor eyesight (extremely common in the RISC OS scene). They may well wish to run a 1920×1080 screen at (say) 1366×768 or 1600×900, but have the mode list created for their screen. Creating an MDF then allowing them to select what they want from it, would seem a very logical solution?

Textile ate the underscores in that post to make italics . Look up CallAVector

Thanks, found it now.

ReadEDID works in the Raspberry Pi 2, the desktop starts at the natural resolution of the monitor, 1680×1050, and the Display Manager shows most resolutions the monitor supports. Some weird sizes are missing, 832×624 1152×870 and 1152×900, perhaps reasonably so. Also missing is 1920×1200 which is listed in the manual and works from my conventional MDF.

David: 1900 X 1200 may be missing because of the settings in Config/txt: not in front of my Pi right now but the display limits are set in there. I changed mine (think there was a thread on the subject somewhere here) to increase the bandwidth limit and could get 2048X1152. Per my email to Chris the graphics driver has the power of veto over a given resolution.

Interested to see whether the weird sizes should be missing or not: it may be an extension blocks thing (see the other missing code above).. Could you rebuild with debug on and see whether it reports finding them (ie they were found and rejected) or whether they were not found?

Andrew: I don’t think that code actually belongs in ScreenModes though. We should separate MDFs as a predecessor to EDID from being a diagnostics tool – they are being used (understandably) as the latter when really they are the former.

I agree there is a need, but personally would prefer it if this stuff went into a separate module (‘SystemReport’ for want of a better name), which not just provided the display information but also provided other configuration details. ScreenModes isn’t the right tool to do that for you. Why a module? Well you would want it as part of the ROM in case there were serious peripheral issues, misconfigured filesystems, etc etc.

So – a part of that would be enumerating the available modes. Assume we had EDID as a CMOS configuration – so you can check whether a file was used or EDID. You would also want to know what the display’s preferred mode was, and what the configured display parameters were. Clearly you would then move onto the network configuration, available peripherals, etc etc. All in a single *command, rather than spread across multiple modules. It should also be used by the Configure or Switcher so the user can dump their system status from the desktop.

I changed mine (think there was a thread on the subject somewhere here) to increase the bandwidth limit and could get 2048X1152.

If that was gpu_mem then mine is already at 64, doubling it did not help.

Could you rebuild with debug on

That’s me rumbled then, I have to ask how. I am not a C person.

Hi William
I’ll add mdf creation as an option.. hopefully check something in later or tomorrow.
Added an optional parameter of file name to readedid command. If present it’ll save generated mdf to that file rather than doing its default loadmodefile action. Its not much extra code as you’ve done all the heavy work creating the modefile array.
As a support man, this IS needed. Experience often shows that platforms, in many arenas, do not always correctly react to a monitor’s best needs. A good example of this is the rather large number of mdf tunings Andrew, for example, had to make to make best use of the panda and beagle video systems.

(and, yes, it could be enclosed in conditional compile braces, BUT, in roms I have any responsibility for, it would be a normal element for the forseeable future.)

BTW the error I get on the apple monitor is in checking the return codes from the readiic bit. There are 2 possibilities: 1 is that my graphicsv iic returns the wrong data in (opcode I think), or 2 that you are expecting as defined a response that isnt. I’ll update you when I know the answer.

I uncommented this line and now I have the extra modes back including 2048×1152 @60Hz.
Do you still want the EDID block and debug output?

ReadEDID works in the Raspberry Pi 2, the desktop starts at the natural resolution of the monitor, 1680×1050, and the Display Manager shows most resolutions the monitor supports. Some weird sizes are missing, 832×624 1152×870 and 1152×900, perhaps reasonably so. Also missing is 1920×1200 which is listed in the manual and works from my conventional MDF.

I think the max resolution is restricted to 1920×1080 @60Hz by default. You can override it by adding the following or similar to config.txt.

William. In relation to the location of the mdf generator: it would be a bit foolhardy to put it elsewhere – it really needs to reflect what the edid parser on the machine is actually doing, so it needs to use the same code base, and ideally same actual code. Progressing well BTW. only uncertainty atm is the dpms state value which appears to be -1. as decoded for my monitor.

Chris: sounds like it is doing what is intended – namely the monitor did not specify it could do reduced blankings and the bandwidth restriction kicked in. I think the only question then is whether we are correct in forcing those checks for reduced blanking. the EDID would be useful – but per above it would be handy if they could reside in a Test EDIDs directory. Thanks also for posting the Pi Config changes – I can confirm that is what I have been using (successfully). Pi owners need to remember that the screen mode doesn’t actually change – it is scaled into the screen mode supplied in the Config file. ScrnSetup needs developing both to support EDID and to support Pi where needed I suspect.

John: yes that may be the issue, let me know.

I think Chris G’s results confirms my opinion that reporting the monitors full EDID would be very useful even if it is out of the platforms official capabilities. Though IIRC 2048×1152 is achieved on a Pandaboard without having to set anything other than MDF so AIUI it is ‘officially’ capable!

William
So far the mdf it produces seems OK except the dpms state is negative. will update further soon. OK. -1 understood. basically no account of dpms state deduced atm.

OK. Modification now in CVS. *readEDID behaves exactly as before. *readEDID $.mymdf will dump the calculated information as a mdf file $.mymdf instead of loading it to the video system. When all goes well this is un needed, BUT, in the real world this often isn’t the case; so the resultant file will show what information was generated in a form that can be tweaked if needed, and used as a replacement mdf.

First attempts on a known troublesome monitor, a recent 24inch dell, produced a 1920×1080 mode that wouldn’t display. Customer has already emailed me the mdf that resulted.

in a form that can be tweaked if needed, and used as a replacement mdf.

This is good, into the ReadEDID generated MDF I can add the 1920×1200 mode that my 1680×1050 monitor will accept but does not show up in ReadEDID and more importantly the 320×256 mode that Hopper requires can go into it as well. Using the generated MDF conventionally avoids the problem of Screen Setup stamping over the PreDesk Monitor file. That’s a win win for now. Thanks.

John: I assumed that what William was getting at with the ‘location’ of the file writing code was more along the lines of how writing out a diagnostic file is a wider problem than ScreenModes. Perhaps the ideal scenario would be for components like ScreenModes to store ‘status output’ somewhere in RAM, and a separate utility (module?) could collate and display it all, as one ‘super diagnostics’ command. Imagine a much-enhanced version of *Status, with an option to log to file.

Presumably there is a whole boatload of stuff that would be useful in a single ‘support log’ file? Scope creep, eh? :)

Just run the EDID creation on my test monitor, a very flexible (arguably the most flexible I’ve seen) Asus gaming screen from some years back, and had some interesting results. Most modes were usable, but there were several anomolies…

Background – monitor is native 1680×1050 screen, but has an understanding of 1080p over both digital and analogue feeds (it has RGB component input for games consoles etc). Normally 1080p is offered by Windows (without additional driver), but with 1680×1050 highlighted as “default res”.

1) Maximum resolution offered was 1680×1050 at 60hz – 1080p was not listed, but usually is on other OSs.

2) 1680×1050 was offered at 60hz twice with different sync polarities. Note that since RISC OS selects mode by resolution and refresh rate, having two 60hz modes defined is effectively bad behaviour, as there’s no way to pick which is used.

3) Two modes were identified that could not be synced – 1400×900×75hz and 1024×384@115hz. I’m thinking the latter is an error. The former looks OK, but doesn’t sync.

I’m wondering if it would be useful to include a hex dump of the EDID in the MDF that’s output. That way if someone uses *ReadEDID to produce an MDF and spots something suspicious they can easily copy & paste the EDID into a bug report or something.

2) 1680×1050 was offered at 60hz twice with different sync polarities. Note that since RISC OS selects mode by resolution and refresh rate, having two 60hz modes defined is effectively bad behaviour, as there’s no way to pick which is used.

I don’t think that will be a major issue. The monitor should be able to display the modes equally well. And if the video hardware only supports one of the modes, it should reject the other one as part of the GraphicsV VetMode call – which will mean that the user won’t even know it exists.

However, I do think that Service_EnumerateScreenModes might need updating in order to make sure duplicate modes are filtered out of the results. Otherwise the display manager, screen setup plugin, etc. might end up reporting identical modes.

3) Two modes were identified that could not be synced – 1400×900×75hz and 1024×384@115hz. I’m thinking the latter is an error. The former looks OK, but doesn’t sync.

That 1024×384 mode could possibly be an interlaced mode? ScreenModes should be parsing the EDID for that correctly (or at least it was when I last tested one of William’s betas), but it doesn’t look like the MDF save code is saving out the interlaced flag when appropriate.

Andrew: that may be because an extension block was used – note the To-Do at the start of this thread that isn’t in the checked-in code.

1024X384 = 1024 X 768 (interlaced).

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).

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.