RPi Screen Mode at Startup

I’ve been trying this for a while now, to no avail…

How do I change the startup mode in the current RPi image? If I change it using configure, I lose the ability to use the RasPi-BuiltIn and it always defaults to Auto (Monitor Type)-Unknown (Colours)-Unknown (Resolution) and runs at 640×480.

If I hand-edit !Boot.Choices.Boot.PreDesk.Configure.Monitor to change the first line where it says:

I have tried using Configure to change the monitor resolution using the Generic mode and I get a load of random letters and numbers, with fragments of mode names in there, plus the odd “proper” looking mode name that works (1024×768 springs to mind). This seems to happen with a LOT of the Monitor Types available.

Anyone seeing the same?

I have tried using Configure to change the monitor resolution using the Generic mode and I get a load of random letters and numbers, with fragments of mode names in there, plus the odd “proper” looking mode name that works (1024×768 springs to mind). This seems to happen with a LOT of the Monitor Types available.

Anyone seeing the same?

Yes. It’s been wrong for months now.

I get a load of random letters and numbers, with fragments of mode names in there, plus the odd “proper” looking mode name that works

I think that is a weird side effect of newer mode information with an older version of Configure.

when I reboot, it just returns back to
oadModeFile on a reboot.

I presume you mean suffixed with ‘|’ (I think Textile thought you were defining a table or summat!)? If so, I’ve not tracked down exactly why this happens else I’d tear out the offending code and set fire to it. It is REALLY annoying.

I solved the problem with some lateral thinking. I locked the file. Now whatever it is that changes the file leaves it alone. GOOD.

Anyone seeing the same?

You Are Not Alone. <cue spooky music>

I think that is a weird side effect of newer mode information with an older version of Configure.

Another one of those things from the other year. Jeffrey made some graphics changes and the rom and harddisc elements need to change together.
For people hanging on to old setups that make one change they also have to make the other.

I solved the problem with some lateral thinking. I locked the file. Now whatever it is that changes the file leaves it alone. GOOD.

That was my solution.

Yes – I was looking at ScrnSetup (with regard to EDID support) and realised that Other issues exist which need tackling before EDID can be added. Can confirm that menu behaviour was ‘a bit weird’ and I too found if I added *ReadEDID it would trash it per above. Came to the conclusion it was not quick fixable, needs looking at properly and that hasn’t happened yet.

As Rick and Steve say, the garbled mode names are due to a bug in old versions of ScrnSetup where it wasn’t correctly filtering out modes which it doesn’t understand. That bug was fixed in December 2013 – the big problem here is that it’s never made it into one of the Pi RC images. However now that the Pi 2 is out I believe a new RC, based around current ROM+disc image, is in development.

The ClrMonitor utility in !Boot.Resources.Configure is what’s responsible for turning “LoadModeFile” into “|oadModeFile”. It will do this whenever the OS reports the CMOS as having been reset, the theory being that the user may have reset his CMOS in an attempt to get a usable picture. But with the way the Pi stores its CMOS settings in the ROM image, this will have the effect of nuking the file whenever you update your ROM. However if it’s being reset on every reboot then that indicates a problem. Does *Help SDCMOS show that SDCMOS is running? Is the riscos/img file writable?

RasPi-BuiltIn is a bit of a hack, since it’s located in ResourceFS rather than in the disc image. Hopefully it can go away once EDID support matures a bit.

But with the way the Pi stores its CMOS settings in the ROM image,

Sort of begs the question of why the CMOS is stored in the ROM image when it could as easily be saved in a little file called CMOS. In the absence of a CMOS file the system assumes a reset. A reset routine would simply need to rename the CMOS file as OLDCMOS…