April 2011. After gave a try to OM2008.9 and SHR, I finally switched distribution on my OpenMoko FreeRunner: now I'm using Debian. The rationale is that every distribution except Debian is a nightmare about missing packages, mixing different sources and environments (OpenEmbedded, FSO, Ångström, etc.), lacking of man-power, abandoned software, missing functionalities (WiFi!), and so on.

Debian instead is a rock-solid distribution and some specific OpenMoko packages are in Debian or are debianized (kernel, FOS, etc.). I use the OpenMoko mainly as a smart device with GPS and GPRS functionality; traditional phone usage is not my focus. So Debian is the right way.

• Debian On Free Runner
• Debian FSO Team
• Smartphones-userland mailing list
• pkg-fso-maint mailing list (FSO Debian mantainers)
• #openmoko-debian Freenode IRC
• #openmoko-cdevel Freenode IRC

I read the instructions on the OpenMoko Wiki and on to Debian Wiki, unfortunately the installer script (install.sh) is extremely bugged, so I had to edit it manually and finally I resorted to the following choices:

• The microSD (4 Gb) was partitioned with a primary ext3 partition and a 128 Mb swap.
• I installed the Qi boot loader, so booting from ext3 on the microSD is possible (and the default choice).

The first try was to have a small vfat partition hosting the kernel, so the U-Boot boot loader will suffice. Unfortunately the install.sh is so brain-damaged that it was impossible.

Installing the Qi boot loader was simple: download the image, connect the FreeRunner to the USB cable to a Linux box, enter the NOR menu an and run the following command on the Linux box:

dfu-util -a u-boot -R -D qi-s3c2442-master_c38b062a609f1442.udfu

If the origina image is missing, here it is a copy: qi-s3c2442.udf.gz.

I patched the install.sh script to fix the partition size calculation and to feed the u command to fdisk, to change units to cylinders. Here it is my install.sh.

Then I run the command:

SD_DEVICE=/dev/mmcblk0 SD_SWAP_SIZE=128 QI=true QI_VERBOSE_BOOT=true ./install.sh partition

When the partition worked as expcted, I run:

SD_DEVICE=/dev/mmcblk0 SD_SWAP_SIZE=128 QI=true QI_VERBOSE_BOOT=true ROOT_PASSWORD=MySecret \
    ./install.sh all

The install.sh crashed with the all target, so I had to run it again and again, specifying the various stages in order (apt, fso, etc.) and solving several dependencies problems manually. See ./install.sh –help on how to run the task stage and how to select the various task components (AUDIO, COM, GPS, NET, …). Here it is an example:

TASKS="NET,WIFI,UTILS" SD_DEVICE=/dev/mmcblk0 SD_SWAP_SIZE=128 \
    QI=true QI_VERBOSE_BOOT=true ROOT_PASSWORD=MySecret \
    ./install.sh tasks

I also had to manually enter the chroot environment several times to complete the installation of Debian packages. So it is definitely required a good Debian sysadmin knowledge to succeed in the installation.

The big problem is that I was not able to install the zhone packages (telephony applications), due conflicts with new versions of libevas and other packages. So no phone calls, address book, SMS, etc. The Zhone project is not completely dead, but the Debian package is very old: as SVN snpashot dated 2009-06-10.

I selected the following packages to have a decent user interface:

• matchbox-window-manager
• matchbox-keyboard
• matchbox-panel
• openmoko-panel-plugin

Matchbox is a lightweigth Window Manager. The project seems dead (last 1.2 release March 2007). But it is still usable and packaged in Debian.

The Matchbox features that I use are:

• A Window Manager with windows decorations, buttons, etc.
• A simple task switcher, embedded int a window decoration button.
• A virtual keyboard. Not very finger friendly, it requires a stilus.
• A desktop panel to host systray icons, a clock and an application menu.
• It is themable. I made a mixed finger/stilus theme.

The openmoko-panel-plugin accomodates several icons into the systray, where you can control the battery, WiFi, GSM, etc. It also offer a menu which appears when you press the OpenMoko power button.

Customizations are saved into ~/.themes/ (the Matchbox theme), ~/.applications/ (the content of application menu), ~/.panel-pluginrc (the openmoko-panel-plugin).

The desktop appearance is controlled by ~/.xsession, here it is mine:

#!/bin/sh

