EDID discussion

William: Jeffrey gave more detailed info re Beagleboard GPU in this thread: https://www.riscosopen.org/forum/forums/5/topics/451

Steve: I have put into the last code drop a build switch using the inbuilt values versus the calculated timings. I will probably resort to using DecodeEDID’s calculations in another switch.

I am now looking at validation. If I am passing a Type 3 mode block to GraphicsV, should I just get it to validate all modes (both MDF AND EDID) rather than just EDID? I’m thinking the code belongs in build_a_vidc_list (or immediately before it) rather than in the EDID parsing and it makes things much more consistent. However – do we need a mechanism to overrule the checking? Where should that e implemented? My thoughts are any override should be provided through GraphicsV rather than through ScreenModes. Will look at the comments earlier on validation.

Steve: overall there is no rush to check in EDID (code sent in case you wanted to put intermediate code into CVS and also so that if others want to look at it they can) – mode validation may be a useful add-on to ScreenModes so when done we might want that checked in separately – it will help spot any issues with mode validation etc using MDFs to begin with.

If I am passing a Type 3 mode block to GraphicsV, should I just get it to validate all modes (both MDF AND EDID) rather than just EDID?

That sounds OK to me.

However – do we need a mechanism to overrule the checking?

No. If the driver says it can’t handle a mode, then it can’t handle it. Asking a driver to enter a mode which it says it doesn’t support could result in all hell breaking lose.

I was thinking circumstances such as overclocking to permit additional modes. I agree protections should be in place for the unwary, but am aware that the subject of restrictions have come up before.

Also – any ideas what may be going on with 2048×1152 resolution? It should be supported (in reduced blanking). It displays but has a right border. The desktop is visible but the far right (including all the switcher icon) is missing. I had thought this was a timing issue but it appears not based on your comments above.

The default at present appears to be 1080p but letterboxed around what I suspect is 2048×1152.

I was thinking circumstances such as overclocking to permit additional modes. I agree protections should be in place for the unwary, but am aware that the subject of restrictions have come up before.

Ah, OK.

If we were to allow overclocking then it would probably have to be controlled via a separate GraphicsV call, or via some other driver-dependent interface. Then the driver can adjust its vetting so that it will accept the wider range of values. But this isn’t something that ScreenModes should need to worry about – it still has to vet the modes to make sure there aren’t any other problems the driver knows about.

Also – any ideas what may be going on with 2048×1152 resolution?

No idea! Does it work correctly under Linux?

Also – any ideas what may be going on with 2048×1152 resolution? It should be supported (in reduced blanking). It displays but has a right border. The desktop is visible but the far right (including all the switcher icon) is missing. I had thought this was a timing issue but it appears not based on your comments above.

I suspect this is the same issue as reported here

Any objections to adding a ‘preferred mode’ field into the MDF file? I say this as it’s so obvious I’m a little curious why it doesn’t exist already! We may need a SWI to return the value from ScreenModes (whether read by MDF or by EDID) – advice on a sensible structure for that data appreciated to keep it in line with similar structures. This code should go into ScreenModes because ScrnSetup for example is getting all its mode data from ScreenModes – it doesn’t do any parsing itself (and this is sensible).

I will need some help from users with monitors with ‘known’ MDFs to retrofit some sensible default values into our existing MDFs (the default will be a preferred mode of 640X480X60 if no preferred mode is supplied – but doing a quick lookup for each of the monitors in the MDF folder and adding X,Y,Frame rate shouldn’t be too difficult). Preferred mode will be ‘highest possible colour resolution at the mode the monitor says it wants.’ (whilst you can specify colour depth in the MDF you cannot in EDID, so guessing for both is consistent).

Just looking at ScrnSetup last night – EDID and MDFs should really be treated as equals. I’m using a flag in ScrnSetup at the moment for EDID (versus MDF); but if we decide it’s stable enough this can become a monitor type in its own right later on and some code stripped out very easily.

