Author: hughsie

PowerManager : the quest for world domination continues. The detecting exploding batteries idea is on hold until we can clear up some legal issues – I can't say anymore than that, but everything is looking good so far.

Next on the agenda: laptop light sensors.

These are little sensors (once only found on expensive apple notebooks) that simply tell the operating system how much ambient light there is around. These can be used to adjust the laptop LCD screen brighter on sunny days, and dimmer on cloudy days for instance. You can also control the keyboard backlight like this. DavidZ has written an addon for the Macbook Pro, but other hardware support is planned.

Now, p.g.o readers – I need your help. We have potentially three inputs.

1. Ambient light sensor input(s)
2. User input (pressing the keys)
3. Software input (e.g. totem turning off the keyboard backlight when fullscreen and watching a movie)

At the moment I'm just considering the first two. I'm thinking about a sliding-window auto-feedback scale, where the sensor input is first damped, and then scaled into rangewidth. The output is a percentage scale which is defined by the user with keypresses or power policy. The rangewidth defines the ranging of the sensor input (basically the +/- value the sensor can affect) and allows us to have user control and limited auto-ranging. The brightness policy scale would range from -rangewidth% to (100+rangewidth)%, obviously clamped at 0 and 100. This allows the user to specify a policy of 50%, and if rangewidth was 20%, then the brightness could just range from 40% to 60% automatically.

Now, does this seem sane? How does OSX and Windows handle this? Anyone think of any better ideas?

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.

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.

IMPORTANT NOTE: 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.

Thanks.

UPDATE!

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.

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.

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.

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

Tell me what you think.

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.

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 freedesktop.org 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 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. :-)