I am currently writing a little program that will be called instead of the
player (in INIT) but will start the player itself on the slave end of
a pseudo-tty. My purpose for this is to detach the player IO from the
serial port when in the docking sleeve so I can use the serial port for
my own communication with an external board I am building. I also
want to keep in communication with the player's output so I know when
we change songs. I am using pty's as doing the dual-pipe thing creates
block buffered I/O whereas the pty way keeps it in line-buffered mode.

I am close but I'm having a small problem. I am using the forkpty glibc
routine to create a child on a slave-pty and then exec the player. I can get
the stdout and stderr of the player just fine, keeping it from showing
up on the console unless I want to pass something on. The problem
is stdin. The player seems to step around me and grab stdin directly
from the console and away from my little go-between program. I
wrote another little test program that does simple gets/puts stuff
and it works as expected but the player seems to be a little trickier.

Does anyone know whether the player grabs /dev/console (or ttyS1)
specifically rather than using its default standard input when it starts
up? The even stranger thing is how my program gets _some_ of the
characters but not the others... almost like both processes are reading
out of the same buffer and who ever get there first, gets the data.
Not exactly the behaviour I need :)

Ideas?

I had the same problem in my first feeble attempt at writing GPS-software for the empeg, resulting in me having to re-install the entire image, loose all my work, and discouraging me from trying again...

I guess you could try to
1) Run a "strace" program to see what the player is actually opening
2) run a "strings" dump of the player to see if there is any reference to either /dev/console or /dev/ttyXX
3) Rename /dev/console and/or /dev/ttyXX and see what happens.

If the player is "smart enough" (dumb enough?) to go directly to the hardware without going through the /dev/ devices, I think we are looking for a Kernel Hack.

Marius (Escort Cab + Mark II)

Wasn't there some kind of a 'leave the /dev/ttyS1 alone' command line option (perhaps -s) ? I don't remember what it actually does, though.

Here - if it's still valid... Seems there were problems making it work too, though.

/Michael

BUT... The thread you indicated has the key to solving the problem, though...

1) Rename /dev/ttyS1 to /dev/myownttyS1
2) symlink ln -s /dev/null /dev/ttyS1 (or your pty)

Use /dev/myownttyS1 for your own software.

Marius (Escort Cab + Mark II)

I think a little bit of everything is needed.

1. "player -s-" (the second '-' is required!) does stop the player
from receiving input from the serial port.

2. I've been strace'ing what I could but when my program
forks and exec's, strace gets some errors and then future
output seems somewhat untrustable. Also a simple strace
of just the player wields nothing about ttyS1 or console but
after downloading the player and looking inside, there is a
reference after "Server" to "/dev/usb0" and "/dev/ttyS1" but
no console. So I moved ttyS1 to hiddenttyS1 and relinked
the symbolic link from console (so I still get a console!) and
just placed a regular file at ttyS1 for now.

Results:
-"player" fails to start with "Starting Server Failed" on the display.
-"player -s-" will start as normal.

Great, everything is doing what is should do, except...

Even with "player -s-", my program can intercept the player's
stdout/stderr but stdin isn't reaching my program. From a ps
list, the CTTY for the player is ttyp0 as is should be.

Anyhow, I will continue to hack away and try and find out just
where my typed characters are disappearing to. Hopefully I
will have some more positive results for people later.

Brett

I know neither whether it will help you or if it will compile on the empeg, but you might try using lsof to look for files (and devices, directories, etc.) that the player has open.

... funny, I was just using lsof. And it confirmed my growing thoughts.
When I went back a revision, I went back far enough that I took out
my commands to set the FD to non-blocking mode... I was stuck always
looking at the players output and never coming back to the central
select loop. Ooops.

Anyhow, here is my final result for the environment I want.

1) mv ttyS1 hiddenttyS1
2) rm console
3) ln -s hiddenttyS1 console
4) ln -s ttyp0 ttyS1
5) wedge player (wedge is my program name)

Notes:
- I now can parse player output for status info and can control the player
from my program if I want
- I could call "wedge player -s-" and not do the ttyp0 to ttyS1 link but I would
loose the ability to control the player myself.
- I already created about 5 pty sets earlier (ptyp0-5 and ttyp0-5)
- I should dynamically create the ttypX to ttyS1 link from the return
value of forkpty but since not many things are running or requesting
ptys at this point and I want to keep things mounted ro... I'm not :)

I'll update this page with a URL when I get some more of my code
together (probably in about a day) and put things online.

Thanks for everyone's help.

Brett

Okay, as promised I have started a web page which will be updated with
my work as it progresses. Pretty d**m basic right now. More later.

http://216.231.34.101/miatastereo/empeg.html