Fast and simple library of common openmoko utility functions
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


*** README for omhacks

It is a fast and simple library of common openmoko utility functions.

There is a very simple command line front-end called "om", which exposes all
the library functions. Just run om to get its command line help.

The extra om-led executable is the same as running "om led", but is also
provided separately so that it's possible to make "om-led" suid but not "om".

If you need another function in the library, please send a patch. Please try to
keep in the minimalist spirit of the library, and also provide a command line
front end.

omhacks can optionally be hooked to suspend/resume in various
ways. /usr/share/doc/omhacks/examples/00at is an example on how to
configure the phone to wake up using RTC alarm to run at

/usr/lib/pm-utils/sleep.d/ is a hook that is used only if
pm-utils-light is installed, normal pm-utils ignores it. It turns the
blue LED on during suspend/resume so that you an easily see if the
phone gets stuck while executing suspend/resume scripts. It also
automatically resuspends the phone if it was woken up by usb
disconnect event. The touchscreen and backlight are kept disabled when
this resuspending is taking place. When you unplug the usb cable you
should only see the blue LED light for a few seconds.

** pm-utils-light hooks

omhacks installs some pm-utils-light suspend hooks, using its dynamic hooks
feature to have fast, lightweight hooks implemented in C.

The hooks provided by are:

 Name                          On suspend          On resume
 00-statusled                  Turn on blue led    Turn on blue led
 74-screen                     Turn off screen     Turn on screen
 98-cancel-on-usb-disconnect   -                   Cancel resume if reason is
                                                   USB disconnect
 99-statusled                  Turn off blue led   Turn off blue led

If you do not want one of these hooks to run, just create an empty file
/etc/pm/sleep.d/NN-HOOKNAME and make sure it is not executable. It will
override and disable the hook in /usr as pm-utils hooks are expected to do.

*** TODO list

 - Write the at hook also as a shlib, and package it so that it works both with
   pm-utils and with pm-utils-light

 18:00 #openmoko-debian < lindi-> enrico: btw, how about using "on|off" instead of 0 and 1?
 18:00 #openmoko-debian < enrico> lindi-: I thought about it, since I keep using 'on' and turning things off because 
                                  atoi("on") is 0
 18:01 #openmoko-debian < lindi-> but 1 and 0 sound very odd indeed. almost no command uses that kind of logic
 - get rid of *_swap() in omhacks
 - instead of keeping a table of sysfs names, scan things and create symlink in

    enrico> lindi-: after reading that thread on -kernel, I decided that the way to go is a 
            symlink farm in /var/run/omhacks
    enrico> lindi-: yes, there's a lot of code duplication. I think it's ok so far, eventually 
            we'll see a way to collapse it into something sensible
    lindi-> enrico: when is /var/run available? can you use omhacks on initramfs?
    lindi-> enrico: i'd like to be able to force 500 mA charging in the very beginning of 
    lindi-> enrico: it's always a tradeoff :(
    lindi-> enrico: any idea why running plain 'om' opens /dev/urandom?
    enrico> lindi-: erhm, I see wrt initramfs. You have a point
    enrico> lindi-: OTOH, we can fail gracefully and return the real pathname instead of the 
    lindi-> enrico: I already dim backlight in the very beginning of boot to make my phone boot 
            with low battery
    enrico> lindi-: and just use the symlink instead of the cache, as a sort of persistent 
            cache. If there's no /var/run, then skip the symlink
    enrico> no idea why plain om opens urandom. I really can't think why
    lindi-> enrico: ok using the symlink as a fallback is probably good idea
    enrico> maybe "break open" in gdb should tell you when it happens

20:16 #openmoko-debian < lindi-> enrico: also, access() is useless
20:16 #openmoko-debian < lindi-> enrico: why could just have "FILE *try_open(const char *list_of_alternatives[])" 
                                 that tries to fopen() each alternative and returns NULL if all failed
20:17 #openmoko-debian < lindi-> s/why/we/
20:17 #openmoko-debian < lindi-> then one of the alternatives could be the symlink path
20:19 #openmoko-debian < enrico> lindi-: I thought access was faster than open
20:20 #openmoko-debian < enrico> lindi-: ah, you mean, combining the search with the opening, like a sysfs_open
20:20 #openmoko-debian < enrico> lindi-: interesting... clever...

