Opened 10 years ago

Last modified 6 years ago

#1407 new defect

Touchpad recalibration should be forced under some circumstances.

Reported by: jg Owned by: dilinger
Priority: blocker Milestone: 8.2.0 (was Update.2)
Component: kernel Version:
Keywords: release? touchpad Cc: Eben, dilinger, David.Lin, cjb, bernie, Blaketh
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no


As of BTest-3 (and possibly BTest-2-2), the Touch pad should periodically recalibrate itself automatically.

However, Shiga-san says ideally, the touchpad needs recalibration whenever the XO-1 goes onto, or off of external power source. A command to the touchpad was added to enable this recalibration to the later touchpads.

The touchpad might also need recalibration after long sleep, but as we're not removing power, I don't see why this would be true.

Ideally, the embedded controller should trigger this recalibration, as otherwise, I can see it as a (not very serious) denial of service problem if this is possible from user space.

Change History (26)

comment:1 Changed 10 years ago by David.Lin

I don’t know what you need. Please explain more specifically.

comment:2 follow-up: Changed 10 years ago by jg

New commands to the touchpad/tablet were added: see the section titled "Sensor calibration execution command" in the touchpad specification.

comment:3 in reply to: ↑ 2 Changed 10 years ago by rsmith

Replying to jg:

New commands to the touchpad/tablet were added: see the section titled "Sensor calibration execution command" in the touchpad specification.

Is it necessary to involve the EC in this? The OS can just send the recalibrate command to the touchpad directly. The OS may have a better idea of when this needs to be redone?

What conditions are you thinking we will need to recal under?

comment:4 Changed 10 years ago by jg

  • Keywords Eben added

I guess I'm not sure what we should do.

We can add a EC command to send recalibrate to the touchpad and do it all from user space. Here's some things to think about.

o calibration takes a bit of time, and there will be a flurry of

