RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Bounties →

ReadEDID

Subscribe to ReadEDID 146 posts, 19 voices

Posts per page:

Pages: 1 2 3 4 5 6

 
Feb 8, 2015 4:19pm
Avatar Steve Revill (20) 1361 posts

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!

 
Feb 8, 2015 5:17pm
Avatar Chris Gransden (337) 1098 posts

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?

 
Feb 8, 2015 6:51pm
Avatar William Harden (2174) 244 posts

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.

 
Feb 8, 2015 7:39pm
Avatar Chris Gransden (337) 1098 posts

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.

 
Feb 8, 2015 8:08pm
Avatar William Harden (2174) 244 posts

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

 
Feb 8, 2015 8:34pm
Avatar Chris Gransden (337) 1098 posts

It doesn’t look like it made any difference.

I built the module with debug. The first bit gives

ReadEDID called
Checksum: Block 0 of 0 OK
0 EDID extension blocks found
Parsing EDID block

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

Standard Timing (e1 c0) (calculated):
XRes: 2048 YRes: 1152 (non-interlaced) PixRate: 197967
HSync:224 Hbpch:360 Hlbdr:0 Hdisp:2048 Hrbdr:0 Hfpch:136
VSync:3 Vbpch:36 Vtbdr:0 Vdispl:1152 Vbbdr:0 Vfpch:1

 
Feb 8, 2015 10:02pm
Avatar William Harden (2174) 244 posts

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

 
Feb 8, 2015 10:21pm
Avatar William Harden (2174) 244 posts

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!

 
Feb 8, 2015 11:13pm
Avatar John Ballance (21) 76 posts

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?

 
Feb 8, 2015 11:28pm
Avatar Steve Revill (20) 1361 posts

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!

 
Feb 8, 2015 11:36pm
Avatar John Ballance (21) 76 posts

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

 
Feb 8, 2015 11:37pm
Avatar Jeffrey Lee (213) 6017 posts

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.

 
Feb 8, 2015 11:43pm
Avatar William Harden (2174) 244 posts

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

 
Feb 8, 2015 11:51pm
Avatar John Ballance (21) 76 posts

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?

 
Feb 8, 2015 11:54pm
Avatar William Harden (2174) 244 posts

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.

 
Feb 8, 2015 11:59pm
Avatar John Ballance (21) 76 posts

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

thanks

 
Feb 9, 2015 12:08am
Avatar William Harden (2174) 244 posts

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

 
Feb 9, 2015 12:13am
Avatar William Harden (2174) 244 posts

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.

 
Feb 9, 2015 12:47am
Avatar John Ballance (21) 76 posts

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

 
Feb 9, 2015 12:51am
Avatar Chris Gransden (337) 1098 posts

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.

 
Feb 9, 2015 1:09am
Avatar William Harden (2174) 244 posts

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

 
Feb 9, 2015 1:11am
Avatar John Ballance (21) 76 posts

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

 
Feb 9, 2015 1:13am
Avatar William Harden (2174) 244 posts

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.

 
Feb 9, 2015 1:26am
Avatar John Ballance (21) 76 posts

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.

 
Feb 9, 2015 1:38am
Avatar John Ballance (21) 76 posts

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)

Next page

Pages: 1 2 3 4 5 6

Reply

To post replies, please first log in.

Forums → Bounties →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Discussion of items in the bounty list.

Voices

  • Steve Revill (20)
  • Chris Gransden (337)
  • William Harden (2174)
  • John Ballance (21)
  • Jeffrey Lee (213)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys