Channels

Services

Kernel Log: ALSA driver for the X-Fi, debate over TuxOnIce

by Thorsten Leemhuis

The Linux kernel will soon include a driver for Creative's X-Fi sound cards. After a long pause, the kernel development team are once again debating merging TuxOnIce.

ALSA and kernel developer Takashi Iwai has received an open source driver for X-Fi PCI sound cards from Creative, which he evaluates as being of a sufficiently high standard to be included in the ALSA driver package and the Linux kernel. Not being a proud X-Fi owner, however, he has been unable to test the snd-ctxfi driver himself and has therefore called on users who do own an X-Fi card to give the driver a whirl – and over the last few days several users have indeed done so, providing plenty of feedback.

The odds look good that the new driver will find its way into the next version of ALSA and into version 2.6.31 of the Linux kernel. This should be the end of a long odyssey for X-Fi sound card Linux drivers. Creative originally made repeated promises of a proprietary driver, but never delivered. A preliminary version of the driver was released in 2007, but it had so many rough edges as to be more or less unusable. An open source driver for the more or less obsolete Open Sound System (OSS) was released out of the blue in early 2008, and there were also reports that Creative planned to provide open source developers with documentation for their sound chips. This was followed by another long silence, before Creative finally released their own open source driver in November. However this driver again proved to be a little too rough and ready and was taken up by only a small number of distributions. The snd-ctxfi driver should be spared this fate, since its merger into the kernel will see it included in most new distributions.

Back again

By contrast, one odyssey which doesn't look like coming to an end is that of TuxOnIce. Now however, TuxOnIce developer Nigel Cunningham is once again petitioning for the merger of the alternative suspend to disk and hibernation framework. This is not Cunningham's first shot at this, in fact the developer behind previous frameworks Suspend2 and Swsusp2 (Software Suspend 2) has made many previous attempts to have the framework adopted.

However, as before, the developers responsible for the kernel's software suspend support have once again rejected its inclusion. One reason given for this was that they did not wish to maintain two suspend to disc technologies within the kernel in parallel or to simply replace the tried and tested Linux code with the TuxOnIce code, which offers both advantages and disadvantages and is not as well tested. Additionally, before being merged the TuxOnIce code would require auditing – a daunting task in view of the volume of code.

The proposed solution once again boils down to the suggestion that the TuxOnIce developer should split his code into bite-sized chunks, which would gradually enhance the kernel's software suspend support, so that the process would produce a reliable solution which satisfies all users and developers. This may prove more successful than past attempts, as Rafael J. Wysocki, who is primarily involved in developing the Linux kernel's software suspend code, has shown more persistent interest in collaborating with Cunningham than on previous occasions, even heading off Pavel Machek, the official administrator of software suspend support and declaring that he did not plan on taking part in flame wars between the two this time round.

Kernel status

Following the release of 2.6.27.23 and 2.6.29.3 on 9th May, the stable series administrators this morning released kernel versions 2.6.27.24 and 2.6.29.4. As usual, all users of older versions of kernel.org kernels "are very strongly encouraged to upgrade.". It is not clear, however, whether the dozens of minor enhancements and bug fixes also include fixes to security vulnerabilities.

As usual, in parallel to its Catalyst graphics drivers for Windows, AMD has also made version 9.5 of the Linux version of the drivers available for download. The release notes list some of the fixes in the new version; no new features are listed. Version 9.5 of the proprietary graphics driver is, however, just as incompatible with the latest Linux kernel, version 2.6.29, released in March, as its predecessors.

The developers of the open source driver for Intel hardware have released version 2.7.1. It includes a number of changes which should put paid to the crashes which occur with version 2.7.0.

AMD staffer Alex Deucher has recently announced the release of a "R6xx/R7xx 3D programming guide", which contains a wide range of information on programming 3D graphics drivers for the GPUs used in the Radeon HD 2000, 3000 and 4000 series.

Kernel Log in brief

The development team behind the Ksplice framework, which allows many security-related Linux kernel bugs to be patched at runtime, have won the $100,000 prize in the Massachusetts Institute of Technology's (MIT) 100k competition. The KSplice development team are currently actively working on merging the kernel portion of their code into the Linux main development tree. The odds of the code being adopted look good, though it is not yet clear when this is likely to take place.

Jeremy Fitzhardinge has sent a series of groups of patches to LKML for evaluation. The patches add kernel support for operation as hypervisor-controlling Xen domains (Dom0) (see also The free Xen 3.4 hypervisor and virtualisation strategy). Various kernel hackers have expressed in some cases major reservations about portions of the patches in discussions and on the "Where do we stand with the Xen patches?" thread. It therefore currently looks unlikely, though not impossible, that Linux 2.6.31 will include Xen Dom0 support.

The SANE (Scanner Access Now Easy) project has released version 1.0.20 of the SANE back end. It contains four new drivers and supports 75 scanners not supported in the previous version.

Luis R. Rodriguez, an old hand in the Linux WLAN driver field and nowadays also an old hand at Atheros recently publicly asked whether it was time to kill MadWifi development, since the kernel drivers were now able to address all hardware supported by the MadWifi driver. Some users and developers were, however, far from thrilled by the suggestion, as can be seen from some of the contributions to the discussion.

Further background and information about developments in the Linux kernel and its environment can also be found in previous issues of the Kernel Log at The H Open Source: