Hi, I'll reply to several of your questions/notes in the one message. 1) I forgot to mention that if the laptop is booted without the battery, then the GNOME battery charge monitor will never show anything useful at all. It almost seems if the battery charge monitor decides the machine is mains powered and does not bother checking any more. Booting without a battery also removes the battery charge monitor applet from the task bar, but adding it back does not help - it still indicates there is mains on the unit and no battery present.
So it seems a no-no to boot without a battery present. It would be good if that could be fixed. 2) I understand Sony could use their own API's, but even if they do, I think you might be able to solve it - see next point. 3) Your dtrace script generates output from both inserting AND REMOVING the battery! So it seems dtrace is seeing things 'lshal -m' can not. I run both 'lshal -m' and your dtrace script in separate terminals and found dtrace was detecting both insertion and removal, but 'lshal -m' only shows the insertion of the battery. Also, your dtrace script works whether or not the machine had a battery in when it was booted. So it seems to get all relevant information under all circumstances. # ./acpi.d dtrace: script './acpi.d' matched 2 probes Battery is inserted, so I will remove it CPU FUNCTION 1 -> acpi_drv_cbat_notify acpica`AcpiEvNotifyDispatch+0x7d 0x1 1 -> acpi_drv_cbat_notify acpica`AcpiEvNotifyDispatch+0x7d 0x80 Battery was removed and generated output above. Now I'll insert the battery 1 -> acpi_drv_cbat_notify acpica`AcpiEvNotifyDispatch+0x7d 0x0 1 -> acpi_drv_cbat_notify acpica`AcpiEvNotifyDispatch+0x7d 0x80 The next time the battery is removed, I do not see 'CPU FUNCTION' again - I assume this is some feature of dtrace - I've never used it before. 4) I understanding predicting battery life can be difficult. I have 3 batteries, so it's not as simple as calibrating the battery, unless the serial number can be read from them and a log kept of the performance of each battery. 5) If you need help with differential calculus, help might soon be at hand in the form of Sage (http://www.sagemath.org/), which is a pretty impressive sounding bit of maths software, which has: "Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab." Sage has commercial sponsorship from both Google and Microsoft Research, but is open-source and GPL'ed. Just what I want. A Solaris port is in progress and might, with a bit of luck, be here this month. But it will be a few months at least before I think it will be stable on Solaris, so don't rush out to use it. 6) Does the current battery indicator switch the power off gracefully if the battery is exhaused? The machine always used to power off ungracefully, with no syncing of file systems. But I think the last time I used it, there may have been a graceful shutdown, but I can't recall for sure. 7) When I last checked the time for the battery monitor to register the change of status, so it worked quickly a few times. Perhaps there was some transient thing on the system which caused it to take a long time, but I'm sure I've seen this issue before. It is is going to power the machine off gracefully, and there is a significant problem with the monitor indicating the charge accuratly, it might be better to have the facility to disable that, or let the user add some time period after exhaution before the shutdown occurs. 8) When the machine is booted with a battery, and the applet knows this, it indicates the charge OK. If the battery is then removed (which does not cause any change on the aplet), but replaced by a *different* battery, the applet clearly knows the battery is different and indicates the correct charge. I have two batteries near me at the minute - one 100% charged, the other 86% charged. The applet knows which is which, as long as the machine was booted with a battery in place. Dave This message posted from opensolaris.org
