Okay v124 is out.

Recent stuff of interest includes the new kftpd "SITE" commands:

-- SITE RO
-- SITE RW
-- SITE REBOOT
-- SITE EXEC arbitrary command ; another arbitrary command

The RW command remounts /,/drive0,drive1 for read-write access, and RO puts them back into read-only. Wait about 5 seconds after issuing them, because they execute asynchronously.

None of the SITE commands return any output, and none of them return any status codes other than "Okay". That's because I gave up trying to figure out how to communicate with the child spawned from the internal execve() invocation (slightly different from usermode). All stdin/stdout/stderr for any such commands is simply redirected to the serial port for now. But the mechanism works, crude as it may be.

Also new, is the /proc/empeg_kernel "device", created within the kernel by Hijack. This is simply a block device entry for MAJOR=60 MINOR=8, the "kernel" flasher. If you use FTP to upload a kernel zImage file to /proc/empeg_kernel then it will be burned to flash during the FTP. Takes about 5 seconds.

This is the much faster equivalent to using "download" or "logo editor" to flash a new kernel. Works fine on a stock consumer image, too, so long as Hijack v124 (or higher) has been installed.

Also recently new, is the ability to write to /proc/empeg_notify. Reading from it just gives the player status (requires [output]notify=1 in config.ini), but the other direction can be used to inject commands to Hijack:

echo "button 20df12" >/proc/empeg_notify (a short press)
echo "button 20df12.L" >/proc/empeg_notify (a long press)

This virtual button pressing can be done remotely using FTP to write to those files, as well as using the FTP SITE EXEC command to issue those "echo" commands shown above.

In addition to "button" commands, one can also do"

echo "reboot" >/proc/empeg_notify

and also for fun you can do:

echo "popup Hello, World!" >/proc/empeg_notify

Cool, eh!

-ml

Hmm.. im only seeing v124 on your site...

-Greg

Okay, I've edited the posting.. v124 is correct (I had an internal v125 that confused me).

-ml

Beautiful stuff as always. I love the reboot, now my empflash.sh script can automatically reboot if the kernel files match.

Mark,

What does this khttpd: "index.html" lookups do ?

If you request a directory, say "http://empeg/drive0/" khttpd will look to see if there is a file called index.html in the directory in question. If there is it will serve out the index.html file instead of a directory listing.

At least I guess that's want it does, I haven't downloaded the new version yet...

Yup, that's exactly what it does. Most webservers do (or can be configured to do) the same kind of thing. Useful if you want to hide the contents of a directory from direct viewing, too.. just drop any "index.html" file you please into the dir, and it becomes unviewable. I use this on my webserver to hide "private" content.

Cheers

for us windows users using windows builtin FTP client
ftp> literal SITE EXEC echo "button 20df12" >/proc/empeg_notify

Now where do I find all of the button codes?

The button codes can be found by entering the hijack menu, and using the "Button Codes Display" screen in conjunction with pressing buttons on your remote. Just ignore the codes that start with "8".

Or you could look in the ir_translations section on the hijack website.

Cheers

Speaking of which.. Yes, I am going to be adding "http POST" commands to do what the "FTP SITE" commands do (RO, RW, POPUP, REBOOT, and soon.. BUTTON).

-ml

Cool... another use for Tony's remote control imagemap.

Yes, I am going to be adding "http POST" commands to do what the "FTP SITE" commands do (RO, RW, POPUP, REBOOT, and soon.. BUTTON).

What I would really like to see (rub, rub) is this HTTP interface become a full file management interface. Like this:



What do you think, Mark?

This is a good idea, but I would prefer if it was an option, not the default. Perhaps it could
be like "Fancy Indexing" in Apache where, via the .htaccess file, you can define a header
and footer which would include the necessary forms for your user interface.

What I would really like to see (rub, rub) is this HTTP interface become a full file management interface

That would rule. I don't see a means to changing attributes on existing files, tho. That would make it an almost full file management interface.

Okay, all that we need for this is some html to dress up a directory listing. Anybody want to generate the html?

-ml

Okay v126 has just been released http://empeg-hijack.sourceforge.net/

Improvements from v124/v125 include:

-- http dirlist works again (was broken in v125).

-- SITE EXEC is as broken as before.. I think I'll remove it entirely next release, since the enhancements below pretty much eliminate most needs for it.

-- Popup messages are now used as progress indicators for SITE RO and SITE RW commands in ftp.

-- ftp SITE RO and SITE RW are now implemented internal to the kernel, so they will work fine on a consumer image (previously required the developer image).

-- ftp SITE POPUP command can be used to display a timed message on the front panel, as in:

     ftp myempeg.localnet.



     site popup 99 Flashing new kernel..

     put zImage /proc/empeg_kernel

     site popup 1 Done.

     site reboot

-- ftp SITE REBOOT command now does "SITE RO" automatically before reboot. Note that the Hijack Menu "Reboot Machine" does NOT do RO before booting though..