22:14 #openmoko-debian < lindi-> enrico: it stays asleep and when i resume using button it still has fix
22:14 #openmoko-debian < lindi-> enrico: so works perfectly. now just implement "om gps ubx /dev/gps 
                                 go-to-low-power-state"  to make it also save energy

 - recreate lindi's suspend/resume scripts
 - My goals
    - stand-alone pppd
       + turn gsm on/off (done)
       - turn gsm really on (can be done in pppd's chatscript)
    - wake up alarm
       + at hook, date +%s > $STORAGE/last-resume
       - "alert" script redone
          - for desktop and moko
	  - with config file
	     - on/off go back to sleep if triggered within 1 minute from resume
	       (no need to look at resume_reason)
	     - on/off moko specific
	        - inputs (listen to aux button instead of keyboard/mouse)
		- audio (fiddle with mixer)
		- vibration / leds (flash aux so one can see what to push in
		  the dark)
		- X display to use if undefined
             - ringtone
	  - run maximised
         enrico> lindi-: the hook works! scheduling jobs with at will wake up the phone and at will 
                 run the scheduled job *right away*
         enrico> lindi-: now I need to tweak your alert script a bit, so that if it's run within one minute from resume and noone pushes aux while it's being noisy, then it goes back to sleep
         enrico> lindi-: then any at job can be followed by a run of that alert script, and it solves the issue of going back to sleep at the end of the job
         enrico> lindi-: for extra kicks, the at script can have an option to run a program in background and also wait for it to end before suspending

 - Example of an at job that goes back to sleep at the end, if resume reason
   was rtcwake and there has been no meaningful input
 - GSM
    - turn on all, inc. PIN
 - GPS
    - suspend/resume GPS, saving/restoring status
    - lindi-> enrico: has info about low power mode
    - 00:08 #openmoko-debian < lindi-> enrico: | seems to have routines for this
      00:09 #openmoko-debian < lindi-> enrico: README from Jul 2009 says 'Omgps is a GPS application for OpenMolo mobile phone.'
      00:10 #openmoko-debian < lindi-> enrico: so we have yet another GPS program :)

    - set funky parameters
       - keep GPS on during suspend
       - set stationary threshold for different profiles (Automotive = 3, pedestrian = 2, stationary = 1)
   00:29 #openmoko-debian < lindi-> enrico: 'om gps keep-on-in-suspend' does not say anything to the gps chip. does 
                                    this really work? won't it wake up the main cpu since it is sending coordinates 
   00:30 #openmoko-debian < enrico> lindi-: I have *no* idea
   00:30 #openmoko-debian < enrico> lindi-: it's too cold outside now to test it
   00:30 #openmoko-debian < lindi-> since there's some UBX command to put the GPS chip to a "keep fix but don't 
   			            actively track and report coordinates" mode

   20:37 #openmoko-debian < enrico> lindi-: in fact I can code that ubxgen in C
   20:37 #openmoko-debian < lindi-> enrico: yes
   20:38 #openmoko-debian < lindi-> enrico: together with manual page that has examples it would be very useful tool
 - Wifi
    - ask the kernel people what is the proper way to turn it on/off, and to check if it's on
 - .vapi for omhacks, to use in zavai
 - battery
    - read, monitor
20:18 #openmoko-debian < lindi-> enrico: how about adding "energy" and "consumption" to om?
20:19 #openmoko-debian < lindi-> enrico: and usb_curlimit
20:19 #openmoko-debian < lindi-> and host/device modes
 - fork pm-utils-light off omhacks

 - reduce the size of lindi's ~/bin/
16:18 #openmoko-debian < enrico> lindi-: a few questions:
16:18 #openmoko-debian < enrico> lindi-: 2. what's the fiddling with sysrq-trigger?
16:19 #openmoko-debian < enrico> lindi-: 3. why touch /tmp/ ?
16:40 #openmoko-debian < lindi-> enrico: 2. sysrq trigger just makes sure kernel does not log anything on resume 
                                 to display, this used to slow things down a lot with debugging information
16:40 #openmoko-debian < lindi-> enrico: 3. gsm-watchdog looks at the freshness of /tmp/
16:41 #openmoko-debian < lindi-> enrico: 3. (Right after resume ogsmd won't respond to dbus. touching pid file 
                                 makes sure the watchdog does not immediately kill ogsmd in this case but waits 
                                 for a while)

 - leds
   From: Richard Purdie <>
   Cc: openmoko-kernel <>
   Subject: Re: Renaming of devices in 2.6.31
   Note that the sysfs people hate me for this. They would want you to go
   through each directory in /sys/class/leds/ opening
   the /sys/class/leds/*/function file and reading it to find what you
   want. So it could be much worse!