Proposed GraphicsV enhancements

Certainly for the Raspberry Pi one thing to consider is that (AFAIK) there isn’t a way of writing to EDID, because we’re only able to access EDID by talking to the GPU through the mailbox channels. So if you’re looking for an “in-place” solution for writing the EPROM which doesn’t involve hacking together custom cables then you’ll have to temporarily connect up a different device – which at the moment would have to be an OMAP one considering that they’re the only other ones with HDMI/DVI sockets.

And conveniently, on OMAP3/OMAP4 GraphicsV_IICOp is actually just a wrapper around OS_IICOp. So if we banned writing to EDID through GraphicsV then it should still be possible to write to EDID by making direct calls to OS_IICOp. You’d need to build your own IIC transfer list and specify the right bus number, but that’s all pretty simple and straightforward.

Dave: Part of my laptop project would involve end users connecting up a wide range of LCD panels to the HDMI-LVDS section of our board we are developing. Everyone having to buy special cables for a once of use is not feasible.
Jeffrey: Is “we’re only able to access EDID by talking to the GPU through the mailbox channels.” is that a RISC OS limitation or a Pi Firmware one?
i.e. would Raspian be able to do it or do I need to ask the Foundation to modify start.elf?

Pi firmware limitation, I believe. I’ll have a proper look through the userland sources tonight, but certainly for the mailbox interface it’s only possible to read EDID, not write it.

i.e. would Raspian be able to do it or do I need to ask the Foundation to modify start.elf?

I repeat previous question – please provide a convincing test case of why end user equipment should even have the capability to write to the EDID?

If you are manufacturing something, you should be able to set up the device with an IIC interface during manufacturing.

Rick: As I said to Dave “Part of my laptop project would involve end users connecting up a wide range of LCD panels to the HDMI-LVDS section of our board we are developing. Everyone having to buy special cables for a once of use is not feasible.” The end user will be doing the final stage of manufacturing!
I think it will make more sense when I announce full details of the project.

Rick: As I said to Dave “Part of my laptop project would involve end users connecting up a wide range of LCD panels to the HDMI-LVDS section of our board we are developing. Everyone having to buy special cables for a once of use is not feasible.” The end user will be doing the final stage of manufacturing!
I think it will make more sense when I announce full details of the project.

From which I, and probably others, can only conclude that your project needs to include the equivalent of an adapter cable as Rick was suggesting. Said element does any required write. However, if it is for a Pi then it seems that’s irrelevant as the GPU doesn’t seem to allow that.

It is for the Pi. I think that if necessary I can persuade the Foundation to make any necessary changes to the firmware. If that doesn’t happen then I believe we can include some links on the board that would obviate the need for an adaptor cable which I’d expect to be £25+ each, even if 100 ordered!

Pi firmware limitation, I believe. I’ll have a proper look through the userland sources tonight, but certainly for the mailbox interface it’s only possible to read EDID, not write it.

Yeah, it looks like it’s a firmware limitation. There’s a VC_TV_DDC_READ command supported by tvservice, but no write command.

Thanks for the info Jeffrey. I’ll contact the Foundation.

Chris said:

The end user will be doing the final stage of manufacturing!

after he said:

Part of my laptop project would involve end users connecting up a wide range of LCD panels to the HDMI-LVDS section of our board we are developing.

So, erm, aren’t they doing the “final stage” anyway? :-)

Don’t you have to initially configure the device in some way so it knows how to address the display panel?

that would obviate the need for an adaptor cable which I’d expect to be £25+ each

Really? Wouldn’t it be possible to have a header on the board, and when the user is doing the initial setup stuff, you just hook up a cheap bit of ribbon cable with an IDC plug at each end to go between your board and the Pi’s IIC bus¹. Run a program to set up the EDID and so on using standard IIC commands, then the user can disconnect the programming cable and reboot. Job done.

On the topic of messing with EDIDs, this is an interesting concept: https://media.blackhat.com/bh-eu-12/Davis/bh-eu-12-Davis-HDMI-WP.pdf

¹ Only thing to look out for is the voltage of IIC on HDMI is 5V, but a little voltage convertor will take care of that.

Oh, and if you have a PC, this might be useful to have around:

http://www.entechtaiwan.com/util/moninfo.shtm

I wonder if something similar couldn’t be put together for the Pi¹ now that we have EDID access working?

¹ Etc, etc, depending on hardware capabilities. ;-)

Why write to the EDID of the hardware at all? You could write the EDID to a file, and just load the file (we support loading EDID blocks).

Referring to Jeffrey’s multi display adaptor support, if the HDMI LVDS is classed as a different display to any external adaptor, we simply set display 0 to be the loaded device, and display 1 (the external) will read the EDID as the device gets plugged in.

