EDID discussion

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.

Windows doesn’t have a display control icon – you right click over the desktop. Can’t remember the last version that had an icon. Windows 8 certainly hasn’t. So if windows compatability is a good reason then the display icon should be removed.

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 know. But for now, to test that it going away won’t change much, you can fake it. One thing that comes to mind (I’ve not looked), what part of RISC OS provides LoadModeFile ? The ScreenModes module provides the actual implementation, however DisplayManager provides some sort of draggy-droppy way to load MDFs. Okay, it just throws it to *LoadModeFile, does anybody use this functionality?

On OS 3.5 it was replaced with a tool to manage the hardware – which should have joined other hardware devices.

Funny – I don’t really perceive switching display mode to be “hardware” any more than I consider reporting on (V)RAM and its use to be so.

I suppose !Printers is the anomaly in the plan, because everything else on the left of my iconbar is some sort of filing system. Even the ones that aren’t hardware at all. ;-)

like plugging a projector into a laptop for a presentation, for example,

Fair point, I guess. I’d have all that hooked up before powering up… I grew up in the days when messing with stuff like that risked cooking expensive chips. I recall much the same warning regarding the VIDC and not plugging in a monitor with the things powered up.

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.

…doesn’t this imply that you can see the display in order to use DisplayManager?

The problem is, I think you might need to know the runes – for on some hardware you don’t have a keyboard visible in early boot (so pressing the keys that would reconfigure things won’t work).

A further problem is that you might need to poke and prod the video configuration for the Pi, depending on your hardware. If you thought getting RISC OS working was hard, look at all those hdmi_xxx options. Which ones to choose, though? Eeek!

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

What’s wrong with a selection box at the top of the current set of options? One icon per display seems a waste of iconbar space.
As it is, I wish it was possible/easy to reduce the size of the icon bar (just halve everything to get an idea); more akin to the size of the task bar in Windows XP. I’ve not mentioned this because because, well, it’s Christmas, somebody else got crucified…

about 20 monitors that monitors often report incorrect information

Wasn’t there an interesting ‘issue’ with Select/Adjust where it relied upon using the EDID and this turned out to be bogus in a significant number of cases to break the point of doing it in the first place?
Hence my question above – what happens if the EDID information is gibberish. Or, better yet (and I’ve heard of this happening) the EDID is correct, but for a different display device than it is actually wired in to.

So it would be nice if EDID could be offered but a workaround must be in place in case a user gets no display.

I wonder if fixing the keyboard handling might help, so hot-keys work? Alternatively, how about having something like *Configure DispHack which will set a temporary bit in the CMOS RAM (however implemented) to instruct the display driver to “do what is necessary to attempt to provide a useful display”.

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.

Really? I’d have thought using an unregulated power supply or hooking 3.3V hardware to a 1.8V device would be the more likely source of “ohcrap!” moments.
Still, it is useful to think ahead to hook up stuff, and then switch it all on.

Windows doesn’t have a display control icon

Mine does. It is an Asus widget that is intended to switch resolution and which monitor is in use (internal display or external, or some combination of both).

you right click over the desktop.

Me too. When running on an external display, the widget tends to ‘forget’ that this machine is a netbook with its own internal LCD. Using the Intel driver UI is better (as in it (mostly) works) – it just has a habit of reverting to the dumbest settings, like 800×600 on a 1024×600 display (messes up icon placements) and 16 bit colour instead of 24 bit. But, at least it knows there’s an LCD baked in to this machine! ;-)

Can’t remember the last version that had an icon. Windows 8 certainly hasn’t.

There appears to be a lot of stuff Windows 8 doesn’t have.
It’s like Microsoft looked at Unity and said “how do we dumb it down more than that?”.

So if windows compatability is a good reason then the display icon should be removed.

…Windows compatibility? Shall we revisit the ^C/^X/^V discussion? :-P

BTW, the source for the ScreenModes module – nice sense of humour, whoever wrote the comments, especially in the function service_modetranslation.

