Device Handling and HAL

My blog's been rather inactive for a while. Most of this has been because of being busy, and because of not doing hugely exciting things when I have had Amarok hacking time (mainly some bugfixes in stable branch). But now something's come along that warrants an entry.

Amarok's device handling is pretty adequate. Granted it could be better, but we support nearly every device on the market through some plugin or another. But there's one recurring problem: except in a few cases, Amarok doesn't know what device you have plugged in, and how to handle it. You have to tell this to Amarok. This means you, and we, have to deal with the manual creation of devices. Well, that's going to change.

Enter HAL, and its KDE4 paramour Solid. By now, you probably know what these do. HAL, Hardware Abstraction Layer, gathers information about your hardware. Solid reads it (and some other information) and outputs a KDE interface to it. Now by itself, this isn't enough, because HAL has a namespace called portable_audio_player, but, with a few exceptions, it doesn't actually say what type of device you're using -- simply "storage" for a USB Mass Storage interface, or "user" meaning that a userspace library needs to handle it.

However, for the last few weeks I've been working with HAL developers and the developers of libgpod, libifp, libkarma, libnjb, and libmtp. The goal has been to come up with a way that device access protocols can be auto-detected. If you know what access protocol a device uses, you can load the appropriate plugin automatically. Well, this has been done, and as a result the HAL portable_audio_player namespace spec is being modified to allow libraries to insert information they know about devices into HAL -- while at the same time keeping libraries from clobbering each other. Interested parties can find a draft version here, with the final verison going into HAL as soon as the slugs at freedesktop.org set up my account.

After this, I will be adding proper entries in libmtp and libnjb (easy, since I have commit access for both), making entries for libifp and libgpod, and working with the libkarma developers for their entries. After all this is done (probably in the next couple weeks), Amarok 2.0 and other HAL-aware clients should be able to determine and load the correct plugin for just about any device on the market, automatically. Okay...after a lot more hacking on 2.0...but you get the picture.

I'm hoping that when this is done we can remove manual device addition/deletion. It's a complex part of the code that can be difficult to maintain, and shouldn't be necessary any longer -- if you have a library that can handle the device that Amarok can use, Amarok should already know about the device from HAL. Even generic USB Mass Storage players should be fine, because they should be detected by HAL and exported through Solid as storage volumes. The only thing I can see this affecting negatively is the generic device plugin that just got fixed to support arbitrary KIO paths but I've been thinking about pulling that into the Collection some way anyways, now that the Collection can handle many sources, as this would let it handle lots of sources