Category: Uncategorized

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!

If you are using Fedora Core 7 or Mandriva Linux 2007 Spring and suspend does not work, then please see these pages.
This should explain how the new hal-info + pm-utils system works, and also has the start of a pseudo-interactive suspend debugger.

Comments welcome.

Yesterday I send a patch to hal-devel describing a patch to add nvram polling to HAL to abstract the buttons. I did this basically for comments, and so people can try the addon and see if nvram polling worked for them. And then, feeling less dirty, I wrote a kernel patch. I want to convert the thinkpad_acpi module to use INPUT rather than export random hotkeys using acpi events. The idea being the INPUT keycodes can be mapped using a keymap, and we can make the keys work for people without using some random custom session or system daemon. This means you can do KEY_FN_F2 and then you can map the button in gnome-keybinding-properties just as if it was any other normal AT button, or choose a keymap in gnome-keyboard-properties so all the buttons work. We need to automate this somehow, and I've a funny feeling it might involve HAL. The NVRAM keys (volume, mute, thinkpad) will have to be done a little more carefully as they are tied to hardware, although I think I can do that polling in the kernel quite cleanly. I intend on submitting patches for all the machines that I can get my hands on, first in my sights is toshiba_acpi. Plan?