Accidental blanking and gnome-power-manager

Okay, after having F11 g-p-m blank the screen on me whilst watching some short videos in totem yesterday, I got really angry. It seems lots of other people feel the same way.

I’ve audited all the IDLETIME code in gnome-power-manager multiple times, and when I’ve run it in a console and watched the output, it all seems to work 100% okay for days on end, and then fails when you’re actually trying to do something. And then I had an epiphany: It only seems to fall over gnome-session is involved with handling inhibits.

So, this works:

GPMIDLEDEBUG=1 ./gnome-power-manager
…wait 10 seconds…

IDLETIME fires the idle alarm expired (and g-p-m dims the screen) and the reset alarm is setup

…move the mouse…

IDLETIME fires the reset alarm expired

Then I issue an inhibit request to org.gnome.SessionManager with parameters (‘test-program’,0,’testing’,8) using d-feet and get back a cookie like normal. Session becomes inhibited.

…wait 10 seconds…

IDLETIME fires the idle alarm expired (but g-p-m doesn’t dim the screen, as the session is inhibited from totem) and the reset alarm is setup

…move the mouse…

NOTHING. No event from X.

…close d-feet…

The inhibit gets auto-revoked, session becomes non-inhibited, and g-p-m assumes that x has been idle for a long time, and also the session is not inhibited, and so switches off the screen. You can see this when using GPMIDLEDEBUG as the second icon is a box, not a computer icon.

Now g-p-m is confused, and has to be restarted before it will reset the new idletime counter. You can’t reproduce with the original idlecounter-demo program when using XNextEvent, but you can as soon as you hook into gdk with gdk_window_add_filter. It really looks like something is doing GDK_FILTER_REMOVE on the reset alarm at some point. There’s a test program here which you can see the bug without gnome-power-manager running, just to prove it’s not a silly bug or race in gnome-power-manager. It could also be an X bug, as the XSync stuff isn’t that widely used, although all gnome-session is doing is XSyncDestroyAlarm’ing an alarm, which shouldn’t affect gnome-power-manager’s alarms at all.

After looking in the forums, this problem looks like it’s triggered lots, and by many different users. I would appreciate any help here as I’m well and truly stuck. Thanks.


p.s. if anyone knows how to debug gnome-session to see the debug output, I would be very grateful. Any attempts at replacing gnome-session process in my session lead me to a forced logout.

Firefox plugin woes

The PackageKit browser plugin hasn’t had a lot of love recently. It was written in C++ a few months ago by Owen, but started to bitrot over the last few xulrunner releases.

I’ve spruced up the code, and ported everything to C (using GObject where possible) and now it all seems to work with one exception: invalidaterect doesn’t seem to work where I think it’s supposed to.

I’m setting up the plugin with some default content, which gets shown to the screen. I’m then doing a PackageKit query, and a few ms later I get the results. I then update some internal state, and call the invalidaterect for the whole drawing area, expecting a GraphicsExpose event to render the new content. But alas, invalidaterect seems to do nothing.

I’ve even tried adding a forceredraw call after invalidaterect, but that also gets ignored. If I manually resize the epiphany/firefox window then the GraphicsExpose event gets called, and the plugin then shows the correct state. This is a windowless plugin and nsplugginwrapper has been removed, and so I think I’m doing everything by the book, so to speak. Help welcomed, and anyone pointing out the bug will be rewarded with a beverage of your choice. Code is here. Thanks.

Updating shared libraries

I want to add functionality to PackageKit to detect when a new version of a shared library is installed, and there are applications still using the old version that no longer exists. We can then inform the user if they need to restart the computer or log off and back on if the library was updated for a security vulnerability.

Does anyone have any example code (preferably written in C, although I’m not that bothered) that I could use? I think this would be quite nice functionality in future versions of PackageKit.


HALectomy of gnome-power-manager complete

This morning I committed a rather largish (23 files changed, 28 insertions, 1551 deletions) patch:

commit f884a1ae954d14928a6a7055d4d4b182fbb2a3bc
Author: Richard Hughes <>
Date:   Fri Jul 3 13:49:05 2009 +0100
    HAL is no longer a dependency of gnome-power-manager

This means that gnome power manager in git master no longer needs HAL to compile or run. This is a quite a significant moment, as now it relies just on the thriving DeviceKit* stack, rather than the old lumbering HAL.

Just a word of warning: You’ll need DeviceKit-power 009 (released in a few days time) if you want to use g-p-m in git master without loosing your ability to change your backlight, or to set the lid action preferences. It’ll still compile with 008, but 009 is very much recommended.

Dell Mini 10v and the touchpad of death

The Dell Mini 10v does have a very nice keyboard. But then it also has a very bad mousepad. The buttons are actually on the trackpad, so if you click you end up moving, or if you’re dragging you end up shooting across the screen. Pain.

Anyway, there’s a fairly nice workaround by setting the System->Preferences->Mouse values to “Scrolling: disabled” and enabling “Mouse clicks with the touchpad“. All you have to do then is remember not to click the physical buttons, but tap instead. Not perfect, but saves you wanting to hurt someone. Bug for a proper fix is filed here.

Dell Mini 10 and BCM4312

I’ve just been bought a Dell Mini 10 by my employer, Red Hat.

I’ve wiped Ubuntu, and installed Fedora 11 on the machine, as it’s what I’m familiar with, and the kernel seems to be a bit more up to date than what it came with. Kudos to Dell for shipping with any Linux, I’m sure most people don’t care that much what “version” of Linx they are using.

Now, the interesting part: most stuff “just works”. The screen is fantastic, the keyboard is pretty good considering it’s so small, and the backlight seems to DTRT. It also weighs about one thousandths of a gram, or something in that order or magnitude.

Now, what doesn’t work: the Broadcom BCM4312 network device. Now, somebody has reversed engineered the Broadcom hardware and has published really good specs about the 43xx hardware, and the 4312 is no exception. The 4312 seems to be a LP PHY, so a little different than what the kernel knows about already. There’s already enough code in the wireless-testing kernel tree thanks to Michael Buesch (but EXPERIMENTAL and BROKEN) to get the chip operational, and recognised by NetworkManager, by alas, 95% of the setup code is needs to be written.

Now, all it would take is for a couple of expert network hackers to take the spec, and implement the engine setup in a few days of hacking. Unfortunately for me, I’m no network hacker, and am crazy busy with PackageKit/DeviceKit/PolicyKit work. That said, if no-one steps up to the mark in the next few weeks, I’ll have a go and submit some patches.

There’s also the firmware issue. Using b43-fwcutter I can get working firmware, but this doesn’t feel very “Fedora” as you have to use the Windows non-free driver and cut the binary data from it. I’ve tried to push through the open firmware package into Fedora, but this only supports a few of the older Broadcom cards. It wouldn’t take much to add support for the newer cards, although that’s probably a task for someone very familiar with the hardware, like for instance, Broadcom.

Now, Broadcom, I’m sure the open source community would really appreciate an engineer-day per week (I guess circa $12,000pa plus some good PR) for the open drivers and firmware. If that were to happen, and Linux support for Broadcom networking goes from 10% done to 90% done, I’m sure a whole lot more vendors would ship with your hardware inside. Whether or not that would translate to greater than $12k’s extra profit is left as an exercise for the reader.

For me, so the notebook is at least useful, I’ve replaced the Broadcom card with an Intel 5100AGN mini PCIe half height card with free drivers and distributable firmware. It cost £10, brand new.

I’ll still be testing the Broadcom free b43 driver, and hopefully be hacking on b43 in a few weeks if nobody beats me to it and my TODO list reduces in size.

edit: I’ve been informed the specs are not by Broadcom, they are reversed engineered. Wow.