Any objections to adding a ‘preferred mode’ field into the MDF file?

That sounds fine to me.

We may need a SWI to return the value from ScreenModes (whether read by MDF or by EDID) – advice on a sensible structure for that data appreciated to keep it in line with similar structures.

I think there are three choices available:

1. Return a block in the same format as Service_EnumerateScreenModes (except it would just be one mode in the list). This may entail creating two forms of the SWI (one to read the block size, one to get it) – or I guess you could store the block inside ScreenModes’ workspace and just return a pointer to it.
2. Don’t add a new SWI, but instead just make use of one of the flag bits at +4 into the Service_EnumerateScreenModes block. However this would be a bit messy for something which simply wants to find the preferred mode (it would have to allocate a block large enough for all the modes and then search through it)
3. Return a (pointer to a) mode specifier block. One of the problems with the Service_EnumerateScreenModes block is that there aren’t any other OS APIs which use data in that form – ScrnSetup and the display manager have to parse the data manually. However mode specifier blocks are supported by pretty much all mode-related APIs. So using that format would simplify things greatly if preferred mode support was added to the kernel (e.g. for when the configured mode is set to ‘auto’)

I think I’m leaning towards option 3 as being the best, as it’ll be the easiest for most software to work with. And from looking at the sources, I don’t think it’ll matter much to ScrnSetup what format the data is in – ScrnSetup only tracks the X/Y/Hz/colours of the selected mode, which is all data which can easily be extracted from any of the block formats.

or I guess you could store the block inside ScreenModes’ workspace and just return a pointer to it.

I’d avoid introducing any new APIs that work in that way because it just makes things even more difficult if/when we make RISC OS do multi-core or multi-threading or pre-emptive multi-tasking. In fact, it’d probably already be unsafe – if you called the SWI from a BASIC program running in a task window, for example, and someone else called the same SWI from somewhere else just after the BASIC program has been pre-empted away from.

I’d expect the block to be static until something causes ScreenModes to rebuild its mode list, so it should be relatively safe. But I take your point!

Although really if we’re talking about making things thread-safe, then instead of requiring two calls (one to read the block size, one to read the data) then it should just be one call which allocates a buffer and returns it to the caller (for the caller to free later on). That way it’ll protect against anything which affects the data size inbetween the two calls (e.g. someone being lightning fast and connecting a different monitor)

Although really if we’re talking about making things thread-safe

I think it’s probably a good idea to at least consider that when introducing new APIs; there’s no point making future work (which seems more or less inevitable) even harder than it already is (almost impossible ;).

Surely you have to do a block size call and fill block call for variable sized data if the data is sat in the RMA? If you use RMA workspace the block will be reallocated or moved if the module is reinitialised or moved between subsequent calls to the data block. This is Ignoring, of course, the other elephants in the room surrounding the RMA as a whole as a memory area.

Those were the two structures (1 and 3) I had in mind Jeffrey: I’m inclined to go with 3 as well. Adding a ‘preferred mode’ to the MDFs at least gives consistency but the likeliest other use case is setting up the mode so a mode specifier makes more sense. For ScrnSetup the block format is irrelevant which is why I asked the question (other uses would actually care what the blocks look like!)

Are there any MDFs in the HardDisc distribution where the preferred mode isn’t the highest available?

Another question: at present we are heavily adapting ScreenModes, which was so called because it had a single purpose (to set up Screen Modes).

A complete implementation of EDID doesn’t purely do that: it can also manage colour modelling and also audio properties for sink devices. If we utilise those properties, we should be doing that integrated into the same module (as they are also susceptible to hot plugging and rely upon EDID data). Colour models aren’t as relevant as the audio settings here. Technically this would make it a DisplayManager (but clearly that name is taken!) Audio settings for the device would seem odd residing in ScreenModes.

Should we be looking to rename the module when we release the update to better reflect its purpose? I ask before it gains any SWI calls which may make that process much harder. The only client I am aware of which cares about the name is ScrnSetup (which instantiates the module to get configured settings separate from the settings in use.)

