Monitor Config on Pi

The RISC OS paradigm where the operating system directly controls the video output and the assumption left over from use of multi-synch monitors that several different resolutions would be equally sharp on the monitor now make monitor configuration on the Pi rather obscure.

The GPU now interacts with the monitor, determines its native resolution [but can be over-ridden by config.txt], works out the various timing parameters [independently of RISC OS’s MakeMode settings ?] and takes whatever the operating system sends it and stretches/letterboxes it to suit (doing what a multi-synch monitor used to do and what an LCD monitor does if it receives a signal that is not at its native resolution).

So all that is needed on the Pi is a single ‘built-in’ monitor type but with a range of the usual resolutions people might want – 480×352 1024×768 800×600 1280×1024 1280×800 1360×768 1440×900 1400×1050 1600×1200 1680×1050 1920×1200 etc. The GPU will then decide the refresh rate. All the other definitions are irrelevant surely?

It can still work the same as it does on Beagleboard/Pandaboard. I’m using a 16:10 monitor at 1920×1200. With the latest rom and firmware I get equal sized black bars at the top and bottom of the screen as the default resolution is 1920×1080.
I tried changing values in config.txt but this just results in a blurry scaled display. I think it’s best not touch config.txt if you want to change resolution.
All I did was to use the existing monitor definition file as on the Pandaboard. One problem i get is if I set the default resolution to 1920×1200 the Raspberry Pi freezes just after running BootFx. At the moment I’ve set the default to 1920×1080 and change it to 1920×1200 once it reaches the desktop.

For the HDMI output it needs a way of setting the native resolution for when autodetect gets it wrong. (even if it’s just a configure option that changes config.txt) The desktop should come up in this mode, unless specifically overridden.

(For the composite it would need to be able to be told what type of TV is in use (colour system, 525/625, horizontal resolution/aspect ratio)

Since people’s eyes differ, choice is needed when handling resolutions, particularly between half-native and native; scaling or borders. (It would be nice if the wallpaper could optionally be displayed in bordered mode.)

Personally I would chose:

scaled for resolution < 45% Native
doubled with borders for 45% < resolution < 50%
doubled for 50%
and borders for resolution > 50%

I know other people’s choices would be different.

Hopefully any mode asked for by an application would be accepted and scaled/centred accordingly.

One problem i get is if I set the default resolution to 1920×1200 the Raspberry Pi freezes just after running BootFx.

Solved the freezing problem by using the 192MiB start.elf instead of the 224MiB one.

(For the composite it would need to be able to be told what type of TV is in use (colour system, 525/625, horizontal resolution/aspect ratio)

Does this work yet, on the Pi?

Does this work yet, on the Pi?

Yes (under Linux). Don’t know under RISC OS.

Don’t know under RISC OS.

Err… That was kinda the question… you know, given where this forum is, and all. (^_^)

I think it does work – I’m going to try it with a 3.5" comp video display (£20).

I have set the following *Configure options:
*configure language 13 [BASIC]
*configure mode 28 [640×480 C16]
*configure noboot
(the object being to start up as a BBC model B but faster and with more memory)
but all that has changed is that the langauage=13 suppresses the start up splash screen, leaving the boot messages in the small window in the centre of a 1920×1080 screen. It also tries to boot (succeeds if the filesystem correcponds to a valid drive and sits waiting if not) regardless of the ‘noboot’ option and ignores the ‘wimpmode’(=‘mode’) setting (which should control the screen mode up to the point the desktop starts, which it should do ONLY if it is the selected language OR boot is enabled and that starts it up).

Is there a reason for this behaviour?

If you want to properly disable the splash screen stuff, just *unplug bootfx.

*configure mode 28 still does not work, neither does *configure noboot

Chris Gransden commented that 1920×1200 freezes the Raspberry Pi. I found that as well. I used to use 1920×1200 @16M colours but since starting over with the most recent Alpha distro it crashes out unless I set the colours to 256 (no friendly restore to previous mode after 5 seconds when selecting “Try”! I guess it’s a memory shortage that goes unchecked. I wonder how this will be handled in the Beta release?

Chris said he solved the freezing problem by using the 192MiB start.elf instead of the 224MiB one. I see similar looking files in the !Boot.loader directory but I haven’t a clue what goes on in there or how to invoke the 192MiB version. I’d sure like to get the mode working again.

All I did was rename the existing start/elf and then copied the arm192_start/elf to start/elf.

It’s even easier with the latest firmware. ‘gpu_mem_256=40’ just needs adding to config/txt.

Thanks Chris. Just for kicks I started by adding “gpu_mem_256=40” in the config/txt file but that didn’t work. I guess I don’t have the latest firmware. So I got it going by renaming the files as you described. I wonder what other effects this will have? Seems like a funny way to switch between shared memory sizes (if that’s what it does).

I have rather belatedly realised that I have a problem with two Raspberry Pis that I have recently used and updated. In Configuration → Screen, the Resolution menu is complete rubbish. It’s clear that the Screen doesn’t understand the MDF – or perhaps it’s not even looking at it. The Display icon on the icon bar, on the other hand, seems to work just fine, and gives me choices that do appear to come from the MDF.

One of the things that puzzles me is that the monitor type, Xerox XA7-17i, is listed in Configuration → Screen → Monitor type, but the MDF for the XA7-17i was absent from the Monitors folder of one RPi. So where did the RPi get the monitor name and the MDF from? Is that list of monitor types derived solely by scanning the Monitors folder, or is there somewhere else?

The MDF is something I put together a few years ago on the Iyonix and has been copied to my BeagleBoards and RPis. They are networked together, so I suppose there is the possibility that the information is coming from another machine – though I cannot imagine why it should.

I don’t know whether reading the MDF has changed as a result of an upgrade. The display has simply worked for ages, so I haven’t looked in that area until recently when I brought up a new one from a new SDHC image, saw this issue, and found that the RPi I’ve had on the desk here for ages (though given a new ROM a couple of times recently) behaves the same.

Sorry if I’ve presented the information in a rather chaotic way. I can’t think of a better one.

I have rather belatedly realised that I have a problem with two Raspberry Pis that I have recently used and updated. In Configuration → Screen, the Resolution menu is complete rubbish.

Did you update both ROM and disc installs in synch?

It’s a while back, but I recall a bug I noted, which Jeffrey quickly fixed¹ which produced a gibberish list in the menu. In the period the support for EDID was being added.

¹ that was somewhere round January IIRC

Steve: EDID support is with ROOL (we’ve to-ed and fro-ed it a bit to tidy the source code up, but unfortunately each phase of that has sometimes added a month or two as both they and I have been quite tied up).

I looked at the ScrnSetup code and I suspect there is quite a bit of tidying up to do from what I recall (not had time to look at it in >6 months).

The MDFs list should come from BootResources:Configure.Monitors – is something managing to overwrite your BootResources$Path?

Steve: EDID support is with ROOL

Yup know that, it wasn’t anything other than a pointer to the time of the change that caused the described fault for me so that Dave was checking the right sort of things (hopefully)

Did you update both ROM and disc installs in synch?

The RPi I brought up recently was a fresh SDHC image, created with the Piccolo app, using a freshly downloaded HardDisc4 image from the ROOL site. So the disc image at least should be up to date. The SDHC card was new.

Don’t suppose this relates to only 5 of the 7 definitions in my MDF being recognised on the BB -xM. All seven used to appear in the Screen config & Iconbar Display menus.