#9690 NORM 1.5-sof: suspend/resume from VT sometimes causes spurious linefreeds

[Zarro Boogs per Child]

#9690: suspend/resume from VT sometimes causes spurious linefreeds
------------------------------------+---------------------------------------
           Reporter:  pgf           |       Owner:                                   
               Type:  defect        |      Status:  new                              
           Priority:  normal        |   Milestone:  1.5-software-later               
          Component:  not assigned  |     Version:  Development build as of this date
         Resolution:                |    Keywords:                                   
        Next_action:  diagnose      |    Verified:  0                                
Deployment_affected:                |   Blockedby:                                   
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by dsd):

 ...but during my debugging today I haven't hit that condition. Instead,
 the logs have clearly shown the correct sequence of interrupts arriving in
 timely fashion.

 The problem is related to kbdshim. kbdshim (in userspace) listens for all
 the keyboard events and prevents the rest of the system from listening to
 them. It then relays them through the kernel's uinput mechanism, which is
 where other software hears the events from.

 There are events for both key presses and releases which get relayed
 through this system.

 The uinput device enables the kernel's soft timer-based autorepeat
 functionality. This means that if you send a keypress event through uinput
 and then take a while before sending a key release event, then the kernel
 will cause the keypress to repeated at a fixed interval during that time.

 The atkbd driver disables the soft-timer based autorepeat functionality,
 because the hardware itself generates periodic interrupts which say "this
 key is still held down", meaning that the atkbd driver can periodically
 nudge the input layer into repeating the keypress without having to run a
 software-level timer.

 What happens in the case where this is reproduced is as follows:

  1. keyboard sends "enter pressed" interrupt
  2. kbdshim picks up that keypress event, and relays it through uinput.
 this causes the software-level autorepeat timer to start.
  3. the suspend-to-RAM code freezes all userspace tasks because we're
 about to suspend
  4. keyboard sends "enter released" interrupt (kbdshim cannot process this
 right now because it is frozen)
  5. some time passes while all the hardware is being suspended. during
 this time, the in-kernel soft autorepeat is still running, causing the
 keypress to be repeated every few milliseconds
  6. system goes to sleep
  7. system is woken up by power button
  8. autorepeat timer is still running, causing the keypress to be repeated
 periodically
  9. some time later, userspace is woken up, kbdshim catches the "enter
 released" event from earlier, and relays a "enter released" event through
 uinput, causing the autorepeat timer to stop after having repeated the
 keypress about 20 times

 one way to solve this problem would be to eliminate the difference between
 atkbd and uinput: the autorepeat timer is never started for atkbd
 keypresses, and is always started for uinput. If we could make it also
 stop causing software-based autorepeats for uinput, then we would not have
 experienced any repeats during the example above.

 If I were actually holding down the key and causing atkbd to receive
 repeat interrupts, appropriate events for those will be generated which
 kbdshim will receive and relay through uinput, so the above proposal
 wouldn't break anything.

 unfortunately, as far as I can see, uinput currently does not allow us to
 control whether timer-based autorepeat is set up or not for its injected
 keypresses. but this is perhaps something we could work on...

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