Platform integration for mobile linux devices May 29, 2006Posted 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.