Category: Uncategorized

So the “unfuck my keyboard” project is going well. We now have a way to map scancodes to keycodes even for the vendors that choose non-standard scancodes that don't get input events.

The thinkpad-acpi and sony-laptop kernel drivers now also support the setkeycode ioctl and report key presses over input. This means we can map the acpi events to keys, even when vendors do crazy things and move the decal on the button between models and ranges for no apparent reason.

ALL LINUX USERS:

So now I need your help.

Do you get something similar to this in dmesg?:

atkbd.c: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e017 ' to make it known.

Try using all the fn-buttons and the special multimedia buttons, you might find you could help make this work.

SONY USERS:

I need to know what button does what on your laptop. You can already see I've fixed Bastiens laptop by looking at this file. This gives you an idea how simple it is.

THINKPAD USERS:

I also need to know what mapping you have. See this file and send me a patch to make it “just work” for you in the future.

Big Note:

You'll need to be using a very new HAL and hal-info to make this work right now. If you want the sony and thinkpad bits to work you'll also need kernel modules from git. Actually getting it working now is unimportant – getting the data as soon as possible makes sure it should work for as many people as possible for Fedora 8, or the next version of Ubuntu or Suse.

So please, visit the quirk site and help me try to fix broken keys by sending patches. I need your help.

I've just had a bug reported:

“At Ottawa Linux Symposium, it was common to see people walking around with
their laptops half-open because they didn't want them to sleep. Whether wardriving, Web serving, or music playing, some people do not want their PCs to sleep.“

I cast my mind back to GUADEC, and sure enough I can remember an entrance hall full of people walking about with half-open laptops. This made me smile.

I figured I could use the inhibit applet for people to use for a “don't do what you normally do” type action.

So now we have a new toy. With gnome-power-manager from SVN you can add the standard  “inhibit” applet into the panel, click the button, shut the lid and walk over to show someone your new coolness.

But wait! Some laptops melt or get rather hot when you do this. So just in case we have the following warning that is displayed when you manually inhibit and you have either suspend or hibernate configured as the battery lid close action.

So, maybe for GUADEC this year we'll see less half-open laptops…

The powertop utility from INTEL has been very interesting to use. Unfortunately, I'm quite pissed off.

“gnome-power-manager doesn't dim the backlight to save power it actually just changes the colour of the pixels on the screen”

Err no. It never has and never will. It actually dims the backlight on all the hardware I have tested it on.

Dimming to 30% when idle saves me about 1-3W of power on all three laptops I own. That's a X60 (ibm+intel), n100 (lenovo+nvidia) and a A10 (toshiba+old-intel).

For the X60, g-p-m calls HAL, which writes to the thinkpad_acpi controlled backlight class. This then writes a value into the embedded controller address space (or issues a CMOS command) which changes the hardware backlight brightness.

Really impressive graph by the way – but what crack are you smoking?

If you have a Gateway 400VTX or 450ROG please email me your output of lshal.

I would like to add more broken batteries to the hal-info blacklist. Thanks!

For the last few days I've been working on DBus system activation, extending and slightly modifying on the work David Zeuthen did a few months ago. So what is is?

You already see activation working in the session, for instance where notify-send can get dbus to start notification-daemon only when a notification needs to be shown. The bigger problem was to launch stuff on the system bus under different users. Securely.

We think we've worked out how to do this securely, but further review would be lovely. The patch is here, and I've got a SRPM also here.

So what?

• We can launch helpers to do things as different users, for instance use a combination of PolicyKit and a system helper to set gconf defaults for all users. We can do some cool things with this.
• We can launch some automatically, only when required. For instance, we only need to start ConsoleKit when HAL is started, and this is done automatically for us on the first method that HAL requests from the ConsoleKit service.

So, for a non-legacy system (think OLPC) we can just do:

• kernel….udev….messagebus….login-screen

And that is it. As sugar (or another interface) requests the network state, then NetworkManager is started. This calls into HAL, so that is started. That calls into ConsoleKit, so that is started. As soon as we are on the network, we search for users, which queries avahi, so that is started. Can you see where this is headed? Parallel start-up with dependencies essentially for free.

Already, I've taken my Fedora 7 boot time from 20 seconds to 14 seconds by dropping a few service files in directory and turning off services in chkconfig. That's pretty substantial in my book. I've yet to build this for OLPC, but I'm guessing it will be a more substantial reduction.

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.