Cursor sometimes goes strange

[philipmac]

Sometimes the cursor on my B4 goes strange. A video will best explain it so here one is http://www.divshare.com/download/1582009-2db This sometimes happens just minutes after turning it on. And other times only after hours or not at all. However once it starts, only restarting the machine will make the cursor go back to normal. (the four finger salute doesn't fix it)

OLPC Build: 542

Kernal Version: Linux 2.6.22-20070801.5.olpc.be30006dad097b8

XO Firmware: CL1 Q2C22 Q2C

XO Serial Number: SHF72500529

[jg]

I've seen this on tamtam too.

[warp]

It would be useful if someone, on either machine showing this problem, could jump through a few hoops.

Firstly, start up the machine, get into the developer's console, and su - to be root.

Then add '*.* /var/log/syslog' to /etc/syslog.conf.

Then run '/etc/init.d/syslog restart'.

After that, try to reproduce the problem, once it is happening reliably, as root, 'echo 1 > /sys/module/psmouse/parameters/tpdebug'.

Make it jump around a few more times, then 'echo 0 > /sys/module/psmouse/parameters/tpdebug', and before rebooting get /var/log/syslog off the machine, and attach it to the bug report.

That will hopefully give me enough information to have a better idea of what's breaking.

[bernie]

I had seen this bug myself a few months ago (also on B3 laptops).

Now I'm afraid I couldn't reproduce it any more, not even on B4's. If anyone sees it on their laptops, please bring them to me.

[bernie]

I could reproduce it on one of Walter's B4 laptops.

I *think* I triggered it by exercising some pressure on the touchpad to get input from both pads at the same time.

Once the bug is triggered, gliding on the capacitive pad results in a jumping cursor (although not as reliable as in the movie).

I couldn't reproduce it on other laptops. Could anyone confirm or deny my finding?

[bernie]

Recalibrating with the "four fingers salute" does not fix the problem.

[bernie]

• Suspending and resuming does not make the problem go away
• Switching to console and back to X does not make the problem go away.

[dilinger]

I've been unable to reproduce this reliably. I saw it happen on my c1; however: a) I hadn't done any suspend/resume, b) I didn't see any errors from the kernel, and c) it reset/fixed itself after a few minutes. This was with q2c25 and build 556; the journal shows that I used the record activity, the turtleart activity, and pippy. After I closed pippy, it occurred.

[bernie]

Also happens in the console, with gpm. So it's not at the X level.

[dilinger]

Nah, what you saw in the console was simply the mouse incorrectly set. By default in X, it's the same way (small movements make the cursor go very far), but we correct that in X. What I saw was jerkiness without moving my finger; simply lifting my finger off the touchpad and putting it back down would make the cursor fly across the screen.

[dilinger]

BTW, you can tell by switching to X; the cursor is then fine. Switch back to console, and it's still unusable. That means it's just a miscalibrated mouse cursor. What I saw was in X, and didn't go away by switching to console.

[RafaelOrtiz]

Seams like calibration issue, i had not been able to reproduce this bug, but today because to the higher temperatures its clearly happening,from my point of view the recalibration of the capacitive sensor still has some issues.

[YChao]

I have several similar experiences before, but can't reproduce now right away. (B4 OS557 Q2C25) To me it looks more likely a timing problem as this once triggered when I sweap over very fast. Slow down or change the starting point sometimes helps. It seems that the controller or driver (?) thinks my finger is actually sweap back and forth instead of a connective forward. (any adaptive threshold here?) I'm wondering this could be improved by adjusting some timing or distance threshold?

ps. playing around by tapping fast enough at two different points on touchpad alternatively with two fingers, you will see the cursor sometimes goes back and forth but sometimes move along one direction. I used to use track point so not sure what situation should be normal.

[philipmac]

Here are the results of the test asked for above

[bernie]

I could reproduce it with wad's B3 too. New findings:

• Today it's rather colder, so it does not seem to be related to temperature (RafaelOrtiz may be observing a different bug on the trackpad?)

• I double checked and the bug *is* definitely reproducible in the console with gpm. (dilinger, this time I have smithbone as an eye witness ;-)

• Tomeau confirmed that the tamtam issue is totally unrelated: they move the mouse to the center of the screen intentionally.

[bernie]

I reproduced it in the console with dilinger.

Enabling debug in /sys/module/i8042/parameters/debug, we observed sequences of more than 6 bytes coming from the PS2 port while touching the trackpad. During normal operaion, each packet should be 6 bytes long.

Unfortunately, I couldn't reproduce this behavior after enabling logging to a file.

[bernie]

Yesterday we gave it another shot.

Debugging output on the EC port does not reveal much, not even with smithbone's trace dump enabled.

We believe the EC does not really decode the packets it's relaying, so the problem may be in the touchpad microcontroller.

To see if I'm right, I'm looking for a way to reset the uC without actually resetting Linux or the EC. Does anyone know how to do it? And what would I then do to re-initialize it?

I'm also going to have a quick look into the kernel code for handling the trackpad. Dilinger gave me some insight on it yesterday.

[bernie]

Can't reproduce with Q2C26... (just hidden, not fixed)

[philipmac]

I've got Q2C26, build 579 installed and I still seem to have the problem. It doesn't always flick to the bottom right corner of the screen like it used to. But instead sometimes flicks around half a screen length and sometimes to the side of the screen, when you remove your finger from the touchpad.

[bernie]

Replying to philipmac:

I've got Q2C26, build 579 installed and I still seem to have the problem.

So it depends both on the EC *and* kernel? Oh, dear!

It doesn't always flick to the bottom right corner of the screen like it used to. But instead sometimes flicks around half a screen length and sometimes to the side of the screen, when you remove your finger from the touchpad.

We may be seeing two different problems then.

The one I know very well and concentrated on is:

1) put your finger on the GS 2) the cursor jumps to the bottom-right corner of the screen 3) keep moving the finger and the cursor moves normally 4) raise your finger 5) GOTO 1

It's 100% repeatable once it starts.

Is this description anywhere similar to what your seeing?

[philipmac]

That description matched what used to happen. However when I upgraded the problem changed. The cursor now jumps to all parts of the screen. The four finger salute seems to make it not jump for around three slides of the finger but it starts up again after that.

[bernie]

Replying to philipmac:

That description matched what used to happen. However when I upgraded the problem changed. The cursor now jumps to all parts of the screen.

Ugh... I can't reproduce it on wad's laptop, the one that would do it all the time when I had Q2C26.

But I'm running build 582. Could you test with that and tell me what to see?

Do you remember if, before upgrading, you had Q2C26 already?

Do you do anything in particular to trigger the bug?

[philipmac]

Replying to bernie:

Ugh... I can't reproduce it on wad's laptop, the one that would do it all the time when I had Q2C26. But I'm running build 582. Could you test with that and tell me what to see?

I just upgraded to build 592. Is it alright if I use that or should I downgrade to 582.

Do you remember if, before upgrading, you had Q2C26 already?

I think I installed the new firmware when I upgraded to either 575 or 579. So it's possible.

Do you do anything in particular to trigger the bug?

I have no idea on how to trigger the bug. It just seems to start at different times and wont stop until a reboot.

[bernie]

Today erikos (Simon) told me on IRC that he has also seen the bug when he updated to OS588, while still running Q2C25.

And I'm damn sure I could trigger the bug off by just replacing the firmware (smithbone was with me).

So: it's triggered by a *combination* of OS and EC?

Simon, could you read the last 3-4 comments and confirm whether the symptoms resamble philipmac's description or mine?

And don't you dare coming up with yet another different behavior!

[Simon]

So on machine one the bug i described yesterday was the following: (similar/same to what is described in http://dev.laptop.org/ticket/2804#comment:20)

I had 581 running and firmware Q2C25. I upgraded the image to 588. The firmware was not upgraded. I did tests on the mesh view. The cursor was jumping wild to all the edges. Actually i had the 'strange cursor problem' on this machine a few weeks ago but it went away and was more like bernie describes in dev.laptop.org/ticket/2804#comment:19, though i never tested the procedure since it went away. I booted this machine this morning and it is all fine - the behavior went away without changing firmware or image.

[Simon]

So like described in the comment above I upgraded to image 588 using firmware Q2C25. So one machine had the behavior described above and the other one was fine. I booted the machine this morning and the one that never had problems started to show the strange cursor bug, well.

So what happens.

1) put your finger on the GS 2) the cursor jumps towards (not fully) to the bottom-right corner of the screen 2.2) keep moving the finger and the cursor moves normally 3) raise your finger, when you did not move it after putting on the GS it will jump back to the same position that it was before putting the finger on the GS, this behavior is consistent.

