xf86-video-geode 2.11.13

A few days ago, I pushed out version 2.11.13 of the Geode X driver. This is the driver used by the OLPC XO-1, by a plethora of thin clients such as the ThinCan, by low-power desktops such as the Linutop and by a few notebooks such as the eCafé EC800.

While this release indeed features a few bugfixes (mainly to keep this driver compilable on the latest X server), the lion's share of the changes involve a complete overhaul of the build scripts, courtesy of Gaetan Nadon. The key motivation for this overhaul was to acknowledge the efforts made by third-party contributors to make the driver compile on BSD variants. Sure enough, this release finally compiles on FreeBSD and, low and behold, on Hurd.

However, the hybrid nature of Debian's FreeBSD kernel-based GNU operating system variant posed an additional challenge, because it provides usable support for Video for Linux version 2 (V4L2), but without the full complement of Linux definitions. This resulted in one post-release commit (included in Debian and Ubuntu package 2.11.13-2), following which my assertion that we could now safely define this package as Architecture: any-i386 finally proved to be a safe one for Debian-based operating systems.

At this point, I'm curious as to how many more operating systems, especialy BSD variants, can finally use this driver. Patches to further improve support of non-Linux systems are welcome.

Proposed updates for CUPS-PDF packages at Ubuntu

For those who use CUPS-PDF on Ubuntu, I have pushed some updated packages into Lucid-proposed, Maverick-proposed and Natty-proposed, mainly to make the package's post-install actions bulletproof, so that automated installs and PPD updates take place in a flawless way. Comments from anyone who tested these package updates are welcome on Launchpad bug #805947. Once these updates have been approved, I'll go through the daunting task of reducing the debdiff down to its utmost essential components and attempt to submit a stable-update to Debian as well.

Configuring GNOME themes for both gconf and dconf?

For a number of years, I've been making myself metapackages that pull favorite packages and pre-configure the desktop environment to use my favorite global default settings. This currently means configuring the gconf keys for the GTK theme, icon theme and background image for GDM. Until now, I implemented this by calling gconftool-2 directly in postinst as user gdm but Lintian recently started warning me that the correct way to do this would be by calling gconf-schemas or update-gconf-defaults instead. I was thus wondering, would anyone have any sample code that accomplishes this? To further complicate things, GNOME 3 has transitioned from gconf to dconf, which suggests that a slightly different method needs to be used to perform the same. Would anyone have any sample code to implement this? Thanks in advance to anyone who can help me with this!

X.org video driver Geode 2.11.12

Today we published version 2.11.12 of the X.org Geode driver, code-named "Squeezing the Wheezy out of Debian" in honor of the recent Debian stable release. 2.11.12 is yet another minor bug-fixing release, this time featuring yet another EXA fix for the LX component, courtesy of the OLPC team, plus the removal of an obsolete V4L1 include that was preventing the building of the ztv video input component of our driver since Linux kernel 2.6.38 - thanks to the Fedora and Ubuntu teams for spotting this!

Adding default support for Airport remote sinks in PulseAudio

In another case of "what were they thinking?" it has been my displeasure to find that support to discover remote Apple Airport audio sinks is not enabled by default in PulseAudio and, in practice, enabling this requires the user to install paprefs just to enable the loading of two modules (module-raop-discover and module-zeroconf-discover) that really should have been loaded via the global /etc/pulse/default.pa by standard. The question is, why? I perfectly understand not enabling the publishing of local audio sinks by default, but why prevent the discovery of remote audio sinks by default? More to the point, why force the end-user to jump through hoops and Google for hours just to enable something that really should have worked out of the box?

New GPG key released - signatures welcome

Having rediscovered the wonders of GPG, I finally got around generating myself a 4096R key, signing it with my old key and issuing a transition statement. Given this, if

1. You happen to have signed my old 1E0CB9CD key at DebConf5 in 2005, at Solutions Linux 2008 or at some Free Software event in Finland or in the Baltic countries over the past 7 years and
2. You're satisfied with the content of the transitions statement,

your signature would be appreciated on my new C4B4D7B6 key.

Ubuntu kernel at 1000Hz with PREEMPT enabled?

Back when Linux kernel 2.6 was released, one of the immediate benefits that I noticed was how beautifully responsive my desktop had suddenly become. As it turned out, Linus figured out that he would create a buzz to accompany kernel 2.6's release by having a default clock rate of 1000Hz. However, the excitement was short-lived and kernel defaults were soon brought back down to a more conservative rate of 250Hz, allegedly because some peripheral chips could not handle such a high frequency bump without producing an increased amount of processing errors.

Adding insult to injury, Ubuntu defaults eventually dropped another responsiveness enhancement, kernel preemption, allegedly because the goal was to have a one-size-fits-all kernel shipping with Ubuntu and preemption was detrimental to the kernel performance when the host is used as a server, which was a problem because Ubuntu had somehow decided to shift its focus from the desktop market towards the more lucrative server market.

While there is nothing wrong with universally-safe kernel defaults or with a corporate decision to shift a distribution's focus towards more lucrative markets, it nonetheless left me pondering what would be the best way to get a 1000Hz kernel with preemption on my desktops, without constantly having to crank out my own kernel packages. As such, I was wondering if there would be enough traction from desktop users to justify producing such a kernel and to make it available as a post-install option from the Ubuntu repository?

PS: I'm already aware that a specialized Ubuntu kernel is available to cater for the needs of audio production, but my understanding is that it has power management disabled, because it can interfere with the real-time operation of MIDI devices, while normal desktop users would definitely want to have power management enabled.