gnome-power-manager and multiple batteries

In times of 2-21 to 2-25, gnome-power-manager maintained an big fat elaborate cache of power devices and combination devices which was populated by HAL. This allowed us to have “virtual” devices such as multiple composite laptop batteries. This abstraction sucked and made some horrible assumptions about devices. And it was slow.

These virtual batteries were used for policy, and generally multiple batteries sort-of-just-worked, with a few random things happening when the engine virtual layer fell down. I couldn’t test virtual devices, as my Toshiba only had one battery with no expansion available, so I relied on random patches from strangers.

Fast forward to last-week/2-26/DeviceKit. Now gnome-power-manager had a very small new ‘thin’ engine with all the devices supplied by DeviceKit-power. Batteries, on the whole were a whole lot more predictable, and the architecture was at last fairly sane. I had now got a nice shiny Thinkpad, still with only one battery, but with extra space for another. But wait, I know what you are thinking; Thin engine means no composite devices, which makes people with multiple battery laptops sad.

Fast forward to this weekend/2-27/DeviceKit. My ultrabay battery arrived in the post from the US (with customs charge, bahh) which I plugged in to the Thinkpad. Much hacking was done, and a few changes (related to empty batteries) went into DeviceKit-power and a few changes went into gnome-power-manager. Now we have a composite store with a thin engine, so the best of both worlds.

So, long story, short: if you have laptop with multiple batteries and your experience with gnome-power-manager sucks, update to git versions of DeviceKit-power and gnome-power-manager. I’ll be making releases later this week, and backporting to stable once it’s had some testing.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

4 thoughts on “gnome-power-manager and multiple batteries”

  1. This prompted me to poke a bit of g-p-m I hadn’t looked at for a bit: wireless mouse handling.

    I thought this was broken, but it’s actually not – if I plug in a wireless mouse and set the icon policy to ‘always’, I get an icon in the notification area which tells me the charge level of the mouse. Shiny. But the icon doesn’t show up if the icon policy is set to ‘present’ – I guess that only considers the presence of a laptop battery, not any other kind of battery…

    Also, gnome-power-preferences only lets you set the ‘always’ or ‘never’ policies for the icon. That seems somewhat over-simplified. I can’t see why the UI shouldn’t expose the other choices too.

  2. This is great news. I’ll have to give it a try some time.

    I had a look at the code in the 2.24 codebase a while back and thought it looked a bit weird. By tracking a discharge profile of the combined virtual battery, it was essentially throwing away information about the reported charge levels of each individual battery. With one of the batteries in my laptop failing at the time, the erratic readings from that battery basically ruined the accuracy of the readings on the other one.

    Also, the design looked like it prevented carrying over discharge profiles for a battery when used together with a second battery and when used alone.

    It’s good to hear that things are improving.

  3. >that only considers the presence of a laptop battery, not any other kind of battery

    We only show the mouse battery icon if it’s low — we try not to show the icon unless it’s going to be useful.

  4. >it was essentially throwing away information about the reported charge levels of each individual battery

    I know, it sucked. The new way of doing things should be The Right Way ™.

Comments are closed.