EDID discussion

Just checking mode vetting: Jeffrey, am I right in thinking that you built screen mode vetting into ScreenModes already (line 1738 of screen modes.c, in the mode_valid function)? If that is functioning correctly, then EDID modes are already being vetted since I pass them on just as if you’d read the MDF file in.

I say ‘if functioning correctly’ because my modes-that-don’t-actually-work that I fed to the Panda weren’t dismissed. Which makes me wonder whether that’s because the Panda wasn’t mode-vetting. All the modes on my monitor are supported by the Pi; I haven’t tried feeding it nonsense values to see whether they would appear on the mode list after all.

It wasn’t me who put it there, but yes, ScreenModes does already do mode vetting.

The panda does have mode vetting code, but there’s no guarantee that it’s bug-free.

Can’t you fake it now if you don’t need it? Unplug the DisplayManager module?

Gold star for pointing out the zero effort solution to Steve’s ideal.

Never underestimate the creative ingenuity of lazy people. ;-)

Right – update from tonight.

I now have EDID working with reduced blanking timings on both the Pi and the Panda (using nice tidy code).

My timings are appear correct according to the EDID spreadsheet. Tested only on one monitor so far; will take the Panda on tour around the house in the next few days to check on the other TVs in the house.

Reduced blanking timings means EDID will not work on a CRT monitor. However – if you have a CRT monitor using HDMI then I suspect you’re in a small minority. For that very small minority, I will accept them having to use MDFs I am afraid for the additional ‘fun’ (for a variable value of ‘fun’) of trying to support GTF calculations.

That should just leave updating the plugin to be done now :-).

I should point out that the reduced blankings seem to also work quite nicely for my HDMI→VGA adaptor. The reduction in bandwidth appears to have removed the ‘judder’ I was seeing on the Panda at 1680X1050 (it is still there at 2048 X 1152).

Two Pi specific question William:
1. Are you able to ask the GPU if no HDMI monitor has been detected and therefore use a PAL type mode or do you assume PAL type monitor if EDID does not respond at all?

2. Not really in the remit of the EDID bounty but are you planning on addressing the following?: AIUI at present unless an entry config.txt commands otherwise the Pi GPU will always output at the screens native resolution, scaling any other resolution.
Presumably the aim is to be able in the screen manager change modes to one that EDID says the monitor supports and for the GPU to be instructed to change its output.
This would then rely on the monitors built in scaling which may or may not be better than GPU’s.
Having written that I’m now wondering what if any other advantages there may be. ¹
From what Jeffrey wrote last week about talking to the GPU adding that support is not trivial and those able to do probably have other priorities.
¹ I think I know one scenario: we have a 2048×1152 monitor, the Pi’s GPU seems to recognise it as the monitor reports it is receiving 2048×1152 but it is displayed truncated at 1920. (I think this is a firmware problem on the Pi and have raised it on the forums but got no response.)

Chris: define what you mean by ‘PAL-type’.

EDID is simply a set of data obtained from the monitor providing timings and supported mode descriptions. A monitor can either provide it – or not. Most monitors produced this century do – the spec we are using dates to 2003 (earlier specs were present before this which are broadly compatible).

If the monitor can’t produce EDID or produces duff data, the *ReadEDID command will realise and fail with an error. You can still use *LoadModeFile for these devices. HOWEVER EDID is mandated on the HDMI spec so devices which cannot do this on ‘current’ hardware will be limited. RPCs are the only OS 5 machines which cannot read EDID or who might use monitors which don’t provide it. If the monitor provides it but it cannot be read, *LoadModeFile will also take raw EDID data instead of the textual MDF..

2048*1152 looks like a firmware issue to me. The mode is stable (and works on the Panda) but the same mode fails on the Pi. So not a RISC OS-end issue. It’s either firmware or HAL (the former most likely but I have not had chance to test on Linux).

It will not change low level graphics handling on the Pi at all – the Pi’s firmware has much more control over the display than on the other devices. However it will offer you all the screen modes that are appropriate for the monitor on a Pi. Change to that resolution and the Pi’s firmware matches the screen to the nearest one it knows (in practice since it too uses EDID these should be identical), and then displays.

Chris: define what you mean by ‘PAL-type’.

1V composite: Video: RCA Video: the output from the Pi’s Phono socket. Choose your own definition.

Ah – I get you. A device plugged into the RCA phono socket, rather than into the HDMI port?

The distinction between which socket is in use is at the HAL layer. My changes are all within the ScreenModes module, so my code is reliant upon the HAL. In that sense the code is interface-agnostic: it doesn’t care what the interface is – if the display driver supports the necessary call to read EDID, we do so.

