mouse cursor moves after suspend/resume

[pgf]

• note the position of the mouse cursor
• go into suspend (os33 or later, so the screen will wake back up)
• wake with power button
• observe that mouse cursor jumps (often, but not always, straight up to the top of the screen)
• touch the touchpad lightly to cause a very small motion
• observe that the small motion is relative to the _previous_ position of the mouse cursor: i.e., the random jump after resume wasn't "real", in some sense.

[dsaxena]

This is likely an issue with the kernel not saving and restoring the cursor location in the viafb driver.

[Quozl]

Might this be caused by #9572 (touchpad allocates new input device after every suspend)?

[Quozl]

Triage.

Reproduced on os39. Agree, #9572 relates.

[pgf]

there's no data from the device causing the cursor to move. the device is, however, closed and reopened. (due to #9572.) but since the close/reopen is happening in olpc-kbdshim, and not the X server, it's pretty unlikely that that's related to the cursor jump.

[dsaxena]

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).

[dsaxena]

via-chrome tool modified to dump iomem registers. run "via-chrome-tool -i 0xf0000000"

[wmb@…]

"When read: Graphical Display Vertical Line Number"

That is probably the current scan line that is being read from memory. Useful info for preventing glitches due to changing data while the display engine is fetching it.

One workaround would be for chrome to shadow the cursor position in scratch registers that viafb can read. CRT registers 49-4f would do. The manual lists them as "reserved" on page 20 (pdf page 27) but the top of page 38 (pdf page 45) suggests that they are scratch registers. I have verified in OFW that you can write to them and read them back. So they would serve as a back channel between chrome and viafb.

Yes, I know it's a hack.

[dsaxena]

Since X doesn't know when we'll suspend without the VT switch signal, we would have to a scratch register write on every cursor movement. Fairly easy to test, but it adds yet another non-standard hook into our software stack.

Mitch, how hard would it be for me to locally simply disable the OFW mode restore on resume? I'd like to attempt my proposal and see what the suspend/resume performance is like.

[dsd]

why don't we just disable HW cursor for now?

[dsd]

Another point to throw in: won't a VT switch cause a lot of expose events? If so we'd likely be unfreezing the dcon while everything is still redrawing

[wmb@…]

Replying to dsaxena:

Mitch, how hard would it be for me to locally simply disable the OFW mode restore on resume?

You can download and build a new firmware image in about a minute, including the time to check out the repository.

$ yum install iasl $ svn co svn://openbios.org/openfirmware $ cd openfirmware/cpu/x86/pc/olpc/via/build $ make

To disable graphics restore, edit openfirmware/cpu/x86/pc/olpc/via/romreset.fth and comment out the restoration load line as follows:

\ fload ${BP}/cpu/x86/pc/olpc/via/startgfxrestore.fth \ Display restoration

i.e. add the backslash at the beginning of the line. Recompilation will take a few seconds.

If you want a distinct build ID, edit openfirmware/cpu/x86/pc/olpc/via/versions.fth and change the value of FW_MAJOR or FW_MINOR .

[wmb@…]

The overhead for shadowing the cursor position in the scratch register set would be about 4 uS per cursor update. Indeed it is yet another nonstandard hack.

[dsd]

Given the headaches here I think the best plan of action is to enable SWCursor until we are able to implement something nicer (through KMS?)

I just tried enabling this. Assuming that you reboot after changing the setting, it fixes the problem. (If not, the cursor is still present in the video memory and the viafb resume path will re-enable hw cursor, so you end up with 2 cursors. This could be tweaked if necessary)

Should I go ahead and make this change in xorg.conf?

[cjb]

Yes please, Dan. We can keep thinking about it, but let's SWCursor for now.

[dsd]

OK, olpc-utils-1.0.10 ready for next build. Thinking forward, I opened #9708 in terms of getting a KMS driver done and being able to use HW cursor again.

[cjb]

test in os43

[Quozl]

confirmed fixed in os43 by testing, cursor no longer shifts on resume. raised related ticket #9711 found during test. closing this ticket.

[anonymous]

Milestone 1.5-software deleted