# Load X resource (Xterm colors, etc.)
xrdb .Xresources
# We use matchbox-panel instead of trayer.
# Don't make the panel too high, otherwise openmoko-panel-plugin
# cannot accomodate the icons, and will crash.
matchbox-panel --size 36 --orientation south --no-menu --no-session \
    --default-apps mb-applet-clock,mb-applet-menu-launcher &
# Fill the system tray with some OpenMoko controls.
openmoko-panel-plugin &
# Some applications to start automatically.
xli -onroot -quiet /root/Documents/Pictures/olimpia.jpg &
#xterm &
# Start a Window Manager.
exec matchbox-window-manager -theme bigmenu -use_titlebar yes -use_cursor no

I had to fix manually the folowing issues:

• Reboot does not work with the default power-button menu configuration. I had to set rebootexternal = True in .panel-pluginrc.
• I added confirmation for reboot and shutdown to the power-button menu.
• Documentation for .panel-pluginrc does not exists, see the source code of the Buttons module /usr/share/pyshared/panelplugin/Buttons.py.

October 2011 update. The FSO project provides an abstraction middleware for smarphones, i.e. applications can ignore the details of the hardware and just ask for devices (GPS, GSM, WiFi, etc.). The framework keeps track of devices used, set power, etc. The project seems alive, but the Debian packages are lagging behind.

The FSO stack is work in progress. From the first implementation we have frameworkd (provided by the fso-frameworkd package). From the second generation, called Cornucopia, we have fsodeviced (provided by the fso-deviced package). See FSO implementations and this interesting reports from Michael Lauer.

So frameworkd is deprecated, but still needed because some modules are still not present in Cornucopia (e.g. opimd).

The package fso-gta02 installs both fso-frameworkd and fso-deviced. Because both packages provide the DBus org.freesmartphone.odeviced interface, it is disabled in frameworkd by default.

This is the chain of dependency of installed packages:

• fso-gta02
  • fso-frameworkd-gta02
    • fso-frameworkd
  • fso-deviced-openmoko
    • fso-deviced
  • fso-gsmd-openmoko
    • fso-gsmd
• mdbus2
• fsoraw
• omhacks

NOTE: do not use the mdbus command provided by fso-utils, which has a bug. Use instead mdbus2 provided by the mdbus2 package.

Check if GSM is working, and how.

The configuration file is:

• /etc/frameworkd.conf

NOTICE: Because the odeviced DBus interface is provided by the newer fsodeviced, the [odeviced] section ha disable = 1 into the configuration file.

See man fsodeviced.

The configuration file is:

• /etc/freesmartphone/conf/<platform>/fsodeviced.conf or
• /etc/freesmartphone/conf/default/fsodeviced.conf

Platform is read from /proc/cpuinfo (the line starting with Hardware, it is GTA02 on our phone). If that file is not found, the default is read instead.

The default configuration file is provided by the fso-deviced-openmoko package and it is located in /etc/freesmartphone/conf/openmoko_gta/fsodeviced.conf. There is a symbolic link:

/etc/freesmartphone/conf/GTA02 -> openmoko_gta

The configuration file is:

• /etc/freesmartphone/conf/<platform>/fsogsmd.conf or
• /etc/freesmartphone/conf/default/fsogsmd.conf

Man page says: The daemon will be started automatically by DBus, once a request is send to it; actually the daemon is started just after fsodeviced is started.

The fsogsmd implementation is capable of GSM 07.10 Multiplexing using the library libgsm0710mux, so installing the fso-abyss or the previous fso-gsm0710muxd packages is not required.

One big problem with FSO is with GPS: near all the GNU/Linux applications using a GPS will search for gpsd, a program which talks to the GPS device and provides data to applications using a socket connection. Unfortunately gpsd is not capable of power management.

FSO would like to take the GPS device for itself. replacing gpsd. FSO provides a compatibility layer called fso-gpsd for applications requiring gpsd. Unfortunately that component speaks an old version of the gpsd protocol, so it is not compatibile with newer clients (Navit, xgps, etc.).

I had to deinstall the fso-gpsd package and disable GPS management from FSO framework (/etc/frameworkd.conf), so I resort on self-made scripts to manually control the GPS power. For that I installed the fsoraw package. Here it is the script navit that I use to start Navit, it contains several hints about FSO device allocation, X.org screen saver and legacy notes about using omhacks.

I don't need to upgrade the GSM modem firmware (see flashing) because Moko11 is the latest version available. Checked with minicom (/dev/ttySAC0, 115200 8N1):

AT+CGMR
+CGMR: "GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11"

