EDID discussion

This is a continuation from the GraphicsV discussion.

I’ve been making good progress on this front – I’ve got the ‘standard’ modes working (unfortunately whilst these are useful for RISC OS they usually aren’t the optimal mode for the display – but could allow people to use a device on a monitor they were completely struggling with so not entirely useless).

I now have an additional selection of modes on the Pi which is nice – which will obviously be better when I’ve cracked the other modes.

FAO Jeffrey in particular: my work so far has been building out ScreenModes to do the work:

*LoadModeFile will now take a text file or a dump of EDID data (allowing EDID export and then use on non-EDID capable devices).

*ReadEDID will read the EDID directly.

In terms of hot plugging – do we need much more than this? If a graphics driver supports hot plugging, then the intent would be that the code within *ReadEDID needs to be called. That will read the data, update the mode lists, and then change mode if required. The priority there will be: keep current mode (so if you pulled a display’s video cable out and plug it back in you’d get the same display); then the preferred mode for the display; then a ‘safe’ mode.

We could encapsulate that into a service call which if ScreenModes receives the service call it will then call readEDID.

Any thoughts on multiple displays? I think ScrnSetup instantiates the ScreenModes module – maybe different instantiations could be used for each display? I currently only read from display 0 because there is only a single list of screen modes (where we need a per-display list; but that’s an equally big job in itself!) Obviously it’s out of scope – but useful to keep things in mind so I make that part of the work as easy as possible.

The bounty suggests that the display manager needs modifying – but I can’t see where; ScreenModes is treating it basically like you just changed MDF files; and ReadEDID is picking the data up from hardware rather than a file. From what I have so far, Display works fine as-is. What are the plans for multi-display support here – more than one monitor icon seems to make more sense (and maybe cause ripples through RISC OS land by moving the display onto the /hardware devices/ side of the icon bar…) – each one dealing with an instantiation of ScreenModes???

Just looking at ScrnSetup now to add the EDID support: what is ‘Auto’ actually doing? I clearly know what it is /not/ doing – but what is the intent/purpose of the ‘Auto’ option at present? I have thoughts for a significant improvement on ScrnSetup – moving the screen saver out and using EDID data for a multi-display configuration tool. However, the task in hand is just to allow EDID to be switched on instead. For that I was planning on adding two radios (effectively Use EDID versus Use MDF but appropriately labelled); UseEDID will call ReadEDID at startup as opposed to LoadModeFile. For selecting modes, I was going to add an option saying ‘use the device’s preferred resolution’ (effectively).

Struggling a lot with: “This list is then refined by comparing the capabilities of the display against the capabilities of the video hardware in the platform. The list is made available to the OS and other software through a suitable API.” Struggling as in: can’t quite work out what parameters we’re going to be setting here to compare against, or how the API would work. There is a list of ‘official’ Pi modes. But I’m not aware of ones for other platforms, and the risk is that we restrict devices from making perfectly valid display choices. Ideas needed if this is to be pursued.

In terms of hot plugging – do we need much more than this?

Let’s back up and ask – is it even “safe” to hot-plug? I could have sworn the Beagle’s manual specifically said that connecting/disconnecting a video device while it was powered up was liable to risk blowing up the video hardware?

Any thoughts on multiple displays?

It could be best to wait to see how this is actually implemented within RISC OS. In theory, you would need a different list for each device; for instance – it is theoretically possible to run two entirely separate displays on the OMAP hardware (HDMI and s-video; I don’t recall if the LCD connection is a third type or if it ‘borrows’ from one of the others) which will not share anything related to screen setup – HD vs LCD and/or analogue. All different.

Jeffrey – quick question – is it possible to run the Pi’s composite as a second video source, or is it always going to be a scaled version of the primary output?

The bounty suggests that the display manager needs modifying – but I can’t see where; ScreenModes is treating it basically like you just changed MDF files; and ReadEDID is picking the data up from hardware rather than a file. From what I have so far, Display works fine as-is.

That’s what I expected – that a change in EDID would behave like a change in MDF.

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

Argh! That would look too weird!

Just looking at ScrnSetup now to add the EDID support: what is ‘Auto’ actually doing? I clearly know what it is /not/ doing – but what is the intent/purpose of the ‘Auto’ option at present?

