ReadEDID

We’ve just pushed some prototype code for automatic monitor configuration into CVS. If you’re feeling brave, please give this a test (as described in the commit log) after the next nightly build rolls along. Cheers!

Using ViewSonic VP2770-LED connected via DVI to a PandaboardES i get,

*readedid

EDID checksum is incorrect (block 0 of 0 failed) – cannot read monitor settings

*

Will the entries returned be CVT timings with reduced blanking?

Think it may have been to do with some changes that were made to the code pre-submission which I hadn’t managed to check (ironically couldn’t use EDID myself when checking it so was using soft loaded EDID data).

Could you try the following:

- 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 …

Looks like we’re reading 127 bytes rather than 128.

That did the trick. Thanks.

The mximum resolution I end up with is 1680×1050 @60Hz. The monitor is capable of 2560 × 1440 @60Hz. Is there any way of forcing it to use reduced blanking.
Without this it doesn’t allow 2048 × 1152 @60Hz which I was using before. I believe the maximum pixel clock on the Pandaboard ES is 186.0MHz so the reduced blanking version which has a pixel clock of 156.75MHz is well within the limits.

ARGH! Yeah. The monitor I was using was fairly ancient, so most recent testing was all done with soft loaded data – this is another shortfall in the same function as the earlier change.

Those mode definitions will probably reside in an extension block. Whilst we handle extension blocks when the data has been soft loaded, we didn’t fix the TODO to read it from the actual monitor.

Slap bang on line 2777 is the TODO for this .

NB this is completely untested. Replace:

2777 with // Reload EDID data including extension blocks

Add below that (2778):
if (!res) {
iic_opcode = (0xa1 << 16) | (0 << 0); // Reset the iic_opcode
op_code = (0 << 24) | (0 << 16) | (14 << 0); // Reset the op_code
res = _swix(OS_CallAVector, _INR(0,2)|_IN(4)|_IN(9)|_OUT(0)|_OUT(4), iic_code, edidblock,128 * (edidblock->extension_block_count + 1), op_code, 42, &iic_code, &op_code);
if (iic_code != 0) {
res = error (iic_code, 0, 0, 0);
}
// OP code not checked as it should have failed with the earlier call
}

I hope what that should do is that if you’re lucky enough to have a monitor which supports extension blocks, it should reload the full EDID including all extension block data.

The extension block support is all in there, so if the definitions are there in the extension blocks we should be able to look at them.

Edit to try to make the code look more readable using Textile

It doesn’t look like it made any difference.

I built the module with debug. The first bit gives

It also picks up the screen mode but not with reduced blanking.

Chris: Would it be possible to upload the actual EDID and the debug from a taskwindow to somewhere?

To fetch the EDID, basically do line 2739 in BASIC or C, but set up a data block of 128 before it and then just save the block out. You should be able to load the block in afterwards using *LoadModeFile (just as you would an MDF file). It would be doubly helpful to also do the same with 256 bytes to check we’ve not got an extension block which is failing to be recognised for some reason.

The resulting file should be loadable using *LoadModeFile – ScreenModes now reads raw EDID data as well as MDFs. So effectively my side I can check which modes your display is reporting (although obviously I can’t change into them – just check that it registers them and that the outputs are correct).

Chris: just thinking about this…

Firstly I’m presuming you are using the DVI/DisplayPort connection on the display. Only asking this as an EDID from a monitor I was given to test a while back had different EDIDs for different ports. It’s worth experimenting with the other ports if only to see if the EDID differs.

Secondly – does the monitor definitely support reduced blanking? It states it ‘does’ 2048X1152 on the D-Sub port, but that doesn’t mean it has reduced blanking and normal modes defined in EDID (or that it supports them if they are).

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.

You will see in the code (since I’m presuming from the above you’ve had a rummage!) that we can calculate CVT-RB if the monitor will support a resolution that is not one of the pre-defined ‘standard’ modes. You can also edit the EDID to ‘add’ modes if you think the monitor supports it but the EDID doesn’t (warning – do so at your own risk!) So it’s possible that the monitor will do a reduced blanking version but one was never defined. Need to prod the data really to find out!

