Author Archives: Daniel Drake

New hardware support in the Gentoo kernel

Just a quick reminder regarding the gentoo-sources patching policy:

If you have some new hardware which is currently not supported by gentoo-sources, but you know of drivers or patches in the upstream development kernel to support such hardware, you are encouraged to file a bug and we will consider backporting the patch to the current release kernels.

An ideal bug report would look something like:

I recently purchased a Fritzomatic E2 which is not supported by the current gentoo-sources (tested both stable and testing). However, the upstream 2.6.23-rc kernel tree does contain a patch to support this hardware. I applied this patch to 2.6.22 and it works great. Here’s a link to the patch: http://foo. Please consider for upcoming gentoo-sources releases.

Even if you aren’t able to initially go into such detail, you should file a bug anyway.

While we won’t proactively go out adding new hardware support to kernels, if such patches are requested and tested by Gentoo users, we’ll add them provided that they don’t show immediate risk of increased maintenance burden.

WiFi is patented

Seemant pointed out an interesting article this morning, where the Australian Commonwealth Scientific and Research Organization (CSIRO) have successfully filed an injunction against Buffalo, a manufacturer of wireless routers, access points, and wireless adapters. Buffalo are no longer able to sell wireless equipment in the US unless it licenses the technology from CSIRO.

Further research shows that CSIRO believe they own the rights to orthogonal frequency division multiplexing, which is the data modulation scheme used in 802.11a, 802.11g and 802.11n (note that 802.11b, the older/slower standard, uses complimentary code keying instead).

If this lawsuit succeeds, it means bad news for all wireless vendors.

Distributed distributions

Does anyone know of any Linux/BSD/similar distributions that are employing a distributed/decentralized source code management system for their package trees?

To clarify, the difference that I’m interested in is as follows:

Distributed development tools such as git and mercurial allow everyone to clone the whole tree including all history. Everyone who does make a clone — let’s call it a branch — is able to commit new changes to their own branch, and can publish their branches. As everyone effectively has commit access, development hierarchy is built purely based on politics and personal standing (e.g. in the case of the Linux kernel, Linus is recognised as the boss, therefore his tree is ‘the one that counts’). Within reason, these systems all make it very simple (i.e. 1 easy command) to merge all the changes in someone elses branch into your own, even if the 2 branches are stored on different computers.

Centralized tools such as CVS and Subversion are different. There is a concept of ‘commit access’ to a centralized repository, and while anonymous read-only access may be granted for users who do not have commit access, such users can not make their own commits and do not have such an easy way of sharing their changes with the people who do have commit access to the centralized repository.

So, does anyone know of distributions that are using distributed systems for managing package trees? Gentoo uses the centralized approach — packages are maintained in CVS and we only give commit access to people who we certify and trust as Gentoo developers.

ZD1211 back in production

Since the Atheros acquisition, introduction of new ZyDAS ZD1211 USB-wireless devices has been concerningly slow.

Fortunately, some new ZD1211 devices have been popping up recently, based on new radio chips. After some help from the community, I managed to get my hands on the new types and write zd1211rw code needed to support these chips.

The first new chip, the AL2230S, only needed a few changes on top of the older AL2230 code. This radio is working well.

The second new chip is especially interesting: the Ubec UW2453. Ubec publish full technical specs for this chip, so we’re able to understand more than usual about the ZD1211 interactions with the radio. Maybe due to it’s complexity, the UW2453 isn’t performing quite as well as the other radios, but this should improve after time. I emailed ZyDAS some feedback about their UW2453 programming code – I think I spotted a few mistakes.

Third, we started seeing the already-supported AL7230B RF chip being combined with the ZD1211B base chip on some newer ZyXEL products. This particular combination was not supported before, but thanks to some testers on the mailing lists, the code has been written and submitted to support these.

Fourth, Atheros appear to have rebranded the ZD1211B chip as AR5007UG. These devices are appearing in Medion laptops, very popular in some parts of Europe. The first ones seem to be based on the UW2453 RF mentioned above. I’m especially interested to hear from people who have AR5007UG devices in other laptops or in standalone USB-dongle form, and also if they exist based on other RF chips.

