Hey Mark,

I wrote an expect script to automate ftp downloads of the kernel. I also added 'ftp' as a make target that invokes it, and a README.ftpempeg.

Attached is the patch. Can you take a look and add it to the Hijack tree? The patch is against v234, but as I doubt you've touched the toplevel Makefile since, there shouldn't be any merge issues.

This is what happens:
[me@here]$ make ftp
./ftpempeg
spawn ftp empeg
Connected to empeg.nowhere.net
220 Connected.
Name (empeg:root): anonymous
331 Password required.
Password:
230 Login okay.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bin
200 Okay.
ftp> put arch/arm/boot/zImage /proc/empeg_kernel
local: arch/arm/boot/zImage remote: /proc/empeg_kernel
200 Okay.
150 Opening data connection.
Please wait. This should take about 15 seconds.
226 Okay.
Kernel Download succeeded.
[me@here]$

Err.. I don't see the connection between that script, and the kernel source code.

And I already have a (better) script that serves my purposes.

Cheers

??

Does no one besides me know about .netrc files anymore?

That makes two of us, Bill!

But I still use a separate script for kernel uploads, to do "popup" status messages during/after, and to do a readback & compare before rebooting.

Cheers

Nothing to do with kernel source beyond the fact that every linux kernel tarball I've ever seen had a working "make install" function, and I felt that the empeg kernel shouldn't be much different.

But then again, I'm a relative newbie to kernel installs, having only built and installed my first in '95...

Would you care to share that better script?

Oh since you're here, can you suggest a way to stick a hijack_tone_init function in the kernel such that is called after the player starts?

It seems as though the player app checks the eq values when it starts up, and bails if they don't match expectations.

Don't worry, found it.

I used the Linux make install once, and it only works if you have your lilo.conf exactly like it wants it and you have your kernel files in the same place. And you'd better hope that it doesn't overwrite your old working kernel.

I've used make {b,}zImage ever since.

That's Bitt, not Bill, Mike.

If the player can ever "see" the modified settings, then there's a flaw in the implementation. The idea is that any EQ/Vol modifications we make should be kept separate, and applied only at the last instant when reading/writing the hardware registers.. completely invisible to the player software, even when it reads them back.

?

I don't think that was the problem, but the only way that I can see to initialise the tone controls at boot so that the player doesn't overwrite them again is to hijack the ioctls for writing the eq completely, but that wouldn't allow users to tweak f or q settings through the eq, which currently works. In the long run, I would hope to crack the register format for f and q, so that these could be tweaked through config.ini, so this isn't earth-shattering. If I did this, I could create a store of what the player thinks it has set the eq too, and return it in the read ioctl.

But I don't think that this was the real cause of the issue with the player bombing out. I discovered that a bug in my code was setting one of the register words to 0, and I think that this was causing the problem.

I do know that the tone controls work great after they are initialized through the hijack menu, and that I am able to switch between tweaking tone and eq without killing the player. Of course, the hex codes that I am using for the f and q are the same as those generated by the player eq, so it may be that the player uses a LUT to generate these values and does a reverse lookup for it's display, and that this could cause a problem if the register value doesn't match the LUT. But I'm guessing that a LUT for this would be huge, and direct calcuation is the way it is done, and maybe I caused an overflow with the bad setting. This argument would be reinforced by my experiences with the gain setting, as I have coded 0.5dB increments, whereas the player eq only allows integer increments, yet my code works.

But before I hack around the eq ioctls, do have a suggestion for where to place a tone_init call, that occurs after the player starts?

I looked quickly at the idea of placing a trap in the ir_translate code, so that the first keypress would init the tone controls, but there's several issues with doing that.

I noticed hijack_player_started in hijack_notify.c, but I don't understand that code very well. Is somewhere in there a good place to call a tone_init function?

Oh, I've found the quick and easy solution. Set another fake button to call the init function, and use an initial= feature of ir_translate.

It works! ir_translate did it, and now I've found the send initial buttons code, so users won't have to use a config.ini's initial= statement

I'll leave the ToneApply fake button though. It might be useful to some people.

Ok, more testing, but I feel that a patch is imminent.