GNOME Power Manager "you have 10, 9, 8…"

Thanks everyone from the feedback (and lshal entries) from my last blog entry.
I have got lots of data on this, and am now in the process of getting a couple of patches finished and (hopefully) approved to be added to HAL sometime soon.

I've added initial code to gnome-power-manager (it's not going to work yet!) for the warning notification. I asked my girlfriend (a typical non-technical user) if she would check her battery faced with that warning and she said probably not as it didn't seem very serious.
I'm not sure I can (from a legal perspective and user sanity point of view) put up a window saying “YOUR BATTERY MAY EXPLODE ANY SECOND!!!” but the wording could do with some work. Comments please.

Exploding laptop batteries

I'm looking to add an fdi file to HAL so we can check if a battery is defective and is likely to go boom.

I want to see if I can match battery serial numbers against fdi rules and if present, merge a key battery.is_likely_faulty so applications like gnome-power-manager can give a nice warning message so the user can go check on the recall website.
Note, I think we need to keep the word “likely” to avoid lawsuits. :-)

So, I need some data. If you have a Dell laptop:

 – Latitude: D410, D500, D505, D510, D520, D600, D610, D620, D800, D810
 – Inspiron: 500M, 510M, 600M, 700M, 710M, 6000, 6400, 8500, 8600, 9100,
9200, 9300, 9400, E1505, E1705
 – Precision: M20, M60, M70, M90
 – XPS: XPS, XPS Gen2, XPS M170, XPS M1710

Or an HP/Compaq laptop:

HP Pavilion : dv1xxx ze2xxx
Compaq Presario: V2xxx M2xxx
HP Compaq : nx48xx

I would really appreciate if you could send me (richard at hughsie dot com) the complete output of lshal. Include [fire] in the subject so I can filter them easily :-). And also, if you know your laptop might be affected (or another one that might have been affected) and isn't a DELL or HP then please send me the data also.

: Don't panic. Your battery is probably fine, but I want to see if these models express the battery serial number in HAL (via ACPI) or just fill in junk data.



Please also state:

  • If your battery is affected by the recall
  • The value of your barcode
  • cat /proc/acpi/battery/BAT*/info | grep number

Also, I would appreciate it if someone could test this hal patch as it looks like it's needed to properly detect the DELLs.

Drop down menus for batteries

Okay, two posts in one day. A new record for me. :-)
Whilst playing with bug #347913 I've been thinking about killing the “Information” window (as this is also in-process with gnome-power-manager).

The planned solution is like NetworkManager, where you have all the possible battery devices on the drop down, where you click them for more information. I can then launch gnome-power-info (or whatever the executable will be called) with the HAL UDI, and the user can get all the detailed hardware information (like present capacity and stuff like that).
Now, two questions all you p.g.o readers: What is the standard for the right-click menu, and what belongs in left-click? The r-c-m has About and Help currently, but I've a feeling Preferences belongs there too. Second question. Is this sane? There's nothing in CVS yet.


Lots of people has recently been striving to get down the memory requirement of thier GNOME application or deamon.

I've recently created an out of process (the old one was in-process for each instance) graphing program, gnome-power-statistics. The displayable name is yet to be decided, but it's basically a graph viewer that talks to gnome-power-manager over DBUS to the shiny new org.gnome.PowerManager.Statistics interface.

Notice the surge in power usage as I start “make distcheck” on HAL in the 23rd minute.

Now, I know the application really needs some HIG love, but this removes a whole chunk of memory from the session daemon, namely 500kb of writable memory.

Comments welcome.

Glib DBUS Problems

Maybe because it's been a long week, or maybe because I'm being a moron, I can't see to get a specific dbus annotation to work. The problem I'm having is with the signature “a(ii)” i.e. an array of a structures made up of two integers.

There's no example in the tutorial or the test/glib/test-service-glib.xml file, so I'm somewhat lost. I'm guessing the prototype would contain 'GList **list', but when I try appending a GValueArray of two G_TYPE_INT's then I don't get any data returned.

So anybody really using the glib bindings for dbus to unwrap an array of structures? Pointers to code or documentation welcome. Thanks.

CPU Frequency Scaling (post 2-16)

Today I've released 2.15.92 which is the last test release before 2.16.0 is released. I'm amazed at the work people have done in the last few weeks to make gnome-power-manager ready for the 2.16.0 release.
Now I've been banned (thanks to the string freeze) making large changes and adding functionality, I've been thinking about functionality to add post 2-16.
I get an email or bugzilla every few weeks asking about CPU frequency scaling, and how to add support into g-p-m. Traditionally the CPU frequency has been changed by system daemons such as cpufreqd (there are a lot more to choose from) which require editing odd files in /etc and are not new-user friendly. Holger Macht has written a addon to control this using HAL, so system and session software can control CPU frequency scaling in an easy, and architecture neutral way.

