Once you manage to boot a new kernel with the new filesystem as root you can finish configuring the rest of the system and then finally start using your machine and getting on with your life. Some of this can be done while bootstrapped from the Progear kernel, but only the USB/Keyboard support previously mentioned needs to be, so might as well save the rest for here.
First do the usual system maintenance. Add users, set up apt, set the hostname, install any apps or utilities you want, check to see that X works and fix it if is doesn't.
With proper kernel or standalone pcmcia support pcmcia should be mostly self sufficient. At least one adjustment must be made to the standard configuration. The touchscreen device uses ttyS1 and IRQ3. The pcmcia driver doesn't not recognize this interrupt and being unavailable and so it will use it when the modules are loaded and as a result the pen will cease working. Edit /etc/pcmcia/config.opts to exclude irq 3 from use by the pcmcia drivers. In exchange you can allow the use of irq 7 as there is no parallel port to compete with.
Also, as configured, the slot will not recognize card insertions and removals. When using the standalone drivers, ``poll_interval=100'' can be added to PCIC_OPTS in /etc/defaults/pcmcia (for debian) which fixes things fine for 2.4.
According to the Linux PCMCIA Howto, the root of this problem is an interrupt configuration deficiency and a proper fix for this problem is to manage the interrupts properly. The standalone pcmcia drivers can not be used in 2.6 and the yenta_socket CardBus driver doesn't support a poll_interval option so straightening out the interrupts is the only fix in this case. Unfortunately it is not a fix I have managed to do so I have to manage insertions and removals manually with cardctl insert/eject. This isn't much of a burden in practice as I rarely remove or exchange cards. But it is still annoying enough in principle that I will try again to fix it. The 2.6 kernel includes an i82365 driver, perhaps forcing this to load with allow the poll_interval option to be used again.
If you get a working network connection, set up /etc/network/interfaces (in Debian) so that ifup/ifdown work. For dhcp be sure to install pump. dhcp3-client and udhcpc seem like they should work as well, but neither ever has for me.
As previously mentioned, battery status is not available via ACPI, or APM or any other conventional mechanism, though I aspire to learning enough to implement ACPI support. In the meantime you must use sbstat, wmpower or another suitably customized version of your own favorite app. See the wmpower code for a guide. Adaption is quite straightforward.
Make sure that the i2c_ali1535 driver is loaded when needed. Either list it explicitly in /etc/modules. Or arrange that it is configures in /etc/modules.conf to load when /dev/i2c-0, char major 89 is accessed. For example, in debian put the following:
above i2c-dev i2c-ali1535
This gives basic functionality but it is still frustrating not to be able to see this via ACPI so that any standard monitor will work. As far as I can tell, the BIOS supplied dsdt makes no mention of the battery at all, so I suspect it was just left out. The system uses a SmartBattery controller, which is natively supported by ACPI, so re-integration should be straightforward. I am imagining that it is possible using a modified dsdt loaded a boot so that a BIOS modification is unnecessary. I have yet to confirm any important details of this idea.
'senors' and any other lm-sensors compatible tools will work immediately after adm1021 is loaded. List it in /etc/modules. I don't know devices are used so I can't immediately say how to configure it with modutils.
I modified the dockapp wmsensors to read cpu temp via libsensors rather than ACPI, in addition to getting battery status via the SMBus. An advanced warning that you may initially be alarmed at the results. I get idle processor temps of 45-50C that quickly and easily shoot up to 75-80C when busy. That had seemed rather high and I was worried that something was wrong. I fished around a bit on the web but never really found anything that consoled me. In the meantime I just forgot about it. They system continues to run fine, so these must be reasonable normal temperatures.
On other systems CPU and M/B temperature information is available via ACPI's /proc interface. Here again it doesn't seem to be mentioned in the Progear BIOS supplied dsdt. This would be another nice thing to re-integrate into ACPI, though lm-sensors is standard and universal enough itself.
The problem with controlling the LCD backlight remains. Coarse control is possible via dmps in X with xset, but fine dimming control can only be done through fpPowerMgr. I have isolated all the LCD bits of the driver into my own derived code, as well as changed the interface so that control is possible by writing to /dev/progear_lcd rather than solely via an IOCTL which then requires another supporting app to make the actualy change. Again I will see about getting permission to distribute either the original or derived driver code, or reimplementing it using published data if anyone cares. Also, I haven't ported this to 2.6 yet anyways. The driver interface has changed, reportedly considerably, and I am not yet up to date on the differences.
As with the battery status, I would like to make this accessible via ACPI.
For managing shutdown and suspension there are two alternatives and one intermediate option. Neither is ideal, but all are functional. For 2.4, if you have the fpPowerMgr code you can simply recompile the module for the new kernel version and run fpPowerMgrd. Power and sleep will be managed exactly as it was for the stock Progear.
This method lacks some flexibility since it is a dedicated solution, and may not be available to everyone. Alternately, as of 2.4.19 or earler, the kernel and user space tools provide the same functionality, with an important difference discussed shortly, so it is possible to completely do without fpPowerMgr.
First a note regarding ACPI. In APM, power management is initiated by the hardware, with only polite notification given to the OS. In ACPI this is inverted and the OS completely manages power transitions. ACPI's only job is to let the OS know, for example, when the power button is pressed. So the way to do Shutdown or Suspension on an ACPI system it to have the OS itself shutdown or halt services and hardware when told by ACPI that it has been requested, and to restart them again when again told by ACPI to do so.
In debian acpid can be used to monitor ACPI events and configure appropriate actions. There the same or similar tools for other distributions. The default behavior is to run powerbtn.sh in /etc/acpid when the powerbutton is pressed. This should work right out of the box if ACPI kernel support is properly configured. The default powerbtn.sh just shuts down the machine. With a bit of adjustment the original Progear behavior can be reproduced, one press for sleep, two presses for power off.
For an example of how to implement these kind of distinguishable button sequences see my own powerbtn.sh. When invoked as a result of a first button press it simply starts sleep.sh, which itself first creates /tmp/.do_sleep and then waits for 2 seconds to see what else happens. If, in the meantime, the button is pressed again, powerbtn.sh sees that do_sleep.sh is already running and instead removes /tmp/.do_sleep, which we will see signals do_sleep.sh to shutdown instead of suspend. Further button presses before sleeping starts have no effect. Meanwhile back in do_sleep.sh, after the two second wait is up, the /tmp/.do_sleep is checked for basic existence. If it is gone, presumably because powerbtn.sh removed it as a result of a second button press, do_sleep.sh starts a shutdown and poweroff via shutdown. This does as you would hope and cleanly shuts down the system and powers down. Otherwise the sleep sequence is initiated. There may be better means of communicating between the two tasks, and they don't really have to be two separate scripts either. Do what you want. You could even get more elaborate and have three button presses restart X if it gets locked up, or have it wait for further commands from from the power button via morse code! HA!
Now consider the actual sleep sequence in do_sleep.sh. The Progear technical docs report that fpPowerMgr does the following when suspending the machine:
This same sequence is followed in do_sleep.sh but implemented with discrete tools and with two important notes.
'cardctl suspend' stops PCMCIA services.
'hdparm -y ...' spins down the hard drive. Here you could be more ambitious and use -Y to force the hard drive to sleep, but it will do it itself after some 30 seconds anyway, and I have had intermittent trouble getting the drive to wake up after resuming when forcing it in this way.
Next the display must be shut off. Here is one bit of unpleasantness. As discussed already, and further below, coarse control of the LCD backlight as needed here, that is simply on and off, is possible via dpms in X, or the Progear fpPowerMgr device driver and the test_dpms utility. Either can be used to immediately shut off the display by either 'xset dpms force off' or 'test_dpms 3'. Unfortunately xset requires a connection to the xserver, which it will not have when run from the do_sleep.sh script as root in its own universe, so that only test_dpms can be used unattended. It seems like you should be able to set a display variable, like '-display localhost:,0' but everything that I have tried like that has failed and on reflection, I understand that even with an explicit display specified I still need a connection.
There is probably still a way around this, but as I do have test_dpms I haven't tried very hard.
For those without, I have to suggest manually blanking the screen in X before pressing the power button to suspend the system. Try either the xset just mentioned or even something like 'xscreensaver-command -activate && xscreensaver-command -throttle'. Neither of these needs an inverse because X managed the unblanking itself when events start to come in again. I will be doing the same for a while as I have not yet gotten to porting the lcd device drivers to 2.6. Better yet, put a button on the screen with a nice 'Zzzzz' pixmaps that runs this and then do_sleep.sh (or powerbtn.sh) directly when you press it. I have the sequence as a menu item in the main menu of perlpanel. It is actually not much of a burden. It may even be easier than pressing the physical power button.
Finally, there is the matter of the sleep mode. The stock Progear uses S3 without effort. 2.4 only supports S1 sleep via ACPI and is easily invoked by writing to /proc/acpi/sleep, which should probably be changed to the corresponding entry in /sys for 2.6. The difference between halting and powering off the processor makes a significant difference in power consumption. Once again if using the fpPowerMgr device driver you can invoke S3 via the BIOS as the stock Progear does, otherwise you are stuck with S1, which the performance differences noted presently.
2.6 is supposed to support S3 sleep, but so far I have never managed to wake up from an 'echo ``3'' > /proc/acpi/sleep'. You get a locked up machine with a blank screen that isn't roused by pressing the power button. It isn't off either, as a power button press doesn't turn it on. Instead you must hold the power button down for 5 seconds for a hardware enforced power off and then power up again. As far as I can tell from syslog the machine doesn't even start waking up. Once again, I have not yet tried very hard.
S1 still works in 2.6 and furthermore it appears that the kernel and cardmgr work together to shutdown pcmcia and usb themselves, so it is not necessary to do so explicitly in do_sleep.sh. The harddrive if probably dealt with to, but even if not, it will shut down by itself after something less than a minute of inactivity. So now in practice all I need to do to start sleep is blank the screen and hit the acpi /proc interface.
Once in sleep mode the system waits until the power button is pressed again. Then everything comes up in the opposite order it was taken down. For 2.4, the system time is also explicitly reset using the hardware clock. In 2.6 this is all again already taken care of.
I did a bit of a current accounting inventory to understand what is using power and when in an effort to understand the sleep lifetime and try to improve it. With everything on including PCMCIA, the system uses between 900mA and 1300mA, typically averaging about 950mA. This is almost exclusively a function of disk activity, 900mA is from a basically idle system, 1300mA is with the hard drive being continually accessed such as when downloading a large file, or when searching the filesystem. With the 3200mAh battery this gives the reported 3-3.5h battery lifetime.
Shutting down PCMCIA reduces current consumption by about 150mA. The lcd is of course the biggest pig, shutting this down yields another 400mA. Checking the effects of spinning down the hard drive is hard to do independently as almost any activity wakes it up, so I compare the difference between sleeping for 30 seconds with and with out explicitly spinning down the drive before sleeping. There may be a difference of 10mA or so but it is hard to see. As far as I can tell 'hdparm -Y' does no better, and again can lead to trouble anyway. Halting the processor itself, and whatever else goes down in S1 (USB?), reduces current consumption by about 150mA. In total these account for about 700mA, reducing power consumption to about 200mA. This implies a battery lifetime of some 16 hours. In practice I do a bit better. In 12 hours a initially fully charged battery is slightly less than 1/2 expended giving about 25 hours of total possible sleep time. This implies a snoozing current consumption of about 125mA. I don't know what accounts for the difference.
If you can do S3, you get only 10% depletion in 12 hours, for a total lifetime of more than 100 hours implying current use of only 25mA. A considerable improvement but again only available in 2.4 with fpPowerMgr via an appropriate ioctl in the original code, or a write to /dev/progrear_power in my modified driver.
Besides suspending, there are a few things that can be done to manage power consumption during use. These I have not yet fully explored. Three hours of battery life has been sufficient for me, though admittedly occasionally inconvenient. I would try harder to double it, but that seems unlikely and an extra 30 minutes is not worth too much work. Still I am curious and will be pursing these as time permits.
The biggest possible savings comes from the LCD backlight. Full brightness requires almost 400mA. A usually sufficient 70% uses 300mA. Even 50% is easily visible anywhere but outside and uses only 250mA. This reduces total idle power consumption to only 750mA, giving a battery life of more than 4 hours. If you are really desperate, 10% is still usable at 200mA, 700mA total, 4.5h. Even 1% is visible. You don't get any less than about 175mA without turning it off. Which might be reasonable if you are just playing audio, or have some other application the doesn't require the screen (the ultimate universal remote control?). Turn off the PCMCIA port while you are at it and you get down to 250mA while still using it. That gives more than 12h of battery life. Almost half the sleep life, and not much less than some portable digital audio players.
The hard drive can also consume a lot a power, though intermittently. There are some guides to reducing disk activity on mobile systems. I haven't tried any of the ideas yet. There is also a new laptop mode kernel option, which again I haven't yet seen personally. One of the things it does is to reduce the frequency of buffer flushes and syncs to once every 10 minutes or so, so that the rest of the time the drive is mostly idle except when it needs to load up an explicitly requested file.
There should also be the possibility of managing the cpu clock frequency. As mentioned the Progear does not use the Transmeta Crusoe's with the celebrated LongRun support. However ACPI reports 8 throttling modes available, so clock rate fiddling should be possible via ACPI. So far I haven't got cpusdyn to admit the possibility yet, and attempts to manipulate the throttle states manually via something like 'echo T1 > /proc/acpi/cpu/0/throttling' have just resulted in locking up the system.
Finally get the sound going if you care. Both OSS and ALSA work, but, as mentioned above, when the OSS driver is initialized the mixer is not muted by default. I don't know what then determines the startup values, maybe some accidental powerup defaults. For the case of the Progear this turns out to be a high microphone gain and high speaker volume and the result is ear piercing feedback until you get enough mixer control to mute the microphone. I tried every thing I could think of but could not eliminate it completely, there is some inherent delay between initializing the hardware and allowing a mixer to change the settings. The best I could do was to have the modules configured to load on demand in /etc/modules.conf when the mixer device is accessed, then running aumix -m 0, typically at start up, the debian package will do this by default. When aumix tries to access the mixer device, the driver is loaded, again yielding the shriek, and then the microphone is immediately muted. This happens in less than a second so it is tolerable.
The stock Progear uses a modified audio device driver. Perhaps it is to deal with just this problem, and it mutes the mixer immediately when it loads. I have not investigated the changes. The ALSA driver does none of this. Use it.
In 2.6 the ALSA driver loads automatically during boot. In 2.4 set up modutils and for debian run '/etc/init.d/alsa start'. If you are using the OSS drivers, install aumix and be sure that is runs before the sound driver is loaded explicitly so that the microphone channel is muted as soon as possible and feedback is minimized.
A more important problem for 2.4 and both ALSA and OSS is that when the sound driver was loaded, the pen behaves erratically. The pointer does not consistently accurately track the pen, often flitting around the screen apparently at random. Also button down event are rarely sent even when you could get the pointer positioned somewhere useful. So you can neither click nor drag anything. The audio was also adversely affected. If any sound was playing, it would be interrupted when the pen hit the screen. A track would completely stop playing and everything would be silent until the pen was removed at which point the track resumed playing at the same point it was interrupted exactly as if is was paused in the meantime.
I never got to the bottom of this. The pen data come through the serial port, ttyS1, so I suppose there was some kind of interrupt, or perhaps dma conflict. I started to have the same problem with 2.6 and ALSA, but after some mucking around I found that when if does happen, strangely often after fiddling with PCMCIA, or rebooting from 2.4, it would be reliably restored after a clean shutdown, including power off, and then restarting.
So both ALSA audio and pen are fully functional now, but since I don't know why I fear this problem might come back.
/proc/acpi shows an entry for a power button and a sleep button. The power button is the obvious one used above to implement suspend and shutdown. I was hoping that the other might refer to the lid switch, but I have yet to get operating the lid switch to generate any ACPI events. Maybe the sleep button is some ghost device that doesn't refer to anything and the lid switch isn't even mentioned. Hard to tell if it is listed from the dsdt. Haven't studied the Progear code to see how it interacts with the lid. Would be nice to be able to wire it to shut off the LCD backlight when the flap is closed, would make using it as a monster potable .ogg player more convenient.
Still doesn't work, and even if it had been in 2.4, now I would still have the task of porting the driver to 2.6. I am just getting to this. Can't be that hard. Also am getting the impression that the joystick is an analog device. Maybe it could be used as some kind of mouse pointer in addition to just sending certain select keystroke. Even if it is just switched it could be used as a hardware interface method for my wmwrite like alphabets.
As I recall the early marketing propaganda, these Code Morphing Transmeta CPU were supposed to have speeds comparable to, or better than, x86 processors with the same clock speed. My experience with the Progear has been, to the contrary, that these things can be dog slow. For the most part performance is reasonable and certainly overall the machine is usable, but a few things can really tax your patience. Overall the machine feels even slower, much slower, than my 233MHz x86 laptop.
Launching any GTK2 app is one of these. Launching Galeon can take almost a minute, even GEdit takes 30 seconds. Once running, these apps can be slow during other activities as well. Switching contexts or windows, or opening dialog boxes or menus all cause a bit of commotion that takes a while to settle before the app is usable again. KDE apps are just as slow. GTK1 apps and generic Xlib apps are noticeably faster. Dillo starts without a fuss and any window manager I have ever tried is plenty snappy. Java apps, on the other hand, are completely unusable. I have only rarely waited around long enough to any .jar to even finish launching.
I haven't been able to pin down any particular rate limiting step. The speed of GTK2 apps is independent of whether or not the fonts are anti-aliased, or what widget theme is being used, but it could still have something to do font-rendering or some other fancy feature. On the other hand some simple console tasks also take forever, like building or reading the dpkg database after and apt-get update or before an install. So maybe the whole system is just slow except that, at the same time, some CPU intense chores are fast. oggenc a certain .wav what takes 30 minutes on the above mentioned 233MHz machine takes only 20 minutes on the Progear. So maybe it is a bus to memory speed, or cache size problem.
I did some initial basic benchmarking but still couldn't pin down any particular systems. As far as I could tell every isolated spec was faster on the Progear.
One concrete handicap is the low 128MB system RAM. This memory can fill up quickly and cause a lot of swapping when moving between apps. Unfortunately this is a permanent ceiling as the RAM is not upgradable. Or at least it was not designed to be used upgradable. If I get desperate I might look into a more invasive upgrade procedure, but with the overall slow speed of the rest of the system it is probably not worth it. In the meantime just keep an eye on things and watch your memory usage. (Hint: don't run apache, or mysqld).
I fear this means the machine will not be so useful as long as I thought. Oh well, hopefully it will last until those Gateway Motion Computing tablets start showing up on EBay for $300 as well.