Month: August 2009

A few people mentioned on my last blog post that instead of nagging the user to unplug or restart, we should just rebind the device. I didn’t do this yesterday as it was quite hard to do the layering correctly as the session is running as a normal user.

But of course, doing things correctly is often harder than doing things quickly. I’ve merged an optional helper into PackageKit that just pokes the hardware in the right place to make it rebind and re-request firmware. This is all done using the pkexec functionality in PolicyKit1, and a custom policy rule.

If you want this new functionality you need to build contrib/device-rebind in the PackageKit project, and also have GUdev and PolicyKit1 installed. If you don’t have these things, the session will fall back to just asking the user to reboot.

Ohh, and if the rebind fails in any way, we just fall back to asking the user to re-plug or restart like we did before. Device rebind functionality is currently Linux specific, but patches for other operating systems welcome.

For a few months now, PackageKit has been able to install firmware for devices. Sometime in 0.5.x series the functionality broke, so I spent the morning fixing up the module properly.

So, when you start your session (or insert the device), you get greeted by:

Notice, we now display the device model, but in this case where a device is waiting for firmware, normally the results are not complete and thus not pretty. USB WLAN is the best we can do in this case. If the user clicks install, the install continues in the background, and then the user gets a few minutes later:

but if it’s not a removable device:

Of course, you’ll need a pretty new distribution to have GUdev installed, but if you don’t it’ll fall back to being unhelpful.

I’ve been working with the xorg people upstream, trying to sort out all the remaining blanking problems properly, rather than just working around the problem. I’ll explain the key issues:

gnome-power-manager uses a counter inside Xorg called IDLETIME. This counter is incremented only when the user does not move the mouse, or click some keys. When the user clicks something, the IDLECOUNTER is reset. Unfortunately, the IDLETIME counter was also being reset (in two places!) when the DPMS level is set. Now, this doesn’t affect most users of IDLETIME, as the screen doesn’t blank that often. For the most part, IDLETIME was a welcome addition to the X server.

For gnome-power-manager, we set up a XSync alarm for IDLE counter being over a certain value, and then we set up a XSync alarm for the IDLE counter being reset. When the alarm goes off we wait the policy time for the “display sleep” and then turn off the panel using DPMS. Which then resets the idletime, which turns the panel back on. Urgh.

So, what we do is handle the reset event, and if the event is less than a few milliseconds since we did a DPMS action, we ignore the alarm. Of course, if we ignore the alarm, then we don’t get the reset event when the user moves the mouse and the IDLECOUNTER gets reset. So, in this case, gnome-power-manager sets up a 1ms timeout when we detect an alarm a small time since a DPMS event. This triggers almost immediately, and so we get the alarm fired practically straight away.

Except, due to another X bug, if we set an alarm value on the timer that’s already been passed, we don’t get the alarm fired. So, if you’ve got a high load value, or a slow system, you could miss the alarm. So, we had to raise the bodge alarm value to 50ms, rather than 1ms. Urgh.

But then, there’s a nice 50ms race between the two timers, and 50ms is a small amount of time in human terms, right? No. When the user is reading something, and the display blanks, most users move the mouse pretty much straight away. If you hit this 50ms race (which some people seem able to do, me included) then gnome-power-manager misses the reset event, and if configured to do so, gnome-power-manager will still think your idle, and then go on to suspend your system. Urgh.

So, the only way to fix gnome-power-manager and remove all these ugly kludges would be to fix the xserver. I’ve sent two patches to xorg-devel which remove the IDLECOUNTER reset when DPMS off is sent. The second upstream patch is here.

So, I’ll remove the kludges from gnome-power-manager git master today and will depend on a runtime version of the xserver that has these patches applied. If you are trying to run gnome-power-manager with a broken version of X, gnome-power-manager will warn you in the notification area. Distributors will just need to patch xserver with my previous patch and the current one to have all the issues resolved with git master.

edit: updated with links to the signed off patches in xserver!

So, Peter Hutterer is my new best friend. Peter has found and patched the bug in the X server that was causing the failure of negative transition triggers in XSync. For you and me, that means that XIDLETIME now works as expected, and gnome-session and gnome-power-manager do the right thing. This means no more random blanking when typing.

There’s a pending Fedora 11 update here and a build for rawhide here — it should be tagged for F12alpha, but no promises at this stage.

The important patch for the xserver is here and I urge all distros to cherry-pick this commit into their stable branch, as this affects a lot of users. Hopefully this is the end to the saga of accidental screen blanking.

Anyone familiar with GtkPlug? I’m having issues with the PackageKit XEmbed browser plugin — unless I set the sizes for the widgets using gtk_widget_set_size_request, or set the widgets to expand to all the space, I get widgets with close to zero width and height:

The line across the widget is meant to be a GtkButton! Ideas welcome, and experts rewarded by beer! If anyone has examples of how to do a browser plugin with GTK controls, that would be great too. Thanks!