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)
(Created page with "= Introduction = This guide attempts to document the ideal situation for porting Nemo to new hardware targets. = Architecture = Generally speaking, like Mer and Nemo in genera…") |
(→TODO) |
||
| (10 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 | + | * This daemon then exposes this information to MW via properties |
| − | * The mw monitors/consumes these | + | * The mw monitors/consumes these properties as required |
= Properties = | = Properties = | ||
| Line 34: | Line 36: | ||
* Environment.IsDark | * Environment.IsDark | ||
* Environment.IsBright | * Environment.IsBright | ||
| + | |||
| + | Other properties we probably need to cover: | ||
| + | * Location based (position) stuff - geoclue, ??? | ||
= Implementation plan = | = Implementation plan = | ||
| Line 44: | 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 49: | Line 55: | ||
On the middleware side: | On the middleware side: | ||
| − | * Neuter qmsystem/Mobility into talking to our | + | * 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 55: | Line 63: | ||
Things yet to cover. | Things yet to cover. | ||
| − | |||
* 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? | + | * 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?
- Seems sensorfw indeed works on the idea of plugins, plus a configuration to tell it what to load.
