Re: LED notification
On Friday 17 Oct 2008 8:16:10 pm Michael wrote: On 16/10/08 16:52:10, Andy Green wrote: Somebody in the thread at some point said: | (The first message I sent does not seem to have arrived) | | On 12/10/08 18:00:55, Andy Green wrote: | Yes always-on MPU can deliver consistent power behaviours we can't do | in | our current way of relying on PMU. You would basically make the PMU | a | slave of the MPU. Stuff like debricking scheme for a programmable | and | so brickable MPU that controls the PMU... needs careful thought. | | -Andy | | That shouldn't be a problem, because microcontrollers support in | circuit serial programming, so just make sure we can get to those pins | and have a doc that specifies the programming protocol for the brave. The issue is that if we allow user-updateable MPU, it can always be bricked. So for example we put out a new package with some MPU update that is broken, suddenly many devices could be bricked before we pull it. We definitely need some credible sequence of actions for the end-user that can unbrick the devices. Just telling him where some pins are doesn't really cut it. If the MPU is master of the CPU, then when it is bricked a lot of assets we might otherwise call on are unavailable. So it needs thinking through being aware of specific capabilities of the MPU. Should have mentioned that I have flashed microcontrollers for various projects that I am doing, so this was just meant for people who are used to this sort of thing rather than end users. I think you would probably want to leave MCU updates to the distributors or people who have done this sort of thing before and I suppose you would need a nano boot loader if you wanted to flash the MCU from user space (if microcontrollers that small will allow you to rewrite the flash from code). Indeed this is the method we follow for microcontrollers that may need firmware upgrade after deployment. the controller itself has a small boot loader that can only be modified with a hardware programmer. This basic boot loader can be used to flash the firmware that acts as the Linux boot loader. Of course, this may require that the USB port be multiplexed so the microcontroller is connected to it at boot and the main controller takes over later. -- Cheers! Kishore ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
On Sun, Oct 12, 2008 at 4:53 AM, Jason Cawood [EMAIL PROTECTED] wrote: My reason is because if I suspend my phone then I walk away and return to it, I have no visible notification I missed an event unless I touch the screen and see if my phone is still suspended. If I'm not constantly touching the screen to make sure it's still suspended and I did miss an event. Then my power consumption just increased and my battery life is quickly diminishing. Andy Green in this thread said that it is possible to leave an LED on prior to going to suspend. If that is the case then I suggest: 1. Whenever there is an event which requires user attention one LED is turned on, I suggest the blue power LED. Events include: a) new unread sms b) new alarm c) missed call 2. LED stays on until user has confirmed ALL outstanding events. 3. Leave LED lit while going into suspend. This way way if the phone wakes on call, alarm or SMS and there is no interaction from user prior to suspend, whenever the user returns, then it will be clear there has been a missed event. The only difficulty I can see (without familiarity with all the frameworks available to us) is knowing if there are any outstanding events not yet confirmed by the user but I suspect some system level daemon is required so that no individual user level application like sms does not have to make decisions or be coupled to other subsystems. Is this a viable approach ? cheers Denis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
On 16/10/08 16:52:10, Andy Green wrote: Somebody in the thread at some point said: | (The first message I sent does not seem to have arrived) | On 12/10/08 18:00:55, Andy Green wrote: | Yes always-on MPU can deliver consistent power behaviours we can't do | in | our current way of relying on PMU. You would basically make the PMU | a | slave of the MPU. Stuff like debricking scheme for a programmable | and | so brickable MPU that controls the PMU... needs careful thought. | | -Andy | That shouldn't be a problem, because microcontrollers support in | circuit serial programming, so just make sure we can get to those pins | and have a doc that specifies the programming protocol for the brave. The issue is that if we allow user-updateable MPU, it can always be bricked. So for example we put out a new package with some MPU update that is broken, suddenly many devices could be bricked before we pull it. We definitely need some credible sequence of actions for the end-user that can unbrick the devices. Just telling him where some pins are doesn't really cut it. If the MPU is master of the CPU, then when it is bricked a lot of assets we might otherwise call on are unavailable. So it needs thinking through being aware of specific capabilities of the MPU. Should have mentioned that I have flashed microcontrollers for various projects that I am doing, so this was just meant for people who are used to this sort of thing rather than end users. I think you would probably want to leave MCU updates to the distributors or people who have done this sort of thing before and I suppose you would need a nano boot loader if you wanted to flash the MCU from user space (if microcontrollers that small will allow you to rewrite the flash from code). -Andy Michael. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
(The first message I sent does not seem to have arrived) On 12/10/08 18:00:55, Andy Green wrote: Yes always-on MPU can deliver consistent power behaviours we can't do in our current way of relying on PMU. You would basically make the PMU a slave of the MPU. Stuff like debricking scheme for a programmable and so brickable MPU that controls the PMU... needs careful thought. -Andy That shouldn't be a problem, because microcontrollers support in circuit serial programming, so just make sure we can get to those pins and have a doc that specifies the programming protocol for the brave. Michael. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | (The first message I sent does not seem to have arrived) | On 12/10/08 18:00:55, Andy Green wrote: | Yes always-on MPU can deliver consistent power behaviours we can't do | in | our current way of relying on PMU. You would basically make the PMU | a | slave of the MPU. Stuff like debricking scheme for a programmable | and | so brickable MPU that controls the PMU... needs careful thought. | | -Andy | That shouldn't be a problem, because microcontrollers support in | circuit serial programming, so just make sure we can get to those pins | and have a doc that specifies the programming protocol for the brave. The issue is that if we allow user-updateable MPU, it can always be bricked. So for example we put out a new package with some MPU update that is broken, suddenly many devices could be bricked before we pull it. We definitely need some credible sequence of actions for the end-user that can unbrick the devices. Just telling him where some pins are doesn't really cut it. If the MPU is master of the CPU, then when it is bricked a lot of assets we might otherwise call on are unavailable. So it needs thinking through being aware of specific capabilities of the MPU. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkj3YyQACgkQOjLpvpq7dMpyyQCfSZYQPHneZXNAJNDYB7IqbZ/Q rxQAniNtY9xYzk8epS7KagcJGLKipmbo =fbfM -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
2008/10/12 Kishore [EMAIL PROTECTED] In addition, i would recommend a look a look at multimedia functions. If the device were to play music (mp3) if there were ways to be more power efficient. Good point. Am I right in thinking that there was a point during the development of Sony-Ericsson's phones (the point being the introduction of the Walkman series) when they suddenly became able to play MP3s while on standby? This would be a really good feature for OpenMoko phones to have, especially if they are to be competitive against mass-market media player phones. [snip] using one of the ultra low power micron controller such as one of the AVR pico series will allow greater flexibility with the ability to make it function like the device BIOS as well and upgrade its firmware if and when necessary. This could also help the battery charging problem when powered down! I agree; enabling the device to charge when powered down would be a good thing. The vast majority of consumers will need to be confident that if they plug their phone into a power source, it will (1) start charging and keep charging until the battery is full, and (2) light an LED while charging to indicate the state of the battery (typically, red=empty, amber=usable but not full, green=full). An awful lot of consumers, after all, do not RTFM and will assume the phone is broken if it doesn't do this. I know FR is still oriented at developers, but most developers are consumers too, and would prefer not to RTM any more than they have to. What's more, even with the best will in the world, batteries *do* run down completely from time to time. OM users deserve better than to have to remember magic sequences, etc, to get the phone working again after this happens. People do need to be able to rely on their phones. At the moment, if you've forgotten (or didn't know) about the magic sequences, and you find yourself with a discharged phone at a place with not internet access and only a USB charger, you'd be rather stuck. With most commercial phones, however, you'd just plug them in and let them charge until they had enough power in the battery to be switched on again. Sorry if this has all been said before. All best, Sam ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sam Kuper wrote: 2008/10/12 Kishore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] In addition, i would recommend a look a look at multimedia functions. If the device were to play music (mp3) if there were ways to be more power efficient. Good point. Am I right in thinking that there was a point during the development of Sony-Ericsson's phones (the point being the introduction I think we are better to try to find a general low power mode of operation for the CPU somehow than put in special MP3 playback hardware. But there is a case for a system management MPU that provides some always-on intelligence even when the CPU is down, that may appear in future. But for now as far as we got with always-on intelligence is the LED flashing thing. PWM is down in suspend... really all that CPU is very much down, the PLLs are off, there is no peripheral clock. All there is working is a kind of hold on GPIO state, and the IO pins are still powered. I agree; enabling the device to charge when powered down would be a good thing. The vast majority of consumers will need to be confident that if Yes always-on MPU can deliver consistent power behaviours we can't do in our current way of relying on PMU. You would basically make the PMU a slave of the MPU. Stuff like debricking scheme for a programmable and so brickable MPU that controls the PMU... needs careful thought. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjyLUcACgkQOjLpvpq7dMpKMACfU4CID24JhIzqkLIVVLXB1PB8 DggAn0dvM1FYG1qnOZpUT1k3SS/XCtFs =ccs/ -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sam Kuper wrote: 2008/10/9 Andy Green [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Robert Norton wrote: 2008/10/9 Robin Paulson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: the main cpu is suspended, like in the neo, but the power management unit is not I'm sure I recently read a datasheet for a PMU which supported various flash patterns for LEDs even during suspend. Unfortunately I can't Not really a PMU but an i2c device for just doing that. We might be using one or another in future products To me, having the phone able to perform basic notification functions (LED blink, vibrate, make a sound) on certain events, even when the phone is on standby, seems like a very desirable - not to say obvious - feature. Well you can simply wake and do event type actions like vibrate and flash LEDs then, the stimulus you are responding to like incoming call will be a CPU wake event so that lot will work. What can't be done (because of a completely Linux-centric POV in the design) is anything while the CPU is off in suspend. We can leave a LED on during suspend, but there is no intelligence to flash it or whatever. So overall it's not quite as bad as it sounded I hope. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjwjA0ACgkQOjLpvpq7dMqx1ACeLcpilImxowZ4IAYo2HnmQKGy OG8Anj9t65Je7ZS4X9/nMXnG3RNh0ezz =FaNT -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
2008/10/11 Andy Green [EMAIL PROTECTED] Well you can simply wake and do event type actions like vibrate and flash LEDs then, the stimulus you are responding to like incoming call will be a CPU wake event so that lot will work. What can't be done (because of a completely Linux-centric POV in the design) is anything while the CPU is off in suspend. We can leave a LED on during suspend, but there is no intelligence to flash it or whatever. So while the CPU is awake, it can set the state of the LEDs, etc, and then when it suspends, that state will remain unchanged? That actually doesn't sound *so* limiting. I guess that ultimately it would be nice if the states that you could leave the indicators in included cyclic states - flash once every 2 seconds, for instance. This could perhaps be handled by a *very* basic microcontroller to which the CPU would devolve responsibility for managing the indicators. This would increase the richness of the hardware UI provide developers/users with many more options for how the phone would behave in the suspend state. This is evidently the sort of thing the I2C LED drivers you mentioned above would be used for, but by indicators, I'm thinking of not just the LEDs but also the vibrator, screen backlight speakers. So something like a QFN PIC might be more appropriate than just an LED driver (although maybe an LED driver could be interfaced to non-LED indicators; I'm not sure). It's great to hear OpenMoko might introduce this sort of extra circuitry into the next generation of OM phones. It would be awesome if it was implemented as a retrofittable PCB for the FR, though I guess this would be pretty hard to achieve. So overall it's not quite as bad as it sounded I hope. No, it isn't. I'm still not totally sure I want to spend ~400GBP on the FR+debug board just yet, but I'm much closer to doing so. Thanks for your quick reply, Sam ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
this is exactly what I was trying to get at. I just couldn't find the correct words to communicate this effectively. My reason is because if I suspend my phone then I walk away and return to it, I have no visible notification I missed an event unless I touch the screen and see if my phone is still suspended. If I'm not constantly touching the screen to make sure it's still suspended and I did miss an event. Then my power consumption just increased and my battery life is quickly diminishing. On Sat, 2008-10-11 at 12:20 +0100, Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sam Kuper wrote: 2008/10/9 Andy Green [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Robert Norton wrote: 2008/10/9 Robin Paulson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: the main cpu is suspended, like in the neo, but the power management unit is not I'm sure I recently read a datasheet for a PMU which supported various flash patterns for LEDs even during suspend. Unfortunately I can't Not really a PMU but an i2c device for just doing that. We might be using one or another in future products To me, having the phone able to perform basic notification functions (LED blink, vibrate, make a sound) on certain events, even when the phone is on standby, seems like a very desirable - not to say obvious - feature. Well you can simply wake and do event type actions like vibrate and flash LEDs then, the stimulus you are responding to like incoming call will be a CPU wake event so that lot will work. What can't be done (because of a completely Linux-centric POV in the design) is anything while the CPU is off in suspend. We can leave a LED on during suspend, but there is no intelligence to flash it or whatever. So overall it's not quite as bad as it sounded I hope. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjwjA0ACgkQOjLpvpq7dMqx1ACeLcpilImxowZ4IAYo2HnmQKGy OG8Anj9t65Je7ZS4X9/nMXnG3RNh0ezz =FaNT -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
On Saturday 11 Oct 2008 7:25:38 pm Sam Kuper wrote: 2008/10/11 Andy Green [EMAIL PROTECTED] Well you can simply wake and do event type actions like vibrate and flash LEDs then, the stimulus you are responding to like incoming call will be a CPU wake event so that lot will work. What can't be done (because of a completely Linux-centric POV in the design) is anything while the CPU is off in suspend. We can leave a LED on during suspend, but there is no intelligence to flash it or whatever. So while the CPU is awake, it can set the state of the LEDs, etc, and then when it suspends, that state will remain unchanged? That actually doesn't sound *so* limiting. I guess that ultimately it would be nice if the states that you could leave the indicators in included cyclic states - flash once every 2 seconds, for instance. This could perhaps be handled by a *very* basic microcontroller to which the CPU would devolve responsibility for managing the indicators. This would increase the richness of the hardware UI provide developers/users with many more options for how the phone would behave in the suspend state. This is evidently the sort of thing the I2C LED drivers you mentioned above would be used for, but by indicators, I'm thinking of not just the LEDs but also the vibrator, screen backlight speakers. So something like a QFN PIC might be more appropriate than just an LED driver (although maybe an LED driver could be interfaced to non-LED indicators; I'm not sure). It's great to hear OpenMoko might introduce this sort of extra circuitry into the next generation of OM phones. It would be awesome if it was implemented as a retrofittable PCB for the FR, though I guess this would be pretty hard to achieve. So overall it's not quite as bad as it sounded I hope. No, it isn't. I'm still not totally sure I want to spend ~400GBP on the FR+debug board just yet, but I'm much closer to doing so. Thanks for your quick reply, In addition, i would recommend a look a look at multimedia functions. If the device were to play music (mp3) if there were ways to be more power efficient. Currently, i think this would consume a lot of power. For the LED's, does the processor support PWM output in hardware? With the many smaller processors that i use, the PWM output continues to be active when the processor is in power saving mode. Of course, even the PWM output stop when the processor is in the power down mode. This is just a thought. I have not seen the processor datasheet yet. But i agree with Sam and think that using one of the ultra low power micron controller such as one of the AVR pico series will allow greater flexibility with the ability to make it function like the device BIOS as well and upgrade its firmware if and when necessary. This could also help the battery charging problem when powered down! -- Cheers! Kishore ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
2008/10/9 Jason Cawood [EMAIL PROTECTED]: What I think I didn't communicate very well is: 1. phone is in suspend mode. 2. GSM wakes phone for sms notification 3. screen blanks after timeout 4. LED blinks while phone is not in suspend. Would that be a possible solution? I think I understand what you mean, but the question is: would that be very useful? - If the user sees their phone when it wakes up, they won't need to see a blinking LED too. - If the user does not see their phone when it wakes up, it is unlikely (I would guess) that they will return to it in the interval before it suspends again. I don't know what the current default is for the interval before the phone suspends again, but I imagine one would want it to be quite short, so as not to allow incoming calls and texts to consume a lot of battery. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
2008/10/9 Andy Green [EMAIL PROTECTED] Robert Norton wrote: 2008/10/9 Robin Paulson [EMAIL PROTECTED]: the main cpu is suspended, like in the neo, but the power management unit is not I'm sure I recently read a datasheet for a PMU which supported various flash patterns for LEDs even during suspend. Unfortunately I can't Not really a PMU but an i2c device for just doing that. We might be using one or another in future products To me, having the phone able to perform basic notification functions (LED blink, vibrate, make a sound) on certain events, even when the phone is on standby, seems like a very desirable - not to say obvious - feature. I was right on the verge of buying a FreeRunner when I read the message above, but think I may hold off for now, as it looks like that sort of functionality isn't something a firmware upgrade would enable. Is my understanding correct? If so, am I also right in thinking that retrofitting the hardware capability to do this would be *really* hard without serious SMT-soldering/PCB-fabrication tools and a big investment of time? Many thanks in advance for your help, Sam ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
No. You can get it to stay on but not flash, and this will kill the battery. Here's what Andy (kernel dev) said: It's possible to leave a GTA02 LED lit during suspend, but without waking-suspending each time, from PMU RTC interrupt for example, not to have it blink. It sounds a pretty hairy thing to attempt and it will halve suspend life at least to have an LED lit during it. from: http://lists.openmoko.org/pipermail/community/2008-October/032608.html -Nick Jason Cawood wrote: What I think I didn't communicate very well is: 1. phone is in suspend mode. 2. GSM wakes phone for sms notification 3. screen blanks after timeout 4. LED blinks while phone is not in suspend. Would that be a possible solution? On Wed, 2008-10-08 at 23:51 +, zing wrote: On Wed, 08 Oct 2008 15:21:08 -0600, Jason Cawood wrote: Someone posted awhile back and asked about a blinking LED to notify that was me :) missed call or message and someone responded with can't do it when the phone is suspended. In the current state, if you don't have your setting to suspend automatically, wouldn't the phone wake up from suspended mode to notify of an event? and while in that state, couldn't we make the LED blink? My understanding was that blinking in suspend mode is no go (or at least not exactly battery efficient because you'd need to wake/blink/suspend/ wash/rinse/repeat), but brightness fully on during suspend was possible (eating into your battery though also.) AIUI. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
On Thursday 09 October 2008 07:49:32 nickd wrote: No. You can get it to stay on but not flash, and this will kill the battery. Please forgive me if this was discussed already. But how do other linux powered devices (e.g. Nokia N8x0) manage their suspend? They seem to not go into such a deep suspend like the om's do. They just turn off the display (touchscreen is able to wake it up) but are still able to reach a battery life of 10 days. They do have blinking leds on incoming IM or e-mail messages even during suspend. Any ideas? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
2008/10/9 Michael Zanetti [EMAIL PROTECTED]: Please forgive me if this was discussed already. But how do other linux powered devices (e.g. Nokia N8x0) manage their suspend? they have a separate, very-low-powered processor, that handles only power usage of the phone, which runs continuously. they are generally very low clock-rate, and couldn't do much in the way of general-purpose processing, but are more than capable of this sort of thing the neo doesn't have one They seem to not go into such a deep suspend like the om's do. They just turn off the display (touchscreen is able to wake it up) but are still able to reach a battery life of 10 days. They do have blinking leds on incoming IM or e-mail messages even during suspend. the main cpu is suspended, like in the neo, but the power management unit is not ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Norton wrote: 2008/10/9 Robin Paulson [EMAIL PROTECTED]: the main cpu is suspended, like in the neo, but the power management unit is not I'm sure I recently read a datasheet for a PMU which supported various flash patterns for LEDs even during suspend. Unfortunately I can't Not really a PMU but an i2c device for just doing that. We might be using one or another in future products, eg, http://www.nxp.com/acrobat_download/datasheets/PCA9632_3.pdf http://www.national.com/ds/LP/LP5521.pdf - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjt29MACgkQOjLpvpq7dMqBvACfUsU+27mrxa98K2HOcQ12fTCj +TwAnAvQ7pxKxMW+pPPStFtorfrdEAjA =qbVL -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
2008/10/9 Robin Paulson [EMAIL PROTECTED]: the main cpu is suspended, like in the neo, but the power management unit is not I'm sure I recently read a datasheet for a PMU which supported various flash patterns for LEDs even during suspend. Unfortunately I can't remember where I found it or exactly why I was reading it. I have a feeling I may have followed a link on the OM wiki. Did GTA01 have a PMU which supported this? Anyone know what I'm talking about? Robert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LED notification
On Wed, 08 Oct 2008 15:21:08 -0600, Jason Cawood wrote: Someone posted awhile back and asked about a blinking LED to notify that was me :) missed call or message and someone responded with can't do it when the phone is suspended. In the current state, if you don't have your setting to suspend automatically, wouldn't the phone wake up from suspended mode to notify of an event? and while in that state, couldn't we make the LED blink? My understanding was that blinking in suspend mode is no go (or at least not exactly battery efficient because you'd need to wake/blink/suspend/ wash/rinse/repeat), but brightness fully on during suspend was possible (eating into your battery though also.) AIUI. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
