Technical Blog of Richard Hughes

A couple of days ago my new laptop arrived. A nice shiny new Lenovo 3000 N100. Most stuff worked out of the box (well done kernel guys), but most important to me: the battery ACPI code was really bad. So I got no rate information and a really bad approximation of the charge level. For a bloke working on gnome-power-manager, this was really bad news. Windows XP just gave me the percentage charge also, so this wasn't a Linux bug.

Last night I decompiled the DSDT and was surprised to find no errors or warnings. Hmm. So I looked closely at the source. LENOVO were just hardcoding values rather than querying the smart battery which is what they are meant to do. And when they were querying the battery, the return value was being processed incorrectly.

So I re-wrote the _BIF and _BST ACPI methods to actually interface with the hardware in a sane way. Bear in mind I only had a copy of the generic ACPI spec, but managed to figure out most of the undocumented embedded controller interface (EC0). I'll formally write up what I found when I get a chance.

So now, I have a really custom DSDT that provides me with accurate voltage, charge and rate information that works really well. If anyone from LENOVO is reading this, then please get one of your BIOS engineers to call me on my mobile or email me. I would love for this to be included in a BIOS update to fix all the other Windows XP and Linux laptops out there. I've also got a fully commented (well the battery bits anyway) DSDT for any LENOVO owners wanting to hack even more than I've done.

Also, I had to recompile a custom kernel with this patch just to enable dsdt loading into the kernel using an initrd. Ubuntu make this super-duper easy I'm told, but working with Fedora makes this a pain in the backside. Anyone with contacts to IBM/Lenovo then please send them a link to this post or get them to email me. In the words of Mattew Garrett: “0 out of 10 – See Me”

I spent a couple of hours last night trying to fix a broken BIOS.
It's a long shot, but do any of you have the specification for ACPI: Embedded Controller [EC0] (gpe 25)?
So far, I think I'm managed to work out (from the ACPI spec and lots of googling):

• EC0.BMF0, 3 // always == 2
• EC0.BTY0, 1 // always == 1
• EC0.BST0, 8 // Battery State Bitfield
• EC0.BRC0, 16 // Remaining Current (mAh)
• EC0.BSN0, 16 // Serial Number ???
• EC0.BPV0, 16 // Present Voltage
• EC0.BDV0, 16 // Design Voltage ???
• EC0.BDC0, 16 // Design Capacity ???
• EC0.BFC0, 16 // Last Full Capacity
• EC0.GAU0, 8 // Battery Gauge = WTF?

But these may be wrong, and I don't know what Battery Gauge is.
Any helpful links, pointers or other help will be rewarded with a beer at GUADEC2007. :-)

Thanks.

Okay, information requested. Can anybody with a Toshiba:

• Satellite A100
• Satellite A110
• Tecra A7
• Satellite Pro A100
• Satellite Pro A110
• Equium A100
• Satellite M70
• Satellite Pro M70
• Equium M70
• Satellite M50
• Satellite Pro M50
• Equium M50
• Satellite M100
• Equium 110
• Tecra A6

Please send me a lshal please (richard_at_hughsie_dot_com) – with [fire] in the subject. There's another recall I'm trying to add to the bad-battery-database, but I need to know the battery vendor. NOTE: Your battery won't explode in this case, but it might stop working after a little while. Thanks.

My faithful development machine, a Toshiba A10 2.2GHz Celeron is nearly dead. The screen backlight keeps cutting out when you move the lid, the hinges are floppy, the maximum brightness is half what it used to be and the fan makes noises that it really shouldn't. Ohh, and the AC adapter plug is really broken too. Now, I've got to decide if I want to repair everything (probably about £200), or just buy a new laptop.
As I'm now back being a poor student, money is fairly tight. I've been looking at the Toshiba Satellite Pro A120 – which seems very similar to what I have already, but I've also been looking around: I've compiled a list of needs / would likes / don't wants:
Needs:

• Less than 700 GBP (student)
• WXGA screen
• Open graphics chip (Intel?)
• 15 inch screen
• Wireless G networking
• DVD reader
• 40Gb hard drive
• 512Mb RAM (I have existing SODIMMS)
• Intel Pentium M or Duo.
• 2 hours battery life

Would like:

• WXGA+ Screen
• SPDIF out
• Brightness sensor
• DVD-Writer
• >3 hours battery life

Don't want:

• DELL or Sony (nothing personal, just ACPI issues)
• 64 bit anything
• Gigabit ethernet
• Lots of 3D performance (I don't do games)
• Bluetooth
• Biometric fingerprint security
• Lots of special buttons that do clever things
• Firewire
• Modem
• Software
• Windows XP (although I'm probably going to get it “free”)

So anybody got any good ideas for a budget laptop that will have good Linux support for less than 700GBP? Also, if you are running Linux on a Toshiba Duo, please let me know. Thanks.

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.