[split] Maintaining config.txt

[split] Maintaining config.txt - Printable Version

+- Moode Forum (https://moodeaudio.org/forum)
+-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3)
+--- Forum: Support (https://moodeaudio.org/forum/forumdisplay.php?fid=7)
+--- Thread: [split] Maintaining config.txt (/showthread.php?tid=3878)

Pages: 1 2

RE: Official moOde 7.2.1 support thread - fdealexa - 05-30-2021

(05-29-2021, 05:27 PM)adrii Wrote: Hi Tim

In config.txt, if user settings come after Moode settings then they can override them. It seems like the options are:

put user settings in a separate file and include it last in config.txt, but then raspi-config changes (which I imagine will occur even if unnecessary) might be added both before and after the include statement

put Moode settings in a separate file and include it first in config.txt, then any settings in config.txt are user settings (including changes made by raspi-config) and always come after Moode settings.

The second option seems better from the point of view that it ensure that user settings come after Moode settings. However, there may be other aspects to consider, and I don't know all the details of the config system.

Adrian.

Hi Adrian,
I apology to have introduce the "raspi-config" and if it had created some confusion.
I have a very limited experience in the i2c oled : I have tested them on rpi3 and rpi4 and, normally, I used raspi-config and baudrate 800000 in the config.txt and I never got any problem.
Best regards and excuse me, please , for the interrupt,
Francesco

RE: Official moOde 7.2.1 support thread - adrii - 05-30-2021

Hi Francesco

It is helpful that you mentioned you are configuring I2C with raspi-config, and worth taking into account that other people will use it too.

Adrian.

RE: Official moOde 7.2.1 support thread - bitlab - 05-30-2021

Since this isn't a support question, maybe we should continue the discussion about config.txt in an own feature request thread?
That makes it easier to read the "Official moOde 7.2.1 support thread" for people who actual are looking for support as opposed to developing new features ;-)

RE: Official moOde 7.2.1 support thread - Tim Curtis - 05-30-2021

(05-29-2021, 05:27 PM)adrii Wrote: Hi Tim

In config.txt, if user settings come after Moode settings then they can override them. It seems like the options are:

put user settings in a separate file and include it last in config.txt, but then raspi-config changes (which I imagine will occur even if unnecessary) might be added both before and after the include statement

put Moode settings in a separate file and include it first in config.txt, then any settings in config.txt are user settings (including changes made by raspi-config) and always come after Moode settings.

The second option seems better from the point of view that it ensure that user settings come after Moode settings. However, there may be other aspects to consider, and I don't know all the details of the config system.

Adrian.

Hi Adrian,

The second option works and is an excellent way to protect the config.txt settings that are manipulated by moOde :-)

The challenge is how to deal with it in the in-place update because existing config.txt files may already have user settings. Simply inserting the line "include config.txt.moode" at the top of existing config.txt files would be problematic because user settings override moode settings and moode only manipulates the settings in config.txt.moode.

For example

Existing config.txt and some user settings after it. The in-place update has added the include line at the top. The file /boot/config.txt.moode contains the moOde manipulated settings i.e., all the lines above "user-setting-1"

Code:
include config.txt.moode

disable_splash=1

disable_overscan=1

hdmi_drive=2

hdmi_blanking=1

hdmi_force_edid_audio=1

hdmi_force_hotplug=1

hdmi_group=0

dtparam=i2c_arm=on

dtparam=i2s=on

dtparam=audio=on

#dtoverlay=disable-wifi

#dtoverlay=disable-bt

user-setting-1

user-setting-2

user-setting-3

.

.

User configures an I2S DAC using Audio Config. Since moode would be manipulating /boot/config.txt.moode we end up with the lines "dtparam=audio=off" and "dtoverlay=allo-boss2-dac-audio" in that file but remaining in /boot/config.txt would be "dtparam=audio=on" which would override the earlier line and thus cause breakage due to on-board audio and I2S device both on.

A second approach would be to overwrite /boot/config.txt with the new one and start from scratch. This would mean users would need to re-add their settings after the include line in the new config.txt otherwise there would be breakage.

Code:
pi@rp2:~ $ cat /boot/config.txt

include config.txt.moode

pi@rp2:~ $ cat /boot/config.txt.moode

disable_splash=1

disable_overscan=1

hdmi_drive=2

hdmi_blanking=1

hdmi_force_edid_audio=1

hdmi_force_hotplug=1

hdmi_group=0

dtparam=i2c_arm=on

dtparam=i2s=on

dtparam=audio=off

dtoverlay=allo-boss2-dac-audio

#dtoverlay=disable-wifi

#dtoverlay=disable-bt

pi@rp2:~ $

So there is breakage either way with in-place update to the new method. The second approach is prolly the safest and cleanest but would require some effort on our part to help users re-add their specific settings.

Another consideration would be whether to also place mpd_oled settings in an include file for example "/boot/config.txt.mpd_oled" and manipulate that file instead of config.txt.

-Tim

RE: Official moOde 7.2.1 support thread - adrii - 05-31-2021

Hi Tim

The first config.txt update could possibly be managed by a script. It could scan the contents of 'config.txt.moode' and look for corresponding 'param=val', 'dtparam=param=val' (any others? [EDIT: I see it is possible to have a line like 'dtoverlay=lirc-rpi,gpio_out_pin=16,gpio_in_pin=17,gpio_in_pull=down', which may complicate things, but there may be a utility to help process the files]) in config.txt. If a match is found then the corresponding values could be compared: if they are the same then the line is deleted from config.txt, if they are different then the line is kept as an override in config.txt. Maybe some particular setting combinations could also be detected and handled. (I could help with the script.)

If there was going to be an mpd_oled settings include file it would probably be better to just have a single general user settings include file (which would be the first of the two options from earlier) as, for example, possible mpd_oled settings like the I2C bus speed can affect other I2C devices being used, and vice versa.

Adrian.

P.S. If you decide to split this off into a fresh topic I will follow up there.

RE: [split] Maintaining config.txt - Tim Curtis - 05-31-2021

The other option is to leave the maintenance of config.txt as-is.

It's never overwritten during in-place update and /etc/modules was only overwritten during that one past update and given that we will be including i2c-dev in it going forward it also would not be overwritten during in-place update.

RE: [split] Maintaining config.txt - adrii - 05-31-2021

Hi Tim

I thought that the Moode upgrade had commented out one or more of my settings in config.txt, but if the upgrade doesn't do that, and user settings are already preserved in config.txt, then the i2c-dev loading change should be all that is needed for mpd_oled to continue working after a Moode upgrade.

Adrian.

RE: [split] Maintaining config.txt - Tim Curtis - 05-31-2021

The only changes to config.txt were in the updates for release 6.6.0 and 6.7.0 and these did not involve mpd_oled.

Code:
r660

# Update /boot/config.txt with HDMI settings

sed -i '/hdmi_blanking=1/a hdmi_force_edid_audio=1\nhdmi_force_hotplug=1\nhdmi_group=1' /boot/config.txt

r670

# Rename wifi and bt dtoverlay names

sed -i 's/pi3-disable-wifi/disable-wifi/' /boot/config.txt

sed -i 's/pi3-disable-bt/disable-bt/' /boot/config.txt

I think we are good leaving things as-is regarding maintaining config.txt :-)

RE: [split] Maintaining config.txt - adrii - 05-31-2021

Hi Tim

Thanks for looking at this. All sounds good. Looking forward to the next upgrade!

Adrian.