I cannot speak for “at present”, but in historical terms, Auto would attempt to determine the monitor type in use and set the display hardware accordingly. It only seemed partially successful to me, as it (IIRC) relied upon stuff like certain behaviour if certain pins on the VGA connector were pulled high or low. This all predates stuff like having EDIDs and IIC PROMs.

For selecting modes, I was going to add an option saying ‘use the device’s preferred resolution’ (effectively).

That would be good. It would be nice to be able to boot up the Beagle and have a display. You see, unlike the Pi (where the GPU generates the display itself and mostly ignores any info supplied by RISC OS) the Beagle does its display generation old-school, in that RISC OS indicates the resolution and timings. It appears as if the timings that I use are not spot-on, so the HDMI→VGA adaptor doesn’t like it much.

Therefore, it would be great if there was an option to tell RISC OS – find out what sort of display this is, and set yourself up accordingly and ignore mode changes to the contrary (if any are defined in the boot sequence).

Here is a question or two – what do you do if:

• the EDID returned does not supply any timing information?
• the EDID returned is utter gibberish?
• the EDID returned does not actually match the display itself?
• the EDID returned provides a mode that is not actually possible by the hardware (ie, some hardware needs values divisible by 8)?

Do you have a stand-alone program to read the EDID on the Pi (do I need to update my ROM image?)? It might be interesting/instructive/a nightare(delete as applicable) to see what sort of information actually comes out of an HDMI→VGA adaptor? (^_^)

“…(and maybe cause ripples through RISC OS land by moving the display onto the /hardware devices/ side of the icon bar…)”
Argh! That would look too weird!

It would also be rather non-intuitive – even windows puts the display control stuff on the right of the iconbar

Sounds like great progress.

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

Argh! That would look too weird!

Why? Display has long since ceased being a palette-definer app and has morphed into a controller for the monitor. It’s made more sense for ages to put it on the left hand side of the iconbar, along with the controllers for other hardware devices, printers, etc. However, RISC OS-land being what it is, I expect the suggestion will still be met with howls of outrage :)

However, RISC OS-land being what it is, I expect the suggestion will still be met with howls of outrage :)

Look at a Windows PC – where do you see the display control icon? Off at the right or the left?

OK. So, while it’s nice that somethings in RO are different, changing that particular one to a non-standard location would meet resistance from incomers too.

Look at a Windows PC – where do you see the display control icon? Off at the right or the left?

So we are going to move applications from right to left? With the Switcher as the leftmost icon, because this is the nearest thing to the “Start” button we currently have?

As Chris says, Hardware and psudo-hardware (Filing systems) go to the left.
Windows, as always, does things the other way…. Programs that are running or pinned to the task bar are on the left, and some programs and hardware are on the right !! (Windows 7)

As Chris says, Hardware and psudo-hardware (Filing systems) go to the left.

and configuration to the right

Windows, as always, does things the other way….

au contraire – RO and Windows have been doing the same thing and showing the display configuration to the right for years (decades?)
I regard moving the display configuration on RO as the same level of (lack of) sense as the window close icon move on certain versions of Linux. Done to be different and damn the users.

Of course if someone wants to configure a MiniDisc style clear up utility for the increasingly cluttered left side then it might not be so bad, except when you have to explain to a newbie that it isn’t “where it ought to be like on Windows”
Love it or hate it windows has two positives in this discussion:
1. It’s the commonest OS people know
2. It does the same as we currently do.

Or do you want change for changes sake?

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.

I’ve always thought that having both the plug-in and the app on the iconbar was confusing to newcomers. For example, they might change mode with it to get their display set up and then reboot and it’s all gone! I also think the app is a waste of valuable iconbar real estate because most people will never change mode once their display has been configured, and you don’t even use the app for that, doh!

I actually voted to ditch the Monitors app from the RPi distro when we were pulling that together but it was risky precisely because we didn’t yet have EDID support and it’d probably be a step too far for the existing users – any change would inevitably have people who don’t like it, after all – so we decided to keep it even if it might be confusing to new users.

All IMHO.

is it even “safe” to hot-plug? I could have sworn the Beagle’s manual specifically said that connecting/disconnecting a video device while it was powered up was liable to risk blowing up the video hardware?

Can someone check that out? It sounds utterly, utterly bonkers to me! The whole point of things like HDMI is that you can hotplug your sink (display); this is why you have the ability to test for connect/disconnect state as well as rx sense to tell you if the sink is actually active (on) or not (these are usually mapped onto events by the driver). It’s up to the software stack to deal correctly with hotplug of devices (just like USB) so to have a hardware design which could blow up if you switch your display while the machine is running is just crazy.