Maybe this is too much detail for the average user, but the feedback I've been getting is that users are screaming for cpufreq support in g-p-m.
The question is how to expose the options, given that there is are a large number of permutations of governers and working options for any given laptop.
My initial reaction was to hide the “use low power mode” checkbox to do scaling, but some computers scale better than others, and some just dont work in some modes, but do others. So it's got to be exposed in the UI.

So far, all the possible options (assuming you have all the governers installed) are:

#define CPUFREQ_ONDEMAND_TEXT           _(“Based on processor load”)
#define CPUFREQ_CONSERVATIVE_TEXT       _(“Automatic power saving”)
#define CPUFREQ_POWERSAVE_TEXT          _(“Maximum power saving”)
#define CPUFREQ_USERSPACE_TEXT          _(“Custom”)
#define CPUFREQ_PERFORMANCE_TEXT        _(“Maximum performance”)
#define CPUFREQ_NOTHING_TEXT            _(“Do nothing”)

With “Computer processor policy:” as the prefix. New names and descriptions

Tell me what you think.

GNOME Power Manager in 2.16

Just a few days ago, gnome-power-manager was accepted as part of the GNOME desktop 2.16 release.

This makes me happy. I've been getting some overwhelmingly good feedback about this, and I'm hoping being part of the release proper means we get more HIG compliance, more translations, and more polish generaly.
I would like to thanks all the contributors to gnome-power-manager over the last couple of years, and all the people that have helped me and pointed the project in the right direction. And for all you translators, you rock.

Fixing the video and kernel suspend mess

Okay, a few weeks ago I blogged about a script that could autogenerate a fdi file for HAL that could create the required video_adapter_pm methods and properties needed to suspend and resume your videocard on suspend and hibernate.

So, if you are one of a few people that are running a very recent (CVS less than a few months old) HAL and the new pm-utils (the one from rather than redhat), and have to set odd kernel command lines or hacky commands to get your machine to work please can you give my script a whirl.

The idea is for technical people to send me autogenerated fdi files that are matched to their hardware, which are then be merged into upstream hal. This means on the next HAL release more systems just work out of the box without new users having to google and add oddball options gleaned from some random post of a bloke that has a similar laptop.

So, if you know you have to set S3_MODE or you have to add dpms suspend calls at the end of your custom suspend script, can you please try pm-utils and my script. The script probably won't be much use if you don't know what the cause your suspend problem is, although you could use it for that.

Feedback, as always, welcome.

Utopia repo

Utopia FC5 repository now has never new version of glibc (and the updated deps for glibc…) needed for the new CVS HAL dependency on libvolume_id. This is a good thing as removes a whole chunk of code out of HAL and into a shared library that can be used by other stuff.

Not sure how many people this will affect, but don't run this repo update on an important machine. It all seems to work for me, but test at your peril.

On a related note, the latest g-p-m checks with PolicyKit to prevent the “suspend error: unknown error” if you try to suspend with no (or with a broken) PolicyKit. You'll need to add –disable-policykit to the configure line for now, if you don't use a new HAL or have no desire to test PolicyKit. :-)

Update since GUADEC

Okay, long time no blog, which I'll apologize for: As some of you may know, I've just started a stressful new job for the summer, and am sharing with a friend in Gravesend near London. The house is a new-build, and has no phone-line or Internet yet, and the Internet at work is closely monitored – hence why I havn't blogged since before GUADEC. And people complain my entries are too long, so I'll try to keep this one brief.

There are also a few people in my family who are currently unwell, so all-in-all this month has had little time or concentration on OSS stuff, so apologies if there have been long delays in email replies.

GUADEC: Wow wow wow. I've never been to a GUADEC before, and sure will be going again next year. It was really great to meet all you guys in the flesh, so to speak. It was really odd to talk to people face-to-face for the first time even tho I've known them for years. Apart from not finding my flatmates on the first day till nightfall, and Jon McCann successfully getting me very drunk on the Fluendo beach party, the whole thing was really great. Thanks go to all the people that made me feel very welcome (especially Puaff for the lift from Reus airport).

GNOME Power Manager: Lots of nice fixes and translations being committed (THANKS), and also lots of sane feature requests in bugzilla. Initial feedback on d-d-l is good for inclusion in 2.16, which would be great as other modules can then start relying on the Inhibit stuff for g-p-m and g-s also. Feedback on sleep nomenclature has been good, even tho a recent Fedora kernel has broken resume for a few people. I'm just glad I'm not a kernel maintainer. :-)