Anyhow, after success with gmu I attempted to build gmenu2x for the zipit Arch image. I was compiling on the zipit itself, so it took forever. To speed it up I tinkered with zram at high priority with failover to the lower priority swapfile, but that tended to fail rather than failover. Locking up the zipit did not improve compile time. Oh well, so for coding and pacman updates I disable zram and switch to a 64 megabyte swap file. Otherwise I just stay with the zram. I built my arch gmenu2x with the IZ2S gmenu2x code fork because I'm more familiar with it than the openwrt branch. Unfortunately I had to modify the code to use the Alsa API for volume control because mozzwald's kernel wasn't configured with OSS support. I suppose that means I'll have to start another github fork of gmenu2x for Arch. I'm not too excited with that idea as the Arch alsalib (like all things Arch) is full featured and heavy and tends to push gmenu2x into swap. So I convinced mozzwald to add OSS to his kernel build. However I still need to go back and rebuild gmenu2x to test it.
AFAIK nobody's built any zipit specific power management utilities for Arch yet, so I added keyboard and LCD backlight controls to gmenu2x, but it needs more work. For example, there's no screen blanker for graphics mode yet, so you close the lid on gmenu2x and the backlights stay on, unless you dial them down manually first. Hmmm, that got me thinking the IZ2S utilities and some unimplemented features I'd put on the backburner for all that stuff. So I gathered up the old scripts, and various scraps of code from pastebin, and assembled an IZ2S utilities repository on github. Then I got to work on some of those backburner utility projects. First I folded the power management and LED control multi-call-binaries into one super utility mcb. This allowed me to add the missing keyboard backlight restore function to lid switch monitor, without calling a separate executable. I built it with tiny executable settings, so someday I'll make yet another jffs image and this'll save a bunch of space on the flash, and possibly some runtime RAM as well.
I also cleaned up the fake mouse demon and added code to intercept key press events on the zipit's side mounted volume rocker button. If the control or alt modifier keys are active when the rocker is pressed then the demon steals the key events and adjusts the backlights instead. It's almost just like I promised way back when I published my preferred "universal" keyboard layout. While I was in the code I also (finally) added functions to get some use out of the play and stop buttons, when they're being interpreted as the left and right fake mouse buttons (probably most of the time given the general lack of mouse aware programs on the zipit). Previously I'd added play and stop icons on the gmenu2x settings screen, which is nice, but the actual physical play and stop buttons are available all the time. Much better. I've currently got them sending fake key events to tty4 if anything like mpg123 is running there, but you can edit the OnPlay or OnStop scripts if you want them to do something else.
The play and stop button work got me thinking about the youtube and movgrab. I long ago lost track of the SD card where I originally set all that up for IZ2S, and couldn't find a pastebin with my IZ2S youtube scripts, so I started over and came up with something that mostly works. Live streaming only works well with the postage stamp size video. Perhaps the stdin and stdout buffers are limited (like named pipes) to 64K in the aging stock zipit kernel? So to work around, I let movgrab spool things to a file on the SD card and pointed mplayer at that instead of a pipe. It works well for short full screen videos, but eventually breaks up on the longer ones. That's ok, I suppose. The movgrab process eventually gets it all and you can play it back later with slightly better settings.
Slightly better is still sorta iffy. I swear it looks better in real life.
I suspect maybe youtube is throttling the stream, so I tried to get mplayer to display the progress bar and let me monitor how far along it was getting. But apparently the old IZ2S mplayer was compiled without progress bar support. It's a pretty old version. Maybe it's time for an upgrade?
The tiny 3gp video streams ok, but there's not much to see.
I started on a new mplayer build for IZ2S, disabling this and that -- things that will never work on the zipit -- and patching the ffmpeg code for uclibc. But what I've come up with so far is still too fat and bloated. If I can't build a reasonably lean and mean mplayer with progress bar support, then perhaps I can convince the existing mplayer to leave a few rows of pixels on the bottom of the screen untouched. Maybe I can put up my own progress bar with a small framebuffer program running in the background, monitoring the movgrab download progress while simultaneously tracking the estimated play time? I did some experiments with libFB and libpsf, but nothing conclusive yet. Also, while I can have the background process send pause and play commands to mplayer if the download buffer gets too low, what happens if the user (me) manually tells mplayer to pause, or even quit. How's the background process gonna know about it? Gotta do some more thinking on this...
I'll try and package up the goodies and drop them here when I get a chance.
Ok, here's the Arch gmenu2x, gmu, and qemacs in /usr/local/*.
zipit-arch-local.tgz
Here's the assorted helpful scripts that I've got in the Arch home directory.
archome.tgz
Update - December 2015:
Mozzwald made an updated arch image with the oss enabled kernel, and I recently acquired some cheap 32GB micro sd cards, so I decided to try it out. Dropbear is a real package now in the arm arch distribution, so that's pre-installed on the new image. Nice. This also has the backlight blanking demon so the screen will blank even when closing the lid on an SDL program. Good stuff!
Since this was a new install, it gave me the chance to document the steps required to get the gmu and gmenu2x in the zipit-arch-local tarball above running.
Right after installing mozzwald's image on the sd card, I installed the two tarballs above. Then I put it in a zipit and booted. When it was up and running, the first thing I had to do was look under the battery for the mac address so this zipit wouldn't conflict with my other arch zipit on the wifi. Install the correct mac and connect to the wifi.
ifconfig wlan0 hw ether xx:xx:xx:xx:xx:xx
wifi-menu
Next you want to install some packages. You'll need to turn off zram and use just the swapfile, otherwise pacman will run out of RAM. Maybe zram and a swapfile work ok together for small things, but I never got them working well together for pacman.
swapoff /dev/zram0
swapon /swapfile2
Then update the packages, and install some good stuff.
pacman -Syu
For SDL you have to use --nodeps twice or pacman will pull in all sorts of bloated X11 junk. The dependencies for the other sdl libraries are ok though. Same for alsa-utils.
pacman -S sdl --nodeps --nodeps
pacman -S sdl_ttf
pacman -S sdl_image
pacman -S sdl_gfx
pacman -S alsa-utils
I use mpg132 for the internet radio app in gmenu2x. Openssh is handy for scp. And fbgrab is handy for screenshots to prove you did it.
pacman -S mpg123
pacman -S openssh
pacman -S fbgrab
Once you have all this stuff you need to setup your environment for SDL so it knows to use the framebuffer and alsa drivers. You'll use some of the scripts from the archome tarball above.
. /root/sdlenv
. /root/alsaon
I probably want to set the init system to do this and the mac address on every boot up, but I'm not there yet. This should be enough to run gmu, but I still need to create a wrapper script for gmenu2x in /usr/local/bin, and maybe plug it into the init system.
Don't forget to fix the top display settings. Scroll to the bottom for instructions.
No comments:
Post a Comment