Windows having a display icon on the right was being used as a reason to keep it. I was pointing out that windows doesn’t have one so windows compatability is not a reason to keep it. You confirm this by pointing out that your version of windows doesn’t have it either – you have a third party icon.

Therefore getting rid of the display icon doesn’t upset new users so we needn’t take them into consideration.

As an oooooooooooold user I can’t remember the last time I used the display icon. It would be better if it’s functionality was included in the screen configuration utility so that everything was in the same place.

Rick: the modes bit isn’t ‘hardware’ – but MDFs making things hardware-specific is. If we are managing multiple displays we are definitely managing hardware just as much as Printers is.

With regard to a FUBARed Boot – it is not uncommon to be dropped into a malformed 640*480 (mode 27) needing correct MDF loading and a mode change to get out to something nice (and made worse when windows assume a screen size > 640*480 will be available and windows go partially offscreen.) Having the desktop partially off-screen but useable also happens. You can fix these without the mystic WimpMode runes. Obviously some displays aren’t useable at all and runes are needed.

If monitors play nice we are OK. My 15 pin Samsung plays nice. Two HDMI TVs in my house play nice so far (in fact the Tv has FAR better mode support than my monitor). But we do have to allow for monitors not playing nice, users hot-plugging devices (i.e. On hardware designed to handle it), users remote accessing from a headless display, or devices not doing EDID (including the Pi.) Whilst My EDID changes will make life better (no MDF needed – get a monitor which does EDID, and you can extract the EDID using a Beagle or Pandaboard and all modes are available rather than having to craft an MDF file) it doesn’t remove the problem a significant proportion of the user base will still have.

One icon per display better fits the RISC OS 1 icon per FS/partition, 1 icon per printer ethos. A display field plus menu would be less real estate but is a messier UI and harder to use if you are configuring /because/ your display is a mess. If you have multiple displays you should have enough real estate for another icon! However, As I said – it isn’t something needed for EDID or imminent change – I was just raising it as these are the sort of questions multiple displays will pose.

And – despite having spent quite a long time with ScreenModes I hadn’t actually read the service_modetranslation commentary until you pointed it out. Thankyou. THAT is how code should be commented :-). I presume the author was TMD from the writing style.

Just a quick update that the detailed timing descriptor blocks from EDID now appear to be working: can’t be 100% sure as 2048X1152 isn’t supported by the Pi, but it behaves as I would expect it to do (ie. badly and in the same way my MDF does when I tried it with a correctly populated VIDC block). There are still more modes that can be obtained from the EDID. The early portions of DecodeEDID however have a maze of algebraic spaghetti which I need to get my head around I think before I can add much more. We currently also use preset data which we may be able to drop for more calculated data once I get my head around that.

Does anyone have any decent documents on how to calculate the parameters which make up a mode descriptor file (‘MDFs For Dummies’)?

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

I think that’s good. All sorts of stuff festers in the unopened cans. :)

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.

Ah, yes the shift around of various functions that Linux went through appropos not being like windows was the general view. Just don’t mention Unity or I may go postal.

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

As Rick pointed out quite some time back when things are really FUBARed the runes element really kicks in – hence his Harinezumi boot utility. A tweak there to ensure that the default display kicks in perhaps?
Not really relevant to the excellent work you are doing, more a case of your work revealing, or rather highlighting an existing issue.

@Rick

As it is, I wish it was possible/easy to reduce the size of the icon bar (just halve everything to get an idea); more akin to the size of the task bar in Windows XP. I’ve not mentioned this because because, well, it’s Christmas, somebody else got crucified…

hmmm, yes a resize iconbar facility – didn’t someone once do something like that so that the iconbar was a resizeable “window”?

Wasn’t there an interesting ‘issue’ with Select/Adjust where it relied upon using the EDID and this turned out to be bogus in a significant number of cases to break the point of doing it in the first place?

