Technical Blog of Richard Hughes

So you are using gnome-power-manager on your laptop. You notice that sometimes when you shut the lid it suspends, and sometimes it doesn't. After a suspend it also acts a little funny, but you can't quite work out why…

The lid “up” event is not sent when you resume from suspend as the lid state changing triggers the resume, but no event is sent to userspace. This took me ages to work out yesterday. See my patch to LKML for a fix. Hopefully this is headed to 2.6.22 as it's a trivial fix, although it might be a little late in the day. Distributions might want to add this patch in the meantime.

When g-p-m doesn't have a complete profile of your battery, it tries to shutdown or hibernate when the known battery remaining is very low. If you've never tried to take your battery to 10%, g-p-m assumes it can't and calculates only the capacity it has seen being used.

This fixes many broken batteries. It also introduces a problem when you first start using the profiling code, in that g-p-m knows nothing about what the battery actually can do.

What about the following tooltip:

Laptop battery 30 minutes remaining (97%)
Battery discharge profile is estimated
Policy actions will not be performed until battery profiled

As usual, my spelling and grammar are sh1te and so suggestions welcome. The last line is far too techy, but I'm not sure what to write. Please add a comment to this blog (or email me) with better suggestions, thanks!

The SMI method on the X40 looks sorta like the PHSS method on the n100. It's protected by the same type of mutex and does a similar sort of SMI call. SMI is undocumented and thus difficult to understand. The SMI interface on the n100 is 40% similar to the X40 interface, although there's a lot missing on my lenovo. None of the cmos commands work, although that's not a big surprise. Lenovo, I would really appreciate a hand with this, even if it's just one of the BIOS engineers saying “it just won't work”.

So I got my degree result: Masters with Distinction (1st class). I even won a prize.

Today is going to be a good day.

More proposed updates to thinkpad-acpi were submitted today:

 thinkpad_acpi.c |  387 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
 thinkpad_acpi.h |   53 +++++++
 2 files changed, 426 insertions(+), 14 deletions(-)

With the patch I've just proposed, the mute and volume up/down buttons get mapped to the hardware mixer, and this mixer is exposed through ALSA. This means that when you press the media buttons on recent thinkpads, you'll soon get a GNOME feedback volume widget and be able to control the hardware mixer in the volume applet in the panel.

I've also made the other media buttons found on the side of some older thinkpads actually do something sane. I'm defining something sane as not running tpd as root executing random xosd commands. I'm exporting the buttons over a exported INPUT device like other patches I've written.
This means you can map the buttons to any session action in gnome-keybinding-properties, as I've done with my “ThinkVantage” button which is now mapped to lock screen.

This has taken me the best part of a day to implement properly, and removes years of hacks involving xosd, tpd and userspace polling.

I've just posted a patch to fix the toshiba_acpi kernel driver to emit INPUT events when the fn hotkeys are pressed. This means that the hardware works out of the box, and integrates nicely with KDE and GNOME without using oddball uinput-injecting system daemons such as FnFX to do the userspace polling. This also obsoletes my hal addon to do basically the same thing.

This is part of the “Unf*ck my keyboard” initiative, and allows us to kill lots of userspace bodges aquired over the years.

Hopefully the patch will get merged in the next merge window, and then that will be Toshiba sorted. My initial IBM patch should be merged soon, and then I can work on the NVRAM mixer interactions with thinkpad_acpi once again. I think Lennart is working on ASUS, and so that will be a good few laptops “just working” sometime soon.

I've started to create a kernel driver for my 3000 series lenovo, to try and sort out some of the brokenness. At the moment, the driver just polls a bit of memory (0xb9) on the embedded controller and emits a KEY_BRIGHTNESS_XXX INPUT event when it changes. It also expresses a backlight class for the panel, although setting the value doesn't do much yet.

Now the question: for debugging I want to dump all 255 registers of the embedded controller to userspace. In thinkpad_acpi this is done using /proc/acpi/ibm/ecdump but I really don't want to hack proc support into my tiny driver. Should I be using the mem or misc kernel class for this? debugfs? relayfs? All I want to do is be able to read all 255 bytes, and also change them individually if needed.

Ideas? Thanks.

GNOME Power Manager trunk now does more with your backlight:

You'll notice the interactions are both subtle and complex.

Three significant new features:

• Actually using the ambient light sensor on the Macbook Pro
• Optionally using an integrated laptop webcam to sense ambient brightness
• Learning when to dim on idle.

Using the webcam is more sane that you think. Using gstreamer, the webcam is turned on for about 300ms every minute, and a picture is taken. The luminance is used to find the ambient brightness. This means we can dim the screen when walking into a dark room, and also make the screen brighter when the sun comes out of the clouds. This uses about 5mW extra power, but saves many times that if we can automatically reduce the panel brightness by 15%.

Also in trunk we listen to GNOME Screensaver for the SessionPowerSave message which only fires when the session is momentarily idle. If on battery we reduce the brightness of the backlight and the split-second the session become non-idle (when the user touches the mouse or presses a key) the brightness comes back to what it was before. By default this timeout is 30 seconds, but if the backlight dims, and you immediately make the session non-idle, g-p-m learns that it should make the timeout longer.

Also, I'm now working for Red Hat UK for a couple of months during the summer. Without the help of Red Hat, and the flexibility to sometimes work on upstream stuff, none of this new coolness would be possible. Thanks.

More updates to the pm-utils and hal-info suspend pages. Ubuntu, Foresight, OpenSUSE, do you want to join the party?

My new battery for my Lenovo arrived this morning. It works, and I'm happy. I might have bitched quite a bit about LENOVO in the past, but the IBM customer services experience was fantastic. I think the longest I was on hold was a couple of minutes, and they sorted out the courier to swap the batteries within one day. Nice one!