Blinker-be-Gone

Ok, so that pesky blinking text cursor interfering with all the SDL programs on IZ2S was starting to drive me nuts.  I know, there's a workaround, but who wants to make yet another wrapper script for every little SDL program I might happen to churn out.  But you know what?  I already made a new SDL lib for the ALSA sound support, so why not also patch it to get rid of that pesky blinking cursor.  Turns out the SDL_fbevents.c file already was already opening /dev/tty0 to access the keyboard, so I could also use that file descriptor to write the "\x1b[?25l" hide cursor escape sequence from the wrapper scripts whenever SDL switches into graphics mode.  One simple line of code and the nasty blinker is banished forever!  About time.

So I updated the SDL lib in here:  sdl-salsa-iz2s.zip


Still gotta replace it in all the other zip packages though...

Meanwhile I have a patch for directfp that might work, but only glinks uses directfb so far, and it still needs a wrapper script to load a different keymap.  So I'm gonna hold off on that patch.

I'm also sticking with a script for mplayer since it's a big static executable and apparently it works directly in the current tty rather than opening a free tty for the graphics.  So it needs a slightly different wrapper.

Here's what it looks like all cleaned up with the no-blink wrapper script.  You'll have to fetch the actual mplayer-rc2 executable from IZ2S 2.04.  This is just the wrapper and a config file that tells it to print as little as possible.

mplayer-iz2s.zip

On a Lighter Note...

So maybe all that e-reading makes you tired.  You need some lighter fare, like say some e-comics.  Or maybe you just want to review a new batch of pics from your camera.  If so, perhaps you've been looking for something like o2xiv.  It's a simple batch image viewer from the gp2x that also happens to work pretty well on the zipit.  Just don't ask me how to get those pics transferred from your camera to the zipit.  Maybe you got one of them SD cards with the built in wifi in your camera.  If so, perhaps this is for you.

 o2xiv-iz2s.zip

Careful, the zip file has the both the source code and a bin directory with executables for a bunch of different platforms.  You want the o2xiv.iz2s executable.  Put it in your bin directory and give it a shorter name that you can actually type on the zipit.  Or make a small wrapper script for it that kills that pesky blinkin cursor first.  It's up to you.

OK, enough with the fluffy light stuff.  Back in ancient times Gnu Emacs served a multitude of purposes as my preferred text editor, debugger, screen multiplexer, news reader, whatever...  Well it's back.  I finally compiled an IZ2S version of the real thing.  It uses every last bit of RAM and almost 100MB on the SD card (gotta prune it down a bit) but it's almost worth it.  Actually I'm not even close to sold on the tiny split screen.  But it makes for a nice screen shot.  Don't it?

emacs-iz2s.tar.bz2

When it Rains it Pours

The PDF reader got me thinking about ereaders in general.  I've tried FBreader on the on the eee-pc and thought it was pretty decent, but I'm not quite ready for the massive effort required to build the DirectFB version of GTK I'd need to run that.  Someday though...

So I looked around for a somewhat lighter ereader and found greader2x.  It only does txt files (and zipped txt files) but the build requirements seemed reasonable.  Well, I quickly realized that it needed the SDL_mixer lib for the built in music player, and that needed a different mpeg lib than the mpg123 I already had.  Fortunately I found a patch file on the net to convert it over to mpg123.  So I pressed on and built the lib and the greader2x executable.  It seems to work ok.  The music player is underwhelming compared to rockbox or gmu, but it played the few mp3s I tried on it.  Here it is, displaying the readme file that comes with it.  Simulated night reading with "oldbook" theme...

And here's the files:

greader2x-iz2s.zip

You'll need to fetch the GMU package for the codecs if you want music, and to be honest you may need it to run just the ereader part.  I haven't actually tried it by itself.

A Little Something for Nothing.

Well almost nothing.

Building all those libs required for netsurf got me thinking, "What else could I build to make use of all that stuff that I might want someday?"  PDF file viewers are occasionally handy, and always quite bloated with the libs.  So I figured maybe I could look twice as geeky, shopping for toys with a handy toy cheatsheet loaded up on the zipit.

I grabbed the sources for the nupdf program used on the nanonote and the dingoo and after a few false starts settled on the mupdf-0.5 lib to go with it.  Neither had a workable makefile for the zipit, so there was a little work involved to get them compiled, but nothing too difficult.  Now I still need to add a zipit keymap patch and move the nupdf config files to someplace sane, but it works ok for testing already.  Here it is showing off the super secret toy barcode decoder cheetsheet in glorious 320x240 resolution.

And here is a static build of nupdf for IZ2S.

nupdf-static-iz2s.zip

I suppose you could also use it for more serious stuff...

