State of large screen modes on Pandaboard

Hi,

I acquired a Pandaboard (non-ES) a couple of weeks back, which I cannot persuade to work through a converter to my monitor which only has 15 pin output.

Just weighing up my options:

1) I am really tempted by a Dell Ultrasharp 27" monitor for more ‘serious’ purposes. I was thinking the multiple inputs would allow me to use it for both ‘serious’ stuff and RISC OS stuff in different inputs. However, can Panda cope with the 2560×1440 modes without video artefacts now? If not, can it be forced into a different mode at startup as per the Pi?

2) has anyone had experience of converting the Panda’s DVI to VGA with modes set? This would obviously need to not only convert the signal but again fix the mode.

I should point out on my TV with a standard 1980×1080 output through HDMI the machine works fine.

> can Panda cope with the 2560×1440 modes
I don’t think so.

> can it be forced into a different mode at startup
I believe it’s possible… Just choose another mode. On Pandaboard, modes are physical. So 1360 × 768 is 1360 × 768. On Pi, it’s different.

Choose a mode through the Standard RISC OS methods, or by messing with settings in boot.scr (assuming I am right in what I think is referred to in OMAPpedia)?

I would say with RISC OS methods…

My screen does not support 1920×1080/30Hz. With the Raspberry Pi, i can use this mode, since 1920×1080/30 is in fact a virtual mode inside an HDMI one (1920×1080/60). But with the PandaBoard ES, the mode used by the screen seems to be the one defined by RISC OS. So if you use 1920×1080/60, you’ll not use a virtual 1920×1080/60 mode inside a 2560×1440/60 one, but a real 1920×1080/60 mode.

All of this needs to be confirmed :)

RISC OS methods.
You need a MDF (Monitor Definition File) for the mode you will use. I use a 1920×1980@60Hz one with my Panda and RPi. Not sure what the limitation is. Edit your own (I can also do it for you) and try it (I can not).

[cut – obsoleted by followup post]

OK – that’s weird. Got the Pandaboard running with my VGA monitor. It appears to work as long as the (powered) HDMI → VGA adaptor is UNPOWERED.If the 1A 5V DC suply is provided to the active convertor, then the Panda refuses to power up. Once initial startup has been achieved, you can provide power or remove it and it will work fine (there seems to be no difference on the Panda whether the external supply is provided or not). On the Pi – no power = no picture. Can anyone with better understanding of the hardware than I explain why that might be? My poor brain was of the understanding active convertors needed additional juice – that was the whole point of them right?

Still got a horrid picture (MDF tweaking etc needed) and haven’t yet worked out how to change the CMOS settings in a persistent way (edit the CMOS file on the Boot loader)? But progress!

Back to the Pi for a bit for some sanity :-).

I was going to say could it be an earthing problem, but as both the computer and the HDMI→ VGA power adapter’s are likely to be double insulated I think I need to say ‘could it be a neutral problem’?

Also I’m not sure why you are getting a horrible picture. The HDMI→ VGA adapters we’ve tried (and sell) have looked quite good even at the wrong resolution. Though our tests have all been on Pi’s not PandaRO’s.

Yeah – not sure if that is just MDF tweaking needed or more to it. The picture on the Pi is fine with the same kit which is why I am puzzled. However if I was going to upgrade monitors the best practical choice is a nice 2560×1440 panel for real work, which may just lead to different video issues.

I don’t think the adaptor itself is causing the bad video as I get a lovely 1650x image using the same adaptor on the Pi, albeit by configuring the mode in the config.txt at startup.

Clearly more prodding needed :-(.

So – next step then will be to build an MDF to see if that gives me a stable picture.

I’ve compiled EDIDDecode (and read the bounty page on EDID). Has anyone written a tool to extract the EDID from the monitor? I’m aware that the bounty suggests all the components are there (and the plan for the bounty was to tie them all together in a sensible way into the OS).

Has anyone written a tool to extract the EDID from the monitor?

Yes, I’ve written a small app, EDIDtoMDF, that reads the EDID using GraphicsV and then passes that to EDIDDecode to produce a MDF. The output needs to have its header trimmed for the OS to accept it but other than that it seems to work okay.

that reads the EDID using GraphicsV

Does this work on a Pi? The GraphicsV command talks about IIC, however Pi requires talking to the GPU…

Does this work on a Pi?

Don’t know, I don’t have a Pi to test. I’ll try to tidy up EDIDtoMDF and upload it tonight.

Fred: Is your app available from anywhere? Are you using that towards the EDID bounty or just using it standalone? I presume you have to use the internal only HAL_IICOp call to gather the EDID (was going to attempt to write an EDID reader but little point if someone has already done so).

That makes several of us. ;-) There’s an EDID→MDF program in the source repo. Don’t remember where (I’m on the PC), I found it while wandering around. That just leaves GraphicsV which, while talking about IIC ops, seems a bit low-level and, as I hinted above, might be prone to problems on devices where there is another mechanism for reading the data…