The TCP/IP connection is called GSM PDP (Packet Data Protocol) and it is handled by the FSO stack, the package providing this interface is fso-gsmd. The fsogsmd daemon actually uses pppd to make the connection and to create the ppp0 interface.

pppd is called with some default options (search ppp_options into the source files), which don't work with the ISP provider I know. Fortunately we can override the options in /etc/freesmartphone/conf/GTA02/fsogsmd.conf

# Conseder also the options ktune;proxyarp for tethering.
ppp_options = debug;115200;nodetach;modem;crtscts;hide-password;noauth;noipdefault;defaultroute;replacedefaultroute;usepeerdns;noproxyarp

There was the bug 647078 which caused this error in /var/log/fsogsmd.log:

[INFO]  PdpPppMux <>: PDP Context Status now FREE_SMARTPHONE_GSM_CONTEXT_STATUS_OUTGOING
[INFO]  PdpPppMux <>: PDP Context Status now FREE_SMARTPHONE_GSM_CONTEXT_STATUS_RELEASED
[WARN]  PdpPppMux <>: PPP quit immediately; check options and permissions.

I had to make this symlink:

/usr/lib/cornucopia -> /usr/lib/arm-linux-gnueabi/cornucopia/

This is the service provided by the package fso-gsmd and the low-level driver fso-gsmd-openmoko, which are from FSO Cornucopia implementation.

Making a TCP/IP connection uses the Packet Data Protocol interface. This is an example of DBus chat, using mdbus2 in interactive mode.

1. The GSM modem gets powered-on with RequestResource.
2. Register on the GSM network.
3. APN, login and password are entered.
4. Check PDP status and start the connection.

mdbus2 -s -i
MDBUS2> org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.RequestResource GSM
MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Network.Register
MDBUS2> org.freesmartphone.ogsmd  /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.SetCredentials internet.wind wind wind
MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.GetContextStatus
("released",{})
MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.ActivateContext
MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.GetContextStatus
("active",{})
MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.DeactivateContext
MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device  org.freesmartphone.GSM.Network.Unregister

: exiting mdbus2 (with Ctrl-D), the GSM device is released (and the power turned off), but pppd is not terminated, it remains running and consumes the log file.

The following is old stuff, superceeded by FSO Cornucopia implementation.

FSO provides a nice multiplexing of GSM/GPRS. Different aplications can talk to the GSM modem concurrently and place GSM calls while running a GPRS internet connection (bandwidth will be the bottleneck!). The GSM multiplexing is handled by the fso-gsm0710muxd package.

Clicking on the GSM icon on the panel should allow to start/stop a GPRS connection. Unfortunately I got several problems maging GPRS calls, may be simply related to the AT commands used in dialling. I was lazy on debugging, so I resorted on self-made scripts and the traditional pon/poff commands. Here it is my gprs-on script:

#!/bin/sh
# Don't use GSM multiplexer, talk directlty to the modem.
killall gsm0710muxd
om gsm power 1
poff -a
pon

The openmoko-panel-plugin has a battery applet to check battery status, force charging current to 100, 500 or 1000 mA.

There is a bug in BatteryIcon.py with kernel 2.6.29, the sysfs path to the charge current limit (self.sysUsbLimit variable) is wrong and some other bugs.

FSO gives information about the battery via the mdbus interface, here it is an example:

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/PowerSupply/battery \
    org.freesmartphone.Device.PowerSupply.GetInfo

Several input devices are predented by the kernel. Use input-events and input-kbd to get some info from that.

TSLIB_TSDEVICE=/dev/input/event1 ts_test

With input-events you can see if the buttons are working:

root@om-gta02:~# input-events /dev/input/0
/dev/input/event0
   bustype : BUS_HOST
   vendor  : 0x1
   product : 0x1
   version : 256
   name    : "gpio-keys"
   phys    : "gpio-keys/input0"
   bits ev : EV_SYN EV_KEY

waiting for events
10:17:50.191840: EV_KEY KEY_PHONE (0xa9) pressed
10:17:50.191858: EV_SYN code=0 value=0
10:17:50.440349: EV_KEY KEY_PHONE (0xa9) released
10:17:50.440365: EV_SYN code=0 value=0

root@om-gta02:/sys/class/input/event0# input-events 2
/dev/input/event2
   bustype : BUS_I2C
   vendor  : 0x0
   product : 0x0
   version : 0
   name    : "PCF50633 PMU events"
   bits ev : EV_SYN EV_KEY EV_PWR

