Memorial Day

I really like the English version of the latest jffs dronz put together!  It's got just about everything I want on the zipit.  But I did make a few changes over the Memorial Day holiday.

First I fixed a tinyirc bug so it no longer wraps the status bar when using the large 8x14 font.  I tend to use a smaller font so I didn't notice the bug right away.  Sorry.

Then I went to work, making it just a wee bit more user friendly, at least for me.  I'm starting to appreciate gmenu2x as a program launcher, so I wanted that available right away on boot up, with no extra work.  At first I tried to get it going from the Zcovery startup script, using the toybox nohup to work around a problem with the hangup signal.  (Just like we did in olden days with the dialup modems).  But nohup wants to redirect stdout, which is troublesome for text terminal programs launched from gmenu2x.  So instead I simply fixed the bin/gmenu script to trap sighup just like on slug's jffs.  No more hangups means I can launch from the Zcovery startup script.  Yay!

With that problem solved, I modified Zcovery to first start a shell prompt in the background on tty1, then switch to tty2 to run gmenu2x.  Works like a charm.  But I'm pretty old school, so I want to get at that command prompt on tty1 at least half of the time.  To make it easy to switch between gmenu2x and tty1 I modified the three keymap files so ctrl-alt-home always goes to the command line shell on tty1.  I'm not actually sure I got this right in the calculator keymap, but I may try to eliminate the calculator keymap someday by remapping the keys inside the script like I did with zcalc.  Then I'd only need to maintain two keymaps.  Anyhow, ctrl-alt-home should work from gmenu2x or any SDL or text program launched by gmenu2x.  Then alt-rightarrow will get you to the gmenu2x text screen on tty2 and another alt-rightarrow will get you to it's graphics screen on tty3.  Sometimes the gmenu2x graphics remain on the screen after ctrl-alt-home, but you can clear that by typing cls or by pressing alt-rightarrow then alt-leftarrow to go to the gmenu text screen on tty2 and back to the command shell on tty1.  In this setup, SDL programs tend to run the graphics on tty3, leaving the text screen on tty2 in limbo.  With gmu and links you can type ctrl-z and bg on tty2 to free up the shell, however this is not advisable when running things from gmenu2x as it wants to manage both tty2 and tty3 for it's program launching scheme.

Once things were working satisfactorily, I decided to Americanize a few settings.  I changed the timezone file and switched the time format in the clock and alarm scripts to 12 hour time with no seconds because that's what I use here.  Since 99.9% of the time I only read things in English on the internet, I decided to compile an ASCII only version of links with SSL to save 200k on the jffs.  I'm seriously considering using the much smaller SSL-free ASCII only version to save even more.  I can always keep a full version of links on the SD card.  I also removed the green gmenu2x background.  I'd prefer to simply replace the wallpaper file if I ever get tired of the blue one.  That saves a few more K.

I used all that saved space to add the rockbox executable and a single codec to the jffs.  The rest of the codecs are softlinks to the jffs addon pack (or the normal IZ2S rockbox package) on the SD card.  Yeah, I know... rockbox doesn't really make any sense on the jffs because you still need an SD card for the music files, but I'm smitten by the coolness factor of it all.  Actually, now that I'm hooked on multiple ttys I may need to build a new rockbox executable because the current one doesn't realize it's supposed to give up drawing things when I switch to tty1.

 

Stock zipit boots into gmenu2x and plays the zipit sound in rockbox with no SD card.

There's still more Americanizing to do.  The gmenu2x glinks app file sends the browser to the french portal by default.  I'm OK with that for now, because it points to lots of handy zipit friendly internet sites.  I also need to switch a few other things like the gmenu2x settings tab to english.  But I think I'd like to get a build out there now because I like the new boot sequence so much.

In the future I still want to try swapping MatrixSSL into links instead of OpenSSL.  And I'd like to switch to slug's gmenu2x sources, then hookup the wifi icon and paste in the IZ2S battery monitoring code that I used for rockbox.  Both of these efforts should save considerable jffs space.  I also want to add the new set timezone script to the initial boot sequence.  Then maybe I'll get back to bunjallo for a browser choice somewhere between links and retawq in size and functionality.  Or maybe I'll see if it's possible to dim the status LEDs (like the backlights) or just turn them completely off when the alarm clock is running.  They're way too bright for night time.

I also need to figure out a better way to organize the goodie bag.  Dronz has been busy adding everything, which is great, but now there's so much in there I can't remember what it all is.  I'm not sure what would help.  Short descriptions?  Dates?  Pointers back to the original blog posts?  Gotta think about it...


Here's the Americanized jffs.  iz2jffs-v4-en.tgz
The old install instructions should suffice.

