jump to navigation

Platform integration for mobile linux devices May 29, 2006

Posted by Florian in GPE, Maemo.

The Maemo platform for the Nokia 770 devices is a good example for a tight hardware + software integration on a mobile Linux device. It gives us a good impression about what we need to do to make Open Source rock on all the nice existing and future gadgets becoming more and more common in our daily life. One of the basic principles for a good integration of hardware and software is that the software running on a device needs to be aware of all features present on the target hardware. Exposing these hardware features to the user needs to be done in a way making it as easy to use for unexperienced users and convenient to use with the end user software.

There are still several approaches for solutions to solve these integration tasks – software like HAL or ODevice (Opie), but there are conceptual problems with these. HAL has its focus on PC devices, is big and does not really cover the needs of mobile devices. Device is quite specialized for Opie and provides a library interface only. The needs for a solution all affected platforms and software environments can benefit from are slightly different:

  • Independence from the target platform.
  • Low memory and CPU usage.
  • Implementation independent API.
  • Low latency
  • Access control
  • Simple to understand for developers.

bindings for various programming languages. Access control is possible as wellThe current software stack for the Nokia 770 provides a part of these features already and shows us how things may be implemented and which technologies might be used, but it lacks a proper interface specification, documentation and does not even cover all hardware features on the 770 itself. This implementation is using DBus for communication which is used for similar tasks in other environments as well. It fulfills most of the API and communication aspects pretty well – it is fast, lightweight and there are DBus and it is already used in GPE and therefore it does not add additional dependencies to a GPE filesystem. Applications which need to get information from kernel interfaces or other lowlevel subsystems can just hook up to the bus and get updated information whenever necessary without the need to query some interface frequently. For example the battery status display does not need to care about the kernel interface for battery management and poll data from it – the system software sends information about battery status changes via DBus where this information can be used by all applications which need it.

The central part of a platform integration definition would be the specification of a DBus API and a separation into required and optional features. For the devices there will be the need to implement backends for the desired functionality such as data providers for switches and sensors or control entities for power management and screen backlight brightness. Having a communication bus structure it is not relevant how the backends look like – they might be a set of small tools, a monolitic thingy or just an emulating piece
of software. It would be even possible for hardware vendors to supply closed modules… not that this desireable, but it is possible. A major share of these backends can be used for multiple devices such as an implementation of backlight control using the standard sysfs interface of Linux 2.6. For the GUI environments you need to implement the controls and status displays only once – they are supposed to communicate with the backends through the defined API and should just work on any device with the functional backend in place. With such a framework we would gain a maximum degree of flexibility and maintainability. Most of the device specific adaption would be part of this framework and implemented in one piece of software only. Just to have a comparison: In a current GPE image there are three applications which implement backlight control.
The current plan is to start collecting proposals for interfaces in some wiki. After having a comprehensive set of APIs we can start to make a proper specification for it and implement some modules and do tests if the theoetical work meets the requirement of the real world.

One thing to start with might be this collection of things a device integration may cover which is located here:


So far this just reflects my personal view on the problem, but i would be really interested in additional opinions or suggestions for different approaches.


1. Michael 'Mickey' Lauer - May 29, 2006

As one of the Opie core developers I worked a lot on our ODevice HAL and I fully agree with your points.

The worst thing is the duplicated work we are doing here. If we can agree to a sane API then I’d be happy to migrate Opie from ODevice to that new framework.

I support this proposal and will contribute to it.

2. Lorn Potter - May 29, 2006

As one of the Opie core developers, I can also agree to a new device abstraction. You might also add modem control lines to the device control framework. Phones can control much of the hardware through AT commands.

3. Marcos Japa - May 30, 2006

I have no idea when or how to do this. But count me in to do something like GPE apps on SymbianOS. Perhaps not this summer/winter. :)

4. Luca De Cicco (aka bedboi) - May 30, 2006

Yep, i totally agree with this, i had this idea at least one year ago…The problem is sharing a common interface, the implementation issues shouldn’t be that hard.

The difficult part is having a really good power managment controller built on top of the device framework. My original idea was (don’t flame me please) to implement a frontend (not in the sense of a GUI) for each hardware piece in a generic framework. I still have some proof of concept code i wrote one year ago (Sun Jun 26 15:18:17 2005)

The main idea is this:

struct device *foo;

foo = device_new();
device_init(foo, foo_on,foo_off, foo_gui_frontend);

/* Define an extension to the generic device “foo” */
foo_extension = foo_new();

device_set_extension(foo,(gpointer *)foo_ext);
/* Turn on foo */
/* Check if foo is on */
printf(“Foo is on\n”);


If someone is interested in the code please shout :)


5. Michael Lauer - Freelancer / Collaboration Launch on PhoneServer and DeviceDaemon - November 26, 2007

[…] the next couple of days I will add some initial thoughts into the freesmartphone.org wiki. Please see Florian’s blog post here and this wiki page for some more details. Right now it’s not even clear whether we need […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: