Posts Tagged ‘hal’
As most of you are probably aware, HAL is dead. So let us all cry out: HAL is dead, long live… what, exactly?
If you’re wondering what on earth HAL is, it is (or was) a daemon that sat on your computer and told interested parties (such as KDE applications, via Solid) about various bits of the hardware. This went beyond abstracting away kernel interfaces, however, and included information about laptop batteries that have been recalled, for example.
However, it was decided that HAL was getting too big for its boots and was failing to acheive its stated goal of “making hardware just work”. But it was filling a need. So what is sweeping into the void to replace it?
Well, there’s UPower, for all your power management needs. It replaces those parts of HAL that dealt with screen brightness, the power button, the lid closing and entering various power-saving modes. It even goes further than HAL ever did, allowing applications to request latency targets, for example.
Then there’s UDisks. You may be thoroughly unsurprised to learn that it deals with the various bits of storage you may at various times attach to your computer: anything that appears as a block device, basically.
For many other services, you are expected to deal with either higher-level services like NetworkManager (or WICD, or other solutions) or with lower-level ones like PulseAudio or ALSA. And for everything else, there’s direct interaction with udev, via libudev.
This is all very well, but what about all that extra information that HAL provided? Well, UDev provides a device database that allows extra information to be stored with devices. UPower provides battery recall information using this mechanism, for example. There is a media-player-info project that provides UDev rules and some desktop files that furnishes interested applications with information about supported protocols and media formats of various portable media players.
But after that, I get stuck. I guess that many of the video power management quirks that HAL documented are expected to be dealt with by the kernel. But this is just an educated guess.
The major problem with this “kill off HAL” project is the sheer lack of documentation. UPower has a useful website. UDisks has an almost entirely unhelpful one. media-player-info doesn’t even have a website, and you wouldn’t really know to go looking for one anyway unless you follow the right development mailing lists.
Solid is currently having problems with developing replacement backends for HAL. What is the correct way to get the processor information that HAL previously exported? LibMTP used to augment HAL’s media player information store with its own information, but there is no clear way for it to extend the information provided by media-player-info. How should libMTP provide that information now?
All this should really be documented somewhere. Maybe it is, and I just can’t find it, but that means it’s not documented in a sensible place. The sensible places being the HAL website and the DeviceKit website (DeviceKit being the overarching term for the “stuff to replace HAL” – UPower and UDisks in particular).
I really hope someone knows what’s going on, and I wish they would communicate it to the rest of us.
EDIT: I realised that, freedesktop.org being largely composed of wikis, I could do some improvements myself. The udisks site now has some useful information on it, and there is a media-player-info site.