framebuffer select argument

[catfact]

added matron argument for specifying path to framebuffer used by cairo

defaults to /dev/fb0

change it like so:

matron -f/dev/fb1

have only tested on norns to make sure nothing is broken. @okyeron (or anyone else requiring this feature) - would be great to get feedback before we merge

addresses issue #749

[okyeron]

Clarification - where would this argument be used?

matron.sh ? Attempting this:

#!/bin/bash
./build/ws-wrapper/ws-wrapper ws://*:5555 ./build/matron/matron -f/dev/fb1

lead to errors:

10.0.1.18 ~/norns $ ./matron.sh 
attempting to bind socket at url ws://*:5555
./build/matron/matron: invalid option -- 'f'
./build/matron/matron: invalid option -- '/'
./build/matron/matron: invalid option -- 'd'

[catfact]

ah right, hm - i'm not sure if ws-wrapper currently passes arguments correctly since we've never used them before. that might require a fix.

can you try running matron with the argument, without ws-wrapper?

[okyeron]

Update - I screwed up and didn't have the updated args.c compiled. So I fixed that and now I can run matron.sh without errors... but no display activity (with either ./matron.sh or ~/norns/build/matron $ ./matron -f/dev/fb1).

[catfact]

and you usually get display to work by hardcoding /dev/fb1 in screen.c?

[okyeron]

Gah - apologies. I'm doing it wrong. I didn't get all the changes. One sec and I'll report back

[catfact]

things i have verified:

• with no argument, the default /dev/fb0 is used and norns continues to work.
• with -f/dev/fb1, screen.c uses the requested path. norns doesn't work cause this FB doesn't exist.

that's about all i can do from here 🤷‍♂️

[okyeron]

Sorry - i did something dumb and only grabbed the args.c changes, not the whole branch. 🤦‍♂️

Works like a champ!

Please approve!

[okyeron]

Last question then - does this need to update anywhere aside from matron.sh?

norns-image/config/norns-matron.service perhaps?

[catfact]

yeah, i guess that's where you would make the change persistent on your system. we don't need to change anything upstream to keep it working here.

so, i don't know that this is hugely more convenient than hardcoding and recompiling, but it's definitely a little cleaner.

we are gradually working towards adding platform options to the waf configure step, that's another possibility down the road.