#12798 NORM 13.2.0-: Screenshot does not take every time

[Zarro Boogs per Child]

#12798: Screenshot does not take every time
-----------------------------------+----------------------------------------
           Reporter:  tonyforster  |       Owner:  suyouxin                         
               Type:  defect       |      Status:  new                              
           Priority:  normal       |   Milestone:  13.2.0-android                   
          Component:  android      |     Version:  Development build as of this date
         Resolution:               |    Keywords:                                   
        Next_action:  design       |    Verified:  0                                
Deployment_affected:               |   Blockedby:                                   
           Blocking:               |  
-----------------------------------+----------------------------------------
Changes (by Quozl):

 * cc: pgf at laptop.org (added)
  * next_action:  never set => design
  * version:  not specified => Development build as of this date
  * milestone:  Not Triaged => 13.2.0-android


Comment:

 When you say "does not take every time", what do you mean?

 My tests on 1GB and 2GB units show several possible "does not take"
 results:
  * the volume control dialog appears instead,
  * the power control dialog appears instead,
  * there is no response at all.

 The first of these occurs if the X game key is seen first, probably due to
 a race.  See below.

 The second of these occurs if the X game key is not seen before the power
 button has been down long enough.  Being more careful with the finger
 timing solves this.

 The no response at all only ever occurs for me if the ''Saving
 screenshot...'' notification is still in the top left of the screen.

 Now, about the race.  The underlying cause is that the data path for the
 two keys are separate; the power button down event is from the embedded
 controller power control subsystem, and the X game key event is from the
 security processor PS/2 keyboard scan algorithm.  These two keys were
 never intended to be used in combination in the original design, and so
 there is no attempt to ensure timing consistency between them.  @pgf, any
 comment?

 Looking at the schematic,
  * PWR_BTN# on page 25 connects to GPIO 14 of the EC, and the EC debounces
 and delays the signal and delivers events to the SoC via an OLPC specific
 protocol,
  * KEY_R_DN on page 25 connects to GPIO 18 of the SoC, and is handled by
 CForth running on the security processor, which debounces in a different
 way and delivers events to the main processor via shared memory.

 @Ben, can we have a duplicate key binding for screenshot to overcome this
 design incompatibility?

-- 
Ticket URL: <http://dev.laptop.org/ticket/12798#comment:1>
One Laptop per Child <http://laptop.org/>
One Laptop per Child bug tracking system