UPDATE:  I patched nupdf for the zipit keyboard and IZ2S filesystem and fixed the zip file above.  The nupdf source code changes and my makefile for the mupdf-0.5 libs are here.

nupdf-patch-iz2s.zip

Another batch of stuff.

Have I mentioned my short attention span?  The other day someone was talking up the netsurf broswer on the Zipit IRC channel and I thought, "Hey, that links browser is nice and all, but I'd really like something that renders the pages a bit cleaner."  So off I went on a compiling binge, building all sorts of libs required for netsurf.  It actually wasn't all that difficult to compile so I quickly loaded it up on the zipit and tried it out.  Looks pretty, but needs a zoom out function because it requires lots and lots of scrolling to see the pages as rendered.  And apparently you need a mouse to click on any of the links.  Why would anyone create an embedded web browser that doesn't support mouseless browsing?

netsurf-iz2s.zip 

Now I don't really think a mouse should be required to use a GUI program on a tiny screen like the one on the zipit, but I'd run into this before when playing with some SDL programs.  So I grabbed the z2mouse sources, added some key repeat code and built the fake mouse driver for IZ2S.  Since they share some device nodes and kernel modules, I tossed it in with the ebindkeys stuff from last week.

Run setup-mouse.sh and then you can toggle the mouse emulation on and off with the Options key.  If you also want ebindkeys you should run it before z2mouse, or you'll need to edit the ebindkeys config file to use event1 instead of event0. Because of this minor conflict, I set the Ctrl-Option key combo to terminate the z2mouse.  I'm not sure I'm gonna keep that in though because it currently leaves a z2mouse zombie process.  I also added an optional command line arg to z2mouse so you can set the key repeat rate for the mouse motion events.  The default is 20 motion events per second, but if that's too slow for you you can bump it up a bit.  Edit the z2mouse line in setup-mouse.sh and add a number for the event repeat rate, like "z2mouse 40" to double the default rate.

ebindkeys-z2mouse-iz2s.zip

z2mouse-iz2s.c

Now since freetype was among the libs I had to build for netsurf I decided to build the SDL_ttf lib and test that with the dgclock program in use on some other small gizmos.  You can use it to set the clock when you're not on wifi, and thus without ntp. 

dgclock-iz2s.zip 

I also built fbshot for screen captures and the sdl GUIlib okay program for testing the z2mouse.  And meanwhile, I'm actually starting to consider building the framebuffer version of gtk and then maybe xdialog so I can play with pretty scripted GUIs on the Zipit.

testprogs-iz2s.zip

Oh yeah, before I forget... here's the source packages for dgclock and nightsky with the zipit keypad mods and the matching onscreen hint messages.

dgclock-src-iz2s.tar.bz2

nightsky-src-iz2s.zip

A new day brings some new stuff for an old IZ2S.

Remember that bit about the double trouble?  Well, forget it.  Sometimes I have no idea what I'm talking about. 

I still don't really know what prevents me from puting a working libasound together.  It could simply be one of the zillions of ALSA config files is busted for all I know.  However I was successful with the salsa embedded ALSA lib.  I managed to build it and actually got some test programs from a beat up old Linux Journal to work.  I played with these for a bit, did some reading about "safe ALSA", and compared the way SDL wanted to use ALSA to the working mpg123 and aplay executables.  It turns out the simplistic buffering strategy used by SDL is probably ok for games, but not so good for gapless music playback on a stressed out low MHz linux box (like the zipit running IZ2S).  So I mercilessly hacked the SDL_alsa_audio.c file to make it behave more like the other programs.  Then I built a new libSDL with my changes, and with the tiny salsa library built right in. 

If you like, you can replace the old libSDL in IZ2S with sdl-salsa-iz2s.zip.  Then set SDL_AUDIODRIVER=alsa instead of dsp and go.  I recycled some rather under-utilized SDL_ALSA environment variables, just in case you want to play around and adjust the buffering scheme.  These are (lightly) documented in a text file included with the lib.

I also put together a real gmu-0.7.2-iz2s.zip package with the new libSDL since it no longer skips on IZ2S.  I must say GMU is really handy for debugging the audio code.  It's well written and easy to follow, unlike the gigantipus that is rockbox. 

I happen to like rockbox though.  So I rebuilt the IZ2S version with a more recent branch of code.  It has better (but not quit perfectly smooth) battery monitoring.  It can now change codecs on the fly and it no longer needs to move config files in and out of the /tmp directory.  It also seems to quit after 10 minutes on pause.  Perhaps that might help with the IZ2S power management?  I also let it use the standard linux file structure which prefers to install in the /usr/local directories instead of the embedded setup using the /.rockbox directory.  I'm not sure how much I like that, but for now it lets me keep the old and new versions installed at the same time for testing.  Here it is.  rockbox-iz2s-t11.zip

