#9561 NORM 1.5-F11: mouse cursor moves after suspend/resume

[Zarro Boogs per Child]

#9561: mouse cursor moves after suspend/resume
--------------------------------+-------------------------------------------
           Reporter:  pgf       |       Owner:  dsaxena                          
               Type:  defect    |      Status:  new                              
           Priority:  normal    |   Milestone:  1.5-F11                          
          Component:  kernel    |     Version:  Development build as of this date
         Resolution:            |    Keywords:                                   
        Next_action:  diagnose  |    Verified:  0                                
Deployment_affected:            |   Blockedby:                                   
           Blocking:            |  
--------------------------------+-------------------------------------------
Changes (by dsaxena):

 * cc: cjb, quozl, wmb at firmworks.com, dsd (added)


Comment:

 I've spent sometime poking at this and have determined that it is not
 possible to fix this by a simple save/restore in the kernel. We are
 already saving and restoring the appropriate registers, the issue is that
 the Y-position of the cursor is not readable from the registers as can be
 seen from the following dump that I got with via-chrome-tool (modified to
 dump the video engine register):

 {{{
     IOMEM[208] = 0x02570000   # At bootup, cursor in middle of screen

     IOMEM[208] = 0000000000   # Cursor at upper left

     IOMEM[208] = 0x04ae0000   # Cursor at lower right
 }}}


 As per the manual, bits 26:16 are the X position and bits 10:0 are the Y
 position.  These are listed as WO but the 10:0 description contains the
 following note: "When read: Graphical Display Vertical Line Number" (See
 page 99 of the Chrome9 manual). I'm not quite 100% sure what this means
 but I can tell you that it means no Y position for us to read back.

 I tried an experiment as per our discussion on IRC to disable
 CONFIG_DISABLE_SUSPEND_VT_SWITCH and have the X driver restore the mode
 and cursor and even in that case I see a jump. What happens is that when
 the screen is restored, the cursor has jumped but it jumps back to the
 original location. There is no code in the openchrome driver to restore
 the position, so my guess is that when we use the VT switch setup, X calls
 the driver's SetCursorPosition() interface after it has restored the video
 mode.

 So in summary...HW interface FAIL. Basically there's no way to have a
 glitch-less suspend/resume of the cursor position without some changes in
 either the OpenChrome driver to cache the cursor position on every call to
 SetCursorPosition() and restore it immediately on the call to EnterVT().
 This means using the VT switch suspend/resume mechanism (''and no, we're
 not going to trap writes to the cursor position and cache those in the
 kernel''). This can probably be implemented and tested in less than half a
 day on the X driver front but we would have to modify the kernel to send X
 a VT switch signal but not actually switch modes so the screen does not
 blank, but I imagine that is not too hard to do either. I'm actually
 really leaning towards this as our current approach of having OFW restore
 the video mode and then having the kernel restore the video engine is
 somewhat of an ugly hack.

 There's also the KMS approach but at this point I know nothing about how
 to program against that interface and would prefer not to make such a
 large change given our release timeframe (and I don't think it would do
 anything for our cursor issues as KMS is about mode setting, not cursor
 setting).

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