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...

Comments

by andre (not verified)

What I like the most about KDE is the clean and lean plattform. You don't have to install 20 packages when you want a tool to get run. KDE application developers build on the ke plattform and don't try to infect you with dependencies on their favourite packages.

by A Debian User (not verified)

Of course, many people view that as a bad thing. I've read many comments by people who don't use KDE as their DE, and refuse to use any KDE apps at all because they claim they don't want to install the "mess that is the KDE libs." Of course, I think that's absurd, but there are people who think that way. :)

by kollum (not verified)

Yes, and most of these people are runing mono, ( and often java too ) to get beagle indexing, and they don't complain about the mess that mono (java) is :(

by Andre (not verified)

Sure, I know this is also something of a distro issue, but I would really like to see better support for HAL in the future. Currently, I can only use an outdated version of HAL with KDE 3, which is annoying in terms of package management. Is HAL really changing that much between versions?

by superstoned (not verified)

thanx to solid, this will be easier to do. Now, you have to patch and rebuild ALL KDE 3 applications using HAL, in KDE 4, just change solid, and all apps continue to work with the newer HAL. so it is much more likely that KDE will support the latest HAL!

by aha (not verified)

I like the way K3B and KPlayer autodetect devices, and also when you insert a disk they recognize it. I hope they will be able to port that functionality to KDE4 and Solid, because it's really great!

by André (not verified)

AFAIK, it is the whole point of Solid to make this kind of behaviour easy to accomplish for applications, so you can bet that you will see this (and more) in KDE 4 as well. Not necessarily 4.0 though.

by Ask (not verified)

Really, kplayer version 6.0 onwards does an excellent job of detecting
removable devices, like video/audio cds. The way it handles these
devices and lists the tracks therin is simply brilliant. Other programs
have a lot to learn from the way kplayer has been designed

-ask