All the above will be available in Linux 2.6.22, except UW2453/AR5007UG which will be available in 2.6.23.

On a final note, I moved the zd1211rw homepage to the new linuxwireless.org wiki. One nice feature here is that the zd1211rw supported devices list gets aggregated onto the more general Linux-supported USB wireless devices list, however we’re the only USB driver with device information published there at the moment.

Dell laptop LCDs not powering up on lid open event

My Dell Inspiron 640m laptop has some strange behaviour which irritates me: when the lid is closed, the display turns off as you might expect. However, when the lid is opened, the display remains off.

The workaround up to this point has been to use acpid to listen for “lid open” events, and then have an event handler which uses vbetool (or xset) to restore power to the display.

I’ve been digging deeper into this problem, and have realised that the above behaviour is entirely due to the behaviour coded into the system ACPI tables (DSDT). With just a few lines of code, this strange behaviour can be “corrected”.

I’ve posted a DSDT patch to fix this. To use it, you have to decompile your DSDT, apply the patch, recompile it, and then build it into your kernel. For interested people, there are plenty of DSDT-patching guides on the Gentoo Forums and similar.

After applying this fix, I can uninstall acpid completely and the screen blank/unblank “just works”. The above patch is suitable for Dell 640m and e1405 models, and possibly others too.

UPDATE: I’m working on kernel patches which will mean that no DSDT hacking is needed, and LCD resuming will really “just work”. Keep an eye on my weblog for more.

Widescreen Intel video BIOS hack no longer needed

Many of us with widescreen laptops which have Intel graphics chipsets have been unable to use wide display resolutions without running hacky programs (such as 855resolution or 915resolution) on every boot to patch the video BIOS.

The new xf86-video-intel-2.0.0 driver no longer uses the video BIOS, it does native mode setting. In other words, the 855resolution/915resolution utilities are no longer needed.

For Gentoo users: xf86-video-intel is named xf86-intel-i810 in the portage tree.

Using ketchup to quickly install kernel sources

ketchup is a neat utility to download and unpack a specific version of the Linux kernel sources into the current directory. It also does rather well on saving download bandwidth, i.e. if you have the 2.6.17 source tarball and ask for 2.6.18, it will only download the 2.6.17-to-2.6.18 patch.

Here’s a quick usage example, which installs the 2.6.21-rc7 kernel sources:

# emerge ketchup
# cd /usr/src
# mkdir linux-2.6.21-rc7
# cd linux-2.6.21-rc7
# ketchup 2.6.21-rc7

When ketchup has finished, you then have a clean set of kernel sources for that particular version in front of you.

I like to configure ketchup to use the same storage directory as portage, so that they can share kernel tarballs. In my ~/.ketchuprc I have:

archive = "/usr/portage/distfiles"

Hardware protocol analyzers

After learning of my involvement with USB drivers through a recent interview in a Gentoo Weekly Newsletter, Elias P has donated me a couple of hardware protocol analyzers:

The USB one should be useful with my current and future USB driver projects, and will be a useful tool to learn more about USB on the physical/electrical level. In addition, the vendor do provide Linux drivers but they are closed source, so I will soon be attempting to reverse engineer the protocol analyzer (oh the irony) in order to provide open drivers.

I don’t currently have a use for the I2C/SPI analyzer, so if you know of any open source developers who would find this useful in their projects, please send them this way. I’m happy to send this device on, provided that I can see that it will be used to aid open source development.

UPDATE: I2C/SPI analyzer was donated to David Brownell for Linux kernel SPI development.

Thanks Elias!

SFLC legal assistance for fingerprint projects

Now that NIST have finally made public information provided to me in private about their export control concerns, I wrote up a summary of the situation and approached SFLC about getting legal advice.

Shortly after, I am contacted by James Vasile, a member of their counsel. James has experience in this area and I anticipate some answers within the next few weeks. The process so far has been very simple and efficient, let’s hope the news is good news!