So I gather – the thread on c.s.a* that Martin started about RO6 features people would want in RO5 prompted Druck and ?mr hughes? to exchange opinions about the naffness of the EDID implementation in RO6. Suffice to say there was yah boo sucks, but the underlying element is that the implementation needs to catch bad responses and fail gracefully – Something William already has high on the list.

Couldn’t the FUBAR situation be handled via the “MonitorType” configuration option? “auto” would give something generic every screen should be able to display (640×480 like PC BIOSes?), and would be the default. For modern hardware, a new option “EDID” would automatically select the “native” mode for the screen.

There are still more modes that can be obtained from the EDID. The early portions of DecodeEDID however have a maze of algebraic spaghetti which I need to get my head around I think before I can add much more.

For another reference implementation of EDID, you could take a look at the dlo_mode.c and dlo_structs.h files in libdlo – this is written to be reference code (not for EDID parsing, admittedly) so should be about as readable as you can hope for. It does the standard timings stuff and detailed timings, but not the newer EDID extension blocks.

If you can’t get your head around it, blame the author (Steve ducks). ;)

For some background info, libdlo was a reference driver library for the DisplayLink chipset. If you look into the code – edid_to_vreg_commands() – there’s stuff that translates from the timings derived from the EDID into stuff that roughly maps onto what you’d find in an MDF. I’m pretty sure there was some Acorn influence in the early DisplayLink designs.

Thanks Steve – that looks good.

