View source for FSO Resources
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to FSO Resources.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to FSO Resources.
Here goes some introductory text shamelessly borrowed from FSO specs.
One of the most important aspects of middleware for mobile devices is saving energy. To do this, the system needs to make sure that peripherals are only powered when they are actually in use by at least one application. In order to support multiple concurrent applications, it is not possible to leave peripheral control up to individual applications — otherwise one application could shut down e.g. a GPS receiver, while another application still wants to access it.
FSO introduces the concept of resources. A resource is a high-level entity with a name and a state. The name is used to identify a resource (e.g. WiFi), the state is describing its condition (e.g. enabled). It is important to understand that a resource not necessarily correlates to a peripheral device. Although enabling a resource such as Bluetooth most likely has the consequence of powering up a device, there may as well be more to it, such as launching a low level device handling services or allocating related resources.
Once in a while, reference counted handling of resources gets in your way, for example when you are running legacy applications or want to configure or debug peripherals. In that case it may become necessary for a resource to be always enabled or always disabled. While not recommended, it is possible to switch from automatic resource control to manual control by calling SetResourcePolicy. Valid values are auto (which is the default on system startup), enabled, and disabled.
Unless this resource is enabled you've no eth0 and wifi module is completely unpowered.
While this resource is kept the display won't be blanked.
A test resource
You need to have this resource requested to have bluetooth module powered.
The same for GSM modem
Default rules.yaml checks for this resource to disable automatic suspend when it's requested.
Same idea as WiFi/Bluetooth
It would be nice to have a command to list the current state of all resources. Unfortunately, such an utility is yet to be written. See [1]. First take on implementing the desired functionality can already be downloaded from [2].
With the help of SHR Settings or an appropriate mdbus call (example: mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Bluetooth enabled
) you set resource policy to "enabled". Do not forget that way you'll lose power since it will leave the corresponding device powered all the time.
Use the fsoraw
(created per Joerg's request [3]) utility. With it you can automatically request the necessary resource before starting a command and release it when it's finished (this will happen even if it was killed with SIGKILL).
Typical basic use:
fsoraw -r CPU,Display mokomaze
Start a game (or any other app) and avoid auto-suspend and display-blank
Especially recommended for WiFi since due to the bugs in the firmware and the driver full power-cycle of the module is often advantageous.
Example command (works for open, WEP and WPA/WPA2 networks, automatically determining the network it can connect to, just add all the networks you use to the config):
fsoraw -r WiFi -- wpa_supplicant -ieth0 -Dwext -c/etc/wpa_supplicant/wpa_supplicant.conf
Bluetooth scan for nearby devices example:
fsoraw -r Bluetooth -- bash -c "sleep 1; hcitool scan"