User:Daltona
From Openmoko
(Difference between revisions)
(Added configuration management ideas) |
|||
| (5 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| + | == Application that I've developed == | ||
| + | * [[Mokostat]] An application to monitor various status of the openmoko phone | ||
| + | * [[MokoFEM]] A Field Engineering Mode application for openmoko | ||
| + | |||
== Configuration Ideas == | == Configuration Ideas == | ||
There are my ideas or to-do list of enhencements I'd like to see / actually implement | There are my ideas or to-do list of enhencements I'd like to see / actually implement | ||
| Line 10: | Line 14: | ||
=== neod === | === neod === | ||
| − | * | + | * neod would listen to all configuration keys and will actually activate / deactivate the HW modules according to key modifications. |
| − | the HW modules according to key modifications. | + | * neod will set some status keys in order to reflect the current state for all other components |
| − | * neod will set some status keys in order to reflect the current state for all other | + | * For the button click sound and touch panel click sound, two gconf keys monitored by neod would allow to actually send the pulseaudio play sound command or not according to the key value. The preference application would just have to change these keys values in order to configure the sound/vibrator activation. |
| − | components | + | |
| − | * For the button click sound and touch panel click sound, two gconf keys monitored | + | |
| − | by neod would allow to actually send the pulseaudio play sound command or not according | + | |
| − | to the key value. The preference application would just have to change these keys values | + | |
| − | in order to configure the sound/vibrator activation. | + | |
=== Init scripts === | === Init scripts === | ||
| − | * During power-up the init scripts would read the gconf config keys in order to | + | * During power-up the init scripts would read the gconf config keys in order to condition the power-up of a specific module in order to keep the power state accross reboot / crashes. It would also set the state keys in order to reflect the actual state. |
| − | condition the power-up of a specific module in order to keep the power state accross | + | |
| − | reboot / crashes. It would also set the state keys in order to reflect the actual state. | + | |
=== Other Components === | === Other Components === | ||
| − | * Components that display the status of the HW modules should also listen to status | + | * Components that display the status of the HW modules should also listen to status keys changes in order to reflect the correct status. i.e. panel applets. |
| − | keys changes in order to reflect the correct status. i.e. panel applets. | + | * Components that allows to change the state will actually change the gconf config key value that will notify neod to act and will have the confirmation of the change by looking at the status key. |
| − | * Components that allows to change the state will actually change the gconf config | + | |
| − | key value that will notify neod to act and will have the confirmation of the change by | + | == Misc Ideas / TODO == |
| − | looking at the status key. | + | * A new panel applet showing an handset when a call is active. |
| + | * A new panel applet to notify of incoming SMS, Mails, etc... | ||
Latest revision as of 15:52, 14 November 2007
Contents |
[edit] Application that I've developed
- Mokostat An application to monitor various status of the openmoko phone
- MokoFEM A Field Engineering Mode application for openmoko
[edit] Configuration Ideas
There are my ideas or to-do list of enhencements I'd like to see / actually implement in the configuration and power management area.
[edit] Gconf
Use gconf to store all configuration parameters
- Power state/config of GSM
- Power state/config of GPS
- Power state/config of BT
[edit] neod
- neod would listen to all configuration keys and will actually activate / deactivate the HW modules according to key modifications.
- neod will set some status keys in order to reflect the current state for all other components
- For the button click sound and touch panel click sound, two gconf keys monitored by neod would allow to actually send the pulseaudio play sound command or not according to the key value. The preference application would just have to change these keys values in order to configure the sound/vibrator activation.
[edit] Init scripts
- During power-up the init scripts would read the gconf config keys in order to condition the power-up of a specific module in order to keep the power state accross reboot / crashes. It would also set the state keys in order to reflect the actual state.
[edit] Other Components
- Components that display the status of the HW modules should also listen to status keys changes in order to reflect the correct status. i.e. panel applets.
- Components that allows to change the state will actually change the gconf config key value that will notify neod to act and will have the confirmation of the change by looking at the status key.
[edit] Misc Ideas / TODO
- A new panel applet showing an handset when a call is active.
- A new panel applet to notify of incoming SMS, Mails, etc...
