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

[Dot Stories]

URL: http://dot.kde.org/1177385913/

From: Troy Unrau <troy at kde.org>
Dept: kde-and-hal-living-together
Date: Monday 23/Apr/2007, @20:38

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 [http://solid.kde.org/] hopes to fix that for KDE 4.
In many ways, Solid is like Phonon [http://phonon.kde.org/], in that
it's a Qt/KDE style API around already existing components at the lower
level, such as freedesktop.org's HAL
[http://freedesktop.org/wiki/Software_2fhal].  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
[http://solid.kde.org].  Since then it has mostly flown under the radar,
with the odd mention here and there thanks to Danny Allen's Commit
Digests [http://commit-digest.org], or the occasional blog posting on
the planet [http://planetkde.org].  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 seemlessly switch between types of
output devices, including hotpluggable sound devices.  You may remember
this from the demonstration in the Phonon article
[http://dot.kde.org/1170773239/] 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 Off-line
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 distro has done their own thing.  Hopefully
distros 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 libs 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 --comands is your friend.

     Down the road, support for more devices within the Solid framework
is definitely possible.  I can conceive of support for using additional
input devices on the fly, or using Solid to detect changes in display
(new monitor plugged in) so that it become 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 along.  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 distro adoption of HAL, a freedesktop.org
project for hardware detection and more, each distro 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
distros, 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 distros 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
distros to make hardware better for their users is always appreciated -
hopefully these new KDE technologies will facilitate collaboration.

     Until next time...