MSI Megabook x86_64, openSUSE 11.3, KDE 4.6 Beta 2

solid query tells me

udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT1'
udi = '/org/freedesktop/Hal/devices/computer_power_supply_ac_adapter_ADP1'

The battery plasmoid only gives an indication that the AC adaptor is plugged in (which unfortunately remains, even if I unplug the adaptor) with the following information

udi = '/org/freedesktop/UPower/devices/line_power_ADP1'
udi = '/org/freedesktop/UPower/devices/battery_BAT1'

I have HAL installed and because I don't really know what I am doing, I installed the 32bit compatibility option too.

On an Acer Aspire One, without intervention, openSUSE 11.3, KDE 4.6 Beta 2, I have a fully working battery applet. Other than architecture I can't spot the difference between the two installs.

I have seached the forum (and openSUSE forum too) but could not find much information.

I would be grateful for pointers or suggestions

Please run the following commands, and post the output here:

Code: Select all

solid-hardware details '/org/freedesktop/Hal/devices/computer_power_supply_ac_adapter_ADP1'
solid-hardware details '/org/freedesktop/UPower/devices/line_power_ADP1'

thank you for replying

solid-hardware details '/org/freedesktop/Hal/devices/computer_power_supply_ac_adapter_ADP1'

udi = '/org/freedesktop/Hal/devices/computer_power_supply_ac_adapter_ADP1'
parent = '/org/freedesktop/Hal/devices/computer' (string)
vendor = '' (string)
product = 'Generic AC Adapter Device' (string)
description = 'Generic AC Adapter Device' (string)
AcAdapter.plugged = true (bool)

(after unplugging)

solid-hardware details '/org/freedesktop/UPower/devices/line_power_ADP1'
udi = '/org/freedesktop/UPower/devices/line_power_ADP1'
parent = '/org/freedesktop/UPower' (string)
vendor = '' (string)
product = 'A/C Adapter' (string)
description = 'A/C Adapter' (string)
AcAdapter.plugged = true (bool)

In this case, it appears a fault in UPower is misinforming KDE of the status of your system. I suggest you ensure all updates are installed, and contact your distributor for assistance.

Thank you

I've updated UPower and DeviceKit-power to 0.97, I've updated DBus (all from openSUSE factory)

I imagine I'm posting in the wrong place now. However, hoping that you are willing to give this some more time: I seem to be getting extra information now.

solid-hardware list
Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString)
Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString)
virtual QStringList Solid::Backends::UPower::UPowerManager::allDevices() error: "org.freedesktop.DBus.Error.NoReply"

solid-hardware details '/org/freedesktop/Hal/devices/computer_power_supply_ac_adapter_ADP1'
Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString)
Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString)
udi = '/org/freedesktop/Hal/devices/computer_power_supply_ac_adapter_ADP1'
parent = '/org/freedesktop/Hal/devices/computer' (string)
vendor = '' (string)
product = 'Generic AC Adapter Device' (string)
description = 'Generic AC Adapter Device' (string)
AcAdapter.plugged = true (bool)


I take this to mean that there are several things now missing? Am I getting better information? such as before the system didn't know it wasn't getting the right information whereas now it knows it isn't?

Googling suggests that kdelibs might be involved.

Is the real answer (for a user) to sit and wait for openSUSE 11.4 or is there more I can do?

Very unusual, as "solid-hardware list" should return immediately. I gather you have the latest Trunk packages for KDE 4.6 installed? Other than that, it looks like UPower is having issues responding to queries for information, so logging off and back in may be helpful.

alas, no. Thank you for your help, though.

I have similar issue and really don't have any clues to fix it but reinstall/repair the whole stuff.

acpi -b says that the battery is there and recharging when ac power is plugged discharging when plugged off... I had five time since last friday (I make the mystake to do an online update) the opportunity to have the Battery Monitor up and then use vmware that won't launch untill the battery monitor was up. I contacted the developper and waiting for more informations.

I'm using kde 4.4.4 rel 3 on OpenSuSE 11.3 on a hp 6720s.

I'm quite sure that this is either a dbus or hal issue (both daemons are running) started at least at boot. When ps aux | grep dbus or ps aux | grep hal shows they are up.

I got the following message when typing solid-hardware query 'IS Battery'

QStringList Solid::Backends::Hal::HalManager::findDeviceByDeviceInterface(const Solid::DeviceInterface::Type&) error: "org.freedesktop.DBus.Error.ServiceUnknown"

It's the first time I experience such issue, that's a tuff one ^^

The D-Bus error message you posted indicates that HAL is not running. KDE depends upon HAL in KDE 4.5 and earlier to provide hardware information. Please ensure that "hald" is installed and running.

Further research reveals for me that the solution is far away from KDE

look for sensible data using

cat /proc/acpi/battery/BATx/inf
cat /proc/acpi/battery/BATx/state

where x is likely to be 0 or 1 depending on your laptop,

mine, e.g.,

cat /proc/acpi/battery/BAT1/state

present: yes
capacity state:
charging state: charged
present rate: unknown
remaining capacity: unknown
present voltage: 10000 mV

I don't believe any of it, as the charger is 19V This suggests either the BIOS is not reporting or the utility transferring the information needs to be modified. If only I knew what to do.

The interface you are reading that information from is the Kernel itself, which gets the information via ACPI. My machine reads a battery voltage of 11359 mV, with a 19 V charger as well.

I suspect that the ACPI interface is correct, and that the difference is to allow the battery to be charged and the machine to run simultaneously (as the charger needs to power the machine and charge the battery, so effectively double the power requirements)

bcooksley wrote:I suspect that the ACPI interface is correct, and that the difference is to allow the battery to be charged and the machine to run simultaneously (as the charger needs to power the machine and charge the battery, so effectively double the power requirements)

I don't know much about software development but electrical/electronic engineering bring it on.

In the configuration you imply the battery and the computer power supply would not only have to be in series across the power supply but of equal impedance. It is possible to operate a laptop without the battery, in that configuration the computer would be getting twice the voltage as the supply is no longer being divided between the battery and the computer.

If you were to look at a power supply design you would see a massive capacitor strapped across the supply/ground lines (often on a motherboard) being charged by the energy from the supply. As the load draws more current the capacitor is discharged temporarily to smooth the voltage.

A battery is essentially a super massive capacitor.

Your values might be a calibration issue - we know that rechargeable batteries have (had to be?) calibrated for proper monitoring. Somewhere in your software stack something might be set at 100% when it sees your 11xxx mV reading.

Apparently it's not possible to read the BIOS directly but currently (ho ho) I'm unclear whether acpi supersedes or works with dmidecode.

http://www.linux.com/archive/articles/40412

I'm working my way through this

http://www.linuxquestions.org/questions ... op-842336/

I think KDE is several stories above this basement issue.

bcooksley wrote:The D-Bus error message you posted indicates that HAL is not running. KDE depends upon HAL in KDE 4.5 and earlier to provide hardware information. Please ensure that "hald" is installed and running.

Yes this is strange...
I understood the message, but how I can do to have the system work with hald instead of haldaemon that is currently running ?

Code: Select all

106       1227  0.0  0.2  15852  4800 ?        Ssl  13:19   0:00 /usr/sbin/hald --daemon=yes
root      1294  0.0  0.0   3884  1232 ?        S    13:19   0:00 hald-runner
root      1323  0.0  0.0   3964  1032 ?        S    13:19   0:00 hald-addon-input: Listening on /dev/input/event7 /dev/input/event0 /dev/input/event2 /dev/input/event5 /dev/input/event4 /dev/input/event3
root      1327  0.0  0.0   3960  1036 ?        S    13:19   0:00 /usr/lib/hal/hald-addon-rfkill-killswitch
root      1336  0.0  0.0   3960  1032 ?        S    13:19   0:00 /usr/lib/hal/hald-addon-generic-backlight
106       1339  0.0  0.0   3740  1132 ?        S    13:19   0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
root      1340  0.0  0.0   3964  1036 ?        S    13:19   0:00 hald-addon-storage: polling /dev/sr0 (every 16 sec)