We also don’t yet do multiple displays (ie. one on RCA and one on HDMI, or indeed both HDMI ports on a Panda); I am sure this is something that will appear on the ‘Roadmap’ in due course however. ScreenModes will need a reasonable reworking to support this (hopefully my changes have not added significantly to the complexity of that task).

I’ve not tested anything attached to the RCA phono socket. In principle – if it works and sends EDID data as display 0 then EDID will work on it. Otherwise – it will need hardware support.

I’ve not tested anything attached to the RCA phono socket. In principle – if it works and sends EDID data as display 0 then EDID will work on it. Otherwise – it will need hardware support.

… I think some devices can ‘tell’ if there is a video connection to the composite. But EDID? How d’you plan to extract that from a dinky little ’80s era monochrome monitor? ;-)

[yikes, the AKF10 appears to be unknown to Google! I ought to dig it out, take some photos, show it some love]

William: I’ve made a couple of improvements to the GraphicsV code. In particular, the kernel now issues ROL’s Service_DisplayChanged service call when the current driver changes, which means there’s now also a bit of code in ScreenModes to listen out for that service call and act accordingly. Feel free to modify it however you need in order to get automatic EDID reading hooked in cleanly. E.g. if your EDID code always ends up issuing Service_ModeFileChanged once EDID has been read then it probably makes sense to update the Service_DisplayChanged handler so that (for non-EDID use) Service_ModeFileChanged is issued when DisplayChanged_Changing is received rather than the DisplayChanged_Changed. That way the timing of the service calls will be the same for EDID and non-EDID cases. The reason I currently have it in DisplayChanged_Changed is just as a small optimisation so that it doesn’t get issued multiple times if the new driver fails to start for some reason – if a driver fails to start then you’ll get two ‘Changing’ messages back-to-back where the kernel tries one driver before giving up and trying another.

Also one thing that might catch you out with the current implementation is that the ScreenModes_servicecall function will do nothing if there’s no MDF/EDID loaded yet – which won’t be very useful if the module is waiting for Service_DisplayChanged so that it knows it’s a good time to read EDID. So you might need to tweak that logic a bit so that it handles Service_DisplayChanged irrespective of whether any modes are loaded.

Jeffrey: Thanks. I had seen a bunch of changes coming through the ROOL front page today! I’ve just finished the office move (and swapped my primary PC in the bargain), so I’m back to trying to put DMT and then GTF support in. Will give you a shout when this is done.

Incidentally – is the OMAP3 port behaving correctly? Rick raised an issue with Beagleboard raising an error when reading EDID. I have a suspicion like OMAP4 that the status flags aren’t being reported correctly (OMAP4 was updated for this, I wonder if OMAP3 still isn’t?)

Looks like I’ll have to play catchup slightly on ScreenModes too.

Incidentally – is the OMAP3 port behaving correctly? Rick raised an issue with Beagleboard raising an error when reading EDID. I have a suspicion like OMAP4 that the status flags aren’t being reported correctly (OMAP4 was updated for this, I wonder if OMAP3 still isn’t?)

OMAP3 and OMAP4 use different builds of the same driver, so OMAP3 should have had the bug squashed at the same time as OMAP4 (about 7 weeks ago judging by CVS). And it’s a BB-xM I would have used to test it before checking it in.

so OMAP3 should have had the bug squashed at the same time as OMAP4 (about 7 weeks ago judging by CVS).

Known bug. Okay, I’ll update my build; though it might be interesting to see if it is possible to modify the EDID program to fail gracefully on older systems – isn’t there a SWI to read OS tags to get the build date?

isn’t there a SWI to read OS tags to get the build date?

You can use OS_ReadSysInfo 9 to get the build date as a string. Maybe we could do with some way of getting it as a 5-byte time as well.

Although really what you’d be interested in here would be the name and version number of the GraphicsV driver. You can use OS_ScreenMode 68 to get the name of the driver, but I haven’t hooked up anything to get the version. I’ll add that to the todo list!

Also the bug was only introduced in December, so there aren’t any stable versions of the OS which suffer from it. So making sure the EDID code is compatible is technically a non-issue as we aren’t required to make sure software contains workarounds for bugs that only exist in the odd-numbered development OS versions.

Rick: At least that one’s solved then. No need to test the OS version – EDID support is simply an expanded version of ScreenModes and will be part of the ROM build. If post-release someone wants to run a new module on an older version of the OS then they are expected to be on their own!

For reference: DMT support now built into my copy; just working on GTF support at the minute.