{12} Detailed changes to bugs tagged release? (916 matches)

Pull out details of the recent changes to release-critical bugs for convenient release management.

Results (1 - 100 of 916)

1 2 3 4 5 6 7 8 9 10

#1407: Touchpad recalibration should be forced under some circumstances. (43 matches)

Ticket Author Date Created Field Description
#1407 David.Lin May 7, 2007 9:00:50 PM comment

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

#1407 jg May 7, 2007 10:26:47 PM comment

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

#1407 rsmith May 8, 2007 12:45:19 PM comment

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?

#1407 jg May 9, 2007 5:01:06 PM comment

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.

#1407 jg May 9, 2007 5:01:06 PM keywords

Eben

#1407 jg May 18, 2007 10:32:27 AM owner

rsmith

#1407 jg May 18, 2007 10:32:27 AM verified

0

#1407 jg May 18, 2007 10:32:27 AM comment

http://wiki.laptop.org/go/Touch_Pad/Tablet 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.

#1407 jg May 18, 2007 10:32:27 AM cc

Eben, dilinger, David.Lin

#1407 jg Jul 22, 2007 1:05:42 PM component

power manager (OHM)

#1407 jg Jul 22, 2007 1:05:42 PM comment

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.

#1407 jg Jul 22, 2007 1:05:42 PM milestone

Trial-3

#1407 cjb Jul 22, 2007 8:31:17 PM cc

Eben, dilinger, David.Lin, cjb

#1407 cjb Jul 22, 2007 8:31:17 PM comment

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?

#1407 warp Jul 22, 2007 9:20:01 PM comment

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.

#1407 rsmith Jul 22, 2007 10:08:55 PM comment

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.

#1407 rsmith Jul 22, 2007 10:08:55 PM owner

hughsient@…

#1407 cjb Jul 24, 2007 10:47:13 PM comment

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.

#1407 jg Aug 13, 2007 9:27:25 AM comment

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

#1407 jg Oct 1, 2007 1:23:16 PM owner

cjb

#1407 cjb Oct 1, 2007 1:49:34 PM owner

dilinger

#1407 cjb Oct 1, 2007 1:49:34 PM component

kernel

#1407 cjb Oct 1, 2007 1:49:34 PM comment

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

#1407 jg Oct 8, 2007 3:32:21 PM milestone

First Deployment, V1.0

#1407 wmb@firmworks.com Oct 30, 2007 10:00:02 PM priority

blocker

#1407 wmb@firmworks.com Oct 30, 2007 10:00:02 PM milestone

Update.1

#1407 wmb@firmworks.com Oct 30, 2007 10:00:02 PM owner

cjb

#1407 cjb Oct 30, 2007 10:02:33 PM owner

dilinger

#1407 cjb Oct 30, 2007 10:02:33 PM comment

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

#1407 bernie Dec 31, 2007 4:12:03 AM cc

Eben, dilinger, David.Lin, cjb, bernie

#1407 Blaketh Mar 20, 2008 11:08:49 PM keywords

release?

#1407 cjb Mar 21, 2008 1:48:04 AM comment

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

#1407 cjb Mar 21, 2008 1:48:04 AM cc

Eben, dilinger, David.Lin, cjb, bernie, Blaketh

#1407 mstone Mar 21, 2008 2:39:07 AM comment

cjb: he was assisting me: see http://dev.laptop.org/report/11 and http://dev.laptop.org/report/12

#1407 mstone May 2, 2008 12:18:00 AM keywords

release? touchpad

#1407 kimquirk Oct 26, 2008 7:23:58 PM spec_stage

unknown

#1407 kimquirk Oct 26, 2008 7:23:58 PM spec_reviewed

0

#1407 kimquirk Oct 26, 2008 7:23:58 PM comment

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

#1407 kimquirk Oct 26, 2008 7:23:58 PM next_action

never set

#1407 jg Oct 26, 2008 9:43:27 PM comment

NO!

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

#1407 tom Nov 20, 2010 2:28:03 PM comment

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.

#1407 pgf Nov 20, 2010 4:44:47 PM comment

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.

#1407 erikos Nov 22, 2010 3:37:37 AM comment

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.

#2804: Cursor sometimes goes strange (57 matches)

Ticket Author Date Created Field Description
#2804 jg Aug 15, 2007 10:42:31 AM cc

philipmac1@…, dilinger

#2804 jg Aug 15, 2007 10:42:31 AM component

x window system

#2804 jg Aug 15, 2007 10:42:31 AM owner

bernie

#2804 jg Aug 15, 2007 10:42:31 AM priority

blocker

#2804 jg Aug 15, 2007 10:42:31 AM milestone

Trial-3

