Hello, Karl, and many thanks you've spent some time about my beginners stuff !
Allow me to answer on the list, because i enjoy any feedback. > - Most X-based battery monitors already have functionality to warn the > user of low battery. E.g. Gnome battery applet, Enlightenment > battery epplet, windowmaker doking apps, gkrellm and misc stand-alone > packages (e.g. xbatt), and I presume that there is a similar one in > KDE. apm comes with xapm. So there is some duplication of work > (already) here. Yes, of course. I've given the lap away now, suspecting what the future user will know about things. I told her, but why not remember sometimes ? She's a real newbie. And possibly there will be a 'guests' working. There's a guest-account... I aimed for a kind of 'little manual'.... very special task, you see. > - Have you looked into the sleepd package? If this happens to you when > you're away from the machine, this should take care of suspending it > if you leave it too long. Yes, i wanted to do. I simply forgot, cause when i was up to check it, a 'freezing' problem smashes my plans, and i reinstalled most things to track it .... Anyway, 'idle time' suspending seems to work for this machine ( i didn't test it completely, since i never really got idle ;-), but _not to disk_. apm -s doesn't do, only the 'Fn-q' key. I didn't find out how to activate hibernation from apm. Which imho would be the safest solution. > - In the README you mention a potential problem with opening an xterm on > userspace. I think xmessage is nicer :-) I like it, too ! Used it with potato. Unfortunateley, it was not on my woody (3.0) CD set, and i assumed it's gone. So it's back again ? I was interested to do something with xterm, though. Seems to be very flexibel.... and allowing nice fonts and colors :) > - powermesg: Your comments about li-ion batteries and memory effect are > generally true IIRC. But... Most batteries nowadays have circuitry in > them to prevent over- and undercharging. Yes, sure you're right ! This message in fact is specified to this old one laptop here and it's (rather young) users ! It's only an 'example'. Should have made that clear, sorry, was my lazyness. Thanks for the hint. > combination of BIOS and battery circuitry. If the circuitry is working > as intended, then there should be no need to shuffle batteries. What do you mean by 'undercharging' ? There's a chance one will recharge the battery and store it away for many weeks. So i think tell users to recharge it to a good level (about 40%) before storing it. 'Overcharging' is no problem for modern batteries. But, what i imageine about having the full battery inside all the time, is, there might always be a minimal leak, which is compensated by steady minimal recharging. Possibly enforced by the rather high temperature inside ? Which means lifetime is used up, a little. Perhaps Joe can correct me .... ? > And... The Fn+q trick is probably dependent on what type of laptop you > have - may I make a wild guess at Dell's "suspend-to-disk" on a > German Keyboard ?) :))) Quite right. (Inspiron 5000) I consider now i had to explain explicitly my little hack is not meant to be a 'release' ... i sent it to the list just to feedback like yours :-) > - Instead of depending on kdm or any other display manager (the user may > not be using a display manager at all!), why not run the relevant bits > as the user? It is likely that ~user/.Xauthority is set up (very few > users bother to set the XAUTHORITY environment variable anyway, the > defaults are good) and do something like this: > su - user -c /usr/bin/your-script This idea is as simple as genial ... thank you ! However, i have to detect the user's name first, right ? That's the critical point where i use kdm. How to ask X who opened the session ? ( There are 4 accounts on the laptop: user, guest, admin, and root) > - Instead of running your own daemon, you could tie into apmd - it will > be monitoring the battery charge anyway. Unfortunately, apmd only has > one trigger level. That's the point. I did imagine one warning message with a good amount of time to finish things smoothly, plus a critical warning starting a short frequence logging so that one can use up the battery rather completely. Since there are only 80 minutes left, i don't want waste a minute... OK, true it's a question of taste, in the end... > #/bin/sh > if [ "$1 $2" = "change battery" ] ; then > # Do your stuff to warn people > # Volume to 100% > aumix -v 100 > # Play some silly music to wake up the user (through the PC :) > # speaker, esd/artsd might have taken the sound device) > ditty -k -f /usr/share/doc/ditty/examples/notes.dit > > /dev/console & su - somebody -c /usr/bin/weareallgoingtodie & > fi > > /usr/bin/weareallgoingtodie: > #!/bin/sh > xmessage -nearmouse -timeout 60 -title "The End Is Near" -file lol ! > /usr/share/powermon/doomsday.txt > [yes: script names and text are examples only :-] :)) This moment i got the idea to start the logging daemon from apm, to have two triggers. One more thing i'm not clear about is if a 3 minute cron-logging will disturb idle-time suspending of cpu and harddisk ? And how would apmd deal with that ? > - Finding out the number of minutes left is (as you have already > discovered) quite tricky. There are lots of variables in this, many > of which are unknown. Even measure the percentage (from a hardware > point-of-view) is not an exact science. I resorted to writing > battery-stats (http://karl.jorgensen.com/battery-stats) to get some > statistics. But... I still cannot make sense out of it. For me, most important would be to have an excact prediction of say the last 5 minutes. About other things i would be satisfied with roughly estimations, and generous triggers. But to know when i have to really shutdown is essential, if the inbuilt functions don't work. My explanation ist that the BIOS warning starts at below 15% here which it never reaches now.. or was it actually apm calling the 'red light blinking and beeping' ? Unfortunateley i have to stop most testing now, using up my friends battery... the lap's gone, anyway. > Why not go ahead and continue with things like: > - man-pages to document it > - package as a debian package > - get a sponsor > - get it in the next release of debian > > After all, if it is useful to you, then it is likely to be useful for > others too... Wouldn't be only very few working under changing circumstances ( sometimes even without X) or wishing to test out the true powerfail point ? And those very few, i suppose, would prefer to do their own little script anyway. But, ok, you're right, that's how things begin.... but i need some years yet to come up with a really useful tool :-) > Just my thoughts off the top-of-my-head - hope they will be of use to > you. Yes, thank you ! A bunch of good ideas. I will pick the theme up when i got my own laptop ;-) micha.