Surely you have to do a block size call and fill block call for variable sized data if the data is sat in the RMA?

Not necessarily. The SWI could calculate the data size, allocate a buffer, copy the data into it, and then return a pointer to the caller. Then once the caller’s finished with the data he can free the memory himself. That way the module can implement its own methods for making sure the data doesn’t change between the ‘get size’ and ‘copy data’ stages (i.e. by wrapping everything in a mutex)

Are there any MDFs in the HardDisc distribution where the preferred mode isn’t the highest available?

No idea.

It’s a bit of an odd subject, really; with modern machines we’d be aiming for everyone to use EDID for getting their mode lists, so setting a preferred mode in the MDF doesn’t matter. But for old machines (IOMD) directly using EDID isn’t possible, so they’re likely to be using an MDF. But IOMD also has the least amount of VRAM available, so assuming that the preferred mode is the one with the highest resolution might not make that much sense from the user’s perspective. On a machine with 2MB of VRAM the preferred mode for a monitor might give a perfectly usable 256 colour display, but on a machine with 1MB of VRAM you’d be stuck with a much less useful 16 colours.

So I’d be tempted to say that you should skip adding preferred mode information to the existing MDFs. Or maybe make it so that ScrnSetup will only offer the preferred mode to the user if it has a sensible number of colours for desktop use (i.e. 256+)

Although I guess it’s only seasoned RISC OS users who will be running RISC OS 5 on IOMD, so if the preferred mode actually gives them something that they feel isn’t usable then they should have the know-how on how to select a mode manually. Unlike your average joe who tries the Pi NOOBS distro for the first time and might give up or not know how to fix things if the OS gave them a useless display on startup.

Should we be looking to rename the module when we release the update to better reflect its purpose?

Renaming it will make the ScrnSetup plugin a bit more complicated, as it would have to detect which of the two modules is present (At the moment the plugin will work as far back as RISC OS 3.5, and ideally we’d want to keep it that way). Plus anyone who softloads a new ROM without updating their disc image first would be stuck without a working version of the plugin.

So for the moment it’s probably left as-is; if we decide to split off EDID handling into a separate module later on then we can easily make it so that the EDID-related SWIs in ScreenModes simply call through to the new EDID module.

someone else called the same SWI from somewhere else just after the BASIC program has been pre-empted away from.

…and? If it is a block of read-only data in some workspace somewhere, asking the OS for the same thing twice would surely result in two pointers pointing to…the same thing?

Are there any MDFs in the HardDisc distribution where the preferred mode isn’t the highest available?

I don’t know where my MDF came from, it calls itself “Generic” and it lists a selection of resolutions, the smallest being 640×480, then there is an 800×480 Pandora, the largest “normal” mode is 1920×1080, while the biggest mode in the MDF is called “2560×1440 RPCEmu”. This causes the Pi to have a nervous breakdown (the GPU will happily scale down FullHD to my configured monitor size, but select the huge mode and there’s no sensible video output which persists across resets (until the Pi is powered down and back up)).

Frankly, I would have thought that the logical “preferred mode” would be determined in tandem with EDID to read what the native monitor size is…?

Unlike your average joe who tries the Pi NOOBS distro for the first time and might give up or not know how to fix things if the OS gave them a useless display on startup.

With this in mind – and I can hear screaming already ;-) – could we have a “hotkey” like “press F2 twice” when in the Desktop to toggle between whatever the OS thinks is good (would probably eventually be the detected monitor resolution), and a “sane default” (like SVGA 800×600)?
Why?
To quote from the NOOBS documentation: Display Mode Selection: By default, NOOBS will output over HDMI at your display’s preferred resolution, even if no HDMI display is connected. If you do not see any output on your HDMI display or are using the composite output, press 1, 2, 3 or 4 on your keyboard to select HDMI preferred mode, HDMI safe mode, composite PAL mode or composite NTSC mode respectively.

I have not used NOOBS much. Decided Raspian Wheezy didn’t do anything exciting, tried RaspBMC, haven’t looked back. But the times when I went to NOOBS, I needed the hotkey to get something to appear on-screen.
In the same line of thought, might it be a good idea to have a similar sort of facility within RISC OS? This could be provided by DisplayManager (with a configurable OFF for people who would prefer their F2 key to do nothing by default ;-) ). Trapping the double-press is not hard. First press sets a flag and a callback (say 80cs?). The callback, if triggered, would clear the flag. The second press, if the flag is set (means key pressed twice quickly) will do the action. This shouldn’t interfere with programs as when they are running, they will see the F2, not the DisplayManager.
This may help people who see “nothing” to see something. ;-)

could we have a “hotkey” like “press F2 twice” when in the Desktop to toggle between whatever the OS thinks is good

“Key F2 not found, press F2 to continue” ;)

Rick: if you have EDID on your monitor, you automatically get a preferred mode which can be used,
And you won’t be using an MDF. Having a preferred mode is not essential – at present ‘preferred mode’ is 640 × 480 × 60 and this can continue.

No hot key needed either: if EDID works well then we can make that default. If you use HDMI or your monitor is less than 10 years old then it will work fine and the days of monitor hassle on RISC OS are over. If your monitor doesn’t support EDID – well there still be dragons but if you choose to use unsupported hardware on a minority OS then drakonophobia is the least of your issues! (In other words you’re in the same boat people are in now – a world of DIY MDFs etc).

The bounty suggests that the display manager needs modifying – but I can’t see [why]

I tend to agree – the EDID work is essentially one of making sure the drivers (OMAPVideo for OMAP3 & OMAP4, Pi, VIDC20Video, NVidia) all reply when asked for EDID data, having a robust parser that turns that data internally into an MDF, then just passing on the MDF as presently. Display manager shouldn’t care where the MDF came from.

Just looking at ScrnSetup now to add the EDID support: what is ‘Auto’ actually doing?

Auto is shown when no MDF was selected (either because Predesk$Configure isn’t set because no boot sequence ran, or because you actively selected ‘Auto’). The kernel will then have a guess at what to do based on the configured monitor type, which itself can be ‘Auto’, in which case the ID pins will be inspected on the VGA connector. I think there’s a fair few unused monitor types now so allocating one of them to ‘EDID’ should be possible, but equally just reinterpreting ‘Auto’ to mean ‘EDID’ would make sense.

In ScrnSetup I imagine a new button “Read from monitor” which brews the MDF on the fly but it otherwise essentially the same as presently, the button would be greyed out on a machine that doesn’t respond to the GraphicsV call to read the EDID. Or even less cluttered would be to read the EDID speculatively and pop it into the top of the ‘Monitor Type’ menu.

It’d be good to ditch a lot of the MDFs currently provided on disc as many were autogenerated by Castle from EDID in the first place. That would reduce the number offered to just those that predate EDID like the venerable AKF60.

I have thoughts for a significant improvement on ScrnSetup – moving the screen saver out and using EDID data for a multi-display configuration tool.

In a multi display setup you still want a screensaver, and since the screensaver saves the screen it seems right for it to be in the screen setup plugin.

and maybe cause ripples through RISC OS land by moving the display onto the /hardware devices/ side of the icon bar

In the Wimp_CreateIcon section of the PRM it states that filing systems and devices are on the left and applications are on the right. I assume originally the palette utility was on the right as that’s clearly an application, and when that got ditched and replaced by Display Manager nobody could be bothered to move it to the left where it should be (since it’s a device) and left it on the right (since it’s an application). I’d put the ‘Apps’ folder on the right, and move the Display Manager over to the left.

I personally don’t like the ‘Monitors’ app at all – once EDID is fully implemented, it’d be almost entirely redundant for almost all users; we’ve got a configure plug-in after all that could be extended if required.

