suspend oddities

[pgf at laptop.org]

talking with richard just now i realized that there's been a bit
of disconnect, at least on my part, in understanding our current
suspend design.

i was complaining that keypresses were arriving while my machine
was suspended.  richard pointed out that it's meant to work that
way.  my use-case was "i've suspended my laptop because i want to
toss it in my backpack, and no button presses should register". 
richard's use-case is "my laptop is suspended because i'm in
ebook mode, and i want the game-pad keys to wake me up just
enough to flip pages on my document".  turns out the EC goes
out of its way to make sure this happens.

so, while i still think there may be bugs (in that i think i
get keypresses even when i've told the system that keypresses
shouldn't wake me up -- but i'll doublecheck that), there's
clearly a terminology problem:  "suspend" and "sleep" have too
many meanings, and none of the traditional meanings include the
XO's ebook behavior.

any thoughts on this?  i'm not sure "drowsy mode" or "zombie
mode" have quite the right connotation.  maybe "catnap" mode.

i think we also realized that we may need some more logic
(somewhere) to control wakeup events, since both the ebook and
toss-in-backpack modes are valid use cases.

paul

deepak wrote:
 > On Jul 30 2008, at 14:17, pgf at laptop.org was caught saying:
 > > since i'm not sure which of these are known/expected/
 > > alreadyfixed/beingignored, here are a few things i've noticed
 > > with suspend.  i'll trac any that people think should, or comment
 > > existing trac if appropriate.
 > > 
 > > disclaimer:  some of this testing has been on my g1g1 machine,
 > > running 2159, XFCE (not sugar), with a USB keyboard.
 > > 
 > >     - gamepad keypresses aren't ignored during suspend.  whether or
 > >         not the gamepad is selected as a candidate wakeup event
 > >         (via /sys/power/wakeup_events/gamekey), those keys will
 > >         be queued for tty input while we're suspended.  test by
 > >         starting hexdump (or other key capture program), suspending,
 > >         pushing any of the 8 keys on the bezel, and then resuming.
 > >         note that the keys have registered.  (this is/was true in 708
 > >         as well.)
 > 
 > The gamekeys go through PS2 so I'm guessing the EC is queeing that event for
 > us. I can reproduce the same sort of behaviour with by switching to console 
 > on the XO, sleeping via /sys/power/state on serial console, and then hitting
 > a keyboard key to wake up. On wakeup, the character appears on the shell.  
 > 
 > However, I just did the following here:
 > 
 > echo 0 > /sys/power/wakeup_events/ps2event
 > echo mem > /sys/power/state
 > hit a key
 > hit power button
 > 
 > And I don't see the character on console, which means it did not get
 > queued during suspend when wakeup on keypress is disabled. 
 > 
 > How are you trigerring resume?
 > 
 > (FYI, gamekey has been renamed ps2event in latest kernels)
 > 
 > >     - the camera LED flashes while suspended.  suspend the laptop,
 > >         use the touchpad or a keyboard key.  observe camera indicator
 > >         blinking.  also true on 708.
 > 
 > The way suspend currently works is that we actually go all the way back to 
 > userland and OHM makes a decision on whether we actually want to wake up 
 > or not based on our current state and what triggered the wakeup. I'm guessing 
 > the flashing is the camera driver resuming the device. If you're running 
 > XFCE on top of our OHM, you should see the same behaviour. The wakeup_event
 > interface was put in place to stop this by allowing OHM to specify when
 > we want to actually be woken up.
 > 
 > >     - this got me thinking about wakeups and keypresses in general.
 > >        if we're configured to wake up on keypresses or gamepad
 > >        presses (something i've not seen work yet, btw), then the
 > >        keypress causing the wake should be suppressed.  don't know
 > >        whether that's the case or not.
 > 
 > 
 > >From both our tests, it does not appear to be the case ATM.  Whether 
 > this is intended or not, someone who's been around longer needs to answer.
 > 
 > ~Deepak
 > 
 > -- 
 > Deepak Saxena - Kernel Developer - dsaxena at laptop.org

=---------------------
 paul fox, pgf at laptop.org