waiting for events
10:30:07.640053: EV_KEY KEY_POWER (0x74) pressed
10:30:07.640069: EV_SYN code=0 value=0
10:30:07.760032: EV_KEY KEY_POWER (0x74) released
10:30:07.761566: EV_SYN code=0 value=0

With mdbus2 we can see that there are some devices registered (notice that DBus numbering is not the same as device numbering):

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/Input \
    org.freesmartphone.Device.Input.GetId
("aggregate")

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/Input/1 \
    org.freesmartphone.Device.Input.GetId
("PCF50633 PMU events")

We can see events happening:

mdbus2 -s -l org.freesmartphone.odeviced \
    /org/freesmartphone/Device/Input \
    org.freesmartphone.Device.Input
[SIGNAL] org.freedesktop.DBus.NameAcquired  /org/freedesktop/DBus  org.freedesktop.DBus
(":1.177")
[SIGNAL] org.freesmartphone.Device.Input.Event  /org/freesmartphone/Device/Input  :1.105
("POWER","pressed",0)
[SIGNAL] org.freesmartphone.Device.Input.Event  /org/freesmartphone/Device/Input  :1.105
("POWER","released",0)

• X.org requires an /etc/X11/xorg.conf configuration file (see below).
• Just install the fso-gta02 package to obtain all the FSO stack
• Installation from scratch should be executed via install.sh, see DebianOnFreeRunner.

During the last apt-get update/upgrade (October 2011) the udev package required a newer kernel (I was running 2.6.29). Fortunately there is a package linux-image-2.6.34-openmoko-gta02 available from pkg-fso.alioth.debian.org repository. After installing it, I had to manually update the symbolic link /boot/uImage.bin.

I noticed a 100% CPU usage by X. The problem appears as I touch the screen for the first time, the X process enter this loop (viewed with strace -p PID):

select(256, [1 3 6 8 9 10 11 12 13 14], NULL, NULL, {116, 480000}) = 1 (in [10], left {116, 479895})
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {7119, 146550002}) = 0
clock_gettime(CLOCK_MONOTONIC, {7119, 147648002}) = 0

The problem is that X detects the touch screen twice, and tries to access it in conflicting ways. To solve the problem is necessary to provide an /etc/X11/xorg.conf file (which should be installed by the install.sh script). This is mine:

# Xorg configuration for an Openmoko FreeRunner

Section "Module"
       Load    "glx"
       Load    "dri2"
EndSection

Section "Monitor"
       Identifier      "LCD Panel"
EndSection

Section "Device"
       Identifier      "Glamo Graphics Chip"
       Driver          "glamo"
EndSection

Section "Screen"
       Identifier      "Default Screen"
       Device          "Glamo Graphics Chip"
       Monitor         "LCD Panel"
EndSection

Section "InputDevice"
       Identifier      "Power Button"
       Driver          "evdev"
       Option          "Device"        "/dev/input/event0"
EndSection

Section "InputDevice"
       Identifier      "AUX Button"
       Driver          "evdev"
       Option          "Device"        "/dev/input/event2"
EndSection

Section "InputDevice"
       Identifier      "Touchscreen"
       Driver          "evdev"
       Option          "Device"        "/dev/input/event1"
       Option          "Calibration"  "107 918 911 98"
       Option          "SwapAxes"     "On"
EndSection

Section "ServerFlags"
       Option "AutoAddDevices" "False"
EndSection

Section "ServerLayout"
       Identifier      "Default Layout"
       Screen          "Default Screen"
       InputDevice     "Power Button"
       InputDevice     "AUX Button"
       InputDevice     "Touchscreen"
EndSection

The DBus interface changed from the old fsoframeworkd to the new fsodeviced, so openmoko-panel-plugin is unable to read battery status and causes an abnormal high CPU usage.

Reading the battery status is done using the following path (omit the last parameter to see a list of supported methods and signals):

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/PowerSupply/3 \
    org.freesmartphone.Info.GetInfo

Previously it was:

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/PowerSupply/battery \
    org.freesmartphone.Device.PowerSupply.GetInfo

Controlling the UsbHost power is done using this path:

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/PowerControl/0 \
    org.freesmartphone.Device.PowerControl.GetPower

I had to patch some files in /usr/share/pyshared/panelplugin/ to let the application works again, here you can find an archive of the files: panelplugin_2011-10-25.tar.gz.

I think that the Bluetooth, WiFi, GPS and Suspend buttons (from the power button menu) does not work anymore for the same reason (changed DBus interface).