Also a little surprised that displays are being provided without any EDID on board: are you sure they don’t have an EDID block built-in?

Rick: I was thinking similarly actually.

If we had an EDID reader / editor to create EDID files, we could use EDID completely instead of MDFs. Much of the code already exists (all the nasty GTF and CVT timings are built into ScreenModes, plus standard modes should be tick/box options).

Those people running RISC PCs/A7000s can use a Pi or other machine to read EDID blocks and save them.

There will be a small subset who can’t get the EDID data for their display or it doesn’t exist. They would need either MDFs converted to EDID, or the ability to write an EDID. (Side note: it would be useful if anyone could assemble instructions on reading and saving EDID data from other platforms for those users when EDID goes into the main build).

The benefit would be that MDF is quite limited in what it can do. EDID offers lots of support for colour models, audio configuration, etc – data we would need to build in to provide equity between MDF and EDID. And being a standard, it saves us reinventing the wheel.

Hi William. As someone who knows more about EDID than I will probably ever know. Could you give me a call to discuss please? Chris 01903 523222 work hours including today until about 4.30p.m.

Chris: EDID is just a data block stored on the display, that the host machine can read to configure the display. It effectively is a very compact but much more content-rich version of an MDF. It SHOULD be supplied by the manufacturer of the display, and it’s rare for any display in the last 10 years+ NOT to have an EDID.

It requires two things:
- The host machine to be able to use its interfaces to read it (which is why the RPC/A7000 can’t – the VGA standard they used is too old).
- The display to support it. I can only really see two situations there – a device supports EDID data (and has it stored), or it doesn’t (and therefore won’t have the facility to store the data).

The big benefit of having displays which support EDID is that hot-swap is possible – you don’t need to change the MDF, you just plug a new display in, read the EDID off the display, and we’re off with a different display.

So – in the context of that, I am struggling to see how you could manage to acquire a display which has the hardware to support EDID data, but then doesn’t actually have a valid data block. More likely is you’ll get displays which support EDID completely (in which case as long as the graphics driver supports reading it, you’re sorted); or you’ll get displays which have no EDID support – which boils down to writing an MDF (or we now have the option of writing an EDID file – so the data structure of EDID but in a file.

You might, like the RISC PC, have a display which supports it but hardware which doesn’t. In which case the solution is read the EDID off using a device which can such as a regular Pi), and save the data block to a file.

Wikipedia’s page will tell you what the characteristics of an EDID data block are. Basically I’ve been changing ScreenModes so that data block can be processed instead of an MDF file. *LoadModeFile then doesn’t care which of the two it is given, and a new command, *ReadEDID, calls the command Jeffrey is describing to load it into memory (making us hardware-agnostic).

Does that help?

The problem that Chris is facing is that EDID/DDC isn’t part of the LVDS/FPD-Link spec. Indeed, LVDS is just a way of encoding a signal – it doesn’t dictate what that signal is (video, audio, data, etc.)

Some LVDS-based display interfaces do support EDID/DDC as part of their spec (e.g. OpenLDI), but for your basic run-of-the-mill LCD panel I suspect all that you’ll get given is the panel, the LVDS video interface, and a datasheet from the manufacturer telling you what timings it needs. If you wanted to put the LCD inside a monitor you’d connect it up to a VGA/DVI/HDMI decoder and stick an EDID EPROM in there. If you were making a mobile phone or laptop you’d probably want to cut your costs by skipping out on the EDID EPROM and just bake the display timings straight into your OS or drivers (and avoid VGA/DVI/HDMI by interfacing straight to a GPU that supports LVDS output).

So in response to the lack of EDID, it looks like most hobbyist HDMI-LVDS adaptors either expose the DDC pins so that you can connect up your own EPROM, or include an EPROM in the adapter board (e.g. this one includes a PIC so that the DDC/IIC interface can be used both for EDID and for controlling the display brightness)

Jeffrey: Ah, OK.

So – the options are to expose it as you say via the generic IIC SWIs. I absolutely think the EDID SWIs should be read-only.

You probably should (if possible) expose an LVDS display as a separate display for the graphics driver to the external HDMI port (which we will need to do if we want such a display to have multi-monitor); and we create an EDID file to power the display.

Why? Well, in an ideal world (like on a secure OS or something!) you would want EDID read operations to be considered safe and at ‘user land’ level. EDID writing should require elevated privileges as it’s potentially dangerous. I don’t think there’s anything in our EDID code that even the most malicious bit of work could cause trouble with, but in theory I guess you could claim the display uses settings which could potentially damage it.

At the very least, the interface should be so different that a developer has no chance of writing to it instead of reading by accident.

