shield-specific behaviors

[tehn]

system awareness of shield vs. not-shield

for shield:

• remove i2c headphone errors
• "sleep" needs to be clarified because the device doesn't shut down
• remove battery displays/etc
• anything with wifi??

[catfact]

how would we actually detect shields?

it's the same kernel and everything, right?

can we see something different in /proc/cpuinfo or etc?

query for presence of headphone driver on i2c?

[ericmoderbacher]

Maybe this thread will help:
https://www.raspberrypi.org/forums/viewtopic.php?t=192748

Looks like you can get a cpu revision.

[catfact]

thanks!

capturing that: seems like both these paths should have something usable
/proc/cpuinfo, indeed (maybe messier)
/sys/firmware/devicetree/base/model (human-readable string built by rpi bootcode)

[tehn]

sorry I should've mentioned this is already figured out because we have to id the chip for updates. we do it in update.sh which is in the update folder.

other issues however remain, will post them here when i get a minute

[catfact]

gotcha. so, here:
https://github.com/monome/norns/blob/main/update/update.sh#L56-L62

should also, i dunno, write a config file that matron can use.

[csboling]

I think it would probably work to configure all these things in the matronrc.lua file my screen-decoupling branch (for #1187) loads at startup to decide which type of screen / input source to use.

[tehn]

using matronrc.lua is a good idea--- but i'm wondering where/how the config step should happen. at some point matron will have to self-detect if it's on a CM3 or a shield, and that info can be written to the rc file... so should there always be a user config file?

for example, if the user config file doesn't exist, first copy the default, then append some extra information re: detecting architecture? i suppose since desktop is possibly an option it should check that as well?

[tehn]

fixed by #1250