Hmm, I’d be stuck for how to change colour depth, resolution, and eigen factor, as I don’t run my monitor at its native resolution (but that’s just me). I always have a little chuckle when visitors with laptops try various incantations to try to get an image on an overhead projector on Windows/Mac OS, this is one of the few areas where RISC OS’ simplistic not-getting-in-my-way approach would win by just changing mode from Display Manager.

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.

Also – if DisplayManager were to stay: do we have one icon per display?

I’d imagine something more like ShareFS or OmniClient where you have one icon on the iconbar, and SELECT clicking on that opens up a little window with the 5 (or however many) monitors arranged spatially to match reality.

Though little used, you can already have the 1 icon for your display look like the actual monitor by providing a replacement sprite in a !Sprites file in the same directory as the MDF.

I can vet modes on the fly I guess as they are created – run each through GraphicsV 7, and only link modes which pass.

That’s what the ScreenModes module does already for any MDF so if you made an MDF out of the EDID data then that should all fall out in the wash for free. Nothing new to write.

Any objections to adding a ‘preferred mode’ field into the MDF file? Preferred mode will be ‘highest possible colour resolution at the mode the monitor says it wants.’ […] Are there any MDFs in the HardDisc distribution where the preferred mode isn’t the highest available?

I think we’re muddling up MDFs which are a set of modes the monitor likes, with the graphics driver’s set of achievable modes. The intersection of these sets is what the user gets – flagging it in the MDF is no guarantee it can actually get used (eg. user removed the VRAM, or swapped out a PCI card).

It might be appropriate to suffix the textual mode name (eg. “1024 × 768 (preferred)”) as a hint to the human selecting it, but I can’t think of anything that would want to programmatically determine it from the MDF.

ScrnSetup needs to be a radio option (EDID vs MDF) because you’re not just determining what the monitor is on startup. If you choose to listen to EDID data, you’re also implying that you are using monitors which can be hot-plugged (ie. if a monitor is removed and another plugged in that it too will have EDID data to use).

The plan will be to call EDID at ScrnSetup startup: if the call fails because the driver can’t support it then we will grey the icon.

At present, we won’t hotplug automatically (you would need to call *ReadEDID, and on some hardware any hotplugging is caveat user); the Monitors predesk will just call *ReadEDID rather than having a defined monitor type until we’re happy that the implementation works well enough on enough devices. However, the fundamentals are in place to make the changeover fairly trivial.

The preferred mode will never be ‘forced’ – but the idea is that if we’re given a new display and call *ReadEDID we need to decide how to display the screen. The preferred option is to keep the resolution we previously had. However, that mode may now be vetoed (as the new display doesn’t support it). We could then offer the preferred mode. The graphics driver could still veto that, or the user could select another mode. If the preferred mode is vetoed we would fall back to VGA. If you hotplug the monitors the plan will be – keep the current resolution, switch to preferred resolution, VGA in that order.

The MDF could offer a preferred mode primarily so that if you drop an MDF file onto the display manager, or you choose the MDF file in ScrnSetup, the same selection priorities can occur. Otherwise, it will be current resolution or 640X480. However, MDFs should be effectively deprecated anyway (only the RISC PC will use them, and the RISC PC can still use EDID data if you extract it on another machine – hence the allocation of an EDID data type – which then gives us all the benefits of EDID, minus hot plugging).

When you change MDF files (or choose EDID), ScrnSetup instantiates ScreenModes to read the MDF (or EDID) on the temporary instantiation, and ScrnSetup will pass Type 3 Mode blocks to GraphicsV to vet each mode. So – if your mode isn’t supported in hardware, it won’t appear on the mode list.

Hot plugging will definitely need the preferred mode data: if the second HDMI port on Pandaboard became useable for example we would need to respond to another monitor being plugged into HDMI 2 when there was no device or display mode at startup. Part of that process will be a *WimpMode Display1 (clearly not real syntax but you get the gist).

http://www.anandtech.com/show/7635/lenovo-at-ces-2014-thinkvision-pro2830m-28-inch-4k-professional-display