This ‘stuff’ is excellent news.

I had noticed the initial read should be 0×80 rather than 0×7f. It has produced a mdf that only seems to contain 1 non working mode. I then thought… wouldn’t it be nice if there was an option to save out the generated mdf file, rather than softload it. (or have I missed something?)

Incidentally, would it help if I put back the length mod into cvs…? or has it already been put back?

If anyone is going to check things into CVS, please try to stick to some ground rules. If you do any of the things below, your submission is likely to be rejected:

• C++ style comments in C code (unless there are already loads in the file)
• Tabs for indentation (unless that’s what the file already uses – unlikely)
• Any indentation that doesn’t match the surrounding code (number of spaces)
• Inconsistent positioning of opening { – same line vs next line
• if () without the following statement in a { } block
• Short line wrap – assume you can fit 140 characters on a line, don’t wrap at some tiny screen width; it’s 2015 not 1995
• Anything that’s poorly commented
• Other stylistic issues (e.g. incorrect case of ARM code compared to existing code in the same file)

ROOL will be starting to reject submissions that commit crimes such as those listed above and we’ll take a dim view of people with direct CVS access doing the same. I’m planning on publishing a guidelines page somewhere. The simple, obvious rule is: stick to the style of the code that you’re modifying!

Thanks Steve.. Previous comments already noted
BTW.. the 1 glaring error in this code atm is the initial read length being 0×7f instead of the 0×80 required. Without this change what goes in the nightly build is useless. Are you looking after this, or would it help if I put it in?.. (no.. keep out is an acceptable answer!!)

I’m planning on publishing a guidelines page somewhere.

Yes please! I’m sure there’ll be at least a couple of rules that I break on a regular basis.

John: 1 non-working mode is still 1 too many: interesting to know what it was and why it’s failed! Is it a mode defined in the specs for the display? Do you see it when the display is plugged into anything else?

I may not be clear from the stuff above what it’s doing. You don’t need to ‘softload’ it: *ReadEDID just replaces the *LoadModeFile line in PreDesk as a simple *command in the ScreenModes module which says ‘read the EDID from the monitor’ instead of loading the MDF file. No files are generated. So you can use it on a machine without a !Boot file – EDID just isn’t part of a default startup because a lot could go wrong if we assumed it always worked without the benefits of wider testing! Clearly if it was deemed ‘safe’ then using the EDID could be the ‘default’ and probably something configurable/CMOS-based. However, with the breadth of machines, ports, displays etc out there, it is not wise to start from there until any ‘gotchas’ have been found. Hot plug support is there for displays which should support it; but for those who really shouldn’t hot-plug you can also change the display, and then re-issue *ReadEDID from CLI to read the new display’s data.

We don’t yet use the preferred mode – that would be needed in ScrnSetup.

What I was intimating above was that you can also ‘save out’ the EDID data for a particular purpose (or just for testing/inspecting other monitor definitions!), so that machines or adaptors which don’t have the means to read EDID can also use it, without having to generate an MDF. eg. if you wanted to connect up a panel which has an EDID block via the Pi’s GPIO pins, you’d need to load the EDID data manually for your display. EDID is far more comprehensive than the defined MDF. You could also use it if you for some reason wanted to persuade the monitor to do things that its ‘built-in’ EDID data has not defined (ie. if you think there are modes you monitor will display that the manufacturer is not reporting).

Hi William
I was actually working on this sort of stuff.. so the arrival of your offering is most welcome.
I agree about 1 is too many. Since I’m active in the iMx HAL and video I need to be sure that the ‘non working’ is real, not a result of my sums going wrong.
So, if for no other reason than diagnostics it would be so helpful to have this code optionally save out an mdf instead of actively loading it. Reading raw EDID stuff is no problem. What I did want to see was the result. If it has passed through ‘loadmodefile’ the mdf detail isnt visible. (or is it?).

How about giving the readedid command an optional parameter of filename to save the generated mdf out as?

John: Check out ScrModes and try turning debug on in the ScreenModes source. Then just call *ReadEDID again from a Taskwindow.

The debug is enough to basically give you an MDF file (not quite laid out as an MDF but not too far off). You can see a sample of it from Chris Gransden’s posting.

Hi. already did that. Request still stands. (happy to make the mod, but don’t want to tread on toes)

thanks

Chris: just looked up the debug stuff in the source: I suspect ScreenModes is doing its thing correctly (whether the EDID block is right or not is another story!) It declared it could do 2048*1152, but it didn’t use a standard timing, and it didn’t provide the timings itself – so ScreenModes has generated the timings for you (hence the (calculated) in debug).

However, from my understanding of the EDID specs, for a monitor to support reduced blanking it should have a Display Range Limits block, and within that is a timing support flag to indicate whether it supports reduced blanking. I am presuming from the fact it chose not to use the reduced blanking (which it does preferentially if it is able to do) that it calculated the timing using CVT only based on that.

If my understanding of that bit of the spec is wrong that is easily reviewed. Equally this can be tested by editing the EDID data file (check table 3.28 of the EDID spec – Display Range Limits & CVT Support Definition).

Edit: OR – you could just search and replace EDID_USE_CVT with EDID_USE_CVTRB which effectively will ensure that it never uses CVT and only uses CVTRB for calculated modes. Warranty void etc etc ;-).