Another funny behavior is:

Hold your finger close to the GS but actually do not touch it. And like magic - you can still move the cursor. This does not happen on a machine with normal behavior. And even you are not even near the GS the cursor seems to move a little all the time.

I will do more tests as long as i can see this happening.

[bernie]

I can finally reproduce it again on my laptop!

Build 588, Q2C27. The behavior is exactly as described here:

https://dev.laptop.org/ticket/2804#comment:19

[Simon]

Replying to Simon:

so after a while (2-3 hours) the behavior has changed to https://dev.laptop.org/ticket/2804#comment:19, so it does not jump back to the actual starting position anymore.

[bernie]

As we all know, this bug is hard to reproduce, and tends to disappear when we try to instrument our code.

I'm working on the assumption that this bug, or at least one of its forms, is stateful: it's either "on" or "off" for a long time. So I'm looking for places where the PS2 code maintains context in global variables.

I have already reviewed the kernel side of the protocol, without spotting any obvious place where we may hold context.

The EC firmware appears to relay the PS2 data in passthrough, without doing any interpretation on it. Therefore, I think we may exclude it from our list of suspects.

So I'm getting suspicious at the keyboard and touchpad microcontroller, for which we have no source code. It would be nice if we could get it from Quanta, or ask them to do a similar review and report their findings.

Another useful test would be resetting the uC while the bug is "on" and see whether the bug survives or not.

[erikos]

It came back this morning after a while of not appearing anymore. So what discovered again is that I can move the mouse pointer even when <= 1.0 cm over the actual touchpad. So this makes me suspicious this is something to do with the touchpad.

[philipmac]

I've also had the "physic" touchpad which works when your finger is hovering near it. I didn't mention it before as I just though it was normal and it didn't bother me.

[philipmac]

sorry I meant psychic

[erikos]

Well it does not happen when the laptop is not in the 'funky cursor mode'. So I do not think this is a normal behavior :)

[MitchellNCharity]

616 q2c28 B4.

I had a jumpy mouse all afternoon. I assumed because I was using the xo in the misting, so the keypad was wet. It's now (a few ours later, but seems similar to earlier), 58 F and 95% relative humidity.

The usual failure modes:

• jump on touch
• mouse rebounds while dragging

Observed jump-on-touch early on. Humid, pad seemed generally dry, but finger was wet. Later, and throughout the afternoon, had rebound problems. Sometimes intermittent, sometimes making mouse use almost impossible. Pad was generally wet by then. I attempted to dry the surface of the pad a couple of times, but it's not clear it had any effect.

4-finger didn't help. I didn't try rebooting.

I was next to 1cc, so I brought it by, but someone thought the problem had been resolved, so I punted. Sorry.

On a related note: a few weeks ago I dunked and swished the base (battery and keyboard) in a pool. Sunny hot non-humid day. The mouse subsequently had rebound problems. The xo base was partially disassembled, blown on, and eventually the jumpiness went away. The jumpiness persisted though several "pause in disassemply, patch the pieces together, start it up, check to see if the mouse has recovered yet" reboots.

I'm rather surprised this ticket is Component 'x window system". I associate the problem with inclement weather, and so have always thought hardware.

[MitchellNCharity]

See also #4183, which classifies the current problem as hardware.

I was afraid this ticket, which is at least potentially a hardware blocker for MP Start, might (continue to?) get lost in the noise.

[AlbertCahalan]

See also bug #1068, "trackpad doesnt like sweat" and bug #4032 "Touchpad not that easy to use".

[MitchellNCharity]

617 q2d01 B4, and long standing. Reboundy cursor is easily reproduced.

Dripping some water on the mouse pad consistently gets you a reboundy cursor.

This once I tried the psychic cursor test. After a brief period of wetness (longer periods take time to dry out), I wiped, and got ~2 mm low-level psychic-ness. 4-fingers reset it. After a minute, I repeated the pattern (4-finger, hover does nothing, water drops, cursor is reboundy, wipe, hover moves cursor, 4-finger, back to normal).

I'm afraid I didn't check for jumpiness (jump on finger-down, rather than rebound on dragged finger up) until the third cycle. It was jumpy too, but far less than it is after a long soak. Higher psychic-ness this time, ~5 mm.

[MitchellNCharity]

Brainstorming some workarounds:

• Filter out the movement. Both oddities seem events of higher-than-normal cursor acceleration and velocity. Perhaps sugar could watch cursor movement, and one occurs, reset the cursor position to where it began.
• Allow the resistive pad to be used as a fallback. Map the resistive mouse pad to the entire screen, rather than just the top third. Either by 3x stretching of the entire vertical mapping, or by symmetric 3x stretching of one of the three pad tiles. At least when the strageness is caused by water exposure, the resistive pad continues to work even when the capacitive pad has become completely unusable.
• Allow the 8-way game pad to be used as a fallback. The 8-way pad might be used to steer the mouse around. Which would also be useful for surfing in ebook mode.

The 8-way pad idea would be useful in itself. The others would at least allow the laptop to continue to be used, even when the capacitive pad packs up.

[bernie]

We now it's definitely not related to X... Kernel may also be inaccurate, but more likely at this time.

[rsmith]

Gary and I have found root cause of this bug here at CSMC in China using C2 boards.

If the the touchpad in use at the time auto-recalibration occurs the calibration is wrong. Then the touchpad just starts spewing data.

Confirmed with a scope watching the touchpad clock and data lines.

Forcing a re-cal _sort_ of fixes the problem. It make the constant stream of data stop but after that the operation of the mouse is still really jumpy.

To duplicate just have your thumb on the touchpad at the time you do the 4 finger re-cal.

[bernie]

Replying to rsmith:

To duplicate just have your thumb on the touchpad at the time you do the 4 finger re-cal.

I can reproduce it to. Cool! Does it mean I can finally reassign this bug to someone else? :-)

[bernie]

Any news?

[bernie]

(I mean, should we reassign it to someone who is in touch with ALPS? Or can we fix it in the kernel somehow?)

[bernie]

We now have a better idea of what happens: for unknown reasons, the glide sensor switches into an erratic mode where it starts reporting the "finger down" event twice.

So we get two packets (instead of just one) with the absolute X and Y coordinates set to 0. The kernel driver filters out only the first one. The spurious event causes a large delta when subtracted from the next legitimate packet (the offset could be +200, +150).

Combined with mouse acceleration, this huge offset makes the cursor jump to the bottom-right corner of the screen.

A possible workaround would involve improving the gs_down test in drivers/input/mouse/olpc.c around line 146:

    if (psmouse->packet[0] == OLPC_PKT_PT && pt_down) {
        input_report_abs(dev, ABS_X, x);
        input_report_abs(dev, ABS_Y, y);
    } else if (psmouse->packet[0] == OLPC_PKT_GS && gs_down) {
        input_report_abs(dev2, ABS_X, x);
        input_report_abs(dev2, ABS_Y, y);
    }

[rbwjrw]

I have an g1g1 xo that consistently exhibits the jumpy cursor. None of the known workarounds produce any improvement--I tried a number of times over a couple of hours. This is a g1g1 unit right out of the box. Any chance a patch will be available for testing before the expiration of my 30 day RMA window, 18 Jan 08?

[rbwjrw]

Another symptom I see is that the cursor seems to sometimes "hit a wall" and will only move up or down. It's not actually just jumping to the lower-right corner. Can this also be explained by the double "finger down" report?

Ideally one would like to decipher the erratic mode reporting the "finger down" event twice, but, as a workaround (assuming that the two finger down events are coming at a rate which can truly be ruled out as a double-tap,) implement a digital debounce--maybe a gs_down_pending state which persists for a short duration would fix the problem. While in the gs_down_pending state dump the extra (0,0) reports and cache any non-(0,0) reports (if relative, dump if absolute.) The gs_down_pending state would exit after say 50ms--a time period too short to be a double tap. Apply any cached movements once the gs_pending state has exited.

[bernie]

This **lightly** tested kernel should fix the problem:

http://www.codewiz.org/~bernie/pub/olpc-bernie/i386/os/kernel-2.6.22-20071220.bernie14.olpc.0e089c0f.i586.rpm

Tentative patch here:

http://bender.codewiz.org/pub/patches/linux/pending/fix-cursor-occasionally-jumping-to-the-bottom-right.patch

To test, follow the installation instructions on our wiki:

http://wiki.laptop.org/go/Kernel#Installing_OLPC_kernel_RPMs

And in particular:

rpm -ivh kernel-....rpm
cp -a /boot/* /versions/boot/current/boot/

Additional info here:

http://wiki.laptop.org/go/Kernel http://wiki.laptop.org/go/Rebuilding_OLPC_kernel

[rbwjrw]

Just tried the new kernel per the commands above, but it doesn't seem to be booting:

[olpc@xo-0D-09-E2 rbw]$ ls -al /boot/
total 12575
drwxr-xr-x  3 root root       0 Dec 20 22:01 .
drwxr-xr-x 25 root root       0 Dec 20 22:16 ..
-rw-r--r--  2 root root  892883 Nov  2 08:00 System.map-2.6.22-20071121.7.olpc.af3dd731d18bc39
-rw-r--r--  1 root root  893099 Dec 20 10:00 System.map-2.6.22-20071220.bernie14.olpc.0e089c0f
lrwxrwxrwx  1 root root       6 Dec 14 02:51 actos.zip -> os.zip
lrwxrwxrwx  1 root root       6 Dec 14 02:51 actrd.zip -> rd.zip
-rw-r--r--  2 root root 1051218 Dec  4 23:37 bootfw.zip
-rw-r--r--  2 root root   50076 Nov  2 08:00 config-2.6.22-20071121.7.olpc.af3dd731d18bc39
-rw-r--r--  1 root root   50076 Dec 20 10:00 config-2.6.22-20071220.bernie14.olpc.0e089c0f
drwxr-xr-x  2 root root       0 Nov  2 08:00 grub
-rw-r--r--  2 root root     453 Nov  2 08:00 olpc.fth
-rw-r--r--  2 root root       4 Nov  2 08:00 olpc_build
-rw-r--r--  2 root root 2495514 Nov  2 08:00 olpcrd-2.6.22-20071121.7.olpc.af3dd731d18bc39.img
lrwxrwxrwx  1 root root      49 Dec 14 02:51 olpcrd.img -> olpcrd-2.6.22-20071121.7.olpc.af3dd731d18bc39.img
-rw-r--r--  2 root root 1647266 Dec  4 23:37 os.zip
-rw-r--r--  2 root root 2496972 Dec  4 23:37 rd.zip
lrwxrwxrwx  1 root root       6 Dec 14 02:51 runos.zip -> os.zip
lrwxrwxrwx  1 root root       6 Dec 14 02:51 runrd.zip -> rd.zip
lrwxrwxrwx  1 root root      46 Dec 20 22:01 vmlinuz -> vmlinuz-2.6.22-20071220.bernie14.olpc.0e089c0f
-rw-r--r--  2 root root 1645808 Nov  2 08:00 vmlinuz-2.6.22-20071121.7.olpc.af3dd731d18bc39
-rw-r--r--  1 root root 1646992 Dec 20 10:00 vmlinuz-2.6.22-20071220.bernie14.olpc.0e089c0f
[olpc@xo-0D-09-E2 rbw]$ uname -r
2.6.22-20071121.7.olpc.af3dd731d18bc39

It's been a while since I've dealt with the kernel (first time with olpc,) but the links seem OK to me. Am I missing something?

Any suggestions?

[rbwjrw]

Missing olpcrd-2.6.22-20071220.bernie14.olpc.0e089c0f.img file?

[rbwjrw]

'rpm -qlp kernel... | grep img' shows that '/boot/initrd...bernie14.olpc.0e089c0f.img' exists, but all attempts to extract if are failing. (including rpm2cpio.)

[bernie]

Replying to rbwjrw:

'rpm -qlp kernel... | grep img' shows that '/boot/initrd...bernie14.olpc.0e089c0f.img' exists, but all attempts to extract if are failing. (including rpm2cpio.)

That is a just a file that the rpm "owns". On the regular Fedora kernel package, it is generated by mkinitrd as part of the post-install scriptlet.

But we do not use mkinitrd, because the OLPC boots off a custom initrd for the anti-theft system. This image is kernel independent and thus does not not need updating along with the kernel package.

rbwjrw: I tested this kernel on a Joyride system. It may be the case that it is not compatible with OS650 (Ship.2). I'll test tomorrow and in case I'll provide an older kernel with this same fix.

[rbwjrw]

I got a developer key installed and the new kernel installed fine. Unfortunately, this did not fix the touchpad/cursor issues I am experiencing.

I am witnessing large horizontal jumps and sometimes "hitting a wall" like I mentioned above--failure to move horizontally, only vertical movements register even when moving left-right on the touchpad. Lifting off and touching again restores horizontal movement, but nothing fixes the large horizontal jumps. Even the four-finger recal fails to improve performance.

I have captured and attached a syslog file according to the instructions above.

[bernie]

Replying to rbwjrw:

I am witnessing large horizontal jumps and sometimes "hitting a wall" like I mentioned above--failure to move horizontally, only vertical movements register even when moving left-right on the touchpad. Lifting off and touching again restores horizontal movement, but nothing fixes the large horizontal jumps. Even the four-finger recal fails to improve performance.

This seems like a completely new failure mode, not the one I was trying to cure. Could you confirm or deny that whay you describe is different from this video?

http://www.divshare.com/download/1582009-2db

I have captured and attached a syslog file according to the instructions above.

In this log, I see many instances of the "x=0, y=0" case I was trying to cure. I also see several events with the same x coordinate, but it's hard to tell what happened without a description of what you were doing.

Could you make a video?

[bernie]

Dilinger has also been working on a threshold based fix for this problem:

http://dev.laptop.org/~dilinger/olpc-60px-thresh.patch

I'll build a test kernel for you with this fix applied if we get stuck along this path.

[rbwjrw]

Sylog synced with video

[rbwjrw]

video synced with syslog.3

[rbwjrw]

I've attached another syslog and a video. I didn't touch the touchpad until I'd started the video so hopefully this will help correlate the state.

[bernie]

Replying to rbwjrw:

I've attached another syslog and a video. I didn't touch the touchpad until I'd started the video so hopefully this will help correlate the state.

After watching the video, I confirm I have never seen this particular kind of touchpad bug. It looks closer to #4554 than this bug, but failing to move horizontally is really unheard of. I doubt my fix and dilinger's can help here.

If it's a calibration issue, smithbone is working with ALPS to find a solution.

[voden]

We just received our g1g1 build 650 and it is consistently exhibiting the exact problem identified by the original poster (philipmac). I'm willing to test Bernie's fix, but want to make sure I don't disable the olpc in the course of testing. If I understand the procedure, it is to:

1. Copy the file kernel-2.6.22-20071220.bernie14.olpc.0e089c0f.i586.rpm to /home/olpc 2. In the terminal app, execute the commands:

rpm -ivh kernel-2.6.22-20071220.bernie14.olpc.0e089c0f.i586.rpm cp -a /boot/* /versions/boot/current/boot/ reboot

Please confirm the above. If the patched kernel proves unusable, what is the rollback procedure? Thanks.

[TimButler]

Our new g1g1 exhibits this problem. The behavior matches that described above in which a single tap sends the mouse cursor to the lower right hand corner of the screen. This happens spuriously whenever moving the mouse.

One workaround is to use a usb mouse.

We are willing to try a fix, as this problem makes the machine unusable through the touchpad.

Rebooting did not help.

-tim

[bernie]

Replying to voden:

Please confirm the above. If the patched kernel proves unusable, what is the rollback procedure? Thanks.

I confirm, but the kernel I provided most probably also requires a recent joyride image. Joyride is our development branch, and requires a developer key to install.

Once you have a developer key, you can easily upgrade, downgrade and reflash your laptop using a USB stick and instructions found on the wiki. Careful, some documentation is out of date and needs cleanup.

If you need further assistance, I'm _bernie on IRC channel #olpc on Freenode.

[bernie]

Add voden, TimButler, rbwjrw to the Cc list, so they get replies by email.

If you find the bugmail annoying, just remove your name from the Cc list.

[bernie]

Replying to TimButler:

We are willing to try a fix, as this problem makes the machine unusable through the touchpad.

See comment:61 and comment:54.

[bernie]

This test build is a fork of joyride which includes my test kernel and a few other reasonably stable changes:

http://bender.codewiz.org/pub/olpc/streams/xtest/build13/devel_jffs2/

You still need a developer key to use it, but it should be easier to install.

[bernie]

rbwjrw, the bug you describe is *exactly* the same of #5575 ! Sorry for not recognizing this before. Please follow up there from now on so we threat different symptoms as different bugs.

Also, are you perhaps Robert B. W.? If so, the technical support people forwarded me your offer to help. Please contact me at bernie AT codewiz DOT org, or find me as _bernie in channel #olpc on Freenode.

[bernie]

I rolled a new xtest image:

http://bender.codewiz.org/pub/olpc/streams/xtest/build13/devel_jffs2/

I've booted it on my pre-MP laptop and tested it for a while by running the browser and a few other activities. Please test on a laptop that exhibits this bug (cursor sometimes jumps to the bottom-right corner of the screen).

[TimButler]

We actually have two laptops and only one laptop exhibited the touchpad problem. However, now the problem has stopped. I've applied for a developer key (on both machines) and will continue to try and reproduce the problem.

Thanks for the quick response in any case.

[TimButler]

Replying to bernie:

We now have a better idea of what happens: for unknown reasons, the glide sensor switches into an erratic mode where it starts reporting the "finger down" event twice. A possible workaround would involve improving the gs_down test in drivers/input/mouse/olpc.c around line 146:

I would like to suggest a configuration to optionally ignore *all* "finger down" events from the touchpad. For me, and I suspect in many applications, a button click is sufficient and actually more precise and desirable -- especially in the presence of erratic "finger down" events. This might be a more reliable workaround for most people.

I know I've had problems with false "finger down" events on touchpads on other kinds of computers, perhaps because our dry winter air promotes the accumulation of electrostatic charges. I always end up disabling the "finger down" event anyway.

[TimButler]

Replying to TimButler:

Replying to bernie:

I would like to suggest a configuration to optionally ignore *all* "finger down" events from the touchpad.

Sorry, I just realized I was probably confusing computed "tap" events with raw "finger down" events and that my suggestion to completely ignore "finger down" events would not make any sense.

[voden]

The problem wasn't as consistent on our OLPC as I thought. It persisted on the first day of usage through several reboots (initiated via command in the terminal app) and "four-finger salutes". However it disappeared after shutting down for the night and starting again the following day, and has not reappeared the third day.

[bernie]

New image you may want to test:

http://bender.codewiz.org/pub/olpc/streams/xtest/build15/devel_jffs2/

(build 13 inherited networking problems from joyride)

[Twinkle]

If it helps at all, I've actually seem to have corrected this issue a few times by pressing hard on the trackpad near the corner or edge to which the cursor tends to jump.

[dysumner]

Replying to Twinkle:

If it helps at all, I've actually seem to have corrected this issue a few times by pressing hard on the trackpad near the corner or edge to which the cursor tends to jump.

I have purchased 3 XO's for various people, including one for myself. All three have had this problem, intermittently. The two problems are the mouse jumping to the lower right corner (with log saying it sets to x=0, y=0) and occasionally, the mouse tracks a finger that is hovering over the track pad. Like Twinkle, we can often get the problem to go away by wiping a palm across the entire track pad several times or by holding a finger firmly on the track pad. Neither of these solutions works reliably every time, but so far repeating these and wiping our fingers on something else have always resulted in a useable trackpad with less than 10 attempts (I haven't really been counting). The behavior strongly suggests to me that there is a charge or capacitor problem.

[holt]

Bernie suggests the pointer doesn't always jump to the bottom-right (SE) of the screen, but rather this depends where your finger contacts the touchpad.

I.E. the predominant bug behavior is indeed: putting your finger in the middle of the touchpad, usually results in a jump to the bottom-right (SE).

However: putting your finger on the far left side of the touchpad (technically that's the ~5cm wide capacitive GS/glide sensor, below the right-side of the space bar), may result in a jump to the botton-left (SW) of the screen.

[Erregend]

Replying to bernie:

New image you may want to test: http://bender.codewiz.org/pub/olpc/streams/xtest/build15/devel_jffs2/ (build 13 inherited networking problems from joyride)

Loaded the above: xtest 15 & Q2D07 on a G1G1 XO that suffered badly from this problem.

Since install, the touchpad is working properly. It has only been an hour or so of playing with it. I will report here if problem returns.

Tom

[Erregend]

Replying to Erregend:

Loaded the above: xtest 15 & Q2D07 on a G1G1 XO that suffered badly from this problem. Since install, the touchpad is working properly. It has only been an hour or so of playing with it. I will report here if problem returns.

Did not have touchpad problems, but network appeared flakey and since "root" has a password which I do not know, I reverted to 653.

Tom

[bernie]

Replying to Erregend:

Replying to Erregend:

Did not have touchpad problems, but network appeared flakey and since "root" has a password which I do not know, I reverted to 653.

In new builds (xtest, update.1, and joyride), we disabled the root password. Now you should use "sudo -s" to login.

Network problems may be expected with the latest builds due to lots of libertas and NetworkManager work.

Please try this build which is basically 653 plus a few very critical fixes and the touchpad fix:

http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build656/devel_jffs2/

[Erregend]

Replying to bernie:

In new builds (xtest, update.1, and joyride), we disabled the root password. Now you should use "sudo -s" to login. Network problems may be expected with the latest builds due to lots of libertas and NetworkManager work. Please try this build which is basically 653 plus a few very critical fixes and the touchpad fix: http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build656/devel_jffs2/

Downloading as I type... Will report results.

Tom

[Erregend]

Replying to bernie:

In new builds (xtest, update.1, and joyride), we disabled the root password. Now you should use "sudo -s" to login. Network problems may be expected with the latest builds due to lots of libertas and NetworkManager work. Please try this build which is basically 653 plus a few very critical fixes and the touchpad fix: http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build656/devel_jffs2/

Over 2 hours of use and no touchpad anomolies. No other differences from 653 have been noted. If problems show up I will re-post.

Tom

[bernie]

Is this in Update.1 already?

[dgilmore]

we have a kernel from yesterday in update.1 so probably. but i am not going to track down and see if that particular patch is in the build.

[eeksock]

FWIW, I still see the original described behavior in the video in Joyride-1575, after a resume after a long suspend period. If it happens again I'll try and grab the logs.

[homunq]

I'm not sure if this is the same bug, or #3592, or something else. Machine is C2 with q2d11 and joyride-1621.

I have a "modal" bug where as your finger first touches/approaches the touchpad, the cursor moves rapidly up and to the left, then back down and to the right when you take your finger off. Sometimes this does not happen, and sometimes the movement is only horizontal. Tends to happen somewhat less if you put your finger down/up rapidly. Total quantity of movement generally between 1/2 and 1 screen height in each dimension. As you move your finger across the edge of the sensitive area, the same symptom occurs. Generally the bug appears about 5-10% of the time and seems to appear in clusters - even restarting did not fix it on one occasion. I am now updating to 691 to see if this still happens.

[bernie]

Replying to dgilmore:

we have a kernel from yesterday in update.1 so probably. but i am not going to track down and see if that particular patch is in the build.

My original patch has been in the stable kernel since Jan 18, so it ought to be fixed.

Replying to eeksock:

FWIW, I still see the original described behavior in the video in Joyride-1575, after a resume after a long suspend period. If it happens again I'll try and grab the logs.

Does it only happen under these conditions? If so, it may be a different bug. Before, the bug did not require suspending the machine. Please, describe the symptoms you see as precisely as you can.

[bernie]

Replying to homunq:

I'm not sure if this is the same bug, or #3592, or something else. Machine is C2 with q2d11 and joyride-1621. I have a "modal" bug where as your finger first touches/approaches the touchpad, the cursor moves rapidly up and to the left, then back down and to the right when you take your finger off.

This sounds like the calibratiion bug: http://wiki.laptop.org/go/Recalibrating_Touchpad

[bernie]

The fix has been in Update.1 for a long time now, and it seems to work. So I guess we can finally close this!

[mikus]

Here is a report which seems to contradict some of what has been discussed above:

G1G1, Q2D16, Joyride 2146.

Noticed that my cursor was "jumpy" (especially with a particular application). If I remember correctly, it was not jumpy with Joyride 2056. By "jumpy" I mean that for a small movement of the mouse, the cursor "jumps" a greater amount than expected -- and not always in the same direction as the mouse movement.

What makes this unusual is that I'm running my system with an USB mouse -- my hands are nowhere near the XO and its touchpad. And I think it unlikely that the circuitry in my optical mouse has deteriorated.

[I'm probably wrong - but what I'm thinking of is that the "data packet content" describing the physical mouse movement is being incorrectly interpreted by the SOFTWARE responsible for "placement" of the cursor.]

[ixo]

FYI,

Joyride 2208, still found my cursor to be jumpy... reproducible ...

and short term solution !

FIX:

Four finger touch-pad reset.

CAUSE:

Using 'common' laptop shortcuts found on other higher end laptops.

* Touch-drag... release, tap (same as 'mouse-click') * Double-tap (same as 'mouse-double-click').

After repeating the above a few times, the touch-pad goes 'wonky' . ;-)