config.txt for Raspberry Pi

Hi all.

We’re working on a new release of RISC OS Pi (RC12) – little more than a maintenance release, to be fair – and would like to know if anyone has some compelling arguments for changing the default config.txt contents such as we shipped in RC11. All views welcome.

As a footnote, the changes we discuss here might actually miss the RC12 update (because we’re going to roll it out to the Raspberry Pi guys tonight!) but it will be useful feedback for a more comprehensive update that’s planned in the next couple of months.

All views welcome.

I think perhaps creating a “stable” download rather than two betas of different age might be handy.
I noted the possible source of confusion when soemone asked about correct files for updating with and I thought OK, which beta should I tell them is the right beta?

I just typed all this only to end up at our login page and lose it all. So…..

We are aiming for a stable download but it will take iterative betas to arrive there. And there’s no correct beta release on our site; they are just snapshots of the head of the development tree. Our releases through Raspberry Pi are slightly different; they are a half-way house between beta and stable in that we’re selective about what goes in and what doesn’t, and give them a degree of testing.

However, a true ‘stable’ (5.22) release for Raspberry Pi is still a few months away.

I just typed all this only to end up at our login page and lose it all.

We’ve all been there.

For the Raspberry Pi 5.22 release I suggest some more free bundled software. I’m just not sure exactly which bits of software (that are not already included in RC11) are (i) really useful and (ii) something the author is willing to allow to be released/distributed in this way.

Anyone got the config.txt content to hand, and can paste it in here?

Also, should we not consider which version of the Pi firmware to include?

I suggest some more free bundled software

We’d be happy to include more as long as:

a) it’s free
b) we can get source where required
c) the author gives us permission where required
d) it’s of sufficiently good quality.

How about RiscLua?
a) It is free.
b) Source ( ANSI C + Objasm) is available from http://www.wra1th.plus.com/lua/zip/rlua_570.zip .
c) MIT licence. See !lua.doc.readme/html.
d) Ask around. If you are worried, my contribution is a tiny fraction of the RiscLua package and I guess Lua’s reputation is very solid ;).

The current CONFIG.TXT file looks like this:

fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

We’d be happy to include more as long as:

a) it’s free
b) we can get source where required
c) the author gives us permission where required

You have my permission to include any of my software if you want:

http://kevsoft.co.uk/

How about RiscLua?

I second that – I think it would be a great addition.

Also, it would be great to have AppBasic included, if at all possible.

I have just spoken to Joe Taylor on the telephone. He is rather ill and could not speak long, but he did give his permission for AppBasic to be bundled with the RISC OS distribution, if ROOL were happy to do so. It would not be maintained, of course. I have version 3.02 (29-Nov-2007). Does anyone have a later version?

We’d be happy to include more as long as:

a) it’s free
b) we can get source where required
c) the author gives us permission where required
d) it’s of sufficiently good quality.

You have permission to include any of mine, it’s all on !Store. It is for someone else to say whether item d) is satisfied!

Try to ensure that common filetypes are associated with sensible applications and have icons defined.

E.g. IIRC DigitalCD does not claim MP3 by default, and JPEGs should go to SwiftJPEG (fast) not ChangeFSI (slow!).

DigitalCD isn’t in the distribution so I’ll add it to the list as a potential candidate. AppBasic looks like it could be a little more time-consuming given it includes some third-party components for which licences/source/permissions will also be required.

I’ve been trying to update our RISC OS Pi distro to include a newer NetSurf but keep getting warning pop-ups about being unable to verify SSL certificates (for the ROOL site, for example, and for https://www.google.com) – anyone know what causes this and what the work-around is. I was told it might be due to a bug where it’ll do this if there’s no choices file present, but that didn’t fix it. I don’t see the same issue on my Iyonix.

Anyway, this is just FYI – I’m talking to one of the developers about it and may try the mailing list, too.

Obvious question – is the time set correctly on the Pi?

OK, so given:

fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

According to http://elinux.org/RPiconfig

a) the fake_vsync_isr option doesn’t exist (maybe it used to?)
b) the init_emmc_clock value above is the default, so why bother specifying it?