#2804 jg Aug 15, 2007 10:42:47 AM comment

I've seen this on tamtam too.

#2804 warp Aug 15, 2007 12:53:47 PM comment

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.

#2804 bernie Aug 22, 2007 7:26:38 PM comment

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.

#2804 bernie Aug 24, 2007 10:26:03 AM comment

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?

#2804 bernie Aug 24, 2007 10:27:43 AM comment

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

#2804 bernie Aug 24, 2007 10:29:04 AM cc

philipmac1@…, dilinger, walter

#2804 bernie Aug 24, 2007 10:29:04 AM comment
  • Suspending and resuming does not make the problem go away
  • Switching to console and back to X does not make the problem go away.
#2804 dilinger Aug 24, 2007 4:06:56 PM comment

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.

#2804 bernie Aug 24, 2007 9:47:32 PM comment

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

#2804 dilinger Aug 24, 2007 9:54:10 PM comment

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.

#2804 dilinger Aug 24, 2007 9:55:20 PM comment

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.

#2804 RafaelOrtiz Aug 26, 2007 9:35:20 AM comment

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.

#2804 YChao Aug 29, 2007 8:48:02 PM comment

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.

#2804 bernie Aug 31, 2007 11:26:24 AM status

assigned

#2804 bernie Aug 31, 2007 11:26:24 AM comment

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.
#2804 bernie Sep 4, 2007 11:05:01 AM comment

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.

#2804 bernie Sep 6, 2007 11:29:39 AM comment

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.

#2804 bernie Sep 6, 2007 11:29:39 AM cc

philipmac1@…, dilinger, walter, richard

#2804 bernie Sep 13, 2007 8:07:11 PM comment

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

#2804 philipmac Sep 18, 2007 8:39:38 PM comment

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.

#2804 bernie Sep 18, 2007 9:29:46 PM comment

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?

#2804 philipmac Sep 18, 2007 9:38:52 PM comment

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.

#2804 bernie Sep 18, 2007 9:52:27 PM comment

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?

#2804 philipmac Sep 18, 2007 10:01:27 PM comment

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.

#2804 bernie Sep 19, 2007 12:45:04 AM comment

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!

#2804 bernie Sep 19, 2007 12:45:04 AM cc

philipmac1@…, dilinger, walter, richard, Simon

#2804 Simon Sep 19, 2007 5:25:29 AM comment

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.

#2804 Simon Sep 19, 2007 5:37:57 AM comment

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.

#2804 bernie Sep 19, 2007 9:11:46 AM comment

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

#2804 Simon Sep 19, 2007 9:48:40 AM comment

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.

#2804 kimquirk Sep 26, 2007 11:51:52 AM milestone

First Deployment, V1.0

#2804 bernie Sep 26, 2007 2:53:06 PM comment

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.

#2804 erikos Oct 5, 2007 4:36:48 AM comment

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.

#2804 erikos Oct 5, 2007 4:36:48 AM cc

philipmac1@…, dilinger, walter, richard, erikos

#2804 philipmac Oct 5, 2007 6:01:23 AM comment

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.

#2804 philipmac Oct 5, 2007 6:02:18 AM comment

sorry I meant psychic

#2804 erikos Oct 5, 2007 6:14:54 AM comment

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

#2804 MitchellNCharity Oct 11, 2007 7:00:57 PM comment

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.

#2804 MitchellNCharity Oct 11, 2007 7:46:46 PM comment

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.

#2804 AlbertCahalan Oct 13, 2007 12:29:22 AM comment

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

#2804 MitchellNCharity Oct 22, 2007 1:10:27 AM comment

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.

#2804 MitchellNCharity Oct 22, 2007 1:32:32 AM comment

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.

#2804 bernie Nov 1, 2007 10:43:06 PM comment

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

#2804 bernie Nov 1, 2007 10:43:06 PM component

kernel

#2804 rsmith Nov 17, 2007 6:11:25 AM comment

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.

#2804 rsmith Nov 17, 2007 6:11:25 AM component

hardware

#2804 bernie Nov 17, 2007 12:07:09 PM comment

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? :-)

#2804 bernie Nov 19, 2007 4:56:24 PM comment

Any news?

#2804 bernie Nov 19, 2007 4:56:52 PM comment

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

#2804 mstone Dec 5, 2007 1:01:29 AM cc

philipmac1@…, dilinger, walter, richard, erikos, mstone

#2804 kimquirk Dec 9, 2007 11:39:17 PM keywords

relnote

#2804 bernie Dec 20, 2007 12:45:42 AM comment

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);
    }
1 2 3 4 5 6 7 8 9 10
Note: See TracReports for help on using and creating reports.