Ok, most of us know about this problem but I've not heard of any solution and I am becoming convinced that it is a software issue and not just a hardware/design flaw....

If one were to hold on the trackpoint, pushing it in one direction or another for too long, the computer starts to take control over the pointer and it fights against the direction you want to go. If you let go at this point entirely, the mouse cursor moves all on it's own.

A work-around so far, is to occasionally let go of the trackpoint during use, and if you do this often enough, the problem just doesn't happen in the first place. But sometimes it's easy to forget this, and when that happens, it's an annoyance to an otherwise awesome design that overall just works...

I want to work with the community on fixing this if we can, or getting help from the developers/drivers if need be.

One thing, I have noticed, is that if you get the problem to occur (or purposely strive to re-produce the issue) the only way to get it to stop is to wait several seconds until the cursor completely stops moving.  If you try to fight against the cursor, or move in any direction, you just end up delaying the amount of time it takes for the issue to go away, so it's best to just sit and wait it out for a second while this is happening.  You could literally keep interrupting/fighting against it, and it will continue on in error until you give up.  Because of this, I suspect that an adjustment in software or drivers might make it possible to completely correct this nagging and long standing issue that if I am not mistaken, spans multiple Lenovo systems (not just the X220), but I could be wrong on this, I only have this machine to test....

When I first looked up this problem a while back, one poster mentioned that it's part of the design of the stick, counterbalancing itself, but since if even you help it and push it in the direction it wants to go, it still continues in error until you simply wait a period of time.  And with that observation I'm questioning if there isn't more to it than just hardware counterbalancing in the joystick, but rather an issue with the ways in which the driver interacts with the hardware under these very specific circumstances.

I really would love to see this issue fixed.  It's been here since I bought the laptop on day 1 and exists both on the factory Windows 7 install that I still have on this machine and as well on my Windows 8 install.  On the Windows 7 side I am using Ultranav drivers and on the Windows 8 side I am using generic Synaptic drivers and the problem is identical.

If you are trying to reproduce the problem yourself, one strategy is to push the pointing stick very gently, but consistently in one direction without letting up, consistently keeping the same pressure until you see the cursor stop itself/fight against your input, and then let go and watch it move on it's own in the opposite direction.  You might have to try this several times until you get the right pressure but soon enough, if your system is like mine, you will spot the issue and find it fairly easy to reproduce if you try.

If anyone else has been experiencing the same behavior (occasionally or frequently) it would be useful if you could just post that you run into this issue also, just so that it can be clearly defined as a widespread issue that would appreciate some attention.  Of coarse any additional observations concerning this phenomena would be extremely welcomed.

Thank you very much, hope to get this one fixed.  TrackPoint / pointing stick is hands down my favorite built in laptop mouse style, and with practice I have learned to simply avoid this unfortunate behavior more often than not, but it still pops up despite my best efforts and it's rather frustrating as I am sure you either already know or could imagine.  -cheers 

From wikipedia:

"A common problem of pointing sticks is the inability to identify the zero position (the position indicating no user touch). A typical solution, which reflects the fact that user operation of the pointing stick is rarely constant, is to interpret any absence of change of pressure (over a given interval, perhaps one or several seconds) as meaning the user has released the stick.

If the user applies exactly constant pressure to the stick for such an interval, this method mistakenly re-zeroes the stick. Then additional pressure is required to achieve the same movement of the screen cursor, and the cursor spontaneously moves in the opposite direction when the user releases the stick. If the user avoids touching the stick, the error ends when the stick detects the real zero position."

It's a fundamental flaw of any trackpoint device. The trackpoint is not a moving part so there is no natural way to calibrate for (x,y)=(0,0) that would be accurate for more then a few seconds of use. Once you understand why this happens you can even replicate the issue whenever you like by applying constant pressure in any direction; eventually the software will think this pressure state is zero and your mouse will stop moving, and when you let go the cursor will drift in the opposite direction at the same speed you started pushing at. The solution to the problem when you get drift is as you say, just let go for a second and the software will rezero the trackpoint.

Tremendous amount of useful, extra information, can't thank you enough for all that, however I'm not quite satisfied just yet.....

