Status report about suspend/resume issues

[Jeremy Chang]

On Thu, Oct 30, 2008 at 12:17:41PM +0100, Holger Freyther wrote:
> On Thursday 30 October 2008 11:17:02 Jeremy Chang wrote:
> 
> players:
> 	ompower and qpe
> 
> 	qpe opens /dev/apm_bios
> 
> 	ompower executes apm -s
> 
> 	qpe gets a suspend request
> 		=> it executes some commands to prepare the modem for suspend
> 		=> when this completes it ack's the suspend
> 		=> if it doesn't ack, the modem did not respond or there is a qtopia bug
> 			=> the device is messed up anyway.
> 
> 
> >     And there is only one way to do resume, press the Pwr button.
> 
> Or insert a usb cable.
    Thanks.  I noticed that like incoming call, etc. will also resume
the device.
> 
> >
> >     The problems about suspend/resume generally are as below:
> >     1) Unable to suspend, just screen black, Led is still on and ssh
> > through usb is still alive. This will make user think it's already
> > suspended and lead to further problems. (Trac ticket 1991)
> 
> #1991 it is not clear if the device was not suspended, regina is not very 
> clear on that.
> 
> 
> >     2) Suspend is ok, but just as resuming, it goes to suspend
> > immediately after you see the screen for one second. Sometimes it's too
> > quick, so the user thinks it can not be resumed.
> 
> file a ticket for that, this comes from multiple button presses?
> 
> >
> >     3) It can not be resumed. This may due to several scenarios, as ticket
> > #1884. Matt is also looking into this.
> 
> yes, matt solved one issue, there is something else still broken, see the 
> posts on the kernel mailinglist (picture from the scope)
> 
> 
> 
> >     4) After serveral tyring to wake up by pressing pwr button with at
> > least 1 sec interval, finally it wakes up, but it's going to "shutdown".
> >
> 
> press and hold action of enlightenment, so we miss a key up in the kernel?
> 
> 
> >     I am trying to fix this for scenario 1. That's caused by screensaver
> > timeout or the timer timeout in illume as soon as the device resumes.
> > I am looking into if I can do something in ompower to avoid this.
> 
> raster has this system("xset ...") in ompower. Now there are too ugly things, 
> first DISPLAY is set for ompower so the command can work, I don't know if 
> sandman's patches where ever merged to make apm -s not return until after the 
> suspend. So we might invoke xset before going to sleep. The best fix is to open 
> the apm bios to get the notification for resume...
    Right now, I am thinking to invoke "xset s off" before "apm -s" and
"xset s TIMEOUT" right after "apm -s" in ompower. Is it better to open
the apm bios to handle the resume event?
    And I am thinking is there any good way to get the TIMEOUT value in
ompower? What in my mind is may through xlib api.

Regards,
Jeremy
   
> 
> z. 
> 
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openmoko.org/pipermail/devel/attachments/20081031/87e7c6c4/attachment.pgp