John: Feel free. Would suggest putting it on a switch with default of off though simply because from a user perspective we should be encouraging people away from using MDFs and towards a plug-and-play solution. I can certainly see the benefit in cases such as yourself – but it should be an edge-case situation.

Hmm – I do see where you are coming from. As someone who has had to support the riscos platform for many years, when plug and pray goes wrong it is extremely useful to be able to extract relevant support info.

As of now, having built in the new screenmodes to rom, it produces an abort during module initialisation at offset 2088 in screenmodes. (that is after having corrected the byte count.) It does load if it cannot proceed past the initial read with incorrect byte count. Its somewhere around what looks like floating point stuff (looking at the assembler – I’ll need to look further though).

I just did a quick test on the Raspberry Pi 2 and all the extra modes past 1680×1050 appear. Even 2560×1440 appears in Display manager although it gets scaled in 2048×1152.

John: Is that a module order thing? In the ROM build the intent was ScreenModes had to live beyond the FPE module because there is a small amount of floating point in there (I tried to get rid of it but tracking down maths errors across the four sets of mode timing calculations was neither fun nor successful).

That makes sense. In my rom screenmodes is rather early as there is stuff that appreciates it. I’ll investigate. Thanks

Chris: then the limitation is probably a bandwidth restriction on the OMAP’s graphics driver – the other modes will be being chucked out as undeliverable by the hardware. The scaling will be because on the Pi the firmware actually dictates the screen size; RISC OS merely scales into the display. So on a Pi for best results you set the screen mode in the config/txt as well as in the DisplayManager. That said you certainly can display 2048*1152 on a Pi (I do this on my Pi model B). Not tried 2560X1440 but I believe that’s possible too at some resolutions.

Well done. Moving fpemulator to before this sorted it. I wonder.. would it be wise for it to not attempt anything that reacts with the outside world till after the whole rom has initialised?

A reason for this Q is that in one of my setups readedid gives inconsistent parameters for mode ‘%1’ in file ‘%0’. I happen to know that the edid returns all nulls wired as it currently is. The one thing I really like to avoid is anything that could possibly error before the rom has finished booting.

with the monitor connected directly (apple cinema30) it gave Overlarge value for parameter at line ‘%1’ in file ‘%0’ and left the display in a state it wouldn’t recover from. I have the edid data.. would you like a look?, if so, how do I get it to you (or mail me jwb at rosery.net)