Article: Installing Microwindows on the iPAQ
Jan 15, 2001 — by Rick Lehrbaum — from the LinuxDevices Archive — 3 viewsForeword: This article is the third in a LinuxDevices.com series on Exploring Linux PDA Software Alternatives by Jerry Epplin that explores the history, status, alternative architectures, and future developments of Linux on PDAs and handheld devices. In this installment, Epplin examines the use of Century Software's Microwindows and associated Linux software on a Compaq… iPAQ PDA.
Installing Microwindows on the iPAQ
In the previous articles in this series, I introduced the options available for Linux on the Compaq iPAQ PDA and walked through the installation of the base handhelds.org distribution. Although Compaq ships the iPAQ with Windows CE, they also sponsor a remarkably open project at www.handhelds.org with the goal of porting Linux to the iPAQ.
The handhelds.org distribution is a straightforward Linux port based on X, so it appeals to experienced Linux software developers. In addition, at least three other companies are developing add-on GUI development toolkits, all of which replace X with a GUI built directly on the Linux framebuffer interface. This article examines one of these three, namely the Microwindows Development Toolkit by Century Software. Future articles will take a look at the other toolkits.
About the FLTK API
FLTK (www.fltk.org) is a simple but flexible GUI toolkit that is gaining increasing attention in the Linux world, especially for low-footprint environments. It provides most of the widgets expected in GUI toolkits such as buttons, dialog boxes, text boxes, and a nice selection of “valuators”, which are widgets used for the input of numeric values. These include sliders, scrollbars, dials, and a few others.
Anyone accustomed to developing GUI-based applications under more common environments like Windows will adjust to the FLTK environment quite easily. As one who has occasionally written Windows-based GUI applications for a number of years, I especially appreciate the straightforward openness and stability of FLTK — it is not in a constant state of flux as its developers try to follow the mandates of some corporate marketing department. Another advantage of FLTK is its documentation — a very complete and well-written manual is available. Finally, it is distributed under the LGPL, so developers have flexibility in how they license their applications.
FLTK is a C++ library, though Perl and Python bindings are also available. The choice of an object-oriented model is a good one, as most modern GUI environments are object-oriented; this should also facilitate the porting of applications written to similar APIs.
A noteworthy weakness of FLTK
My one complaint about the FLTK API concerns its antiquated callback model. As you probably know, modern GUI environments are event-driven. When, for example, a button is pressed, a user-supplied function known as a callback is called to process the event.
In clean object-oriented environments, the callback is declared to be a member of the widget class — for example, there may be a Pressed() member of the Button class. If the application needs to process a button press, the programmer derives a new class from the Button class; calling it, say, StopButton, for a button that stops some process; and provides a Pressed() member to perform the operation of stopping the process. This clean model of callbacks preserves the object-oriented nature of today's GUIs.
In contrast, FLTK uses an old-fashioned model which requires an explicit call to install a callback; the callback must be a C type function or static member function, which breaks the object-oriented design. I personally find this limitation quite irritating — I can design code according to either a pure object-oriented or pure procedural model, but FLTK's model is a hybrid that I find disorienting.
The only workaround is to use a static member function as the callback, install it in the widget's constructor, and pass the 'this' pointer to the callback. See the FLTK FAQ for details on this rather clumsy and unsatisfying workaround. In my view, this limitation alone puts FLTK in the same class as older C oriented APIs like Win32. It is certainly possible to write good code with this model, but the design seems a shame since it would be quite easy to implement a more modern callback model.
The development process
Several options are available for FLTK-based development under the Microwindows Development Toolkit. I recommend doing most of your development natively on your desktop computer, using the standard FLTK — converting to FLNX on the iPAQ only after the GUI has been completed and debugged. Installing FLTK under Linux is usually straightforward and easy. Download the latest source from www.fltk.org. Untar the file, change to the newly created fltk-1.x.x directory, type 'make', and wait for the build to complete. The build process uses the standard GNU autoconf program and takes most of the usual options.
Once FLTK is built and installed, compiling and linking your applications is quite straightforward. Here is a simple Makefile for building the 'checkers' sample application provided with FLTK. You'll find that native Linux software development using FLTK is fast, simple, and quite easy; so I recommend using this mode for the bulk of your GUI development. Switch to the more complex FLNX/Microwindows/skiff model (described next) when you need to write iPAQ-specific code (such as processing button presses) or for final testing.
Century Software provides its FLNX/Microwindows environment for both the iPAQ and for Linux under X (and other platforms). They also provide a full X-based simulation of their ScreenTop environment. This simulation has a look and feel quite like that of ScreenTop run directly on the iPAQ. That way, you can run your applications directly on your desktop computer and see how they will look and behave on your iPAQ.
Another benefit of the X-based ScreenTop environment simulation is that it lets you get started developing your applications while waiting for your iPAQ to arrive — you'll find that the iPAQ is currently backordered at most of the retail outlets so you're likely to have to wait for one.
Setting up this environment is a bit harder than a simple FLTK install. I'll run through that next.
Setting up the development environment
First, download the current version of Microwindows from the Microwindows ftp area.
Then you can get FLNX from the ViewML CVS repository; see the viewml download instructions regarding how to connect to their server. Use “cvs co flnx” to get the current version.
On your desktop computer, create two directories for the two trees — you might call them basetreearm and basetreex11. You might wish to perform these actions in separate windows and in parallel, since setting up the StrongARM and X11 trees is almost identical. Be sure to “source exports” in the “arm” tree to use the “skiff” cross-development tools as described in my previous article. Untar Microwindows and FLNX in both of these directories, producing (under each one) a “microwin” and an “flnx” subdirectory. Change to the “microwin/src” directory. In the iPAQ (i.e., arm) tree, copy config.ipaq to config, and in the X11 tree, copy config.x11 to config. In the “arm” tree you may want to follow the directions on supporting JPEG found at config/jpeg/README.txt — otherwise clear HAVE_JPEG_SUPPORT in the config file. Then type “make” in the “src” directory of each tree and wait for the build to complete.
To build FLNX, change to the 'flnx' directory of each tree. Type “./configure –with-microwin=(path to tree)/microwin/src”, specifying the full path to the microwin/src directory. Again, type “make” in each tree.
Testing the desktop iPAQ simulator
Once both trees are built, you can test your code under X on your desktop and simultaneously build for execution on your iPAQ.
Get Nano-X running on your desktop by executing basetreex11/microwin/src/bin/nano-X. This opens a window in which Microwindows programs can be run.
Then, when you run your program, its output is visible in the Microwindows window. You'll probably find that this X-based Microwindows environment is rather fragile and inefficient — try running the “checkers” example under FLNX to see how slowly it runs — so you might want to move directly from FLTK development to testing on the iPAQ if possible. Here's a simple Makefile that builds a program either with FLTK, FLNX/Microwindows on X, or FLNX/Microwindows on the iPAQ — use the “checkers.fltk”, “checkers.flnx.x11”, or “checkers.flnx.arm” targets respectively. Again, be sure to “source exports” before running the iPAQ build.
Console I/O
As mentioned earlier, GUI output using FLNX is identical to FLTK on a standard Linux desktop. Input, on the other hand, is quite different.
For input, the iPAQ has a touchscreen and a number of buttons located around the unit. Input to your application must be mapped to these input devices. Both the buttons and the touchscreen are controlled through the touchscreen device driver, found in drivers/char/h3600_ts.c in the iPAQ Linux kernel. When running Microwindows these are normally under the control of that environment, but it may be helpful to understand how they work.
To get the key status, open “/dev/h3600_key”. A read of one byte returns when a key is pressed or released. The low four bits indicate which key is pressed, and bit seven is cleared for a key press or set for a release. Note that detecting multiple simultaneous keypresses is not supported by the interface; this limitation reflects a limitation in the design of the hardware, which cannot detect multiple keypresses.
Access to the touchscreen information is similar. Open “/dev/h3600_ts”. Packets of type TS_RET are returned from a read — find the definition of TS_RET in /kernel/include/linux/h3600_ts.h in the iPAQ Linux kernel. This structure contains an X and Y location of the stylus; and 'pressure', which is 1 for pen down and 0 for pen up.
iPAQ PPP access
The current Century Software distribution (1.01) contains a bug that makes it difficult to establish a PPP connection with the iPAQ. Normally (as in the standard handhelds.org distribution) the PPP daemon (/sbin/pppd) runs with the suid bit set, as it must run as root. But this seems to have been overlooked in the current distribution. To make matters worse, the distribution is not shipped with source — only the cramfs files are available, so you cannot simply make the change and rebuild the cramfs file if you have Linux 2.2.
I know of no reasonable workaround for this bug. The only unreasonable workaround I know of is to download, configure, build, and boot a Linux 2.4 kernel (be sure to select “Compressed ROM file system support” under “File Systems” and “Loopback device support” under “Block devices” when you configure); modify the cramfs file with something like “mount -t cramfs root.cramfs /mnt/cram -o loop”, “cp -a /mnt/cram temp”, “umount /mnt/cram”, “chmod +s temp/sbin/pppd”, and “mkcramfs temp root.cramfs”. See my previous article and the handhelds.org filesystems minihowto for more information on working with cram filesystems on the iPAQ.
Overall assessment
The Century Software Microwindows Development Toolkit is a good choice for developers seeking a complete but compact GUI development environment for PDAs. I find the FLTK API on which it is based to be nearly ideal for compact environments — it has the widgets one would expect from a modern GUI, but none of the bloat one finds in desktop environments.
My one complaint is the hybrid object-oriented/procedural design of the FLTK API, which I find difficult to adjust to. Aside from this annoyance, the environment is easy to become accustomed to.
It is true that one could simply implement FLTK on top of X for the iPAQ, rendering Century's environment unnecessary. But the smaller footprint that Microwindows provides makes it easier to port your applications to PDAs with less generous resources, a factor that will become more important as Linux is ported to lower-end PDAs.
Another advantage of Century's environment is that it provides several useful facilities, such as ScreenTop and the ViewML browser, whereas FLTK implemented directly on the handhelds.org environment does not.
Century Software has made a number of significant contributions to the body of open-source software, ranging in importance from Microwindows itself and ViewML to, most recently, a port of DOOM to the iPAQ. (I'll leave it to you to judge which end of that spectrum is more important.) The Microwindows Development Toolkit continues this tradition, assembling some well-designed components to form a complete development environment for PDAs.
About the author: Jerry Epplin has written embedded software for the past fifteen years, primarily for medical devices. He can be reached at [email protected]
The following articles may also be of interest . . .
- The Linux-PDA and PDA-Linux Quick Reference Guide
- The Embedded Linux GUI/Windowing Quick Reference Guide
- Graphical Windowing systems for Embedded Linux
- Using the X Window System in Embedded Systems
- Insights into ViewML development: history, status, and plans
- Linux + Microwindows: challenger to WinCE
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.