My reason for doing this is quite possibly related to the original poster’s problem with the Panda. I rarely have any trouble getting output from my Pi using the HDMI→VGA adaptor. It doesn’t like RaspBMC doing HD1080, but with RISC OS there isn’t a problem. This is because the GPU is in charge of video output. Everything the OS tries to do is filtered through the GPU, even scaling a smaller display to fit that which it has been configured for. It’s quite nifty.
The OMAP (OMAP3 for Beagle, OMAP4 for Panda) is more like traditional video hardware where the OS configures it. All the boring rubbish to do with the video timing. For this reason, it is a lot more likely that an adaptor may fuss. My Beagle xM is quite stable when the display appears…but getting the display can be like self-flagellation. Furthermore, if I need to reset the board, the adaptor can reject the exact same display mode that it was using happily for the past few hours. Grrr!
[when this happens, I find going to the command line, blind-typing to go in to BASIC, and just changing MODE a load of times (28→15→13→0) can kick the adaptor in to life. Sometimes. But it might involve a reset or two along the way. I kind of wish the adaptor was smart enough to generate its own diagnostic display (even plain VGA!) if the input was not understood, but, that’s too much like helpful ’eh? ;-)

Fred: Is your app available from anywhere?

A rough-and-ready copy can be found here

Are you using that towards the EDID bounty or just using it standalone?

It’s a stand-alone app that I threw together when Jeffrey said that all the required bits were there. I’d love to work towards the bounty but I’m afraid that’s beyond me at the moment.

I presume you have to use the internal only HAL_IICOp call to gather the EDID

No, I’m just calling GraphicsV 14 which is normally claimed by the kernel and passed to HAL_VideoIIC.

Interesting. Trialled on my Pi – with basically no worthwhile output. Remember however I am using an HDMI→VGA adaptor. If I get time this weekend I will try it on my TV which has HDMI.

Next Trial will be on the Pandaboard.

Tried on the Pandaboard. It managed to pull the MDF off the monitor happily (despite the HDMI→VGA). Well done Fred :-).

The picture is still not 100% stable – albeit massively better than before, but not as stable as I see on the Pi.

It’s making me wonder if this is a PSU issue – particualrly with the fact that the Panda seems to be able to power the HDMI→VGA adaptor itself when it shouldn’t. I am currently using an A9 PSU (5V 4A) – as the specs as far as I can see match those described on the OMAPPedia page.

Has anyone else tried the A9 PSU with a Pandaboard? I don’t particularly want to buy an extra PSU ‘just to see’ but if I know a PSU change is likely to help then will certainly consider that.

Doesn’t seem to work on my BB-xM running RO 5.20 with a DVI-D monitor. After dragging the icon to a directory my machine becomes completely unresponsive and has to be switched off.

If I get time this weekend I will try it on my TV which has HDMI.

Just tried it on my Pi connected to a Samsung SyncMaster 2333hd tv/monitor with HDMI. Nothing useful, I’m afraid.

On the Pandaboard you need to keep the screen refresh at around 40Hz to get a good image.
Otherwise there are weird colour effects where there are images with plenty of colour.
It’s a known issue with the pandaboard, but it doesn’t always show up – so you can run at 60Hz but it will sometimes look funny.

On the Pandaboard you need to keep the screen refresh at around 40Hz to get a good image.

I presume you mean when in a 1920×1200 mode. 1920×1080 or lower will do 60Hz o.k.

From my brief test it seems I have to be below 1600×1200 at 60Hz, or maybe I just didn’t trigger the issue with the same graphic when I got down to 1600×900
Some graphics seem fine at 60Hz, others cause the issue…It is weird.
But to test it you do need a sprite with a lot of colours on it.
But as I’m on an LCD I don’t think it will make any difference running at 60 or 40 for running anything on RISC OS will it?
I am assuming there is no real vsync as such on an LCD like there was on the old cathode ray monitors?

But as I’m on an LCD I don’t think it will make any difference running at 60 or 40 for running anything on RISC OS will it?

We find many LCDs want 60Hz and give no display at 55Hz or 50Hz. If they accept lower refresh rates (Frame rates) then yes they look fine.