I don't think Kim ever released his source code
[or a compiled binary].
So, any work Kim did either has to be reinvented, or we ask Kim nicely to share parts of it with us - preferably under GPL.

Thats Kim's call to make.

I think the problem we came across was that config.ini is read very late in the piece by the kernel [after the player program starts],

So one problem we run up against is that the player is already started (and in most cases is talking to the serial port as it wasn't started with -s-)
So, for GPS type apps this won't do.

There are several options to deal with this such as:

1. Persuade the empeg guys to put something into to source code for /bin/init to actually allow for a [simple] /etc/initab type functionality.
Then we can control what processes get started in what order on our players.

2. Or maybe if the /bin/init program (modified by the empeg guys) looks for a "alternative" init program in /empeg/user_init or some other filesystem (maybe /programs0/user_init) .
If the regular init process it finds such a binary, it then exec's it and lets it do the starting/running of the player bunary - if its not present/found or the exec fails, then it does what it does now and starts the player binary itself.

That way we can have our own "custom" init process that can read config.ini or do whatever it likes and its the responsibility of that program to start the real player software in whatever mode it determines is best.

Some of you may ask, why get the empeg guys to modify /bin/init - well that way, the next release(s) of software they make will automatically preserve whatever settings and init procedures we have in place without trashing them.

With a fallback mode to allow the player to always start if the user init program is not found or won't run, so we always get music on our players - unless user_init screws up big time.


3. A third option, is that we use a single bit in Flash RAM to somehow tell the player whether or not its to open the serial port and dump out song info on to this port and/or monitor the port for serial data used to control the player app via serial.

This would require either a mod to the player software and the kernel or the init process looks for this RAM bit being set and when it is, starts the player in silent mode, while I dislike wasting precious flash ram bits - this would let us (users) control the interaction of the player software with the serial port from within Hijack via the hijack menu. Lack of control over how the player binary interacts with the serial port is a major issue to using it with GPS and other apps.

Once we solve that problem, we can then start other apps via hijack menus or whatever as required, knowing that the serial port is free and not being read/written by the player.