Revision as of 21:32, 28 August 2012

Introduction

This guide attempts to document the ideal situation for porting Nemo to new hardware targets.

This is a work in progress, and potentially all wrong. YMMV. Feel free to send flames and feedback to w00t.

Architecture

Generally speaking, like Mer and Nemo in general, we need a layered approach to portability.

• At the bottom, we need hardware dependent daemon(s) which read data for that specific hardware target.
• This daemon then exposes this information to MW via properties
• The mw monitors/consumes these properties as required

Properties

http://maemo.gitorious.org/maemo-af/contextkit/blobs/master/spec/core.context

Interesting properties that should be provided by a hardware adaptation daemon:

• Screen.TopEdge (device orientation)
• Screen.IsCovered
• Screen.Blanked (TODO: is this "screen is turned off"?)

• Position.Stable
• Position.Shaky
• Position.IsFlat

• Battery.ChargePercentage
• Battery.ChargeBars
• Battery.OnBattery
• Battery.LowBattery
• Battery.IsCharging
• Battery.TimeUntilLow
• Battery.TimeUntilFull

• Environment.IsDark
• Environment.IsBright

Other properties we probably need to cover:

• Location based (position) stuff - geoclue, ???

Implementation plan

On the hardware side:

• Nokia devices first, as they're an easy target, and most things already work.
  • A good idea would be to look into mce/dsme, and turning them into our Nokia "adaptation daemons".
  • ExoPC is probably a good target next
    • upower for charger info
    • orientation info is available somewhere in Qt Mobility afaik, but currently nonfunctional
      • Problem is likely in sensorfw...
    • Accelerometer data may be trickier, at least in Lenovo S10-3t that doesn't work
    • Brightness sensor is present, and somehow already controls screen brightness (and never turns it up...)

On the middleware side:

• Remove duplicated qmsystem APIs
• Neuter qmsystem/Mobility into talking to our properties only
• Longer term, look at exposing more Mobility APIs (for things like battery information), introduce/stabilize in qmsystem, then propose upstream

TODO

Things yet to cover.

• Can contextkit provide subscription notifications, so e.g. we can turn expensive sensors off? (assuming we have any...) - fairly sure it can
• Connman portability: modem drivers, properties, etc?
• Bluetooth info: does it belong to our hardware abstraction?
• Screen lock: how does that factor into things? mce tells sysuid (soon lipstick) to turn lock on, but should it? - no, but where does it belong?
• How does sensorfw fit into this? If it supports plugins, then it can potentially already cover a lot for us?
  • Seems sensorfw indeed works on the idea of plugins, plus a configuration to tell it what to load.
    • Detection of configuration based on boardname would be quite handy?
    • Battery "sensor" addition, and we're halfway there?