Ticket #10233 (new defect)

Opened 4 years ago

Last modified 3 years ago

on XO-1, mouse to resume from idle suspend doesn't work well

Reported by: dsd Owned by: pgf
Priority: low Milestone: Future Release
Component: kernel Version: 1.0 Software Build 802
Keywords: os301 Cc: sascha_silbe
Action Needed: design Verified: no
Deployments affected: Blocked By:
Blocking:

Description

On XO-1, using the mouse to resume from idle-suspend doesn't work well - the system wakes up, but the mouse movement or click is not registered.

This is not surprising given that we're resetting the controller on resume. On XO-1.5 we're avoiding that, but if we do the same on XO-1 then we end up with an unresponsive mouse/keyboard on resume. Needs investigating.

Attachments

fixed_revert_of_ffd1100e.patch (1.3 kB) - added by pgf 4 years ago.

Change History

  Changed 4 years ago by Quozl

  • keywords os301 added
  • next_action changed from never set to diagnose
  • version changed from not specified to Development build as of this date
  • milestone changed from 1.0-software-update to 10.1.2

Regression from 8.2.1.

  Changed 4 years ago by Quozl

  • next_action changed from diagnose to reproduce

  Changed 4 years ago by Quozl

  • next_action changed from reproduce to design
  • version changed from Development build as of this date to 1.0 Software Build 802

Tests on os802 (8.2.1)

external eventwakes systemseen by sugar
a mouse clickyesno
a touchpad moveyesno
a keypressyesyes

Correction. Not a regression from 8.2.1.

  Changed 4 years ago by sascha_silbe

  • cc sascha_silbe added

  Changed 4 years ago by cjb

  • priority changed from normal to blocker

Proposing for 10.1.2 blocker triage.

  Changed 4 years ago by Quozl

We've decided to turn off idle-suspend on XO-1 as a workaround to this problem, if we need to ship before it is fixed.

in reply to: ↑ description   Changed 4 years ago by pgf

Replying to dsd:

This is not surprising given that we're resetting the controller on resume. On XO-1.5 we're avoiding that, but if we do the same on XO-1 then we end up with an unresponsive mouse/keyboard on resume. Needs investigating.

can you remind me where this reset is?

  Changed 4 years ago by pgf

problem referred to above is commented here: http://dev.laptop.org/ticket/9779#comment:25

  Changed 4 years ago by pgf

progress, i think: i'm testing a revert of ffd1100e7d386426d6277fb2d972a08f1b37188f to see why it breaks on XO-1. it turns out the kernel is never handling ps2 interrupts after the first suspend/resume cycle. characters are available, since we get one per s/r cycle (w/o benefit of interrupt). need to figure out where the interrupt disable is happening, and/or where the enable should be. (no doubt there's an implicit enable when the controller is reset, which is why it works if we do the reset.)

  Changed 4 years ago by pgf

i've tracked the mouse and keyboard disable to a function in the EC that's being called during suspend/resume, as a result of PCIRESET# assertion. i'll figure out how to undo the effects of this with EC commands.

what's not clear is why we don't see the same issue on 1.5.

  Changed 4 years ago by Quozl

  • milestone changed from 10.1.2 to 10.1.3

  Changed 4 years ago by Quozl

  • priority changed from blocker to high
  • milestone changed from 10.1.3 to 10.1.2

  Changed 4 years ago by pgf

the fix requires changes to both EC firmware and the kernel:

in the EC, if we disable PCIRST interrupts, and/or remove the code from that part of the handler (which is called for other interrupts as well).

in the kernel, revert commit ffd1100e, which will make the code behave the same on both XO-1 and XO-1.5.

since ffd1100e doesn't revert cleanly, attaching a copy of a fixed-up revert.

Changed 4 years ago by pgf

  Changed 4 years ago by cjb

  • next_action changed from design to test in build

test in os852

  Changed 4 years ago by Quozl

  • next_action changed from test in build to diagnose

Tested in os852 with XO-1, using old-style touchpad.