Code: Select all

100       1098  0.0  0.0   3056  1292 ?        Ss   13:19   0:00 /bin/dbus-daemon --system
100       1415  0.1  0.0   3260  1472 ?        Ss   13:19   0:04 /bin/dbus-daemon --system
root      2120  0.0  0.0   3664   524 ?        S    13:19   0:00 dbus-launch --autolaunch 2821caa25ae9ef4733c760b90000042e --binary-syntax --close-stderr
root      2130  0.0  0.0   2916   640 ?        Ss   13:19   0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root      3220  0.0  0.0   3664   532 ?        S    13:19   0:00 dbus-launch --sh-syntax --exit-with-session
root      3222  0.0  0.0   3180  1136 ?        Ss   13:19   0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root     14425  0.0  0.0   2420   476 pts/2    S+   14:18   0:00 grep dbus


It works with the 11.3 livecd so this is clearly OS related.
I'm sure that once hald will work I could add the battery in the Device list.
What I'm expected to do with the upower -e output ?

/org/freedesktop/UPower/devices/line_power_C23A
/org/freedesktop/UPower/devices/battery_C23B

Thank you for your help and your patience

hald appears to be running in the ps output you provided. The UPower output you have provided indicates that UPower is functioning correctly. It appears that you have two system-wide D-Bus buses running simulateously, which is likely the cause of this issue. I suggest dropping to run level 3, stopping NetworkManager, HAL and dbus-daemon, then starting dbus-daemon, HAL and NetworkManager, prior to returning to run level 5.

Today it worked, so I've no complains ^^

This is the shal | grep battery output

udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_C23B'
battery.charge_level.current = 4579 (0x11e3) (int)
battery.charge_level.design = 41299 (0xa153) (int)
battery.charge_level.last_full = 41299 (0xa153) (int)
battery.charge_level.percentage = 11 (0xb) (int)
battery.charge_level.rate = 388 (0x184) (int)
battery.is_rechargeable = true (bool)
battery.model = 'Primary' (string)
battery.present = true (bool)
battery.rechargeable.is_charging = true (bool)
battery.rechargeable.is_discharging = false (bool)
battery.reporting.current = 424 (0x1a8) (int)
battery.reporting.design = 3824 (0xef0) (int)
battery.reporting.last_full = 3824 (0xef0) (int)
battery.reporting.rate = 36 (0x24) (int)
battery.reporting.technology = 'Li-ion' (string)
battery.reporting.unit = 'mAh' (string)
battery.serial = '00990 2008/01/03' (string)
battery.technology = 'lithium-ion' (string)
battery.type = 'primary' (string)
battery.vendor = 'Hewlett-Packard' (string)
battery.voltage.current = 10962 (0x2ad2) (int)
battery.voltage.design = 10800 (0x2a30) (int)
battery.voltage.unit = 'mV' (string)
info.capabilities = {'battery'} (string list)
info.category = 'battery' (string)
info.udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_C23B' (string)
input.keymap.data = {'e001:fn_esc', 'e009:battery', 'e00a:screenlock', 'e00b:camera', 'e00c:media', 'e00e:dvd', 'e031:help', 'e033:f23', 'e057:wlan', 'e012:brightnessdown', 'e017:brightnessup', 'e06e:switchvideomode', 'e008:presentation', 'e059:help'} (string list)


I was again facing the issue, so I did this as a workaround:

change inittab to boot on run level 3
startx once in the run level 3

Each time I tested this workaround it worked, the Battery Monitor was up.
I didn't need to stop dbus, hal or networkmanager.