Most of DecodeEDID is straightforward – just the parameter calculations (first 100 lines or so of #defines) which form a series of defines which seem improbably complex and almost obfuscated.

The most recent mode blocks I have added are detailed timings which are standard in EDID 1.4; I can’t find any specs for anything newer than this – but AIUI 1.4 is the standard for HDMI so should cover us until we need DisplayPort support or some newer standard (and the last I have found on Wikipedia). Any pointers to newer specs appreciated too.

Will update Scrnsetup shortly so we can configure it on and will work my way through the links you have provided.

Steffen: We should only use EDID in this way if we are confident that most devices are providing correct data. I’ve heard lots of things about devices using hacked (ie. wrong) data, or not providing EDID. I haven’t seen this myself – so I don’t know how prevalent that is. I think HDMI should mean we’re fine (this may have been a problem in analogue-world). I’d rather NOT make EDID the standard fallback initially until we’re confident that almost always devices are responding correctly and we have a nice picture on them.

If dodgy devices are rare we can switch it on by default and even consider Steve’s proposal of removing DisplayManager by default from EDID-supporting hardware.

If EDID is not reliable, then having it as an option will help some people. Another factor here is the likelihood of being able to support EDID on the Pi in future – we shouldn’t rely upon a feature as standard when only a minority of hardware is actually going to be able to support it. Not having EDID on a RISC PC is an understandable issue; not having it on the Pi is more difficult.

not having it on the Pi is more difficult.

EDID is on the Pi (I’m pretty sure RaspBMC set itself up for my display without me doing anything, although perhaps it cheated and read the config.txt file?).
The problem is EDID is not obvious on the Pi. It is available by poking the GPU; and if the driver does not (yet) fake the IIC sequence, it won’t be able to be read.

Rick: Yes I know the Pi /can/ do it. The issue is that RISC OS on the Pi /can’t/. I don’t know enough about the hardware side of things to know whether it’s possible now that there is a purpose to doing so to be able to make RISC OS on the Pi support EDID, or whether it’s something we can’t do without better understanding of the GPU.

Yes, RISC OS could do it now if the code was in place. How is available in one of the documented mailbox functions of the GPU. I wrote some code, but it looks as if the GPU gives a response and if you don’t pick it up, the whole thing hangs. Life is too short… so better left to somebody with some experience in talking to the GPU. It appears as if the BCMVideo module has all the necessary parts (aside from the IIC faking part) as it already talks to the GPU for doing the palette stuff.

It’s just a matter of waiting for support to arrive… we need to be patient.

I don’t know enough about the hardware side of things to know whether it’s possible now that there is a purpose to doing so to be able to make RISC OS on the Pi support EDID

I think that’s a question for Jeffrey Lee, when he’s next around. I would hope there’s a fairly simple bit of code required to get at the EDID (via the mailbox property interface) but of course there’s the added complexity that the firmware is the thing that actually talks to the display and sets up the graphics mode – whatever RISC OS displays is rescaled by the GPU to fit onto whatever screen dimensions it has chosen (normally from the EDID). But that shouldn’t really be a problem – I actually don’t recall whether RISC OS now controls the mode on the GPU side.

Sorry for adding more FUD to the discussion, I’ve been a little too distant to developments to add much value here. I’m sure Jeffrey or someone closer to the metal can shed some light when they have a moment.

It may be much easier than suggested by the recent discussions above. If I understand the BCM2835 data sheet correctly, the IIC interface associated with HDMI is simply BSC2. We have code to address BSC0 and/or BSC1 (I know because I wrote it), so addressing BSC2 should “just” be a case of copying the code but pointing at a different address range, and ensuring that the IO pins are set up correctly.

Although I admit that I don’t understand the significance of “Note that the BSC2 master is used dedicated with the HDMI interface and should not be accessed by user programs.” If this is merely pointing out that BSC2 is connected to nothing but the monitor’s (EE)PROM, then no problem; if it’s suggesting some deeper functional interconnection, then I don’t understand.

Get EDID block is indeed supported by the mailbox property interface, so it should be fairly straightforward if the property interface code was exposed by BCMVideo (and that would be useful for other things too).

On the subject of hotplugging, I’ve successfully fried a Pi by doing that. One possible reason is static electricity, that it gives the Pi a static kick and there’s insufficient protection. Anyway, that particular boards are unhappy is not a reason not to add the software support.

On the subject of multiple monitor icons, how is it proposed to arrange them? If they’re in a line, which icon corresponds to which physical monitor? Other OSes have a window where you can drag around boxes proportional to monitor work areas to match the physical layout. If you have them in a line on the iconbar, the temptation would be to think that the leftmost icon is the one on the left of your desk, which might not be the case (perhaps they’re in a vertical line, or in a triangle). If such a thing exists, and is reliable, then perhaps one icon with tiles representing each monitor? Otherwise I think one iconbar icon with a more detailed dialogue on clicking it. That covers all cases from ‘I have 17 monitors arranged in a pentagram’ to ‘I haven’t a clue how many monitors there are because I can’t detect anything, please enlighten me!’

Other OSes have a window where you can drag around boxes proportional to monitor work areas to match the physical layout.

I fully agree. To say that having multiple iconbar icons is a RISC OS precedent set by other apps, such as the Printer Manager is to miss the fact that many other apps have a single iconbar icon which opens a window that may (or may not) look like a filer display which can contain multiple items (e.g. Paint).

I reckon if we must have an iconbar icon for managing your monitors, it’s something which is only going to require touching rarely so it’s a waste of space to have one icon per monitor. Just lead to a window with the one-icon-per-display layout. This is easy to implement and can be extended, as Theo suggests, at a later date to allow drag-and-drop of display position/order, much as other operating systems do. That’d probably tie-into the work that Jeffrey has been doing which (I believe) is at least in part paving the way to having the desktop spread over multiple displays.

My thoughts were that the display positions should be set by reference to the sockets (HDMI 1, HDMI 2, DVI, TV Out) not the displays (because the sockets are fixed and the displays are hot-pluggable). This may of course also need to determine what happens to the iconbar (think OS X here). Of course this may assist the user by stating what is currently attached to those displays. I think this is probably a job for the plugin. DisplayManager probably shouldn’t handle this – I would keep DisplayManager just adjusting resolutions per monitor (hence my icons thought).

We /could/ get DisplayManager to closely mimic ScrnSetup and allow display management for this session only. However we can’t use Toolbox for DisplayManager so this would be a major hassle to implement :-(.

What do we do about ‘non-fixed display sources’? I am thinking USB or VNC where you will have a display added transiently. You don’t want to configure places for theoretical USB displays. VNC needs to display the current display if available, or define a display area if one is not available.

My thoughts were that the display positions should be set by reference to the sockets

That’s basically an arbitrary order from most users’ perspective. I’m still with Theo in that no matter what ‘logical’ order you decide upon, “the temptation would be to think that the leftmost icon is the one on the left of your desk”.

By the way, I don’t want the EDID bounty work to grow to infinite proportions here(!) – remember that RISC OS can’t yet handle multiple heads (Geminus aside) so aside from considering the impact of that eventuality, I’d be happy to just see the basic EDID functionality in place and we can always extend things later (maybe another bounty).

What do we do about ‘non-fixed display sources’?

I think much like the Printer Manager, you’d have to store stuff against some unique ID for the device – I can’t quite recall what I did for that though :) – and simply not show that device in your configuration GUI when it’s not physically connected. I know that DisplayLink (USB display) devices have an unique ID that you could use for this purpose. I don’t think you could come up with a complete solution in one go, aside from assuming some hook code for a particular display type could be implemented that maps it onto an ID.

On the subject of hotplugging, I’ve successfully fried a Pi by doing that. One possible reason is static electricity, that it gives the Pi a static kick and there’s insufficient protection.

The Pi drives the HDMI output direct from the SoC the Beagleboard uses a chip designed for the job, with protection.

No guarantees obviously but the Beagle is more likely to survive repeated hot swaps than the Pi it’s a case of paying for what you get. No doubt the Pi output could have been more robust, but more expensive.

That’s basically an arbitrary order from most users’ perspective. I’m still with Theo in that no matter what ‘logical’ order you decide upon, “the temptation would be to think that the leftmost icon is the one on the left of your desk”.

At the risk of waking up the “windows is bad” crowd – the normal situation on windows, and indeed Linux, is to have a single icon access to the configuration utility which displays a virtual desk on which you place your displays so the screens can be any order.¹ As you rightly say, that is a bigger job and in some respects distinct from the EDID work.
The question is when the multiple display use is done is the intention to produce an ARMClub !Workspace style independent display workspace x N or a !Virtual style contiguious virtual display spreading across multiple real ones? Some consideration to the support needed for this probably required in the EDID code.

¹ 1-3-2-4 being one entertaining variant a young chap in desktop support did to a non-technical co-worker

That’s basically an arbitrary order from most users’ perspective.

My Pi is to the left of the eeePC. It is connected to the display on the right. Furthermore, what is considered the “one on the left”? The one that is actually on the left as you look at the device in situ, or the one on the left when you turn it around and look at the back? Which constitutes left and right on something like the Pi (sockets opposite each other)?

a single icon

I would agree with this; the difference between display managers and printers is that, once upon a time, you would click to select a printer and you could drag files to the icons – so the icons had a purpose.
What is supposed to happen with multiple display icons, other than clutter up the icon bar? For instance, what would be the behaviour to clicking on? Replace the current display with the one clicked?
Better, I think, to offer a single icon that will, in its menu, list the others. This icon will allow colour depth (etc) to be changed, as always, and on a multi-display setup, perhaps it can have a number overlaid to indicate which display you are currently looking at?

Some consideration to the support needed for this probably required in the EDID code.

The EDID code would, therefore, need to be written in a way as to be extensible. But, frankly, I would work on getting single-display EDID working well and worry about multiple devices when it arrives…

1-3-2-4 being one entertaining variant a young chap in desktop support did to a non-technical co-worker

Strange order. I’d have thought 1-3-4-2 would have been better.
(^_^)

Strange order. I’d have thought 1-3-4-2 would have been better.

How does changing it daily (by remote) sound? :)