-- ftp SITE BUTTON xxxxxxxx command exists for remote button simulations. Also works with xxxxxxxx.L to simulate longer presses.

-- Multiple SITE commands can be issued at once, separated by semi-colons.

-- All of the SITE syntax now also works for echoing commands to /proc/empeg_notify as well as for using HTTP GET commands with parameters for /proc/empeg_notify, as in:

http://myempeg.localnet./proc/empeg_notify?button=20df12.L

-- I have replaced /proc/empeg_screen.tiff with a PNG version called /proc/empeg_screen.png --- it is still tiny (32x128 pixels), but if we later put an HTML wrapper around it, we can get most browsers to scale it to a viewable size. I'm hoping somebody writes some HTML to present this screen display along with some buttons that use the parameter syntax (discussed above) to do full remote control.. How about it?

Other changes, but I've lost track..

Enjoy!

Also new as of v126, the SITE RO and SITE RW commands are now fully synchronous, meaning you don't get a response from them until they finish their job 100%.

I'm putting out a v127 shortly, the only difference being that it omits the networking stuff (kftpd, khttpd, and some of the /proc features) when built for a mk1 unit (no ethernet on those).

Cheers.

-ml

I'll start working on HTML for an interface of some sort. I'll keep everyone posted.

Ok, here's my lame attempt at an html interface. Note that this is fairly simple
and I didn't do any image maps or anything (I'll leave that for someone else, or
I'll do it tomorrow after I get some sleep...)

There are three files:

index.html: The frameset file
empeg-display.html: loads the display image and has a 10-second refresh
empeg-control.html: a crude version of the rio remote

Note: my empeg appears to lock up after several minutes when using this.
It looks like the load starts to climb and then it stops responding.

I'll start working on HTML for an interface of some sort. I'll keep everyone posted.

Cool. I was thinking something along the lines of the HTML file management interface that's up for the admins at riocar.org, except without the graphics (don't want to cram those into the kernel).

To support the upload functionality Mark would have to do a bit more work on khttpd, he would need to implement multi part POST requests to process the results of POSTing a form with a "file" type input box on it.

I get the feeling that Mark could implement a cure for cancer and world peace in the Empeg kernel if we asked him to.

Ok I officially suck at java... hehe... I've been trying for about 2 hours to write a script to refresh the empeg_screen image on the page so that there wouldn't have to be a whole frame refreshing, plus it looks smoother, but it doesnt like the .png format. I got it working for .jpg just fine. I threw out the code and am trying again but its 2:44am and i've got class in 4.5 hours. Anyone have something like this? i suppose its the same kind of script that is used for refreshing webcame images on a webpage. If you do post it or email it to me at greg@mandiola.com. I got something kinda cool worked out ; ) but i need this as a start to the (short) developement.

-Greg

> Note: my empeg appears to lock up after several minutes
>when using this. It looks like the load starts to climb
>and then it stops responding.

Mmm.. yes, the khttpd threads seem to be getting stuck in Zombie status, rather than dying away like they were supposed to do. So the machine just runs out of memory after a few (re)connections. Maybe this is why ftp sometimes fails (once every hundred or two files). I'll look into that and fix it (somehow).

-ml

Yeah, sorry for the .png, but it's the only lossless image format that all browsers understand. Pity it's so bloody complex, even for an uncompressed image like the screen dump.

If you'd prefer a raw packed pixel dump, I can provide that as an alternative, almost for free. But it's easy enough to extract from the .png as well. Just remember, in the IDAT section, every screen row is 33 (not 32) bytes -- throw away the first byte of each row (a "null" filter code), and keep the other 32 bytes. Within each byte are four 2-bit pixels, laid out in viewing order from msb to lsb (silly png!!). All of this is at offset 48(decimal) from the first byte of the png file; the rest of the file can be ignored.

-ml

>I get the feeling that Mark could implement a cure for cancer
>and world peace in the Empeg kernel if we asked him to.

Curing world peace is easy.. already been done a thousand times.
But curing world unrest is much more difficult.. not enough memory.

Ok, you know about this then. I was about to post my capture on it, the empeg didn't like my javascript autorefresher.

And would would people prefer, a Javascript based autorefresher, or a java one?

(Ugg, looks like we have a nother round of Nimda running around here again. Looks like that could freese up my empeg, time to move it to the test network again)

Smart ass.

Drakino. I'd say javascript. That way its easily customized and inserted. (plus probobly smaller in size, which I guess doesn't matter since it will be like 30k if that). I still havn't gotten it to work yet. If anyone gets it to work please post it. I'll do the same.

-Greg

< script language="JavaScript" >

function cycle() {

  document.empegScreen.src="http://empeg/proc/empeg_screen.png"

  setTimeout("cycle()",1 * 250)

}

< /script >

< img src="http://empeg/proc/empeg_screen.png" name="empegScreen" border="0" width="128" height="32" >

< script language="JavaScript" >

cycle()

< /script >

That will refresh the image every 250 ms. Keep in mind with the current zombie problem, this will crash the empeg in under a minute.