#12556 closed defect (fixed)

XO-4 mouse cursor corrupt after display-off suspend

Reported by: tomyin Owned by: jnettlet
Priority: high Milestone: 13.2.0
Component: kernel Version: not specified
Keywords: Cc: dsd
Blocked By: Blocking:
Deployments affected: Action Needed: add to build
Verified: no

Description

OS: 31030o4
OFW: Q7B16
EC: 0.3.12
Procedure:

  1. Update OS to 31030o4.zd, enter sugar and check the pointer.
  2. Let machine enter suspend then wake it up.
  3. Check pointer

Attachments (2)

Pointer.jpg (1.1 MB) - added by tomyin 22 months ago.
pointer
pointer (2).jpg (678.0 KB) - added by tomyin 22 months ago.
Sometimes the icon of pointer like as attach picture

Download all attachments as: .zip

Change History (10)

Changed 22 months ago by tomyin

pointer

comment:1 Changed 22 months ago by dsd

  • Component changed from not assigned to x window system
  • Milestone changed from Not Triaged to 13.1.0
  • Owner set to jnettlet
  • Priority changed from normal to high

We do have mouse cursor corruption reported in #12534, but I think this is the first case where it's been reported as happening on resume, and being as corrupt as it is in your screenshot.

comment:2 Changed 22 months ago by jnettlet

I ran into this over the weekend. I could only make it happen when the display was dimmed and I shut the lid of the XO to suspend. I took a brief look at it and think I know what is going on.

Changed 22 months ago by tomyin

Sometimes the icon of pointer like as attach picture

comment:3 Changed 22 months ago by garycmartin

Confirmed on os34 (with Q7B20 firmware) on a B1 and a C1 XO-4. Simple to reproduce it reliably, while booted in Sugar just close the lid, let it suspend, then open the lid and resume with the power button, both XO-4 laptops here exhibit the corrupt (random) cursor every time. Interesting to note that using the power button to trigger a suspend does NOT exhibit this cursor corruption issue (e.g. press power button so the suspend/resume/shutdown image is displayed, wait for the suspend to trigger, then resume with the power button, cursor looks good).

comment:4 follow-up: Changed 22 months ago by erikos

  • Action Needed changed from never set to diagnose

As an update, this is still present in os35.

I had two XO4s suspending and both came up with the corrupted cursor. The cursor stays like that when I move it around, when I reveal the Frame with moving the cursor to a hot corner the corruption is fixed.

comment:5 in reply to: ↑ 4 Changed 22 months ago by erikos

Replying to erikos:

As an update, this is still present in os35.

I had two XO4s suspending and both came up with the corrupted cursor. The cursor stays like that when I move it around, when I reveal the Frame with moving the cursor to a hot corner the corruption is fixed.

After another suspend cycle the corruption is back again.

comment:6 Changed 21 months ago by dsd

  • Cc dsd added
  • Summary changed from [CL4] After wake up from suspend, the pointer will became garbage. to XO-4 mouse cursor corrupt after display-off suspend

Some experiments and analysis on 13.2.0 build 2 on XO-4 B1 and XO-4 C1. All tests were done with the mouse cursor visible on screen (i.e. the last input was mouse input, rather than touch input that would have hidden the cursor).

FB blank/unblank

With X on-screen:

echo 1 > /sys/devices/d420b000.display/pxa168fb_gfx.0/graphics/fb0/blank
echo 0 > /sys/devices/d420b000.display/pxa168fb_gfx.0/graphics/fb0/blank

The cursor is OK.

DCON power cycle

With X on-screen:

echo 1 > /sys/devices/platform/dcon/sleep
echo 0 > /sys/devices/platform/dcon/sleep

The cursor is OK.

Suspend with display on, no VT change

The normal idle-suspend routine does this. An equivalent test with the same results is:

  1. (on serial console while X is on-screen) echo mem > /sys/power/state
  2. Wake up with power button

The mouse cursor is fine after resume.

Suspend with VT change either side

Suspend by tapping the power button; this causes powerd's suspend splash screen to come up (involves a chvt) before suspend happens. It changes back to X after resume.

Upon resume (and chvt back to X), the cursor is OK.

Suspend with DCON off

This can be done by closing the lid while X is on-screen. An equivalent test with the same results is:

  1. (on serial console while X is on-screen) echo 1 > /sys/devices/platform/dcon/sleep; echo mem > /sys/power/state
  2. Wake up with power button
  3. echo 0 > /sys/devices/platform/dcon/sleep

Upon resume, the mouse cursor is corrupt.

Suspend with FB blanked

With X on-screen:

  1. echo 1 > /sys/devices/d420b000.display/pxa168fb_gfx.0/graphics/fb0/blank
  2. echo mem > /sys/power/state
  3. Wake up with power button
  4. echo 0 > /sys/devices/d420b000.display/pxa168fb_gfx.0/graphics/fb0/blank

Cursor is OK.

pxa168fb_cursor disabled

pxa168fb_cursor is the function that backs up the cursor when the framebuffer is blanked.

Let's check it has an effect. Disabled it at the code level, repeated the "Suspend with display on, no VT change" test. On resume, the mouse cursor is bad.

comment:7 Changed 21 months ago by dsd

  • Action Needed changed from diagnose to add to build
  • Component changed from x window system to kernel
  • Milestone changed from 13.1.0 to 13.2.0

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.

comment:8 Changed 21 months ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

A lid-close suspend in 13.1.0 build 3 for XO-4 doesn't corrupt the cursor any more.

Note: See TracTickets for help on using tickets.