The fso-deviced-openmoko before 0.9.5+git20110805-2 has a bug (the WiFi power sysfs path changed in kernel 2.6.34), see Debian bug #647003.

Also openmoko-panel-plugin must be patched to use the new FSO DBus interface. I will release that patched version soon.

There is still a problem with the old fso-frameworkd and fso-gpsd: GPS support provided by FSO (called Gypsy) is poorly supported by applications, which wants gpsd instead. The gpsd compatibility layer provided by fso-gpsd is rather old and not longer compatible with newer applications (e.g. Navit).

This is the DBus interface:

mdbus2 -s org.freesmartphone.ogpsd /org/freedesktop/Gypsy
[METHOD]    org.freedesktop.DBus.Introspectable.Introspect() -> ( s:none )
[METHOD]    org.freedesktop.Gypsy.Time.GetTime() -> ( i:none )
...
[METHOD]    org.freedesktop.Gypsy.Device.GetFixStatus() -> ( i:none )
...
[METHOD]    org.freedesktop.Gypsy.Position.GetPosition() -> ( i:none, i:none, d:none, d:none, d:none )
...

The best solution is to deinstall the fso-gpsd package and disable Gypsy from fso-frameworkd, just write in /etc/frameworkd.conf:

[ogpsd]
disable = 1

Then we enable GPS power control in fsodeviced (the new FSO implementation), setting this in /etc/freesmartphone/conf/GTA02/fsodeviced.conf:

[fsodevice.openmoko_powercontrol]
ignore_gps=false

This will provide a PowerControl interface (the numbering depends on activated devices, actually fso-deviced-openmoko - as patched by Debian - supports bluetooth, gps, usbhost and wifi in that order):

mdbus2 -s org.freesmartphone.odeviced
...
/org/freesmartphone/Device/PowerControl
/org/freesmartphone/Device/PowerControl/3
/org/freesmartphone/Device/PowerControl/2
/org/freesmartphone/Device/PowerControl/1
/org/freesmartphone/Device/PowerControl/0
...

Also an org.freesmartphone.Usage interface is provided, the one that should be really used beacuse it handles automatic power control based on applications requesting the device:

mdbus2 -s org.freesmartphone.ousaged \
    /org/freesmartphone/Usage \
    org.freesmartphone.Usage.ListResources
(["Display","GSM","Bluetooth","WiFi","TEST","GPS","Accelerometer","CPU","UsbHost"])

With this settings, we can enable gps plugin in openmoko-panel-plugin and control the GPS power via the power button menu. The relevant settings in $HOME/.panel-pluginrc are:

[main]
plugins = buttons, gsm, wifi, gps, keyboard, brightness, screenlock, bluetooth, usb, battery

[gps]
notification = True
visible = True

The gpsd daemon is always running (installed the gpsd package) and will provide data as soon as the device is turned on.

There is an FSO wrapper called fsoraw (from pkg-fso.alioth.debian.org) which enables non-FSO-aware applications to allocate resources automatically. E.g. you can start Navit allocating the GPS device and turning it on, if it not already. Once terminated, the GPS device is deallocated and eventually turned off:

fsoraw --force --resources=GPS,Display -- /usr/bin/navit

We have two mechanisms to control the blanking of the screen when idle: the traditional X.org way and FSO with DBus messaging.

For the X.org method look at the xset manpage, here are some usage examples:

# Forces deactivation of X.org screensaver if it is active.
xset s reset
# Disables screensaver functions.
xset s off
# Disables DPMS (Energy Star) features.
xset -dpms
 
# Enables DPMS (Energy Star) features.
xset +dpms
# Restores default screensaver settings.
xset s default

Using FSO, we can trigger display dimming or blanking when idle status changes. Idle status is one of the following:

Switching from one status to the other is controlled by timeouts, a timeout is the delay from entering the previous state and it is expressed in seconds (does the busy timeout has any means?):

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/IdleNotifier/0 \
    org.freesmartphone.Device.IdleNotifier.GetTimeouts
({"busy":0,"idle_dim":20,"idle":20,"idle_prelock":10,"lock":10,"suspend":20})

Timeouts are stored into /etc/freesmartphone/conf/GTA02/fsodeviced.conf and they are automatically updated whenever you change it via DBus:

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/IdleNotifier/0 \
    org.freesmartphone.Device.IdleNotifier.SetTimeout idle 20

We can trigger display adjustment, adding some rules into /etc/freesmartphone/oevents/rules.yaml like that:

-
    #
    # Idleness Brightness Handling
    #
    trigger: IdleState()
    filters: HasAttr(status, "busy")
    actions: SetDisplayBrightness("0", 90)
