The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)


Nemo/Porting

From Mer Wiki
< Nemo(Difference between revisions)
Jump to: navigation, search
(Properties)
(TODO)
 
(8 intermediate revisions by one user not shown)
Line 2: Line 2:
  
 
This guide attempts to document the ideal situation for porting Nemo to new hardware targets.
 
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 =
 
= Architecture =
Line 8: Line 10:
  
 
* At the bottom, we need hardware dependent daemon(s) which read data for that specific hardware target.
 
* 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 contextkit properties
+
* This daemon then exposes this information to MW via properties
* The mw monitors/consumes these contextkit properties as required
+
* The mw monitors/consumes these properties as required
  
 
= Properties =
 
= Properties =
Line 47: Line 49:
 
*** upower for charger info
 
*** upower for charger info
 
*** orientation info is available somewhere in Qt Mobility afaik, but currently nonfunctional
 
*** 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
 
*** 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...)
 
*** Brightness sensor is present, and somehow already controls screen brightness (and never turns it up...)
Line 52: Line 55:
 
On the middleware side:
 
On the middleware side:
  
* Neuter qmsystem/Mobility into talking to our contextkit properties only
+
* 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 =
 
= TODO =
Line 58: Line 63:
 
Things yet to cover.
 
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?
 
* Connman portability: modem drivers, properties, etc?
 
* Bluetooth info: does it belong to our hardware abstraction?
 
* 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?
 
* 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?

Latest revision as of 19:53, 1 September 2012

Contents

[edit] 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.

[edit] 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

[edit] 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, ???

[edit] 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

[edit] TODO

Things yet to cover.

  • 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?
Personal tools