gnome-power-manager and processor wakeups

Powertop is a great tool. Is does however have some disadvantages:

  • ncurses GUI
  • You have to run it as root
  • It gives you hardcore suggestions that you have to do manually, which in turn disable bits of the desktop
  • You can only run one instance of powertop at a time, else you get crazy readings
  • There’s no shared library giving access to the data
  • It’s not extensible, so you can’t do much with the data

Now, it turns out the actual data processing code of powertop is pretty easy, sampling /proc/interrupts and /proc/timer_stats every few seconds and throwing away interrupts that are defered and that sort of thing.

In a couple of hundred lines of C, I’ve added this support to DeviceKit-power on a new DBus interface, and added a trivial GObject helper for applications to use.


Long term I want to get this functionality in gnome-system-monitor (it’s querying a simple DBus interface), as I think this data better fits there. gnome-power-statistics is just a handy module that already depends on DeviceKit-power.

As usual, comments and suggestions welcome.

gnome-power-manager and buttons

Another change coming in 2-27 – gnome-power-manager will stop listening to HAL for button events. Peter has been rocking with evdev over the last few months and now all the multimedia buttons come up through both X and HAL. g-p-m has to filter the second button, and mostly this works well. Some distros are still not configuring evdev properly, and some still inject events into HAL, or rely on HAL to scrape events from oddball kernel interfaces. The way forward is using INPUT in the kernel, and the vast majority of events are now coming through INPUT from random devices, and through X to applications.

Inhibits, and the new world order

Once upon a time there were three inhibit API’s:

Obviously, this has a few big flaws:

  • An application might have to inhibit three services, using slightly different methods
  • gnome-screensaver has to expose lots of low level icky stuff for g-p-m to consume
  • We’ve got a screensaver doing idle detection
  • We’ve got gnome-power-manager writing into gnome-screensaver GConf keys to get the timeouts correct
  • It’s not possible to prevent logout or user switching
  • The hand-off between the session and power manager is poorly defined, so we get stupid libnotify popups rather than nice dialogue integration.
  • We don’t integrate with presence services, so we just ignore away/busy/idle status.

Basically, we need the session manager to take care of the all registrations and handle the interactions. Luckily, this is what Jon McCann has done in gnome-session.

These new interfaces are session management done right. Of course, this breaks the old world order of inhibiting gnome-power-manager and gnome-screensaver. For the 2-26 series all inhibits are proxied by g-p-m and g-s to gnome-session, so everything should pretty much just work like before. But, early in the 2-27 cycle we’re going to remove this compat code and everything will have to go through gnome-session. For most code it’ll just be a couple of lines changed and behind the scenes it’s a much simpler and more powerful design.

Like some of the other changes we are making at the moment (DeviceKit, PulseAudio, KMS) this is a new way of doing things, and things might temporarily break. They’ll be regressions, but things can be fixed quickly and most importantly, correctly. What we were using before just wasn’t good enough. With this new framework, we can do it right for GNOME 3.0.

Libnotifytastic

Every now and then, somebody chastises me for abusing libnotify to display something to to user. I guess it’s easier to just spam a fire-and-forget notification that thinking about how to present the data properly to the user.

A classic example is the messages the PackageKit daemon passes to the client program. These messages are packets of data containing the message type and any specific details. An example of this might be a message telling you that a config file has been automatically merged, or that a non-critical error has been worked around. These also tell you when things like prelink fail, which is a pain when you’re running something like rawhide. These messages arrive as the transaction is running, and are designed to be shown to the user at the end of the transaction and not get in the way.

Now, due to some “just get it working as quickly as possible” design standards, I used libnotify to display these to the user. Bad me. My excuse is that I’ve been very busy with other stuff, and life seemed to get in the way over Christmas.

Now I guess the right way to show the user this sort of data is for an icon to appear, something like this:

When the icon is clicked, something like this would appear:


So comments and feedback appreciated. No code in git yet, until it looks nicer. Thanks.

Microcode pushes and pulls

Every time I start my laptop, I get a firmware request from the kernel for /lib/firmware/intel-ucode/06-0f-0b for a microcode update. This fails, and no package provides it, but I would like to know why the kernel is requesting this. As far as I knew, all microcode is located in microcode.dat, and pushed from userspace to kernel using microcode_ctl, rather than the kernel requesting it itself. If I can’t find any explanation, I’ll just block all microcode requests in the client to avoid PackageKit users having searches automatically done for files that aren’t going to exist.

Help appreciated. Thanks.

Working at Red Hat

About two years ago, I was at a conference with a load of GNOME people. I mentioned over drinks to two friendly Red Hat hackers, that I had an idea about a packaging framework. It was just an idea, as I was working for a large defence company, and had precious little time to maintain gnome-power-manager, let alone start anything new.

Nearly a year ago, I was hired by Red Hat to work on power management stuff. Now, my boss is one of those cool bosses that gives you quite a bit of ‘space’ and with his blessing I started to hack on PackageKit. 18 months later PackageKit is feature-complete, and the defacto standard across a dozen or so distributions.

Every week or so, I put up a new screenshot on this blog of cool stuff I’m working on. Every week people critique my ideas, and I go away to fix them up so the next version is that little bit better. Every week a few people say thanks, and tell me I’m doing some cool stuff, which is nice.

I don’t want people to think that PK or DK-p are Red Hat projects, but the simple economics is that they pay me to hack on cool projects. Whilst working at Red Hat I’m working alongside the very best people in the industry, in an environment that rewards innovation and thinking a little bit different.

What I’m trying to say is, most things you see on this blog are possible because of Red Hat. Sometimes I feel Red Hat doesn’t get the credit it deserves. Red Hat Rocks.

[CVE-2008-4311] DBus 1.2.6

Please don’t yet update DBus for CVE-2008-4311. It’s known to break PackageKit, cups, ConsoleKit, DeviceKit, DeviceKit-power, gdm, and system-config-services. There’s a partial bugfix that has been pushed so PackageKit tools still run (without the GetTid or SetLocale errors), but as introspection is still broken they’ll be odd little warnings and errors for other stuff.

I do understand how important this update is, but given this wasn’t a root login vulnerability, or anything crazy like that, I’m surprised it didn’t sit in updates-testing for a few days to fix up all the other system daemons. The worst bit is that it’s broken automatic updates for thousands of people.

I’m planning to spend this morning closing duplicate bugzillas. Fun.