Next: 1 Introduction Up: Debian on the ProGear Previous: Quick Summary
I finally got around to porting all the hardware drivers to 2.6 and while I was at it added an ACPI interface to the battery/ac driver and even managed to get the joystick to work and some lcd backlight brightness tools wired up. Some day these new details may be integrated into the rest of the document, but probably not, and in the meantime a sketch of the details are given here.
The battery had been available via an /dev/i2c file, but getting the battery stats out of that then required custom apps, i.e. the below mentioned wmacpi, wmpower, sbstat,... While fiddling around I learned how to use the /proc filesystem and made a battery/ac driver that appears functionally equivilant to a standard ACPI system so that all standard ACPI battery apps can now get the progear battery status.
Fetch the latest progear-battery-x.tar.gz, and progear-ac-x.tar.gz if you want it, from the driver directory unpack and 'make install' them. Note that these will clobber your existing battery.o and ac.o in the /lib/modules/.../kernel/drivers/acpi driver directory. No matter since those are useless anyway and this makes it easy to avoid conflicts. But if you like them somewhere else, fiddle with the makefile, or install it yourself, or just 'make insmod' from the driver source directory.
However you like it, after loading the battery driver you should have info, status and alarm entries in /proc/acpi/battery/BAT0. I didn't try to implement any alarm behavior so the alarm entry just reports unsupported. Similarly /proc/acpi/ac_adapter/AC0/state should report on-line or off-line as appropriate.
The info data is cached. It is loaded once when the driver is loaded. All but the 'last full capacity' there is static information so you shouldn't care. Similarly status info is cached, but a new read attempt is made for every item when .../state is read. Sometimes the bus is slow, or doesn't return a valid answer. In those cases the old info is re-reported. I was hoping this would reduce all the ``i2c-0: Error: command never completed'' messages in the syslog. But it doesn't seem to make any difference.
Note that I implemented this driver by directly rewiring the stock kernel acpi battery driver so that it gets battery stats from the i2c but rather that ACPI routines. In this way I didn't have to rewrite how the driver formats that data output. This should result in identical status output and maximum compatibility with existing ACPI apps. I have tested it with the gnome-battery-applet, KDE (kde requires the ac modules) and every dockapp I had around and they all give reasonable results. All agree on the remaining capacity, %, but some seem to calculate the remaining time in different ways, or at different intervals, and so can get different results. But any is as sensible as another.
It seems to me that I should have learned enough about the ACPI interface to just fix the dsdt and be done with it, but I still don't immediately know how and haven't tried. But I am still interested in making the attempt someday.
The pci driver API changed for the 2.6 kernel and 2.4 drivers were not immediately buildable so I had been unable to use even the crude means of adjusting the screen brightness using the Frontpath 2.4 drivers and test_backlight. I have rewritten the driver from scratch for 2.6 and as it, as a result, contains only a few strategic hex addresses from the FrontPath driver I am just going to publish it.
See the driver directory. Fetch the latest progear-lcd-x.tar.gz, unpack it and 'make install' it. Afterwards you should be able to 'modprobe progear-lcd'. I got too excited about knowing how to use /proc so I moved the interface to /proc/progear-lcd, but it probably should have remained a conventional device in /dev/progear-lcd. Some day I will move it back, but now get the LCD status via something like 'cat /proc/progear-lcd' and set it with 'echo $p > /proc/progear-lcd' with 0<$p<100, i.e. 'echo 75 > /proc/progear-lcd'.
Note that for $p=0, the driver will shut the backlight off, so watch it if you are testing and be ready to type blind. $p=1 is still visible even in relatively bright light.
Using a command-line app to set the LCD brightness was always annoying, so I rewired some existing apps for use in controlling the LCD. The are available in the apps directory.
First, gnome-progear-lcd is a gnome panel applet gives a slider from the gnome-panel wired to the LCD brightness. Version 0.1 is a hack of gnome-vaiolcd, 0.2 is written from scratch, but smaller, but stupider as it mostly ignores all kinds of gnome events that should change its position or orientation, but it works fine.
For a while it did amuse me to be running Gnome, but I got over it and went back to OpenBox and so needed a different tool. wmlcd-progear is a modified form of the volume.app dockapp. This is a big honking knob on the dock that you adjust by dragging up or down from. It is wired to the lcd backlight. It works great.
While playing around with /proc I decided to port the code that read the lid switch. progear-lid is the same kind of driver as the rest but just dumps an entry in /proc/progear-lid. I never properly integrated this into /proc/acpi/buttons/... because I never got any sensible results from it. Reading this entry gives the same results whatever the lid state. I have not yet tried very hard to really make this work. Again, I intend to.
Here is my great triumph. This took some work. The timer queue stuff all changed as well as the pci API, so getting the driver to build took some considerable changes. I butchered and streamlined much of the rest, even where not required, just so I could understand it, but didn't really rewrite it from scratch, and didn't feel like doing so immediately after I got it working. Later I will, but in the meantime I have seen this n9joy driver code kicking around the net often enough to not worry too much about publishing this.
Get progear-joystick from the driver directory and 'make install' and 'modprobe progear-joystick' it. You will get a /dev/progear-joystick that you can immediately read from. Try something like 'cat /dev/progear-joystick | hd' and move the joystick around. You should get a stream of data.
I deliberately kept the same output format for the joystick data for now so that the stock progear tools x_fpjoy... would still work. And they do, but again are annoying and inflexible so I wrote another.
While working on this I found that the joystick is actually an analog device, and not just an array of switches. The output is supposed to be a set of continuous 2D coordinates, plus a button press. I was initially excited about the possibilities of using this for richer input, maybe implementing a hardware quickwrite or similar. Unfortunately, for my hardware at least, the output is extremely flaky. There is noise in the coordinates almost as large as the signal itself, the average drifts and the output is sometime not even monotonic or repeatable. In the end it is just barely usable for reliably reporting four positions. Maybe there is hardware trouble with my device, maybe the driver is reading position incorrectly, maybe some fancy averaging would allow more precision (though all my attempts so far have not improved anything significantly) so for now you have to settle for the original factory functionality.
In any case, the program joystick_read in the driver directory deals with using the output for something useful. It should build with the driver. Try './joystick_read dump' for a raw dump of the data from the joystick and converted x/y coordinates from each point. You can use this for calibration but it is hard to see through all the noise to instead do './joystick_read plot' for a ncurses based plot of joystick position. Move the joystick to each side, you should get a set of four mostly independent blobs centered about the origin. If the blobs are off center change yc and xc in convert_point in joystick_read.c and recompile. Someday we will make that calibration easier.
Now try './joystick_read show_key''. Move the joystick. You should get a different number printed to the console for each direction. If so you are read to just './joystick_read' and use the thing. It is currently wired to do up/down arrow for up/down and page_up/page_down for left/right. Change these in the code for anything you want. Also change it explicitly for different screen orientations. Again will get more sophisticated some day.
I also arranged that pressing the button acts as an escape key. This is just the thing for running acroread or evince in full-screen mode without a keyboard or mouse and not getting stuck.
Note the the console is still polluted with output when './joystick_read'ing so you will probably want to do something like './joystick_read > /dev/null' in your .xsession or .xinitrc.
Still don't get much from ACPI/S3, and ACPI/S1 really burns up the battery. But, I am happy to report that Software Suspend 2 works great. This writes the hardware state to the hard drive and does a complete power off. Get the patches and the hibernate app from the SWsusp2 site and rebuild your kernel, fiddle with lilo.conf and just 'hibernate'. The only problem is that when using a rotated X screen, X does not resume properly (apparently as usual when using ShadowFB) but switching virtual consoles before and after hibernating usually works.
Note also that hibernate does everything I was trying to do in my acpid scripts and more, and does it well and right, so just use this instead of bothering with any custom solutions. hibernate can also be configured to use ACPI sleep states, so it would manage S1 and S3 sleep states as well as SWsuspend. I tried it for S1 and it worked fine. Again S3 doesn't work. I am starting to wonder if S3 ever really worked, but I know the sleep state battery life was much better so it must have.
Eventually I read enough to convince me that some people do get USB keyboard support before booting and finally found the latest BIOS'es at progear.org. Fetch 1.04.04 from there and install it with progear-bios from apps. Didn't notice anything else particularly useful, though maybe this is what screwed up my S3.
I was recently introduced to Opie and GPE on a Sharp Zaurus and found them extremely capable. Both have IMAP mail readers, PDF readers, Ogg Players, Consoles, and Web Browsers. They are entirely pen oriented and so seemed possible useful when using the Progear as a slate.
Opie is a fork of Qtopia and is build on QtEmbedded. QtEmb is an alternative to X for driving the display and Qt apps can be recompiled to work on QtE. Unfortunately Opie is based on a heavily patched QtE and as a result an arbitrary Qt App would probably require a lot of tweaking to run on Opie's QtE. But Opie has a (lean) version of every kind of app you would want anyway (KStars) so it is not much of a hardship to be confined to Opie Apps. Both basic Opie and its modified libqte build easily and run as directed, though getting paths, environment variables and other services all lined up correctly is a pain in the neck. If you enable display frame buffer support in your kernel you can start Opie right from the Linux console. You can also start it from X via qtfb.
The direct fb route should be the fastest but there is no stock means of reading the pen in this way. Should be a way around it, but from Opie's built-in benchmarking tools, I don't see much difference in performance anyway so I haven't pursued this. The pen works fine as a pointer for Opie in X, though strangely here the keyboard doesn't. So I just use Opie when only using the pen. I like the purity of the framebuffer route and so I intend to get the pen working there. I already found some leads.
Not all of the apps build immediately, most notably qpdf2 and konqueror-embedded need some kind of coaxing that I have not yet figured out. I was also hoping that the screen rotation would work immediately, but it hasn't. So in the end Opie is still usable, though not actually much faster that a conventional X environment (see below) but its integration is promising enough that I will pursue it and perhaps package a fully functional build of it for debian.
GPE is less dedicated and basically just a collection of apps for X that work nicely for handhelds. So it doesn't have its own web browser or pdf reader, but you can simple use dillo, or xpdf. This would seem to make it pointless, except that it also includes an application manager, panel, window manager and other tools that make working with only a pen much easier, including onscreen keyboard and handwriting (xstroke).
GPE turns out to be the Matchbox apps, the desktop, window manager and panel, and a set a very lightweight GTK+ apps. The basic matchbox stuff and a few core gpe apps, gpe-edit, gpe-julia, gpe-taskmanager, gpe-todo, gpe-contacts, are available in the stock debian archives and so trvially installed. All the rest of everything is available cvs, svn or as tarballs and turn out to be easily built and installed.
For no apparent reason the debian package of matchbox-panel does not include the battery or wifi monitoring applets. You can build and install these from the current subversion source, or from the debian source package with libiw, -enable-apci-linux and a small change to the source. The current upstream also includes applets for volume and pen based keyboard or stroke input. I expect all of these other applets will be included in the debian package when it is upgraded and you won't have to mess around with the source. Note that these applets are just standard system tray applets so that you can, both, use them with any other system tray, with some limitations, I have been using the mail and wifi monitors in fbpanl with openbox, and other tray apps, xstroke in particular, work in the matchbox-panel. The whole arrangement is very flexible.
The gpe apps include little configuration utilities for wifi, sound,... and a huge collections of simple lean apps, gpe-gallery, gpe-filemanager, calculator, clock, calender, mail, contacts, and text and graphics editors, and the usual sort of PDA aggregation tools, e.g. gpe-today. They are clean, start up fast, and just do there job and go away. Again, and X app works, so when gpe-mail ocassionally fails you thunderbird can take up the slack.
When using a keyboard and pen, I still just barely prefer OpenBox/fbpanel, but as a slate Matchbox/GPE has completely taken over.
One or the other, or both, of Opie/GPE is just thing thing for the Progear when using only a pen without all these workarounds for right clicks and keyboard shortcuts. All of the ease, comfort and simplicity of the factory Progear environment are restored, with none of the limitations. These are the closest to the factory environment and completely eliminated any lingering reasons I had for keeping it around.
The panels includes an App menu, program launchers, system applets and an input applet that display an on-screen keyboard or other region for stroke or handwriting recognition. Also since GPE is X11 based xstroke operated perfectly and is activated in the usual way by an icon in the panel.
The desktop is organized collection of the apps and files on your system. Apps, including system configuration and preferences, are launched, or documents opened with a single click on the desktop, or two (or three), if they are in another folder. Everything is easily visible and a pen tap away, separate, dedicated file-managers are rarely nessesary, but still available, a terminal console, dedicated or otherwise (gnome-terminal, xterm,...) is available for hard core fiddling. The GPE desktop is particularly easy to tweak and rearrange by fiddling with .desktop files.
In both cases the window manager assumes there are two kinds of windows, apps, notifications and input. Only one app window is allowed and all apps run full screen. This apps window is then automatically, and sensibly resized to make room for the on-screen keyboard or handwriting input.
Basically it all works like the factory progear environment except for being ten times more useful with enormously more apps and tools available.
With GPE in particular you can integrate any X11 app into the handheld environment, though of course they may come with its own limitations when used in a pen only environment. Both are active projects that can be kept up to date with the latest kernels and distributions.
Since I had to enable the frame buffer to try Opie I was also able to see how well the X framebuffer driver did compared to the Silicon Motion driver. It turns out to be significantly faster. As a crude benchmark, xengine, when started from an X session using Driver ``siliconmotion'' yields 580rpm. With Driver ``fbdev'' the jumps enormously to 830rpm. Clearly the frame buffer driver is enormously faster and so I have been using it exclusively lately though in the end it does not appear to result in apps like firefox, thunderbird, xpdf feeling much faster as those have enough other work to do that writing to the screen is not much of a bottleneck.
I was also hoping that since the framebuffer is a more generic device that it would support screen rotations, but so far xrandr reports no possibilities other than 'normal'. This also merits some more attention.
I tried running both Gnome and KDE for a while, and they work fine, they even work well, but in the end I went back to a simpler OpenBox and a couple of dockapps. I had previously been using PerlPanel but lately decided it was also to bulky and moved to fbpanel for managing workspaces and windows, and for launching a few key applications. The combination of OpenBox and fbpanel provides every bit of functionality I need and is snappy, especially compared to Gnome,...
xpdf is the quickest pdf reader I know of. No full screen mode and has trouble with the occasional bit of exotic pdf weirdness, but otherwise a good staple. Evince is nice for full screen reading, especially with a functional joystick, and will even rotate the doc, eliminating almost all of what I wanted general X rotation for.
dillo works well for reading simple html, though kind of ugly, and no CSS. dillo is being ported to fltk which should improve its looks enormously. Maybe it will get some other advanced HTML support in the process. There are also, of course, the text based browsers, w3m, lynx, links,... which are good enough for many purposes, but I will mention links2 in particular becaus it turns out to have a graphics mode. Start it as 'links2 -g' and you get a fully functional graphical web brower. It is slamming fast, probably faster then dillo. Like dillo it lacks CSS, frames, Java, Flash, ... links2 is also remarkable because it can use the linux frame buffer device for output so in can run directly from the console, that is, without X! There is a bit of a disadvantage when trying to use this on the ProGear without a keyboard as the touchscreen is not immediately available as a pointer, and, of course, there are no means for text input.
Netscape 4.77
Opera
gpe-mini-browser
minimo
For other tools, rox-filer is fine filemanager for this environment, though it will not allow icons on the desktop without letting rox-session manager you entire session and basically run the rox desktop, which is not bad, but also not great enough to be worth the trouble.
gpe-sketchbook is much faster than gournal.
For input xvkbd, xstroke and wmwrite are still all useful in their own way. WMWrite needs an update. An integrated solution like Opie or GPE would be great here.