Finally, here's an ebindkeys executable for IZ2S with a setup to make the home key launch rockbox.  That's a single easy to find button so I can start it up in the car at night without turning on all the lights.  And here's another tip for the car.  Add a line to the startup script to soft link your music directory to /audio so it's right at the top of the rockbox file browser for quick and easy access.


Update:  It's a bit trickier to install rockbox themes on the new release.  You'll need to CD to the share directory on your SD card and temporarily rename the rockbox directory in there to .rockbox.  Then you can unzip an Ipod Video theme into the .rockbox directory.  Rename it to back to rockbox and you're done.

Also, unlike rockbox GMU only allows one key binding per function.  With the wide variation in default key mappings among IZ2S versions, this means that sometimes the volume is controlled via the +/- keys on the side of the zipit, and sometimes you'll have to use the prev/next keys.   So if you're using IZ2S 2.04 with it's default keymap and you want the volume controls on the side then you should edit the gmuinput.z2.conf file and near the bottom replace this:

Button73=280,Volume+
Button-74=281,Volume-

with this:

Button73=270,Volume+                                                                         Button74=269,Volume-

                                                                                                     
I suppose I could try to patch the code to work around this limitation.  Or maybe distribute several different GMU config files with the package.  I'll make a decision someday...

Double Trouble in the NightSky

Sometimes I have trouble focusing on one task.  So as you might have guessed, the internet radio plugin project took a hit this week.  I couldn't get a pipe, named or anonymous, to push the internet samples into the guts of rockbox.  Something, perhaps the rockbox buffering, perhaps my incompetence, always seemed to get the pipe closed before I got any data out of it.  So I went to plan B.  Just use rockbox as the GUI to select a pls file and pass its URL on to mpg123 or mplayer running in a slave process.  That was a quick failure on IZ2S when I discovered the IZ2S ALSA lib is busted and I've been unwittingly using the OSS compatibility layer instead.  Maybe that could explain the performance differences between the Z2lite and IZ2S versions?  I haven't got a clue.  But now I had a new mission to build a working ALSA libasound for IZ2S because with the OSS drivers there's no way to get rockbox and another player to share access to the sound device.  I think it bypasses the mixer, or something like that in sound system jargon.

Now as you might have guessed, this has not gone well.  The IZ2S scratch build environment appeared to come preloaded with an ALSA lib version 1.0.18 to build with, but as I discovered this was broken.  Apparently it was compiled in a buildroot environment and then pasted into the scratchbox env without testing.  When I tried to build some test programs they failed to link because the ALSA lib was built using an incompatible floating point option.  It used FVP floating point, but the scratchbox compiler was using FPA.  You'd think this would be simple as the xscale processor in the zipit doesn't have any floating point support, but what it really means is it just has to be done by some sort of software.

This led me to various history lessons on the deepest dark secrets of the wide variety of ARM floating point options, and on a quest for the mysterious missing libfloat which promised to let me at least link the test programs.  I don't think there's any chance it'll run because the VFP and FPA formats are word swapped.   Anyhow, I discovered that while there are some working VFP static linked programs in IZ2S, the static linked (and functional) ALSA utilities are not among them.  They were built with FPA floating point and ALSA 1.0.21 in some unknown build environment.

Ok, so maybe I could just build a new ALSA lib in the scratchbox build environment.  That's worked pretty well for all the other shared libs I've built.  But no.  It doesn't work.  Deep in the bowels of the libasound it loses it's way "refining the config" and eventually decides it's "unable to find an usable client format".  It looks like part of the trouble is with the sample rates.  It should report something like 8k, 16k, 48k, 96k, 11.025k, 22.05k, 44.1k as available, but it only reports 8k and 96k.  Hmmm, could this be a floating point problem? 

At this point I'm pretty sure the floating implementation in the scratchbox build environment is broken.  It uses gcc 4.1.1 and bugs like this one lead me to believe it's the compiler or uclibc that's doing me in.  Remember way back when I couldn't get doubles to work in night sky, so I eventually replaced them all with floats and it worked.  The ALSA lib code has only a smattering of doubles so I may try the same approach.  But first I might try building the much smaller SALSA library which is suggested for embedded systems by the ALSA folks.


If this all fails I suppose I can return to the buildroot setup and try to build static ALSA, SDL, and pthread libs so I can try a static linked rockbox executable with VFP floating point on IZ2S.  That doesn't sound like very much fun though.

Meanwhile, I really think I'm gonna need a debugger to get to the bottom of this.  Perhaps I should try to build gdbserver...