I can see hints online about this warning in the Beagleboard manual but a quick search failed to throw up the manual itself or the section in question.

Edit: OK, I see this is related to quirky HDMI→DVI adapter cables they use with their odd DVI/HDMI interface on the Beagleboard. I don’t think this is a good reason to implement a software stack that cannot cope with hotplug of displays.

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.

Yes, that makes sense. The days of wanting to change the 16-colour palette ‘on the fly’ are long gone (and you can’t do that from the Monitor app anyway), and changing screen dimensions, colour-depth, etc. is, as you say, really configuration. If the Screen configuration plug-in was extended to cover all bases, then I’d be happy to see the iconbar app go.

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.

I’d go with that – i.e. when people ask where the display configuration is just point them at the overall configuration section, when people ask where the display icon went point out that it’s mostly automated and the bit that isn’t is in the configuration where it always was but with extra features.

Oh, and I get a bit of my iconbar back.

I can see hints online about this warning in the Beagleboard manual but a quick search failed to throw up the manual itself or the section in question.

From the -XM rev C manual (latest version) "http://circuitco.com/support/index.php?title=BeagleBoard-xM#Rev_C2
“DO NOT PLUG IN THE DVI-D CONNECTOR TO A DISPLAY WITH THE BEAGLEBAORD
POWERED ON. PLUG IN THE CABLE TO THE DISPLAY AND THEN POWER ON THE
BEAGLEBOARD.”

Looking at the circuit the ability to hot swap would depend on the robustness of the TFP410 device that directly connects to the HDMI output port.
TI list it as DVI compliant. http://www.ti.com/lit/ds/symlink/tfp410.pdf

Can someone check that out? It sounds utterly, utterly bonkers to me!

I don’t know – is it normal to want to switch display devices with the board powered up?

I can see hints online about this warning in the Beagleboard manual but a quick search failed to throw up the manual itself or the section in question.

? Took me seconds with Google to get the manual, and then just reading the bit about the DVI connector. It says this:

[manual is at http://beagleboard.org/static/BBxMSRM_latest.pdf ]

[update: I notice you found this. I got sidetracked watching a documentary on what happened at Fukushima…]

then I’d be happy to see the iconbar app go.

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

So we are going to move applications from right to left?

Yes. And the reason is because when directory viewers are opened, they tend to be towards the left – while application icons appear on the bar on the far right. If you have to drag something from a directory viewer to an icon (such as an Impact database – which takes the form of a directory), it’s a loooooooong drag from somewhere over there <- to all the way over there →

And on bigger, higher resolution screens, it’s annoying.

Of course, the fact that I’m becoming more and more lazy may be a factor. ;)

To follow up – the TFP410 supports hot-plug, and even has a register bit that can flag this event; and looking at the Beagle xM schematic, pin 9 is connected to a series resistor as expected for this operation.

So… I don’t know. Maybe the Beagle people are being overly cautious? It looks like it should work…
[not that I plan to try it]

The video hardware vs. screen capabilities needs a lot of thought. Maybe for a first shot, it would be sufficient to have a list of screenmodes the video hardware is capable of inside an MDF. That way, it would be easily user-extendable for the tinkerers. This MDF could be matched with the MDF created from EDID info to produce the list presented to the user to choose from. It would also be good to specially mark the native resolution of the screen to help the user.

With the Switcher as the leftmost icon, because this is the nearest thing to the “Start” button we currently have?

Just, FWIW, Switcher is not even remotely similar to the Start button. The only thing they have in common is a method of shutting down, but then I use the keypress under RISC OS so…
(^_^)

So we are going to move applications from right to left? With the Switcher as the leftmost icon, because this is the nearest thing to the “Start” button we currently have?

I was suggesting that moving things from their existing position on a whim or technicality was daft and that even windows had such things on the right like RO. It was not a suggestion that we should adopt a MS centric model, merely that it appeared to be an item that was common already and change was not warrented.
Steve R is in favour of plain ditching the icon on the grounds of duplication of function and I’d agree to it going, I daresay others would too.

ust, FWIW, Switcher is not even remotely similar to the Start button. The only thing they have in common is a method of shutting down, but then I use the keypress under RISC OS so…

The power button works on both, but RO seems more capable of rebooting reliably afterward :)

