Use Cases for OHM
On a mobile machine
Mark has a new laptop with spiffy new C and P states to enable better battery life while hacking (mostly reading and editing) on the airplane. Mark wants to be able to tell the platform that "I'm on the airplane" so don't try to bring up IR, BT or 802.11, also please shut off audio, and USB, dim my screen, change the time it takes to shut off my back light.
Later in the flight, Mark wants to show is buddies sitting next to him a presentation he has been working on. He would like it very much if the platform would figure out that its running the presentation program in full screen mode and it should stop turning off the back light while the full screen presentation is running.
Later after finishing getting nasty feedback from his buds, he wants to listen to some media files (org or mp3), at this point Mark wants his system to understand the decode and play back latency constraints media play back have and adjust the On-demand governor to not violate those constraints, and turns on the audio subsystem.
Mark also would like it very much if the system could figure out how to configure the PM options of the system in the case of all three things happening at the same time (playing back media, while in full screen presentation mode, on an airplane) and it do the right things to maximize his battery life.
On a home machine
Alice is logged in and starts a distribution upgrade and walks away, screen saver kicks in. Bob fast-user-switches to his account, does some work and clicks shutdown.
ATM-> machine will suspend in middle of distribution upgrade
Desired behaviour: the procedure (running as root) should inhibit suspend behavior until it is finished (probably with some sort of polling method). When Bob tries to suspend, he should be informed that the dist-upgrade (by Alice) is in process and the suspend could not be done at this time (and possibly be offered the option to suspend when it has)
Bob is logged in and starts a large download, epiphany makes request to ohm that the machine is not shutdown for the duration of the download. Alice fast-user-switches to her account, does some stuff and clicks shutdown Alice is informed that Bob is in the process of a large download, howver as she has admin rights she can override Bob's request and shuts the machine down
System is configured to suspend on lid close. User clicks 'shutdown' somewhere on the desktop/menu or presses the power button. Then he immediately closes the lid and walks away. Next time he opens the lid, the system resumes and continues the shutdown process. Or even worse, system runs out of battery.
Proper behaviour: System shutdown must not be disturbed by a system sleep, system has to shut down in any case.
Embedded System
Video player is started and requests processor core low latancy behaviour. The increase in cpu speed is approved as battery level is not low. However the processor core is nearly out of it operating temp range, so the request is denied.
- In the latest temperature probe readings, the board temperature over the battery is getting too hot, so a number of components are sent to low power modes.
The backlight is by far the biggest power consumer on the device. When battery voltage gets low, the power draw from maximum backlight brightness can cause the core voltages to fall too low causing the device to crash. We therefore have to limit the backlight intensity at low battery.
The device shouldn't suspend if you were playing music and the lid was closed but the screen should still be blanked (e.g. even if video was playing). Ideally, we shouldn't be decoding the video any more, just audio.
Currently, in Nokia 770 and N800, there is a daemon that handles automatical mounting and unmounting of memory cards depending on memory card cover and USB cable states. Maybe this could be implemented as OHM plugin in the future.
Devices should be aware of plugable audio hardware. i.e. user plugs in headphones and audio is then routed to the headphones instead of speaker. The volume slider should also now control the headphone volume instead of the speaker volume. Similarly, if the user were to plug in a headset it would be nice to associate it with a VOIP call and optionally start a VOIP app.
Handhelds may have several alternative input methods: Bluetooth keyboard, small hardware keyboard integrated to the device, virtual keyboard usable with a stylus implemented on a touch screen, virtual keyboard usable with the fingers. Switching between these could be done with OHM's help. When HW keyboard is used, the virtual keyboard should be hidden but it could still use e.g. a word prediction UI. The finger-usable virtual keyboard could be launched automatically when large area of touch screen is pressed down (as in the Nokia N800). In case of an external keyboard, the screen should be kept lit when typing (not only when pressing the touch screen).
Server
From OHM workshop
Example use cases based on input/output
Name: battery
- input:
- battery state goes critically low
- output:
- take a snapshot of the system
- shutdown
Name: current
- input:
current supply goes critically low (<100mA over device drain)
- output:
- Disable USB host
Name: charger
- initial state:
- device is off
- input:
- boot reason charger connected
- output:
- tell upstart to go charging run level
Name: temperature
- input:
- temperature goes above high threshold
- output:
- signal session
- shutdown
Name: swap
- initial state:
- formated swap available
- input:
- low ram memory
- output:
- enable swap
Name: usb client mode
- initial state:
- usb cable disconnected
- input:
- usb cable connected - client mode
- device is not locked
- output:
- switch swap off
- unmount mmc and what can be unmounted
- inhibit mounting
- tell file storage module to use unmounted file systems
Name: audio routing
- initial state:
- audio headset disconnected
- input:
- audio headset connected
- detect headset type (microphone or not)
- output:
- route audio to headset
- switch to use headset microphone instead internal one
- exception: alarm should still use speakers
- exception: fm radio can request to use speakers
Name: offline mode
- initial state:
- device is in normal mode
- input:
- user switches device to offline mode
- get system preferences what to shut off
- output:
- signal radio (wifi/bt/gsm) controlling deamons to switch off the device
- bt via hal addon
- save the state for application queries
Name: activity
- initial state:
- device is inactive
- input:
- input from /dev/input
- usb/network cable
- custom switches
- charger (dis)connected
- sensors
- headset jack
- mmc card plugin
- output:
- send (active) signal to system bus
- save the state for future queries
- start timer
Name: inactivity
- initial state:
- device is active
- input:
- timer restart on same input as above
- inactivity timer has expired
- output:
- send (inactive) signal to system bus
- save the state for future queries
- stop timer
Name: hw key usage
- initial state:
- device is active
- input:
- device mode
- hw state (e.g. mechanical key lock)
- output:
- change function of the keys
Open or Rejected Use Cases
Name: usb host mode
- initial state:
- usb cable disconnected
- input:
- usb cable connected - host mode / mass storage
- filesytem info available
- output:
- mount filesystems
- todo: is ohm needed to handle this
Name: low memory
- input:
- low ram memory
- output:
- kill applications
- todo: is ohm needed to handle this
Name: keyboards
- initial state:
- onscreen keyboard in use
- input:
- bt keyboard connected
- get system preferences of keyboard priority
- output:
- switch bt keyboard
- hide onscreen keyboard
- todo: is ohm needed to handle this
Name: restore a backup
- initial state:
- device is active
- input:
- request from user to do restore
- output:
- go to restore mode

