In reply to:


Ehh, the patch is attached to the first message in the linked thread. And it looks usable, the code is based off of the in-kernel module loader. I'm starting most applications in the preinit 'M" scripts, which are run after the player has started as well.



I didn't notice the attachement to that thread, so I stand corrected.
But did Kim release it under GPL?

In reply to:



The only thing I don't like is the in-kernel processing of config.ini whenever the player reads it, but that's a hijack thing. Yes, the player still has to be started with -s-, but if we're hacking the players view on it's environment with hijack anyways, why not modify sys_exec to add that flag when we're on DC.


I have no problem with that - Mark Lord might [its kind of kludgy and certainly not elegant, but it would be effective].

It would however affect the ability to be able to remotely control the player as the player won't then respond to fake keystrokes sent to it from the kernel - which are delivered to the player via the serial port (it thinks it has open).

This may make it a non-starter for some.

In reply to:


The best method would probably be to 'virtualize' the serial port, so that when gpsapp opens the serial port it would make the player's bits end up in the bitbucket (while still allowing notify=1 to work).



I agree, I had thought about making all open requests work/succeed on the serial port, but only some (privileged) reads would ever return data from the real serial port, others would block and never return like they would if no data ever showed up.

You would need a special IOCTL (or special device name say /proc/empeg_serial0 - ala the /proc/empeg_kernel special device) to let the kernel know that you were "privileged" to open the real physical serial port for real IO rather than virutalised IO in that case. So that you could talk to the real serial port though.

One thing is that we do want the player binary to output "stuff" to [what it thinks of as] the serial port as thats how the kernel populates the current track, title and other info on the /proc/empeg_xxx special file (can't recall what xxx is called for now but its there).
So if we start the player with -s- it won't do this.

All we want to do is to be able to stop actual physical "reads" of the serial port ever getting data from the serial ports buffer - we still want the player to see the serial "commands" we send it via the httpd process or via "injected" commands - like append/insert/enqueue fid### to current playlist.

So that control of the player via web interface is still supported, even with a GPS connected

Of course the real answer is some kind of "multiplex" IO capability on a single real serial port, but thats way too complicated I think to implement easily and would require external hardware (and software) support.

Maybe one day, thats something Patricks tuner module could support - the serial protocol between the tuner module and the player is multplexed now between stalk commands, tuner commands and other "io" stuff, adding one or 2 low speed serial (receive only) channels to that multiplexed stream would probably be doable with some minor changes to Patricks PIC code and a small add on board to provide the serial IO pins.

[either that or Patricks board is modified to support using one or more of the ADC pins as serial IO pins - not sure the PIC chip has the grunt to handle all that serial io cleanly though].

Could you use a ADC port as a low-speed Receive only "RS232 leve" interface without a transceiver chip?