Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
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 jobs. /usr/lib/pm-utils/sleep.d/omhacks.so 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 omhacks.so 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 omhacks.so 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 /var/run/omhacks/ http://wiki.openmoko.org/wiki/GTA02_sysfs 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 initramfs 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 symlink 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 http://lindi.iki.fi/lindi/openmoko/custom-scripts.txt - My goals - stand-alone pppd + turn gsm on/off (done) - turn gsm really on (can be done in pppd's chatscript) http://lindi.iki.fi/lindi/openmoko/manual-call.txt - 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: http://lists.openmoko.org/nabble.html#nabble-td2476690 has info about low power mode - 00:08 #openmoko-debian < lindi-> enrico: | http://downloads.openmoko.org/developer/sources/svn/omgps.googlecode.com/svn/trunk/omgps/src/ubx.c 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) http://lists.linuxtogo.org/pipermail/smartphones-userland/2009-October/002037.html http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#UBX_protocol http://lists.openmoko.org/pipermail/openmoko-kernel/2008-July/004047.html http://people.openmoko.org/tony_tu/src/u-blox/AssistNowOfflineServerSampleImplementation/ http://svn.openmoko.org/developers/matt_hsu/agps-online/ 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 constantly? 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/ http://lindi.iki.fi/lindi/openmoko/custom-scripts.txt 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/frameworkd.pid ? ------------------------------------------------------------------------------------------------------------------- 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/frameworkd.pid 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 http://www.mjmwired.net/kernel/Documentation/leds-class.txt From: Richard Purdie <email@example.com> Cc: openmoko-kernel <firstname.lastname@example.org> 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!