Should some of the common HDMI/overscan settings be included, even if commented out, just to make things a bit easier for people who need those common tweaks?

Is it worth including commented out parameters, such as HDMI audio and possibly common resolutions and frequencies to override EDID?

For example:

#Send sound over HDMI if supported
#hdmi_drive=2

#Disable HDMI overscan
#disable_overscan=1

#Ignore EDID and force 1920 × 1080 @ 50 Hz
#hdmi_ignore_edid=0xa5000080
#hdmi_group=1
#hdmi_mode=31

a) the fake_vsync_isr option doesn’t exist (maybe it used to?)

AFAIK the option still exists, it’s just not documented on the wiki for some reason. We use it to get a VSync interrupt from the GPU (there isn’t one provided by default).

gpu_mem=64 is supposedly a default setting as well, so that’s another one to potentially drop.

Is it worth including commented out parameters, such as HDMI audio and possibly common resolutions and frequencies to override EDID?

Including a link to the config wiki page would be a good idea too.

Adding lines of this form might be useful:
#Ignore EDID and force 1024×768
#for example for a data projector
#hdmi_group=1
#hdmi_mode=19
#1-4: 720p60Hz = 1280×720
#1-19: 720p50Hz = 1280×720
#1-17: 576p50Hz = 1024×576
#2-35: 1280×1024 60Hz
#2-51: 1600×1200 60Hz
#hdmi_drive reqd for group=1
#hdmi_drive=2

I’ve been trying to update our RISC OS Pi distro to include a newer NetSurf but keep getting warning pop-ups about being unable to verify SSL certificates (for the ROOL site, for example, and for https://www.google.com) – anyone know what causes this and what the work-around is. I was told it might be due to a bug where it’ll do this if there’s no choices file present, but that didn’t fix it. I don’t see the same issue on my Iyonix.

This is one of NetSurf’s most frequently asked questions. Here’s the last time I answered it: http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010912.html

As for software, you’re welcome to any of mine (maybe Cogs might be an interesting diversion?). I’m rather tempted to suggest MBBack, since that’ll do icon bar cropping for you, but that has a convoluted installation and uninstallation procedure, will slow down bootup and will (in normal use) give you a different backdrop every time. It’s more intended to be an optional addition than a core part of the OS.

According to http://elinux.org/RPiconfig
a) the fake_vsync_isr option doesn’t exist (maybe it used to?)
b) the init_emmc_clock value above is the default, so why bother specifying it?

fake_vsync_isr looks to have been added on 2012-09-16:
https://github.com/raspberrypi/firmware/commit/f20e9d70a255d3d02e9d8179415a79a50490bf64

No mention in git of it ever having been withdrawn.

A quick test removing init_emmc_clock seems to suggest that the default set up by the firmware is still 80 MHz, so that wiki page is wrong. You can verify for yourself using *SDIOSlots (the SD stack measures the clock speed at startup – also note there’s a divide-by-two before the clock frequency quoted by *SDIOSlots).

RISC OS doesn’t use the GPU’s more memory-hungry features, so there’s no point in allocating it more memory than that.

Also worth noting is the fact that NOOBS overrides a number of settings by appending them to the end of config.txt, so as OS maintainers, we have no control over them. On an example card here, NOOBS has added the following:

# NOOBS Auto-generated Settings:
hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0

gpu_mem=64

Do we need that much? That’s a quarter of the memory of the original model Bs. I run mine with 32MB and I’d use less if I could.

# NOOBS Auto-generated Settings:

Marvellous. That’s just stuffed¹ everybody who is using a composite video connection.

¹ The word I wanted here is not suitable for a PG audience. Nor a Tetley one.

This is one of NetSurf’s most frequently asked questions. Here’s the last time I answered it: http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010912.html

Sadly, that both isn’t the error I’m getting nor is it the solution. I’ve tried the latest dev build and the 3.0 stable build and still cannot shift this message…

and before anyone blames the ROOL certificates or server setup…