#12556 HIGH 13.2.0: XO-4 mouse cursor corrupt after display-off suspend

[Zarro Boogs per Child]

#12556: XO-4 mouse cursor corrupt after display-off suspend
------------------------------------+---------------------------------------
           Reporter:  tomyin        |       Owner:  jnettlet     
               Type:  defect        |      Status:  new          
           Priority:  high          |   Milestone:  13.2.0       
          Component:  kernel        |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  add to build  |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsd):

  * next_action:  diagnose => add to build
  * component:  x window system => kernel
  * milestone:  13.1.0 => 13.2.0


Comment:

 The interesting thing from the above results is that it is actually hard
 to make the cursor corruption happen. Only one experiment reproduces it -
 having the dcon asleep over suspend/resume.

 Digging further...

 fb blanking does not seem to destroy the hardware cursor data (I checked
 with a further experiment). So it is not exactly clear why the cursor
 save/restore is done in the fb blank/unblank codepath.

 Suspend/resume *does* destroy the hardware cursor data, so we do need to
 save and restore it here. On our other platforms, this happens in
 suspend/resume handlers, but the pxa168fb driver on XO-4 has no
 suspend/resume codepath. Instead, it relies on the fb being
 blanked/unblanked over suspend/resume.

 When the dcon driver switches from CPU to DCON, as it does when going into
 suspend with the screen on, the dcon driver does ask the FB to blank, and
 the opposite during DCON-to-CPU on resume, hitting the cursor save/restore
 paths mentioned above. Good.

 When the dcon driver is put to sleep, it doesn't do anything with fb
 state. When the system then suspends, the dcon driver doesn't do anything,
 since the dcon is asleep. So in this particular case we do not touch the
 fb blank state over suspend/resume, meaning that we don't save/restore the
 cursor.

 There are 2 questionable items here, fixing either one should solve the
 problem:
  1. pxa168fb does cursor save/restore during blank/unblank, however the
 blank/unblank operations do not actually destroy the cursor data in
 memory. Suspend/resume is what kills the cursor data in memory, so having
 cursor save/restore done in suspend/resume PM handlers would seem more
 sensible. Added a FIXME in arm-3.5 f510ff4.
  2. DCON driver generally goes to some lengths to turn the framebuffer off
 when framebuffer output is not shown on screen, but it does not do this in
 the DCON sleep (total display poweroff) case. Fixed in arm-3.5 8e2e2e1c2.

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