-
    trigger: IdleState()
    filters: HasAttr(status, "idle")
    actions: SetDisplayBrightness("0", 60)
-
    trigger: IdleState()
    filters: HasAttr(status, "idle_dim")
    actions: SetDisplayBrightness("0", 30)
-
    trigger: IdleState()
    filters: HasAttr(status, "idle_prelock")
    actions: SetDisplayBrightness("0", 20)
-
    trigger: IdleState()
    filters: HasAttr(status, "lock")
    actions: SetDisplayBrightness("0", 0)

This is the DBus interface provided by FSO Cornucopia implementation (fso-deviced, version 0.9.5+git20110805-1). The interface provided by fso-deviced is not complete, so also the old fso-frameworkd is installed.

Here you can find current FSO specification.

This will display current idle timeouts:

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/IdleNotifier/0 \
    org.freesmartphone.Device.IdleNotifier.GetTimeouts
({"busy":100,"idle_dim":10,"idle":10,"idle_prelock":35,"lock":5,"suspend":20})

This will listen for notification signals:

mdbus2 -l -s  org.freesmartphone.odeviced /org/freesmartphone/Device/IdleNotifier/0
[SIGNAL] org.freedesktop.DBus.NameAcquired  /org/freedesktop/DBus  org.freedesktop.DBus
(":1.35")
[SIGNAL] org.freesmartphone.Device.IdleNotifier.State  /org/freesmartphone/Device/IdleNotifier/0  :1.0
("busy")
[SIGNAL] org.freesmartphone.Device.IdleNotifier.State  /org/freesmartphone/Device/IdleNotifier/0  :1.0
("idle")

Idle status is one of the following: busy, idle, idle_dim, idle_prelock, lock and suspend. To prevent the device entering a state, set its timeout to -1 (see the note below). If a state is disabled, the subsequent states are never reached.

NOTE: to set a timeout of -1 you cannot use the command line because -1 is interpreted as an option. We can use the interactive mode of mdbus2 (terminate with Ctrl-D):

mdbus2 -s -i
MDBUS2> org.freesmartphone.odeviced /org/freesmartphone/Device/IdleNotifier/0 org.freesmartphone.Device.IdleNotifier.SetTimeout idle -1

If you want to use it into a script, just make this:

#!/bin/sh
BUS='org.freesmartphone.odeviced'
IDLE_SERVICE='/org/freesmartphone/Device/IdleNotifier/0'
TIMEOUT_OBJECT='org.freesmartphone.Device.IdleNotifier.SetTimeout'
echo "$BUS $IDLE_SERVICE $TIMEOUT_OBJECT idle_dim -1" | mdbus2 -s -i

mdbus2 -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/PowerSupply/3 \
    org.freesmartphone.Info.GetInfo
({
    "status": "Charging","type": "Battery",
    "technology": "Li-ion","charge_full": "1039941",
    "voltage_now": "4150000","name": "battery","online": "1",
    "time_to_full_now": "1620","health": "Good","temp": "216",
    "capacity": "96","present": "1","current_now": "-130875",
    "time_to_empty_now": "3932100"
})

How to listen for power supply signals (charging, capacity, etc.)

mdbus2 -l -s org.freesmartphone.odeviced \
    /org/freesmartphone/Device/PowerSupply \
    org.freesmartphone.Device.PowerSupply
[SIGNAL] org.freesmartphone.Device.PowerSupply.PowerStatus /org/freesmartphone/Device/PowerSupply  :1.1
("discharging")
[SIGNAL] org.freesmartphone.Device.PowerSupply.Capacity /org/freesmartphone/Device/PowerSupply  :1.1
(98)
[SIGNAL] org.freesmartphone.Device.PowerSupply.PowerStatus /org/freesmartphone/Device/PowerSupply  :1.1
("charging")

First of all we get a list of available resources:

mdbus2 -s org.freesmartphone.ousaged \
    /org/freesmartphone/Usage \
    org.freesmartphone.Usage.ListResources
(["Display","GSM","Bluetooth","WiFi","TEST","GPS","Accelerometer","CPU","UsbHost"])

then we request the usage of the resource:

mdbus2 -s -i
MDBUS2> org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.RequestResource Bluetooth

Notice that we do it in interactive way, so we can have the time to see that the device gets powered on (if the policy says that). Once the program mdbus2 is terminated (Ctrl-D), the resource is automatically released and turned off, if no other processes requested it.