Next: 6 Replacing the Kernel Up: Debian on the ProGear Previous: 4 Basic Configuration
The system is now completely functional, but being a portable, a few other features require attention. Power management is of more significant importance with portables. Most of the power related hardware management necessary in the Progear is done with dedicated drivers and tools rather than standard interfaces. So it takes some considerable work either porting the drivers and tools, or rewriting the drivers to use standard interfaces so that conventional tools can be used.
I ended up doing a little of both. I reproduced as much functionality as I could using standard interfaces, like ACPI. For the rest, I adapted code from the Developer CD or modified standard tools.
I didn't work very hard to adapt the Progear apps as the work/return ratio was too high. The stock Progear system includes a couple of tools to report battery status, adjust LCD brightness, change power management settings and others. These tools will not run trivially in the chroot. By trivial, I mean that a single executables copied to the new partition will not run in isolation. The apps are tightly integrated with a central registry and need at least the registry file and the common library of routines that report and manipulate registry settings. I did spend some time modifying dt_battery to work independently, but I ended up preferring apps like wmacpi or wmpower anyway.
It may be possible to use these hardware tools without changing or recompiling the code. Try moving all of /usr/local/webzine/bin and /usr/local/webzine/etc to the new partition, and starting things up as done in /home/webzine/.xinitrc, maybe something like dt_init & dt_menubar, or dt_init & dt_battery. You may have to mess with some bits in the appropriate registry file in /usr/local/webzine/etc.
Some functionality I was unable to re-implement without using or referencing copyrighted code in the Developers CD, in particular the LCD backlight control. The copyright explicitly states that the code can not be redistributed, so unfortunately I will be unable to just pass it on. If anyone turns out to me interested I will inquire about distributing my modifications, or distributing code using details I learned from Progear code.
Ideally, everything will be made available though standard ACPI interfaces, ie /proc/acpi or /sys, and I am working toward that end.
When bootstrapping from the stock Progear Kernel, this stuff is already functional. The appropriate hardware is managed through a custom device driver, fpPowerMgr, and a daemon process, fpPowerMgrd. This will all be started at boot time and will continue to run even while using a different root. A single press of the power button gives an S3 sleep, (suspend to RAM, power down the processor) using the BIOS, and two presses shuts the machine down. Sleep reduces power consumption to some ~35mA, giving a sleep lifetime of ~120h.
Much of this can be reproduced without fpPowerMgr, but some additional shenanigans is required and even then only an inferior S1 (hallt processor) is easy, which reduces power consumption down to about ~100mA. More details are in the next section dealing with configuring a replacement kernel.
The stock Progear can also be set to sleep automatically through the power setting modes. A setting of Minimal, Average or Aggressive will result in the machine automatically sleeping at 900, 480 or 120s respectively. When using the Progear Kernel, this will still be active, but there is now no means of directly changing the settings it as the factory system uses one the these dedicated GUI tools mentioned above that is not trivially ported.
The code for fpPowerMgr on the developers CD includes a program called set_psm that can be used to read or set the power savings mode. If you happen to have it, copy it to /usr/local/sbin on the new partition and you should be operational. You will need to create an fpPowerMgd node in /dev with the appropriate device numbers. Use the node in the stock Progear partition for reference:
This is equally hard to do whether using the Progear Kernel or not, without using the FrontPath GUI tools. Battery status is not available by any standard means through ACPI, so the information must be obtained directly through the i2c bus. The Progear battery status app does this. Just as with the PSM utility this app is not easily run in isolation. Once upon a time I modified dt_battery so that it would run by itself, which was possible, again, because I happened to have the Progear Developer CD that includes the code for this utility. The apps is fine but in the end I didn't like it since really wanted to be able to use standard dockapps to keep track of the battery. As usual the dt_battery code is proprietary, but a program called sbstat is GPL and that provides a console tool for getting battery status as well as enough clues to get the information generally. I used the latter to modify wmacpi to read the battery state directly.
Coarse control of the screen is easily done through DPMS. Fine control requires proprietary tools.
Option ``DPMS'' ``on'' in XF86Conig-4 makes the DPMS features of the display fully functional. These can be set with 'xset force (mode)' with mode=on, standby, suspend, off. As implemented anything but 'on' yields a completely dark screen. You can also set the dpms timer parameters with 'xset dpms t1,t2,t3' where t1 is the number of seconds to set the screen to standby, t2 seconds to suspend, and t3 seconds to off. The screen will then blank automatically after t1 seconds.
This partly reproduces the LCD management part of the power savings strategies of the factory system. The Progear power savings modes have one additional breakpoint that dims the screen before turning it off. The Progear settings happen to correspond to:
| Disabled | LCD 100% |
Minimal |
where the percentage is relative to the manual LCD dimmer setting and a factor of 0.8 when not using AC power.
Brightness control is not directly available without the Progear tools, via ACPI or otherwise. Again on the ProGear developer CD, the test_backlight tools allows you to set the brightness from the console via fpPowerMgr when installed as describe above for set_psm.
Again I will find out about distributing this to for those without the developer CD. Otherwise the dimmer settings are made directly on the video card through the pci bus, so alternately perhaps some public documentation about backlight registers is available from which to reimplement a control.
The joystick is currently completely non-functional, using Progear drivers and tools or otherwise. Factory support includes a device driver and an intermediate app to supply events to X. I didn't even start trying to make this work while I was using a bootstrapped chroot like this and am only just starting to study it for use in the independent system. Try creating an appropriate device node, and running the x_n9joy app from the Progear partition while X is running. The n9joy device driver should already be loaded. Add an appropriate Xfree86 4 InputDevice section using the corresponding section in the factory configuration file for 3.3.6 for clues. See what happens. Run xev to see if anything is coming in.