Here's the new keymap files with src, plus the new gmenu, tinyirc, and Zcovery.  That should make it easy to update the French version.  gmenu-jffs-fixes.zip

I forgot to include the tinyirc source code with the fixes the so I'll pastebin tinyirc.c

Teeny TinyIRC

In the comments of the previous blog post you'll find a bunch of goodies from dronz.

 

His latest iz2jffs setup attempts to squeeze gmenu2x, gmu, glinks, rockbox, and some handy scripted dialogs for multiple wifi profiles and system configs.  I was able squeeze out a little more space by reconfiguring the libs and now I'm tinkering with the rest.

For starters, as seen above, dronz prefers tinyirc to pmirc because tinyirc keeps your keyboard input isolated on a separate line so you don't get mixed messages when someone else is posting at the same time.  Ok, I can see where that might be helpful when composing a long line of text.  But pmirc squishes down to only 2K on the jffs.  At nearly 40K, tinyirc never seemed all that tiny to me.  So I went to work.  First I weaned it off ncurses and switched to ANSI escape sequences for the few simple screen drawing tricks.  That got the executable down around 17K which is much closer to what I'd consider "tiny". 

Once that was out of the way I figured I should probably take the time to zipitize it to make it more useable.  First I fixed it to stop scrolling blank lines whenever it received a PING message.  That was driving me nuts, slowly scrolling the real messages up and off the top of the tiny zipit screen.  Then I added the home, end, pgup, pgdn, and arrow key support to complement the emacs style line editing keys and make composing messages easier on the zipit.  I also added a -t command line switch to turn on message timestamps, and a ctrl-t key to toggle them on or off at runtime.  Finally I added a splash of color; red for errors, magenta for JOIN messages, and green for my messages because all the cool IRC clients have color, even lowly pmirc.

Here you can see my colorful JOIN.  And if you look real carefully, you can also see that I toggled timestamps on just before the JOIN.  If the channel is quiet you can tell if timestamps are on by the uppercase Z after the TinyIRC release number on the status bar.  A lowercase z means timestamps are off.

 I still need to edit the boot scripts to register an IRCNICK environment variable (maybe in ~/.bashrc).  That way I won't keep getting a 30 second countdown to pick a new NICK whenever I startup tinyirc.  Actually I need to edit all the scripts anyhow since they're currently all in french...

Here's the modified source and the smaller tinyirc executable: tinyirc.zip

In the Zone