Hmm Jeffrey: we’re going to need a bigger boat :-).

I’ve only been loosely following this thread, so forgive me if any of the following has already been covered, but I thought I would just add a few comments from my own experience.
It may be helpful to be able to export the EDID generated MDF, to allow more modes to be added. Also perhaps to be able to select an MDF, to be associated with a given display, to supplement the EDID generated modes.
My thinking behind this is that the EDID does not give all possible modes a screen may support, sometimes you might want to define a non standard mode, for a game, etc. that you would want available. If you could export the EDID generated MDF, you could add to it and just run with that, or you could use the exported MDF as a base reference to create supplementary mode you could choose to add.
Certainly, for some of the Castle MDFs in the disc image, they are based on, rather than directly produced from the EDID data. In some cases extra modes are added with maybe a reduction in the refresh by a few Hz, or smaller borders for example to achieve a working mode for the more limited RiscPc bandwidth.
I also recall getting an MDF set up for an lcd with 1366x resolution, where for reasons I can’t quite remember now, worked best on the Iyonix with a mode defined at 1368x (to be divisible by 4 of 8?), rather than using the 1366 timings offered by the EDID.
I do however only have experience with VGA output in this area, things may be different with digital.

Will – where did the DecodeEDID timings calculations come from (all the #defines)? I presume they aren’t human-generated (the style doesn’t match the rest of the code) – did you import them from elsewhere or generate them from something?

I’m already generating the modes direct from the EDID, not to an MDF. Doing a direct generation just means the EDID parsing code sits in parallel to MDF parsing, making things very straightforward. People are welcome to use tools such as DecodeEDID to make the MDF if they want a specific MDF, or even save out the EDID, patch it, and replace it (probably wiser given the number of extra options EDID has). However, hot plugging or automatic configuration at startup would be impossible down this route.

I did think about non-standard modes though. The simplest route there would be that if you request a non-standard mode, an existing mode is used nearest the dimensions you want, but the borders set to reduce another mode to meet the resolution. Yes that means a ‘windowed’ mode but means the timings can be left functional.

Advanced users may wish to manually alter an EDID or use custom modes on an MDF. But I’d consider that in the realms of ‘advanced use’ – so they would be expected to roll their own MDF from DecodeEDID or somewhere else first. The impression I’ve got from brief testing on HDMI devices is that they are much more compliant. The fact other OSes have such little trouble now is also a promising sign.

Indeed a cool third-party app would be one which allows you to modify a raw EDID file to add custom modes or alter timings – all at your own risk of course.

The #defines are based on a quick and dirty manual conversion of formulas from an excel sheet to calculate the VESA GTF. I don’t have the sheet to hand, but probably an earlier version of http://www.fl-eng.com/_lib/doc/vesa.xls. You’ll see a lot of it is cell references, some of it named cells, and some is a concatenation of many cell formulas with a slightly more readable name. The whole thing resulting in functional but generally unreadable code. I understand the Generalized Timing Formula has been replaced by Coordinated Video Timings, so this would probably be a better point to generate timings on. Hopefully the info on this is more accessible now than 10+ years ago when I worked on this…

Doing a direct generation just means the EDID parsing code sits in parallel to MDF parsing

Fair enough, my suggestion was based on the assumption it would be trivial. I agree that some of my use cases are in the more advanced user category, and indeed nothing will really be lost from what is currently available. I do like the idea of a third party app to modify or add to the EDID file.

The simplest route there would be that if you request a non-standard mode, an existing mode is used nearest the dimensions you want, but the borders set to reduce another mode to meet the resolution.

Yep, that is probably a lot better for the user anyway as the mode will just be effectively available on demand without having to faff with a custom MDF

Ah – the define names are cell references? That makes more sense!

I think where possible users should use EDID – directly or if needed by file. For advanced use cases an edited EDID would work OK – having a third party ‘EDID info / editor’ app would be handy and a great debugging tool for people with hardware issues.