Thanks William for the info and Rick for the links. I need to do some more reading up on the subject.
We have boards with the two chips we are considering on and have been able to test them on a Pi but are rather hindered at present as I still haven’t managed to get the data sheets for either of them.
William, there are a few questions I have that I don’t want to ask in public at present, so if you could email me I’d really appreciate it.
Re custom cables. I have worked out we can achieve the same effect with jumpers on the PCB, but a software method is my preference for a number of reasons.

a software method is my preference for a number of reasons.

Making it intentionally writeable seems to me to be opening a potential vulnerability as a cure to a (maybe) one-off process when assembling a display unit.

To quote you:

Part of my laptop project would involve end users connecting up a wide range of LCD panels to the HDMI-LVDS section of our board we are developing.

If the user is going to need to be competent enough to connect up a display panel, why the reluctance for a programming cable for the EDID device?
Sure, I would agree that to have the Pi’s firmware be capable of writing to the EDID directly would be pretty useful for you. I’m just concerned about potential side-effects.

Sure, I would agree that to have the Pi’s firmware be capable of writing to the EDID directly would be pretty useful for you. I’m just concerned about potential side-effects.

It does sound like the tail wagging the dog.

To be honest, for Chris’s specialist application, I’d have thought that the suggestion of reading EDID data from disc would be the best option.

As Jeffrey said re EDID being writeable: “Because that’s what the spec says!” I try to stick to standards!

Steve: “reading EDID data from disc would be the best option.” I can’t see how that would work. On power up it is primarily the HDMI-LVDS chip that needs the data and it will expect it to be in the flash memory attached to it.

Also I think some/many? of the comments are assuming RISC OS only use. The project is not viable unless significant numbers of Raspian etc users are not using it.

“Because that’s what the spec says!” I try to stick to standards!

Citation?

Look in here:
ftp://ftp.cis.nctu.edu.tw/pub/csie/Software/X11/private/VeSaSpEcS/VESA_Document_Center_Monitor_Interface/

You will find a lot of information about EDID. It looks as if the older DCC method had a way of writing data, though I’m not sure this was anything like EDID (May have been presets for brightness, contrast, etc?).

Then look at this: http://ww1.microchip.com/downloads/en/DeviceDoc/21682E.pdf
It is a chip designed to continually transmit EDID information. It can be switched to be writeable, but note that the following text is highlighted: “Once switched into Bidirectional mode, the 24LCS22A will remain in that mode until power is removed. Removing power is the only way to reset the 24LCS22A into the Transmit-Only mode.”.

If you read up on EDID hacking, you will notice that you will probably need a specific graphics card. Most don’t permit write operations. The VESA BIOS description mentions no functions for writing.

Given that the EDID block defines what the monitor is, what its exact timings are, and it’s colour relationships, etc – are you really certain that this is supposed to be modifiable by the end user?

The project is not viable unless significant numbers of Raspian etc users are not using it.

It is then fairly moot. In the case of a Pi, it doesn’t really matter what RISC OS thinks or wants. The EDID is read from the monitor by the GPU which creates the most appropriate display. In cases where this is impractical or broken, the GPU can be instructed to use a specific display mode by modifying the CONFIG.TXT file.
This was necessary for me after my monitor got itself “stuck” in 800×600. I probably should have tried to dump the EDID but at the time I was more interested in getting a working display!

I’ve just tried the latest ROM with the blended and feathered drop shadows, which look really good. It kind of shows up the lack of alpha channels in most of the icons on the desktop though. Many have a jaggy edge where they’ve been “hard” anti-aliased to the typical window background colour.

Many have a jaggy edge where they’ve been hard" anti-aliased to the typical window background colour.

Yes, we just need some improvements to !Draw, !Paint and !ChangeFSI now to assist with creation of iconsprites with a transparent background colour rather than solid…

As an interim step, a nice online tutorial of how to create a set of iconsprites for an application (!Sprites, !Sprites11, !Sprites22, !Sprites + alpha – I forget what naming policy we went for). Maybe for a super-simple icon of a circle blended onto a transparent background. Even if it’s using Gimp, exporting as a PNG and translating into a sprite using a tool on RISC OS, that’d be better than nothing!

!Sprites, !Sprites11, !Sprites22, !Sprites + alpha – I forget what naming policy we went for

!SpritesA, !SpritesA1, !SpritesA2

I should probably add that to the wiki somewhere…

Even if it’s using Gimp, exporting as a PNG and translating into a sprite using a tool on RISC OS, that’d be better than nothing!

Of course the problem there is that I don’t think there are any tools to convert PNGs, etc. to proper alpha sprites (except perhaps ROL’s Paint/ChangeFSI?). They all seem to require some manual tweaking of the sprite afterwards.