I decided to use my renewed focus on the jffs to try and see if I could squeeze gmenu2x onto the stock zipit jffs along with gmu. (I've already fielded a few not so subtle hints from my co-worker that the linux command line is perhaps not the easiest way to use the zipit.)  This wasn't gonna be easy though because gmenu2x is fairly bloated with C++, freetype, and lots of png files.

The first thing I did was to cut it back to a minimal installation with just the default skin, only one translation (french), and fewer icons and the smallest background image file I could find.  See above.  I also ran all the images through pngcrush for good measure.  This resulted in a gmenu2x installation that was almost small enough for the jffs.  Unfortunately it didn't quite work when run from the stock busybox shell.  I had to build a tiny killall executable to enable my previous uclibc workaround from the iz2s build.  Then I had to make sure to "exec gmenu2x" from my gmenu wrapper script or it would complain about various tty ailments whenever it finished running an app.  Weirdness.

Next I attempted to link gmenu2x without libstdc++ according to these instructions.   But gmenu2x uses STL strings, dynamic casts, and more from libstdc++ so the best I could do was skip exceptions and static link with libstdc++.a.  The shared lib is about 800k stripped, and would would use about 300K compressed on the jffs, so I managed to squeeze a little bit out of it.  I recently discovered the jffs seems to garbage collect on boot up, which means I may have a reliable way to compare the space usage.  So I'll probably try to install the full lib someday to see exactly how much I saved.  Actually, I suspect I'll hold off on that until I find another C++ program that I just gotta have...

I also tried static linking libfreetype, but that didn't save anything.  A stripped libfreetype is 400K, or about 200K compressed on the jffs, so I bit the bullet and stuck it on there.  This meant I could also toss in the dgclock program for only 20K if could trick it to use the same font as gmenu2x.  So I moved the /mnt/ffs/gmenu2x/skins/Default/font.ttf file to /mnt/share/fonts/font.ttf and replaced it in it's original location with a soft link.  Then I soft linked the mplus-2p-medium.ttf file used by dgclock to font.ttf and voila!  The dgclock works.  The gmenu2x font file is fairly compact but I can barely tell the difference in the dgclock program.  It might have slightly narrower glyphs.  Maybe it'll be good enough for a few more small SDL-ttf programs.

This fit onto the zipit, but just barely, so I swapped out the wpa-supplicant and wpa-passphrase for my cut down versions.  The ones from the V1 firmware (and IZ2S) are fairly large, and the ancient wpa-supplicant was having troubles connecting reliably to WPA2 routers anyhow.  The new smaller version actually seems to work better.  This got me to about 700K free on the jffs.  That's enough room for some more small goodies.

While working with dgclock, I noticed the zipit appeared to be stuck in a different timezone (somewhere in europe?) instead of EST5EDT.  I'm not sure what caused it, but eventually I deleted the /mnt/ffs/TZ file and rebooted.  The timezone setting script popped up.  I entered EST5EDT, and it recovered.  Then I realized I was off by an hour because the 2007 daylight savings rules weren't incorporated into the iz2s uclibc.  Fortunately Dom pointed out the uclib TimeZone fix for the US 2007 daylight savings change in one of the comments here.    Down at the bottom it mentions the magic EST5EDT,M3.2.0,M11.1.0 setting for the /mnt/ffs/TZ file.  EST5EDT,M3.2.0,M11.1.0 is US Eastern Time with Daylight Savings Time starting on the 3rd month (March), 2nd week, day 0 (Sunday) and continuing until the 11th month (November), 1st week, day 0 (Sunday).

Here's a combo jffs image containing the base, gmu and gmenu2x packages to make it an easier install for newbs.  Note:  I said "easier", not "easy".

gmu-gmenu2x-jffs.tgz   Here's the install instructions.

And apparently the Goodie Bag was offline for a while.  Sorry.  I think I'll try and mirror it...

GMenu2X Revisited (again)

Looks like some of the issues I had with gmenu2x on the zipit have been discovered.  On the zipit IRC channel, dronz pointed out that launching programs with the gmenu2x wrapper setting chewed up memory like it was candy.  Not so good on the zipit with it's stingy 32MB of RAM.  The crappy uclibc versions of the fork and exec functions strike again.  So I created a fix, and rolled a new package along with the updated icons from a while back and some termula2x tweaks.

But what an ugly fix it was...  It turned out the execlp() call in gmenu2x was leaving the huge gmenu2x parent process hanging around, merely suspended and hogging up all the memory, waiting for the child process to die before exiting itself.  You can see it right there in the htop window launched from bash, which was launched from gmenu2x. 

I tried all sorts of clever  trickery with fork and temporary script files, but nothing really worked well until I got frustrated and tried something really stupid.  Running "killall -9 gmenu2x" in the bash shell launched from gmenu2x  did away with the pesky bugger.  So I simply added that to the wrapper script and voila!  It seems to work.  I may fiddle with moving the killall earlier in the wrapper script to free up the memory before the child process, but for now I think it's ok.

You can find the updated package here:

gmenu2x-iz2s.zip 

I still need to fix the launcher code to set the terminal right so emacs stops complaining about /dev/tty and bash no longer whines about not having job control.  The nanonote patch for this doesn't seem to work for me.   But I applied it anyhow, just in case I ever build a z2lite version of gmenu2x.  What does seem to work is running "setsid cttyhack emacs" instead of just emacs in the gmenu2x wrapper settings.  Same for bash.  Oh well, when I finally settle on a permanent solution for this, I'll probably have to do another gmenu2x package update.

Gmenu2x Revisited

I'm still working my way ever so slowly through the rockbox SVN revisions, searching for the one specific change that's dimming the high frequencies in the up to date rockbox code.  But since I can't hear so well these days I have to wait a bit between test builds for feedback on the zipit IRC channel from dronz who can actually hear the difference.  This occasionally leaves me some time to play with other stuff.

I found some SDL based vnc clients to play with, but they suffer from about as many issues as the framebuffer vnc clients.  I'll have to piece together a good one from all the best bits, someday when I have a solid block of time to think.  But not yet.

So I decided to pick at something a bit simpler.  Way back when, in the early days of my zipit experiments I did a test build of gmenu2x.  But then I got sound out of a rockbox build and put gmenu2x on the backburner.  Since I'd already done a build of gmenu2x I figured now I could spend my little snippets of time working on the config bits required to make it work right in IZ2S.  So I tinkered with the keyboard layout config file and setup a few apps to launch, run, and return to gmenu2x.  I also built the termula2x terminal program to see what that looked like when launched from gmenu2x.  The whole thing needs plenty more work, but all in all I think I like the way it's shaping up.  I can picture myself launching straight into gmenu2x for the car music player instead of hooking rockbox to the home key with e2bindkeys.

I put it here for now gmenu2x-iz2s.zip if anyone wants to try it.

I've recently updated the input.conf keymap file and some of the icons here gmenu2x-iz2s-icons.zip, and the source is available in the Goodie Bag.