Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


[split] Maintaining config.txt
#11
(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
Reply
#12
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.
Reply
#13
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 ;-)
Reply
#14
(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
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#15
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.
Reply
#16
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.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#17
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.
Reply
#18
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 :-)
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#19
Hi Tim

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

Adrian.
Reply


Forum Jump: