#11223 BLOC 11.3.0: XO-1 remapping keyboard on resume

[Zarro Boogs per Child]

#11223: XO-1 remapping keyboard on resume
-------------------------------------------+--------------------------------
           Reporter:  greenfeld            |       Owner:  rsmith                           
               Type:  defect               |      Status:  new                              
           Priority:  blocker              |   Milestone:  11.3.0                           
          Component:  embedded controller  |     Version:  Development build as of this date
         Resolution:                       |    Keywords:                                   
        Next_action:  code                 |    Verified:  0                                
Deployment_affected:                       |   Blockedby:                                   
           Blocking:                       |  
-------------------------------------------+--------------------------------
Changes (by pgf):

 * cc: rsmith (added)
  * owner:  pgf => rsmith
  * next_action:  diagnose => code
  * component:  olpc-kbdshim => embedded controller


Comment:

 i think i've fully diagnosed this, and have a (partial) fix.

 the EC code contains a ring buffer into which characters are put before
 being picked up for transmission to the host.  the code managing this
 buffer is sufficiently arcane that i was able to fix four separate bugs in
 the way it's managed.  two of those bugs conspired to cause my symptoms.
 (the other two were found by inspection, and we may never actually hit
 them in practice.)

 to reproduce the symptoms:  use a magnet to put the laptop into "lid-
 closed" suspend, and hit enough keys to fill the ring buffer -- typing
 slowly, 16 to 20 characters should do it (or maybe more -- i don't have an
 unpatched laptop handy to try it again).  the ring buffer fills because
 the upstream interface to the host is blocked (sort of -- more below), so
 characters accumulate.  once you've typed enough,
 simulate "lid open" by removing the magnet.  you may have to type a few
 more characters to start seeing characters dropped, errant control chars,
 etc.

 i believe that in actual use, the bug was occurring for me because it's
 possible to depress keys on the mechanical HS model by squeezing the
 laptop when it's closed.  this likely happens in my shoulder bag while i'm
 commuting, or perhaps i have a characteristic way of holding it with my
 right hand while connecting power.  not sure.

 it turns out that characters typed while in lid-suspend state are not
 completely blocked from the host.  some will be lost entirely, but others
 (about half, up to the size of the ring buffer, i think) will be sent to
 the host after the laptop is awakened.  i think this behavior is wrong --
 no characters that arrive while wakeups are masked should be saved and
 sent up (with the possible exception of the break code for the key that
 got us into suspend, if any.  but since this is a lid-closed suspend, that
 isn't as much of an issue as it is with lid-open suspend.)

 this bug was present in 10.1.3, and is likely present on earlier releases
 and on XO-1 as well.  this makes it a) not a regression, and b) probably
 not a blocker.  i have a fix, but i think it may be worth fixing the rest
 of the problem at the same time.

-- 
Ticket URL: <http://dev.laptop.org/ticket/11223#comment:18>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system