There is certainly an improvement, in that wake from sleep with a touchpad button click is properly recognised. But a touchpad finger movement is abbreviated somehow. There is a slight move of the pointer, but not to the scale as seen on XO-1.5. It almost feels as if automatic recalibration has happened as well; the pointer seems unstable after a wake.

follow-up: ↓ 17   Changed 4 years ago by pgf

if the kernel does a touchpad resync, or loses sync, it will be recorded in dmesg.

the bulk of my testing was done with a CL1A laptop. i can retest with CL1 tomorrow.

in reply to: ↑ 16 ; follow-up: ↓ 21   Changed 4 years ago by Quozl

Replying to pgf:

if the kernel does a touchpad resync, or loses sync, it will be recorded in dmesg.

Recalibrating touchpad is appearing.


Tested in os852 with XO-1, using new-style touchpad.

Substantially different result to above; after the system wakes the finger move is reflected in pointer move of a suitable size in the direction selected. Moves in compass directions are reflected well. 45 degree diagonal moves are occasionally inaccurate, as if a movement direction is chosen early in the stream.

  Changed 4 years ago by pgf

it seems that the ALPS touchpad/controller (in CL1) does no buffering whatsoever. the EC buffers at most one byte. this means that exactly one complete 3-byte packet will get through in the face of flow control by the kernel. from the point of view of the EC, there will be one byte in the upstream (outgoing) register (that the kernel hasn't read, but which caused the wakeup), one in a temporary holding byte in the EC, and one in the incoming register). after that, any more data from the touchpad is discarded by the touchpad controller.

the synaptics pad and controller (in CL1A) does a bit better -- in addition to the "in flight" packet described above, it buffers one more complete mouse packet -- so the kernel will get two packets on a resume, instead of just one.

both of these are in contrast to the 15 or 20 mouse packets which make up a even a short swipe with the finger when the system is awake and ready to receive them.

summary: there's not much we can do in the very short term. longer term, the EC code being developed for 1.75 has queuing support, which will help with this a lot. whether we can backport the new code safely to the current laptops remains to be seen. it might also be worth looking at how to get the kernel to start reading bytes from the keyboard controller sooner upon resume.

(i'll be comparing this behavior on 1.5 next, to see why it feels better. i assume it's just because it wakes faster.)

  Changed 4 years ago by pgf

one more datapoint re: pentablet mode: ptmode packets are 6 bytes long, so on resume we won't even get a complete packet.

  Changed 4 years ago by pgf

behavior is the same on 1.5 (i.e., 2 packets from synaptics, 1 from alps), so i think any perceived improvement is simply the faster response to the initial touch.

in reply to: ↑ 17   Changed 4 years ago by Quozl

Replying to Quozl:

Tested in os852 with XO-1, using new-style touchpad.

(This build was withdrawn. 96379866c972367f40ec3e8accbaef49 os852.img)

  Changed 4 years ago by Quozl

  • milestone changed from 10.1.2 to 10.1.3

We have temporarily disabled idle suspend for os852, for this ticket and others, therefore we can push this ticket out to 10.1.3.

  Changed 4 years ago by erikos

  • milestone changed from 10.1.3 to Future Release

Moving out, decision in triage meeting. (still the case what James noted above)

  Changed 4 years ago by martin.langhoff

  • milestone changed from Future Release to 11.2.0-M4

  Changed 4 years ago by martin.langhoff

Revisit with F14 kernel

  Changed 3 years ago by pgf

  • next_action changed from diagnose to design

a new kernel won't improve this. new firmware could potentially help, in that it could buffer data while the kernel resumes.

  Changed 3 years ago by dsd

  • priority changed from high to low

  Changed 3 years ago by dsd

  • keywords retriage? added

I think this should be moved to Future Release enhancement; we need new firmware to fix this properly. It is also low-priority as idle suspend gets disabled by default on release builds on XO-1.

  Changed 3 years ago by martin.langhoff

  • milestone changed from 11.2.0-M4 to Future Release

  Changed 3 years ago by dsd

  • keywords retriage? removed
Note: See TracTickets for help on using tickets.