I feel there is certainly extra code that could potentially be written to further alleviate this problem, (and if there isn't), why don't they consider moving on to a modified Xbox/Playstation style joystick design instead, they don't seem to suffer from such effects....

Regardless, that information helps quite a lot, but I can't help but think that this issue can be further improved upon in drivers alone (without a hardware re-design).

I don't know how the stick works exactly, even with all this extra detail.  But I'm going to assume that the hardware can at the very least A. detect a change in pressure and that  B. It can also judge the force of the pressure some-how or another/to some degree (because if you start with no touch and then move to light pressure you get a slow movement or if you start with no touch and then move to higher pressure, you get a faster movement...)

Now if it can judge the force of the pressure from a stationary position and then accurately judge and display a light touch and also do the same for a hard touch from a stationary position, then that right there tells me, that it is feasible to have the software take some overall (averaging) measurements that it can store up, either into a more permanent profile, or for one (session 'aka until you release the stick).  This stored, change in information could possibly be re-used to more effectively judge if a resetting of the zero position is actually warranted or if it's potentially a known error.

At the end of this, I'm no engineer and I don't have enough detail on how the device works, but I would re-iterate in saying, I believe this can be further improved with more effort put into the software drivers and that also if this is a permanent nagging flaw in this implementation of a pointing stick design, then it's time for an updated implementation (aka modified Playstation/Xbox analog style, etc.) of this same great pointing stick design.

Thanks, and yeah, not yet satisfied but definitely psyched the first response was amazing, please don't let the conversation end here, thanks quite a lot.  -cheers

Some additional points that I just remembered.  And potential proof that their is indeed further room for improvement via software...

If you are holding down one of the physical mouse buttons that reside above the trackpad while operating the pointing stick, if the pointing stick errors, normally you just have to release the pointing stick, but when you are holding down a mouse button, even if you do let go of the pointing stick, the error continues until you also stop playing with/release the mouse button.  While it's happening you can even briefly let go of the mouse button and then tap it again (not at all at this point interacting with the pointing stick) and sure enough, the cursor will not settle down to rest until you touch absolutely no mouse buttons or the stick for a few moments....  At the very least, that surely could be adjusted with an alternate approach to drivers.  And I suspect quite a bit more can be as well with some effort.

lenovo does hardware but their software support sucks.

hey lenovo, why not to guide your users to a safe update?

this is ridiculous, this has been going on for over 12 years.  i had an old ibm 14 inch laptop in 1999 and it did this exact same thing.  then i got an r31 and it did it.  then i got an r50p high end over $2000 lenovo and it does it.  other models newer - recent models do it.  lenovo absolutely positively must have known about this for over 10 years and does NOTHING to fix it.  

that is disgraceful, disgusting.  it shows incompetence at the technical and management level.  i am used to lenovo laptops and like some of the high end ones with hi res screens and i like a track point, so i suffer with this ABSURD incompetence.  this never hapens on a toshiba, sony, dell or ANY other laptop i have ever seen.  and for t hese guys to let this go  unfixed for 13 years.  

i think this is complete bs.  i may be wrong, maybe this excuse is corect, that this is an uncorectable problem.  yes, we can have electron microscopes that can move individual atoms around, and we can fit billions of elements on a $5 chip, and we can have a 1999 supercomputer in our pocket for $100, but lenovo cant solve this problem.  BALONEY!  BS!

wherever the mouse cursor really is, the computer knows about that.  if the pointing stick is moved from its spring loaded upright position, the system obviously knows that.  if you tild the thing in any direction it knows that.  if you let go it knows that, because it returns ot its upright position.

so what is going on here is a design flaw in the detectors that detect the exact positoin of the stic,, or bugs in the software.  or, it might be a design flaw in the software,  not a bug.  or a design flaw n the stick and its sensors .  whatever it is, if we can put a man on the moon, if we can fly fighter jtes at mach2 on fly by wire, smart engineers can fix this stupid problem that haunts probably all lenovo laptop users for since the days when ibm designed it wrong.  it seems like lenovo might be too cheap to fix waht ibm designed wrong probably 14 or more  years ago.  thanks, lenovo.  

I'm facing the same issue with my X220T. It is too frequent to ignore, and I'm glad to see that I'm not alone in this regard - though not glad to see that there appears to be no solution to the problem. I've tried cleaning out region with compressed air, assuming that it was dust or some physical interference, but the movement of the cursor seems to be too erratic for such a cause. There appears to be erratic clicking as well, and this is something I am unable to circumvent through updates/cleaning/any inspection that I am currently capable of doing. Any advice/updates on this will be greatly appreciated. BTW, is there any way to get Lenovo to look into this apart from directly contacting tech-support?

Cheers.

I have had this problem on all my thinkpads, x600, t43p, t61p, t500 and now t430. By enabling "Enhanced pointer precision" in the Control Panel -> Mouse Properties the problem reduces to a minimum. It doesn't stop moving completely, but almost

This was less of a problem on my T60 but it's definitely more prevalent on my T530. The issue for me is the amount of time that it takes before it decides to recalibrate. It's only about 1 second of constant pressure before it redefines the zero position and it's very easy to intentionally input that pressure for 1 second. Happens when scrolling up and down, when using graphic programs (trace tracing outlines in photoshop, it's a joke), when playing games, and when minding your own business reading text. The problem could be completely eradicated by redefining the amount of time it takes before it determines a rezero is necessary. If it were three or four seconds instead of one, I'd be a happy camper. Even better if I could play with the variable myself, but as of yet I've seen ZERO workarounds for this, by thirdparty programmers or otherwise. Somebody needs to dive in and figure it out.