Maybe the Beagle people are being overly cautious? It looks like it should work…
[not that I plan to try it]

Probably cautious rather than overly so, remember it’s intended as a development board and people who tinker frequently have kit they connect that they have tinkered with¹ and the beagleboard producrs are aiming to reduce RMA work.

¹ Know anyone that does this? :)
OK, unfair. Does anyone round here NOT tinker with the kit?

The power button works on both, but RO seems more capable of rebooting reliably afterward :)

<gulp!> I hope you count to five in your head beforehand. It used to be “no big deal” to power off RISC OS kit, but with drives having varying degrees of write-behind caching, and flash devices (like SD cards) using both that plus shifting around lots of data for wear levelling – it probably isn’t a good idea to pull to power too soon from the last write to media.

[makes me wonder – is there a command in the SD spec that informs the card’s firmware “flush the cache, power off imminent”? and, if so, does RISC OS issue this upon a *Shutdown?]

OK, unfair. Does anyone round here NOT tinker with the kit?

Me? I have never ever opened up a bit of kit before even plugging it in for the first time. Never. Not even once. Damn, my nose is growing…

I don’t know – is it normal to want to switch display devices with the board powered up?

Not particularly normal for a desktop machine, I grant you, but certainly not unusual for a portable – like plugging a projector into a laptop for a presentation, for example,

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

I can, or I can build a ROM without it. But I was talking more about in RISC OS as standard, rather than for my own personal setup.

I appear to have opened the proverbial can of worms :-).

Steve P: the suggestion wasn’t change for changes sake. The ‘Windows does it" argument falls flat when we consider where !Printers lives and it’s equivalent on Windows. And on OS X or Gnome 2 it is top right.

The palette utility was an application to manipulate the palette – correctly being on the right. On OS 3.5 it was replaced with a tool to manage the hardware – which should have joined other hardware devices. The key to an OS’s usability is consistency. ‘All hardware on the left, software apps on the right’ is easy to explain to users. I don’t think many people will struggle – the display icon does have the picture of a screen on it after all!

I agree with Steve R that one option would be to scrap it entirely. I am reticent – mainly because not all devices provide EDID or worse may provide duff data. Having a tool readily available from ROM is very useful (Configure requires a working !Boot – if your machine is FUBARed it’s up to now not been uncommon to have no Boot and no Display, and needing to know the arcane runes needed to recover from the CLI is not ideal. On a RPC or Pi we have no EDID so this won’t necessarily improve).

We also need to think about VNC or remote interfaces where there isn’t a ‘preferred resolution’ and may need to configure it.

Also – if DisplayManager were to stay: do we have one icon per display? This would make dealing with display issues easier. The display’s name could be displayed as icon text. In which case the number of icons may change as a device is plugged in – which again may be preferable on the left (as we see with USB devices, Printers etc) than at the far right where all application icons would suddenly move.

I change the configured screen mode very rarely but I frequently change mode resolution/colours. Please don’t make it difficult and moving it seems like work that would annoy many many more than it pleases. I’m struggling to see any advantages!

EDID is nice when it works but we know from tests we did for ROL/Advantage Six with about 20 monitors that monitors often report incorrect information and that despite work arounds being built in for those that the A9home’s EDID was in practice unusable.
So it would be nice if EDID could be offered but a workaround must be in place in case a user gets no display. We can’t assume a user will have a second monitor.

I have seen official BeagleBoard postings saying that over half of all warranty hardware failures they put down to hot plugging HDMI! The chip may be specced to support it but in practice there is a problem.

Chris: Do remember however that the A9Home was using 15-pin video. AIUI, HDMI mandates the use of EDIDv1.3 (which is the version being built in). In theory, most monitors should therefore work. However, we do reject EDIDs that don’t conform to the spec (no header, no checksum) because of this.

DisplayManager was an aside comment which appears to have subsequently dominated discussion, which is in a sense useful (to discuss it) but overlooks the other issues with the EDID implementation.

EDID and hot plugging are both AIUI optional features rather than requirements of any of the hardware platforms. It would seem silly if hot plugging is Pandaboard-only, but that may be the case. Still doesn’t resolve the implementation details here.

The problem with EDID on analogue monitors wasn’t that they didn’t support EDID but they returned invalid, nearly valid results or valid results for another monitor e.g. wrong monitor model number or not including 1280×1024 on a 17" 1280×1024 monitor. HDMI monitors may be more correct but I wouldn’t hold my breath.