1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
*** 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.
*** 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 <rpurdie@rpsys.net>
Cc: openmoko-kernel <openmoko-kernel@lists.openmoko.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!
|
