All the apps mentioned in this document and a few others I have found useful are listed here. In most cases the links are to my own packages which are sometimes modified versions of the stock upstream app.
A note to Debian users: don't give me any crap about the quality of the .debs. I know they fail policy on a number of accounts. It is too much work to clean them up compared to the number of people I expect to be using them. In any case they are perfectly functional and probably even have all the necesary Build-Deps.
A note to non-debian users: The .tar.gz's that you will find is the original upstream source. You must apply the accompanying .patch, as in 'zcat ???.patch.gz| patch -p0', to apply get any changes I have made. 'patch'ing also adds a debian directory from which you can build the binary or the debian package. The former via 'debian/rules build'. Otherwise just do the usual ./configure (where applicable) make, make install.
Xstroke allows pen input anywhere on the screen, a dedicated input region is not necessary. Stroke interpretation is fast and robust and in the default alphabet strokes look exactly like the letter they generate making learning fast and remembering easy. This is not handwriting recognition. Input is character by character with one stroke per character. It is like Graphitti for Palm with a more flexible alphabet and full screen input window.
Note that this latter feature can make using the pen for normal clicks and scrolls annoying. There are provisions for such use but in practice it is better to just shut of the gesture engine when not actually using it for typing. If you switch back and forth a lot you may find you prefer to instead have a separate input region which doesn't grab all the mouse events. In this case see xscribble or wmwrite.
Xstroke docs claim that the control window is dockable. I never found the upstream code to allow this so I did it myself. Also had the control window report the last key sent. This is helpful when inputting passwords to confirm you added the character you intended.
If you happen to like using a dedicated input region, xscribble works just like graphitti. It may even use the same alphabet. I am not sure this app it be actively worked on any more. Mostly people seem to use xstroke.
Stroke input is slow even when the conversion is fast and reliable. It is especially slow compared to keyboard input. I am speculating that this is due to the complexity of the strokes and am experimenting with simpler stroke alphabets. wmwrite is the testbed for these ideas. Currently wmwrite implements a two stroke alphabet that I currently happen to think is optimal. Each character is represented by two straight lines. In addition, lifting the pen at the end of the stroke is optional, further saving time, and ideally, eventually the app will optionally work without a dedicated input window as does xstroke.
This was inspired by ideas from Quickwrite which is an alternative shorthand pen input for PalmOS. This system is available as an optional method for wmwrite. Quickwrite's alphabet is simpler at its core. All characters are basically a single horizontal or vertical stroke of two possible lengths or a single tap. But as implemented, two additional strokes are necessary for each character, to and from a common central region, that result in the entire stroke being a bit longer. These extra strokes can be eliminated when using a separate input region, and in wmwrite they are optional, but it would be difficult without them when not using a dedicated input region as the origin of the strokes matter.
Eventually wmwrite will also eventually optionally implement any other alphabet with configurable recognition grids as well, including the sort used by xstroke. Or maybe once I figure things out this can all just be rolled into xstroke. I also intend to use it to implement chorded keyboard and tranliterated alphabet input.
Either way there is more work to be done, though I do happen to already use wmwrite, but it's a bit messy at the moment.
Gournal records raw strokes. It might be better for taking notes when stroke based character input is too slow. You could just use a drawing program, especially a vector drawing app, but Gournal has some nice features that make using it just for taking notes more convenient, like multiple pages, pen size and highlighting color setting available directly in the main window, as well as automatically determined filenames.
Can't tell that this has been worked on lately, but it is currently functional. It was inspired by the Java based Jarnel, which is also good in general, but unusable in the Progear since Java is so slow on the Progear
This is a generic GPL application that reads Progear SmartBattery status using the SMBus (i2c bus) and reports it on the console. Just requires i2c support in the kernel and the appropriate /dev entry. Info might also be available in /proc with the i2c-proc interface in 2.4, or in /sys in 2.6 but I haven't look very hard yet.
This is a slightly modified version of wmacpi that reads battery status via the SMBus, as sbstat above does, rather than ACPI. Also has an unused button that may be good for something, suspend? Should probably call this wmacpi_pg or something to prevent confusing. The upstream wmacpi is already a couple versions ahead of the one I based this on. Remodifying the new version should be quick.
Could integrate these changed with the official upstream source, though it is probably not generally interesting since it is intended for use on the Progear, except that the Progear battery is a SmartBattery system and maybe that itself if common enough and the interface standard enough that this can be used on other systems without ACPI/APM battery support.
This is a similarly modified version of wmpower to get battery status via SMBus. Also rewired to get CPU temperature info using libsensors rather than ACPI. This once should also be called wmpower_pg or similar.
This is a device driver for the Progear lcd. It has a /dev interface that allows you to read and set the LCD dimmer and DPMS settings using simple echo and cat, rather than through IOCTL's that require another dedicated program.
Should probably move this interface to /proc or /sys but I don't know how to do this. Ideally all this functionality is integrated with ACPI anyways.
Since this driver is based on proprietary Progear code in fpPowerMgr, or at least based on information obtained from such code, I don't think I can distribute it. Maybe I can just leave out those bits for you to fill in yourself if you happen to have know. It has also not yet been ported to 2.6.
This driver performs the single function of invoking the S3 power state as done in fpPowerMgr via a write to /dev/progear_power. Also based on proprietary code and ideally superseded by a fully functional ACPI.