I understand that but I remember reading somewhere that a driver is not used in norns for controlling the hp driver just i2c. From the i2cset command you provided I get that the address is 5 on bus 26 so that would mean i2c-26 ?? I’ll research this more and make a small script if I find a solution, should be doable and would be really useful to me and I guess most of the people that feed the norns output to another machine while listening to fates headphones out.
1 Like
The current picture of my soldering is the third time. They’ve had much more significant connections before, to no avail. This was an SMD-assembled board.
What points should be in continuity? I can measure with a multimeter.
this is accurate. i dunno why changing the address wouldn’t just work (i don’t have a fates, do have norns and norns-shield.)
one thing i noticed:
the -f flag forces a write regardless of whether the device is busy or under kernel control. whereas in i2c.c we give up and print a warning. (do you get warnings in journalctl -u norns-matron? &c.)
2 Likes
Exactly as you said. Without the -f flag it reports the device is busy. So something should be unloaded or should be forced in i2c.c, slave_force wouldn’t work I guess since there is the check first. I will check journalctl after finishing work.
Update:
I2c is used by snd_soc_wm8731, if you blacklist this you can set the headphone volume without force flag. Obviously this is the dac’s driver so audio stops working when it’s unloaded . Possible solutions could be unloading driver and setting sound through i2c which is not optimal or rewriting i2c.c so it uses slave_force, then again 8731 driver may stop being able to control the chip. To me it seems that 8731 expects to be controlled through the driver and not through i2c when the driver is loaded.
I hope to figure this out but it’s much more complicated than originally expected.
Looking for a Fates user online right now to help with an update test/question.
Getting it sorted now
EDIT: update should get posted in a couple hours
2 Likes
@okyeron , what’s the process for updating a FATES now ?
I’ve not done it since the SYSTEM>UPDATE became broken,and I’d like to test on it before releasing a new version of sidekick.
(no rush for the actual update , as i see above, your working on it, more interested in the process)
The manual process is detailed here: https://github.com/fates-project/norns/releases/tag/2.3.1
Basically it’s getting the norns directory over to the fates-project repo. The manual update replaces the norns dirs so it’s pretty seamless from the update archive.
Looks like I had an error in my last update tho, so there’s going to be some extra steps for this new update (instructions coming below)
1 Like
ok, so once you have ‘manually updated it’ once - you then for future updates use system>update, since then that picks up your forked norns repo - k, that makes sense 
Update 200328
If you are on a version prior to 200218, DO NOT USE SYSTEM > UPDATE.
You must update manually via SSH. Instructions are on the release page: https://github.com/fates-project/norns/releases/tag/2.3.1
If you are on 200218
use SYSTEM > UPDATE while connected to the internet.
(please report back if that does not work)
If you are on 200323 you need to do some extra steps via SSH*
First you want to SSH to the machine and do
cd ~/norns
git status
if this says you are ahead by X commits, then you will need to do the following:
git reset --hard origin/master
git pull
git submodule update --recursive --init
then SYSTEM>RESET
and then SYSTEM>UPDATE
* I broke something in the last update so this fixes it.
Sorry for the screw up everyone
14 Likes
Just updated. Everything went smoothly .
Also finally managed to find a workaround for the headphones volume. The easiest way to alter the volume is to just run alsamixer since the driver has full control of the chip and that’s the reason i2c isn’t working. I made a quick hack to have i2c.c sending values to alsamixer and now hp level works fine. I wont share the code publicaly since I literally learnt the basics of reading C three days ago and this is a super ugly hack but if anyone wants to fix it and make it public just pm me .
Oh cool! Send me a DM with that if you have a minute. I’ve always been bothered that the alsamixer thingy (driver?) didn’t expose the headphone levels.
Mine refuses to update… I can get to the “update found: 200328 install?” screen, but pressing K3 doesn’t allow it to proceed with download and installation.
Currently using 200323, followed the steps you mentioned. The only hiccup was that after “git pull” It asked me who I was, (email and name).
git reset --hard origin/master
is the crucial part there. If that doesn’t work, you might need to try the manual update, or I can tell you what to edit by hand to make it work via DM
1 Like
Sorry, amateur mistake of mine to exclude the “–hard origin/master” and ”–recursive --init” parts. Didn’t understand that was actually part of the commands and not just notes. Thank you, it’s working now!
im getting exatly the same errors
fatal: unable to auto-detect email address (got ‘we@norns.(none)’)
192.168.0.8 ~/norns $ git submodule update --recursive --init
192.168.0.8 ~/norns $ git reset --hard origin/master
HEAD is now at d45540f2 fix bad merge
192.168.0.8 ~/norns $
Last part means you should be ok.
Just do the SYSTEM>RESET
and then SYSTEM>UPDATE
(from the on device norns menu)
didn’t work, then It did - thank you yet again
1 Like
All working, went from 200323 to 200328
much thanks
1 Like