activity after resuming from a suspend with the lid down (which should be one way to indicate you want a conventional suspend operation. We want to make sure it happens before the machine is opened far enough that it might be touched by the child. But I don't know if we'll have to recalibrate at all in this case, given we're not powering down the touchpad. This may require some investigation shortly.

o if the child has their finger on the touchpad when they go on or off of power, then the recalibration will not work properly. You can look at the spec in the wiki for details. What a UI should do to tell the child to remove their finger is another issue.

comment:5 Changed 10 years ago by jg

  • Cc Eben dilinger David.Lin added
  • Keywords Eben removed
  • Owner changed from David.Lin to rsmith
  • Verified unset has the ALPS document.

ShigaSan also has requested when I met with him during the B2 build we send a recalibrate command when we go onto or off of power (to avoid having to wait for autorecalibration).

I'd suggest we *may* also do after opening the lid (or leaving ebook mode) as insurance. This is to cause the re-calibrations to occur when the capacitance of the environment is likely to have changed. But this may require experimentation to see.

Whether we should do this all in the EC, in the ALPS kernel driver, or in the Hardware manager is not at all clear to me. Let's set up a time to talk through the options.

comment:6 follow-up: Changed 9 years ago by jg

  • Component changed from embedded controller to power manager (OHM)
  • Milestone changed from Trial-2 to Trial-3

Now that we have a real hardware manager, this seems like the easy way to do it, so long as sending the command requires root

The time to do this is whenever the power comes and goes, or when the lid is opened. Ideally, we should check if the touchpad has recently sent events (but I don't know how to do that easily from X: there is no "when was the last input device event sent" request in the window system. To start, we're probably best off to KISS, do the really simple things, and defer that piece of it for some future date.

This is OLPC specific: Richard, you are welcome to push it back on cjb's queue for Trial-3.

comment:7 Changed 9 years ago by cjb

  • Cc cjb added

I suggest doing this from kernelspace, anytime we receive an SCI. Lid open, power insertion/removal both trigger SCIs, as well as ebook mode switch and battery state changes. If we don't want it to happen on *every* SCI, it's easy to insert it into the right place in the switch/case for SCIs.

Andres, what do you think?

comment:8 Changed 9 years ago by warp

This needs to be a kernel driver bug first, we should figure out hooks for both userspace and kernelspace triggering a recalibration, and we might as well figure out how to signal suspend/wakeup (for the C-test touchpads) from both as well.

We'll probably use a sysfs file or two for userspace.

comment:9 in reply to: ↑ 6 ; follow-up: Changed 9 years ago by rsmith

  • Owner changed from rsmith to hughsient@…

Replying to jg:

This is OLPC specific: Richard, you are welcome to push it back on cjb's queue for Trial-3.

Since this was made a OHM thing I think it needs to be assigned to Richard Hughs rather than Richard Smith. The EC is only a bystander here. Commands sent to the keyboard/touchpad are just store and forward for the EC.

comment:10 in reply to: ↑ 9 Changed 9 years ago by cjb

Replying to rsmith:

Since this was made a OHM thing I think it needs to be assigned to Richard Hughs rather than Richard Smith.

.. but I suggested that we do it in the kernel instead of OHM, and haven't had any feedback yet, so I'd like to hear from Andres before we move to userspace.

comment:11 Changed 9 years ago by jg

See bug #2770 and #2613. We should power down in ebook mode (and when the laptop is closed).

comment:12 Changed 9 years ago by jg

  • Owner changed from hughsient@… to cjb

comment:13 Changed 9 years ago by cjb

  • Component changed from power manager (OHM) to kernel
  • Owner changed from cjb to dilinger

This bug isn't ready for me yet; there's no exposed kernel implementation.

comment:14 Changed 9 years ago by jg

  • Milestone changed from Untriaged to First Deployment, V1.0

comment:15 Changed 9 years ago by wmb@…

  • Milestone changed from Update.2 to Update.1
  • Owner changed from dilinger to cjb
  • Priority changed from high to blocker

comment:16 Changed 9 years ago by cjb

  • Owner changed from cjb to dilinger

This should not be set to me (OHM) until the kernel has exposed a way for userspace to force recalibration.

comment:17 Changed 9 years ago by bernie

  • Cc bernie added

comment:18 Changed 9 years ago by Blaketh

  • Keywords release? added

comment:19 Changed 9 years ago by cjb

  • Cc Blaketh added

Blaketh: What do you mean by "release"? Why did you add this to several bugs?

comment:21 Changed 9 years ago by mstone

  • Keywords touchpad added

comment:22 Changed 8 years ago by kimquirk

  • Action Needed set to never set
  • spec_reviewed set to 0
  • spec_stage set to unknown

I think this has been added in 8.2 release - auto-recalibration. Can we close this?

comment:23 Changed 8 years ago by jg


We do not yet force a recalibration in all the circumstances described above!

comment:24 Changed 6 years ago by tom

I'm currently having six XO-1s here. All of them have severe problems with their touchpads. It takes about 5-10 minutes until the trackpad starts behaving "funny". Doing the four finger salute solves the problem for another couple of minutes. Then the "funny" behavior starts again. Currently the only way to solve the problem is to add a usb-mouse. They had the problem before I upgraded them to build 852, nothing has changed since then. Happens under Sugar as well as under Gnome. It can easily be reproduced. Start the XO, start moving the mouse, do this for some time, et voila. Happens every time on all six XOs.

comment:25 Changed 6 years ago by pgf

the touchpad in the first generation of XO laptops was/is basically junky. that's being charitable. i did a lot of work on the driver about a year ago which seemed to help, but not everyone sees it. you, apparently, are one of them. :-) :-/ one thing that was sort of discovered by accident by some kids in haiti that didn't like the "feel" of the touchpad is to put a sticker, or tape, over the touchpad. there's even a size of post-it that fits the touchpad area pretty exactly. it seems that by moving the finger just a bit further from the pad, the jumpiness is reduced. this is incredibly subjective, obviously, but i'd like to hear your opinion, especially since you have a collection of laptops on which to try it.

for the record, we still don't do the recalibrations suggested in the bug description. we do automatic recals in the case of detecting a lot of "bad" behavior, when the driver can reliably identify such behavior, and i believe we recalibrate if the laptop wakes on lid open.

comment:26 Changed 6 years ago by erikos

Hi Tom, you might be interested in contributing to #10373. I have as well laptops where I can reproduce the issue (the two B4 are highly affected by this, less the C2). I tried scotch tape with not much success (did not try other tape sorts), and use mice now as this leaves no room for speculation and no disruption in class and the kids can happily work away.

Note: See TracTickets for help on using tickets.