Re: Battery powerfail / APM text-console and xterm logger
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.
Reply to: