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.
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.
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.
>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.
>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 ™.