• MicroHal

MicroHal

Abstract

MicroHAL is about creating an lightweight and easy to use hardware abstraction layer for mobile devices. The basic idea is to create a defined (D)Bus API for the most common interfaces and reference implementations of the hardware control backend(s) that are accessed by this API. Additional tasks which should be addressed are a highlevel library to provide easy hardware access from applications and access control issues.

The small Picture

http://linuxtogo.org/~florian/micro-hal.png

Some more details

The major advantage of the bus API centered design is its flexibility: There is no need for the communication peers to know each other and how many processes actually participate in the communication. The implementation of the backends is completely transparent to the frontend processes - even better they just need to support a communication subset they need. In the same way you can have a single, monolitic backend or a set of specialized tools implementing the MicroHAL layer.

One way to go would be to have a more static API design so that you need to add a new feature to the API. One advantage of this approach is that it is easy to understand even for less experienced developers and we really want to encourage our developers to integrate their applications well. Another advantage is that this is fast as there is always a direct mapping and no dynamic lookups.

Two steps ahead

If the implementation of the backends - how do we call them - "lowlevel adaptors"? ... is made correctly much of the code can be shared between multiple devices or the adaptor is advanced enough to do the right thing on multiple devices. For this purpose we should be able to adapt quite some existing code from ODevice and bits like minilite and gpe-conf. For a conveient use the different application developoment environment should provide specific libraries to access the bus API. This makes sure the application developers do not need to care about what is going on under the hood - they just get events in a way they are used to or set whatever they want and the device does so.

What do we want to cover?

• Device access control
• Hardware configuration
  • Network device configuration
    • up/down
    • renew dhcp
    • wlan power settings
• Removable devices (to some limited extend)
  • PCMCIA interface
  • Storage cards
  • Backlight control
    • on/off
    • (auto)dimming
    • set to percentage
    • lcd on/off
    • External attached devices (e.g. Keyboard)

• IrDa setup, on, off

• Sound
  • mute/unmute
  • set to percentage
• Power management
  • freeze background processes to save power (dyntick, maemo task-navigator)
  • Use one control from multiple frontends.
  • Provide system status information
    • Memory and storage space consumption
    • Current configuration settings
• Bluetooth (pin, peers, init, on, off)
• Screen orientation and cover sensors
• GSM/UMTS modem power and status control, signal status, initialisation?
• Keyboard presence
• Pointer device presence and type

References

http://fl0rian.wordpress.com/2006/05/29/platform-integration-for-mobile-linux-devices/

Device interface API drafts

DBus API

Screen

Backlight: org.device.screen.backlight

Light Sensor: org.device.screen.lightsensor

Todo: Frequent changes. Can we turn on emission of signal on first registered listener?

Screen Rotation: org.device.screen.status

Todo: Multiple screens, already present on some ebook readers and cellphones.

Power

Battery status: org.device.battery.status

Todo: Define available types.

Todo: Interface to request all available services.