Author: hughsie

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.

A few minutes ago I committed a change to hal to move all the information FDI scripts to hal-info.

hal-info is just a small hal package that provides the hardware data and quirks. These quirks are currently things like what mice support reporting battery status, what music players are supported and what cameras are detected. This could also include a list of display adaptors that need resuming or a list of broken batteries that might explode.

Why split the data from the daemon tarball? Well, policy and probing information is still in the daemon package where it belongs. Hal is released every few months with updated dependencies and lots of snazzy new features. Users love this, stable distributions hate it, and don't update HAL, missing the newest hardware quirk updates. This means that new hardware often won't work out of the box until the next version of the distro is released.

So, for example, stable distro 'x' ships HAL 0.5.9 with no intention of updating it other than for security fixes. Stable distro 'x' does however update from hal-info-20061107 to hal-info-{date} as there are no new features, minimal risk of breaking, and lots of chance that more stuff that didn't work now will.
Note: the hal-info version does not match the hal version – by design. Expect more frequent releases of hal-info than hal.

What does this mean:

• for an end user: Not much – all the fdi files are installed in the same places as they used to be. hal-info updates might be a little more frequent, and more new hardware might just work.
• for a distro packager: hal should depend on hal-info, of any version. Existing patches to the fdi files in fdi/information should be moved to the hal-info product.
• for the release architect: updating hal-info shouldn't break anything that already works or add new dependencies.
• for the developer: hal-info should be checked out in the same level directory as hal if you intend to use ./run-hald.sh

Comments welcome.

I've just read Bruce Perens blog about the Novell and Microsoft agreement.

One sentence that made me think is “…Novell will help Microsoft turn back the Open Document Format and substitute something Microsoft controls…” – now this is Bruce's not-so-neutral opinion, but I personally read this as “Novell might be persuaded to stop actively pushing ODF”. Maybe I misunderstand the agreement.

Basically my concern is simply thus: Why is Microsoft partnering with Novell? I'm sure they're not doing it for the fuzzy pink feeling, but rather long term commercial gain.

A few weeks ago I blogged about moving my development machine to Ubuntu. So far so good, but here is what I've noticed so far as a developer:

• apt-get source foo is the best command in the world when playing with packages
• Fedora configured my X with a very small xorg.conf. Ubuntu's default xorg.conf is HUUUGE and bloated on this new install. Congrats to the Redhat guys that made this possible. Ubuntu guys, please start doing the same.

Also on related X news, I'm very suprised at the lack of noise about open source NVidia driver effort. It seems to me that 5 talented X hackers using renouveau could probably do a half decent OpenGL driver in a couple of weeks. Even if the driver wasn't complete, a driver that would work for 90% of typical use scenarios would be great. Or even better, if renouveau could be made point and click so that 500 semi-talented hackers could do it in a few months.

After looking at the TODO page I've decided my code-karma is probably lacking for X and DRI work, although I'm doing lots of background reading to try and do something useful in a few months, and if nothing else, I can help improve the documentation.