The Road to KDE 4: Solid Brings Hardware Configuration and Control to KDE

One of the many new technologies for KDE 4 is the often mentioned, but seldom explained Solid hardware API. Hardware has always been a bit of an annoying element of using Linux and other UNIX-like operating systems, but Solid hopes to fix that for KDE 4. In many ways, Solid is like Phonon, in that it's a Qt/KDE style API around already existing components at the lower level, such as freedesktop.org's HAL. It is already quite functional in the backend, and it's already affecting visible KDE components. Read on for more...

Solid is an API for accessing device information such as available disks or networks. It does not deal with device drivers, leaving that to the OS. It does not deal with low level device information, leaving that to already existing, and very good tools such as HAL or other underlying subsystems.

Solid was introduced to the KDE world at large at aKademy, and the first signs of work were the appearance of its website. Since then it has mostly flown under the radar, with the odd mention here and there thanks to Danny Allen's Commit-Digests, or the occasional blog posting on the planet. If you visit the #solid channel at irc.kde.org (freenode), you'll find that it's sparsely populated, and mostly quiet. But appearances can be deceiving...

Solid's code base has been growing steadily for the last year and a half, with many parts of it becoming stable and usable already. In fact, things like Dolphin and the File Dialog are already using it in places to do removable storage management.

Internally, Solid is broken up into a variety of hardware domains, with each domain operating somewhat independently. For example:

One of the long term problems with UNIX ease of use has been access to removable devices. Many solutions have come up in the past, including kernel-based automounters (Mandrake of several years ago). HAL is the most recent project to tackle removable devices, and it does so quite well, but some distros still ship without, preventing across the board progress. KDE is building a generic API for removable devices so that applications don't have to know what's happening in the background. And by removable devices, I mean any removable devices, not just storage. Solid already does removable audio devices, laptop batteries and more...

Currently, the only backend supported is HAL, so removable devices will require HAL for KDE 4. Other backends for other OS's may be developed down the road, as HAL does not exist for every platform, but it should cover many of the more common UNIX platforms. One could even, if they really wanted to, write a backend that interfaced directly to the kernel.

It's not all just about removable hardware, but also about what is built into your system. Phonon uses Solid to detect available sound devices on your system, and can seamlessly switch between output devices, including hotpluggable sound devices. You may remember this from the demonstration in the Phonon article from several weeks back of switching audio devices on-the-fly. This is not just Phonon you're seeing, but also Solid providing the available device list.

There are other domains underway, including incorporating existing functionality from the NetworkManager Program into Solid so that more KDE applications can become aware of it. Most of the work will be done by a backend daemon that already handles ethernet and wireless ethernet (WiFi) connections, assuming the underlying drivers are available, and includes most forms of wireless encryption that exist. By the end of this week, VPN and dialup support should be available. We'll have to see what happens to KPPP as a result of this progress, but programs like this still have a role to play. The goal of this network work is to allow KDE applications to have a real implementation of an "offline mode", so you can read your mail, etc. without programs complaining about a lack of net connections. Will Stephenson suggests that cellular connections could automatically disconnect when no program is using the network, and so forth, and many other valuable applications will emerge as KDE 4 develops.

A third domain is Power Management, which is one of those areas on the Desktop where each distribution has done their own thing. Hopefully distributions featuring KDE 4 will present a more unified Power Manager interface. This domain presents an API that lets you configure and tune power and resource consumption of various elements within your system. This one is once again powered by HAL.

And very recently, Bluetooth support has been added. While it's still very young, it already allows device detection and connection. This is one I couldn't test, as I do not own a bluetooth device. :)

There is a very nice command line utility to interface with the various elements of Solid's API from scripts, or if you just want some manual control over your hardware. This program is called 'solidshell' and ships alongside the Solid libraries as part of kdelibs. An example command would be solidshell network set wireless disabled or solidshell hardware list details which will query HAL and return a list of all sorts of devices alongside some information about their capabilities. For those of you that have KDE 4 installed and want to test this feature, solidshell --commands is your friend.

Down the road, support for more devices within the Solid framework is definitely possible. I can imagine support for using additional input devices on-the-fly, or using Solid to detect changes in display (new monitor plugged in) so that it becomes easier to deal with X display settings on the fly. These domains are not yet a part of Solid, but with this architecture, they should be possible down the road.

How to help:

Kevin Ottens (aka "ervin"), the Solid lead developer, has a few suggestions for those willing to help Solid progress. The first thing he suggests is to use the API - the more applications that take advantage of Solid's features, the more complete the API will become. Also for developers, if you wish to extend Solid to other domains, or add backends for systems that are not supported by HAL, help is welcome.

Other ways to help include testing hardware, and reporting problems. Especially useful are reports of hardware that for some reason works in KDE 3.x, but doesn't work with Solid/HAL in KDE 4. If you find one of these, I'm sure the Solid developers would like to hear about it.

Editorial Aside:

While there has been some adoption of HAL (a freedesktop.org project for hardware detection and more) by distributions, each distribution has (generally) in the past had their own implementation of hardware configuration and control interfaces. KDE of old had a policy of leaving hardware to the distributions, so this situation is partially one of our own making. However with the advent of HAL and now Solid, it is hoped that a more uniform system of hardware config and control will arise. Therefore, the KDE developers request that as distributions take a look at KDE 4 for adoption, they consider migrating their in-house hardware control solutions upstream into Solid, thereby benefitting all KDE users and making user support easier to provide by the community. The ongoing work of the distributions to make hardware better for their users is always appreciated - hopefully these new KDE technologies will facilitate collaboration.

Until next time...