UseCases

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.



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

Name: current

Name: charger

Name: temperature

Name: swap

Name: usb client mode

Name: audio routing

Name: offline mode

Name: activity

Name: inactivity

Name: hw key usage


Open or Rejected Use Cases

Name: usb host mode

Name: low memory

Name: keyboards

Name: restore a backup