Category: Uncategorized

I've just merged Benjamin Canou's new brightness applet into gnome-power-manager CVS. It's still WIP, but it looking good already.

If you've got a laptop without brightness buttons, you can now change the brightness easily. And yes, before anyone has a coronary, this is an applet and not another notification area icon, so you have to add it manually if you want it.
We have chosen to integrate this with g-p-m and not use HAL method calls directly as g-p-m is the policy agent. This means it's doing some clever things in the background – for instance dimming your screen when the computer session is idle, or changing your brightness when you are on battery power, and we have to be a bt clever when we try to change things manually.
Now, I've got no problem moving this applet into gnome-applets long term if desired, but for the moment the BrightnessLcd interface for g-p-m is not stable, and might change at a moments notice. You'll have to manually add –enable-applets to the gnome-power-manager configure line if you want to build this from CVS now.

Reading back byte EC0:0x31 on a IBM Thinkpad embedded controller returns the laptop panel brightness. Setting this byte changes the panel brightness. This is how the ibm_acpi module has worked for years. Hacky, but it worked.
On a Lenovo N100, doing this didn't work due a slightly different embedded controller. I've managed to work out that you can read the brightness back (0-7) from reading the byte EC0:0xB9 (\_SB.PCI0.LPCB.EC0.BRTS) but changing it does nothing to the panel brightness. I can set the EC0:0xB9 value manually, and read back the 'new' value but I can't get EC0 to change the brightness at all.
I'm guessing Lenovo have upgraded the EC0, and now we either:

• Can't software control the brightness due to physical h/w limitation
• Have to poke some other register to make the brightness value “set”

I've had a look at the Renesas H8S datasheets (used for the EC0 chip) but it just seems like a bog standard micro-controller.

I've also read the 2161BV ec.s disassembly of the ThinkPad EC0 firmware (which looks like it should do the right thing) but I can't seem to get hold of the decompiled sources for the latest Renesas chip used in the N100. I've a sneaky suspicion there is either a software bug in the EC0 firmware, or that there is just no physical electrical connections to be able to change the brightness in software.
There's a pint offered at the next GUADEC for any help getting this to work.

EDIT: Update: setting the brightness to 7 using the Fn keys and then setting C0:0xB9 value to zero, and then pressing Fn brightness up, the display is set to brightness 1. This means we just have to convince the EC0 to update the brightness, which maybe we could do with a fake keypress or something. Still confused.

In my opinion, Lenovo didn't read the ACPI specification when designing the N100 line of notebooks.

I'm unable to get the backlight class support working on my notebook due to the missing _BQC (Brightness Query Current level) method which is meant to be present in the BIOS.
Lenovo do implement the _BCL (Query List of Brightness Control Levels) and _BCM (Set the Brightness Level) methods, so I just cannot understand why they didn't add the additional three line method to have full support for the ACPI “Output Device” class.

Now, after my partial success in getting a new BIOS from Lenovo to fix the battery reporting (fixes the problems in Windows XP also) I've had no more correspondence from Lenovo. I have also been been sent an email “…IBM/Lenovo provides free software support for the first 30 days after the purchase of the machine… Please note that the software support is chargeable after the first 30 days…”  which I'm guessing is their way of telling me “stop bothering us, go away, we're not interested in fixing anything“. I'm not sure if I should send the notebook back to LENOVO as defective (as it's quite clearly not working with ACPI as advertised) or just send them a bill for my BIOS hacking.

This notebook is fast and Linux support is pretty good, but the BIOS looks like it was rushed and not properly QA'd. At the moment I would probably not recommend Lenovo to somebody that wants Linux compatible hardware, which is a shame considering how good most of the Thinkpads used to be. Perfect Linux support is only a few man-hours of engineer time Lenovo, and I'm sure that would be cost-effective just with one extra bloke choosing Lenovo hardware “because it works with Linux”.

Apologies if I have not answered any emails or bugzillas for a week or so – I've been stressed out of my face for the last week or so. I'll catch up at this weekend.

Any comments on the language used in the warning dialogue? Legally I don't think I can use the words explode, overheat or fire. Thanks.

The last blog today I PROMISE. Three more manufacturers please – if you have any of the laptop models below:

Gateway: CX200, CX210, E100M, M250, M255, M280, M285, M465, M685, MP8708, NX260, NX510, NX560, NX860, NX100, MX1025, MX6918b, and MX1020j
Sony: VAIO: VGN-FE550G, VGN-FE570G, VGN-T240P, VGN-T250, VGN-T250P, VGN-T260P, VGN-T270P, VGN-T340P, VGN-T350, VGN-T350P, VGN-T360P, VGN-T370P
Apple: MacBook Pro (the only ACPI model affected)

Then please, (you know the drill), lshal output to richard_at_hughsie_dot_com with [fire] in the subject.

For all those getting a little peeved with all my posts on exploding batteries : I apologise. There have been over 7,000,000 of these faulty units sold worldwide – and if we assume 1% of these are running an up to date Linux, that's nearly 70,000 people that might need notifying.

Without the help of people reading p.g.o none of this stuff would be possible. When these three vendors are sorted – I'll go back to blogging once a month…

EDIT: Please stop the Gateway emails (just committed to hal-info), but I still need more data for Apple and Sony. Thanks.

Okay, you guys are fantastic. Thanks for all the quick responses. At this rate, no batteries should ever explode again! IBM-LENOVO code is now in hal-info.

Can anybody with a Fujitsu LifeBook  C1320D, P1510 / P1510D, P7120 / P7120D, Q2010 or S7020 / S7020D please email me the lshal output. (richard_at_hughsie_dot_com)… yet more overheating batteries to find.

Thanks. I'm sure someone will complain on p.g.o but this is really a public service announcement with intent to commit code.

EDIT: Please stop the Fujutsu emails, I have enough data now. Many thanks to all that sent emails. Fujitsu is now listed in hal-info.

Today I committed the Dell and Toshiba exploding battery detection into hal-info.

Now I need some help:

LENOVO or IBM Thinkpad users might be subject to recall – can you email me (richard_at_hughsie_dot_com) the output of lshal if you have such a notebook – either if you are affected or if the part or model numbers look similar to 9*P****.

Thanks.

EDIT: Thanks! I've got all the data I need now, so please stop the emails. I've committed code to hal-info to detect the recalled IBM data now.

Memory usage of gnome-power-manager 2.16.x : 2.7MiB
Memory usage of gnome-power-manager 2.17.x : 1.7MiB

On a side note, gnome-power-manager 2.16.x was pretty much synchronous with hard-coded sequences of operations and functions depending on events. 2.17.x is much better code IMO, with most of the events happening asynchronously and with separate state machines. This makes the code much easier to understand and modify, and should squash some weird timing bugs. It also makes adding new functionality as easy to add as dropping in a couple of gobjects and hooking up some signals.

CVS versions of hal, hal-info, pm-utils, PolicyKit, libnotify, GtkUnique and of course gnome-power-manager are in the utopia FC6 repo. Caveat emptor.

Okay, for the first time in my life I'm a distro whore. I'm now running Fedora again on my development laptop (replacing Edgy). Why the switch so soon?:

• RPMs from CVS are easier to make than DEBs in my opinion.
• I've found out you can run synaptic (and apt-get) on Fedora.
• I found myself looking on google to do things with Ubuntu that I know by heart for Fedora.
• A clean init system that I can understand and tweak.
• Signal to noise ratio. The Redhat guys are easy to talk to and there is a minimal amount of noise on the mailing lists and IRC.
• I can use custom DKMS ipw3945 and nvidia packages so my custom kernels can work automatically with binary-shitty drivers.
• Black magic. I'm doing lots of work with development versions of the kernel, PolicyKit, HAL and X and I need a clean environment. Ubuntu has lots of black magic, which is great from a “just works” perspective but bad when you are trying to hack on core bits of the stack.

Don't get me wrong, I still think Edgy is great, and would wholeheartedly recommend it for someone new to Linux. For me, Fedora is just right.