Trackpoint module drift

[mondalaci]

Sometimes, the trackpoint module drifts. In other words, the mouse pointer keeps moving in a direction without any input being applied. This is a known issue of original IBM/Lenovo TrackPoints, too.

Given that the direction and speed of such drifts are constant, I plan to detect drifts on the firmware level, then execute a PS/2 reinitialization sequence. The trackpoint firmware will contain the above fix without affecting anything else.

[anilanar]

Is there a workaround meanwhile? It somehow stops drifting sometimes but I'm not sure what makes it stop.

[ligregni]

Is there a workaround meanwhile? It somehow stops drifting sometimes but I'm not sure what makes it stop.

Sometimes just waiting for 3-5 seconds does it (definitely need to not provide further input), but what surely does it is to unplug the module and plug it back in.

[mondalaci]

According to my experience, if a force is exerted over several seconds opposite the drift direction, the drift can be fixed without disconnecting the module. I'll do my best to fix this as soon as things settle down a bit.

[manueliglesias]

I would like to leave a +1 here.

In my case the only thing that temporarily fixes this issue is to disconnect/reconnect the module.

[stevesea]

+1 happening here too, multiple times a day. same workaround as others have noted -- unplug the keyboard from my docking station.

[anilanar]

@stevesea Just unplug the module instead, much faster and works as well as unplugging the keyboard.

[manueliglesias]

I am using one of these for now 😅
Minimizes wear and tear of disconnecting/connecting

[mkove]

Have been testing all of the modules over the past 2 weeks. for me, the trackpoint is the best, but the drift is a major problem. Is there an update on the firmware fix for this?

[kareltucek]

Have been testing all of the modules over the past 2 weeks. for me, the trackpoint is the best, but the drift is a major problem. Is there an update on the firmware fix for this?

Well, I gave it a few tries and have quite mixed feelings about it. My findings so far:

• I think that the signal is not precisely constant - rather jittering around some value (like alternating between 0 and 1, or 2 and 3), since it is a result of some physical property being sampled.

• The trackpoint board seems to have its own anti-drift system which seems to work quite reliably (although it is configured to act rather conservatively) - kicks in after approximately 3 seconds of constant pressure. (Of course, this is irritating because it heavily interfers with my experiments.)

• It seems like sending reset (0xff) doesn't always stop the drift.

• Calibration process is said to take around 600ms (assuming that we have correct data sheet) which is obviously too long to actually be happening on reset. So maybe simply having it calibrated on startup might solve our issue.

The obvious trouble is that the drift signal is virtually identical to the input of an actual person trying to move sideways at a constant speed. Recalibration at such point will make it drift in opposite direction after the nib is released. It can be even "wound up" as a spring by having it reset multiple times during one long steady move to one side.

[mondalaci]

@kareltucek Thanks for the sharp insights!

Despite the alternating signal, do you think it's possible to detect drifts? If so, over how much time? A user should be unable to manually drift precisely over a long period. If you're unsure about the answer, it'd be worth retrieving the coordinate sequences of the drift to design a drift-detecting algorithm.

What makes you think that sending reset doesn't always stop the drift? If the PS/2 reset command is unreliable, our supplier may be able to provide us with an alternative reset command.

The obvious trouble is that the drift signal is virtually identical to the input of an actual person trying to move sideways at a constant speed. Recalibration at such point will make it drift in opposite direction after the nib is released. It can be even "wound up" as a spring by having it reset multiple times during one long steady move to one side.

The above makes sense, but have you actually tested it?

[kareltucek]

The above makes sense, but have you actually tested it?

Rigorously to all fine details of that claim? No. But: 1) I can trick the built-in anti-drift solution into both those behaviours using just my hands. 2) Naive algorithm (expecting constant sequence) does not seem to trigger. 3) Algorithm which allows for some variation acts just as I expect it to.

A user should be unable to manually drift precisely over a long period.

Precisely enough to keep the value reliably "between" 0 and 1.

What makes you think that sending reset doesn't always stop the drift?

Testing.

If the PS/2 reset command is unreliable, our supplier may be able to provide us with an alternative reset command.

No need to - the datasheet contains explicit comand for calibration (0xE2,51).

Despite the alternating signal, do you think it's possible to detect drifts?

Yes. Reliably? Not without a sophisticated frequency analysis (which is kind of problematic within given performance constraints).

over how much time?

As much or little as you want, given that you are fine with reliability being proportional to the time you have picked.

[ignisf]

Hello, I've been tracking this issue with great interest.

I was wondering if the calibration process duration could be configured. If so maybe we could get a sysfs knob similar to the drift_time one for IBM TrackPoints:

https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/drivers/input/mouse/trackpoint.h#L79-L81

The default drift time of 535ms seems close to the 600ms you mention and is considered low -- sources such as the Arch wiki suggest you increase it 5-6x: https://wiki.archlinux.org/title/TrackPoint#Trackpoint_moves_on_its_own

[kareltucek]

The default drift time of 535ms seems close to the 600ms you mention and is considered low -- sources such as the Arch wiki suggest you increase it 5-6x: https://wiki.archlinux.org/title/TrackPoint#Trackpoint_moves_on_its_own

If I am correct in assuming that you are referring to the last paragraph of the wiki, then the wiki refers to actual drift detection legth, not calibration time. I.e., entirelly different value, although still relevant. Also, a quick peek at the datasheet does not reveal any way to configure either of the two values.

According to my experience, the built-in drift detection works on scale comparable to value recommended by the wiki (that is ~3s). Also, the paragraph suggests that too sensitive drift detection itself is usually the culprit, so implementing second drift detection algorithm might easily be counter-productive.

[mkove]

okay, so through further testing, I've identified something that may be of some value. I'm not fully understanding all the technical details described in this conversation, and am providing real world use case findings. I'm using Windows 10. Since I have 3 monitors, it takes a lot of effort to move the mouse pointer around with the track point at normal setting. so, regardless of what type of mouse I use, I always increase the speed of the mouse. Likewise, when I began using the TrackPoint module, I went into Mouse Properties, selected the Pointer Options tab, then changed the Motion setting from Medium to Fast (there are various degrees of setting this, I didn't make it the fastest, but a few "ticks" left of the fastest setting which is a slider). Very soon after increasing the Motion I started getting drift. I decided today to change the setting back to the default setting (midway between Slow and Fast) and the drift has so far not returned. Of course, this is still a major problem for me ergonomically, as I need the faster setting so as not to fatigue areas of my arm. But it seems that the drift is somehow worsened by increasing the Motion speed in Windows 10. Not sure if this helps in any way, but wanted to report my findings. This is the setting I'm talking about - https://www.windowscentral.com/sites/wpcentral.com/files/styles/xlarge/public/field/image/2020/08/mouse-speed-adjust-control-panel.jpg

[kareltucek]

@mkove can you actually reproduce it "on purpose"?

My hypothesis is that (at least in your case) the drift is triggered by long steady move in one direction at low pressure. The drift will be opposite direction, and will start when you release the pressure. If the drift is slow, it will stop in two or three seconds on its own, given that you do not touch the nib during this time. If the drift is fast, it will not stop on its own.

Can you (or anyone) confirm or refute this hypothesis, or add some more observations of how the drift starts?

[mkove]

@kareltucek I've tried my best to replicate "on purpose" but cannot. I can tell you that as far as I can remember, and this has been for about a week, the drift is always right to left, and at an angle toward the bottom left corner. I will correct myself in another comment if I do see it move left to right.

I do believe that the faster the drift, you are correct, it does not stop on its own. When I see the drift and it is very slow, it often stops by itself. If the drift is fast, I end up having to unplug the keyboard, or remove and reattach the module before it will stop. I'll try again to see if I can make it happen on demand tomorrow, and give any additional insight I notice.

[mkove]

@kareltucek ok, so here are the results of more testing. I still can't produce on purpose, but I can tell you that every time it drifts, I'm moving the pointer in an upward and right direction. Then the pointer drifts downward to the left. So it does appear to be an opposite drift to the movement I'm making....but only in this particular direction, never another direction of movement or opposite drift. The drift does start, once the pointer is released. If I "let it go" and don't attempt to interrupt the drift, the pointer ends up in the bottom left corner of my screen. If I immediately attempt to move the cursor, the drift continues. If I wait 3 seconds after it stops in the bottom left corner, I can move the cursor again, without any drift. I will have to monitor, but I believe that the drift is faster the MORE pressure I put on the cursor. Again, I will have to actively monitor it and continue to give my feedback.

[kareltucek]

@mkove thanks for feedback!

@mondalaci Could you ask your supplier about the drift itself, and any related configuration registers?

[anilanar]

I can consistently reproduce it by doing the following:

⁣1) Apply constant pressure up-right (somehow for me doing it up-right is easier due to position of my hand?) for ~3 seconds until the cursor suddenly stops moving.

Case A:
2) Increase the pressure to make it move more.
3) Release the pressure.
Result: It will drift to bottom-left until unplugging.

Case B:
2) Release the pressure.
Result: It will drift bottom-left for a split second and will immediate stop and fix itself.

[twispt]

I was able to reproduce using @anilanar 's method as well. Exact same cases. Direction doesn't seem to matter, fwiw.

[mkove]

No matter how much I try, I cannot reproduce on demand, even trying many times over the last few days, and with following @anilanar's method. For me, it only happens randomly. Interesting.... For me, it just happens all of a sudden. Only when I'm not trying.

[twispt]

@mkove it is not easy to produce the exact constant pressure for long enough to reproduce. I've found it's easiest to use a pen and push on the rubber point perpendicular from the side. To reproduce Case A, you have to increase pressure almost immediately, otherwise it'll correct and you'll get Case B.

[mondalaci]

I've just asked our supplier about the drift and related configuration registers/commands. I'll share his findings, if any, here.

A decent workaround would be to reset the trackpoint module when pressing both the left and right buttons together. If the mentioned PS/2 reset command doesn't work, it'd be worth trying to toggle the TP_RST pin.

[kareltucek]

@anilanar, @twispt, @mkove thanks for your observations! They all correspond to my findings. That is, I think that the root cause is that the trackpoint's own built-in antidrift/adaptive-calibration/whatever-we-want-to-call-it solution tries to compensate for drifts too eagerly. Let's now wait for Laci's results with the inquiry.

If the mentioned PS/2 reset command doesn't work, it'd be worth trying to toggle the TP_RST pin.

No worries about that - the calibration command which I mentioned earlier works just fine. But let's first try to resolve the cause - chances are that changing the trackpoint board's settings will do the trick.

[ewancoder]

Hi, I just noticed that I have this issue on one of my trackpoint modules, on second one it's not present. It appears after almost every movement of the trackpoint and the cursor continues moving in the direction where you moved the trackpoint initially, mostly to the right. I fear it might be a hardware issue since it's reproducible on almost every move to the right direction and is not reproducible at all on my second trackpoint module. Are there any advices / possible solutions that I might try to do to fix this? The module is practically unusable because of it, it works with 10.10 as well as 10.12 firmwares. The module is brand new, it was not using it, it was just lying on my table for about half a year until I tried to use it today.

[ewancoder]

Sometimes it actually moves to the opposite direction, and it does this with a stable velocity for about 5-6 seconds nonstop until finally stopping. But it happens practically almost on every trackpoint move. Actually I just tried moving it to the right 10 times in the row and all 10 times it started moving on it's own after the end of the input (I moved it to the left to stop it's movement every time after moving it to the right and reproducing the issue).

[mondalaci]

@ewancoder This sounds like a hardware issue. Please shoot an email to support@ultimatehackingkeyboard.com to discuss this further.

[ewancoder]

Thanks, will do.

[Drizzt321]

I've found I'm noticing the drift as well, and reading this does bring to mind that my Thinkpad, back in the day, did sometimes experience drift as well. From my reading there's some attempts to do detection/reset? Haven't made it into the current stable firmware yet? Any ETA?

[kareltucek]

@Drizzt321 unfortunately no. I don't see a way to fix this without cooperation of the manufacturer. Best advice I can give is to not keep the trackpoint in one position for too long during slow movement.

@mondalaci any updates on the inquiry? Should I implement the press-both-buttons-to-recalibrate feature?

[mondalaci]

@kareltucek Sorry for the delay. I asked our suppliers a while ago and recently, but haven't got a useful response. The press-both-buttons-to-recalibrate feature is the best workaround I can think of, but I'm afraid that it'll trigger left and/or right click inadvertently. Any ideas to avoid such an undesired side-effect?

[kareltucek]

Any ideas to avoid such an undesired side-effect?

I don't think that triggering left or right click is a problem. Debugging with the watches behaves the same way and does not really cause any inconvenience.

I am much more concerned about the other implication - that intentional left + right click will shut down the module for half a second instead of the desired behaviour. If I am not mistaken, right + left is commonly used to emulate middle click, which is unfortunately a very relevant usecase for the module.

[kareltucek]

(But no, I don't see any way around.)

[mondalaci]

Another way would be a dedicated macro command to reset the trackpoint module.

I think we should implement the proposed workaround first for the sake of simplicity and possibly later implement such a macro command if needed.

[kareltucek]

Alright.

[mondalaci]

@kareltucek Pulling the TP_RST pin low actually resets the trackpoint module. Until this pin is down, the trackpoint module doesn't talk via PS/2.

The code to pull down TP_RST:

    #define TP_RST_GPIO  GPIOA
    #define TP_RST_PORT  PORTA
    #define TP_RST_CLOCK kCLOCK_PortA
    #define TP_RST_PIN   7

    CLOCK_EnableClock(TP_RST_CLOCK);
    PORT_SetPinConfig(TP_RST_PORT, TP_RST_PIN, &(port_pin_config_t){.pullSelect=kPORT_PullDown, .mux=kPORT_MuxAsGpio});
    GPIO_PinInit(TP_RST_GPIO, TP_RST_PIN, &(gpio_pin_config_t){.pinDirection=kGPIO_DigitalOutput, .outputLogic=0});
    GPIO_WritePinOutput(TP_RST_GPIO, TP_RST_PIN, 0);

I'm unsure how long TP_RST must be pulled down to reset the module, but I guess 100 milliseconds should be enough and probably much less is sufficient.

On second thought, instead of implementing the hardcoded policy of pressing both module buttons to reset the trackpoint, I'd prefer having a resetTrackpoint smart macro command and letting users bind it as desired.

[kareltucek]

I see - I was missing the enable clock line.

[Drizzt321]

So looks like we'll have a fix for this in software? When I've noticed drift I've just pull the module enough to disconnect, then push it back in.

[kareltucek]

Well, not a fix. Just a command that will allow you to reset the trackpoint by tapping a key instead of reconnecting the module :-( .

[Drizzt321]

Ah, I see. Yeah, probably a difficult task to identify drift to automatically issue the reset. At least we'll be able to bind a key now.

[Drizzt321]

I've also noticed that when it's drifting, if I hit the MOD it'll actually scroll down the page (say in a browser) proportional to the amount of drift. So if drifting slowly, it'll be slight, if drifting fast, it'll be a lot. It's almost like pressing the space bar and holding it down.

[anilanar]

@Drizzt321 It's because it's configured to scroll in MOD, so nothing unexpected, right?

[Drizzt321]

@anilanar oh that's interesting. Did not know that at all. Ah. Is there a way to turn that off or modify that? Don't see anything in the UHK Agent for that.

[kareltucek]

Yes, namely configuration will be available as part of smart macros in next firmware release.

[Drizzt321]

@kareltucek Ah, ok. I'll keep an eye out for that then.

[kareltucek]

As to answer any questions...

The trackpoint drifts are a problem of the third party trackpoint board and cannot be fixed without cooperation of the manufacturer. And unfortunately, the manufacturer does not cooperate.

They are induced by a steady pressure on the trackpoint, which leads to an unwanted recalibration of the trackpoint, which leads to a drift in the opposite direction when the trackpoint is released. In other words, you can learn to not trigger the drifts by changing your usage habits.

Furthermore, 10.6.0 release implements a drift-detection algorithm which resets the board whenever it detects the drifts. In other words, if you encounter a drift, the cursor should stop moving after a few seconds if you release the trackpoint. Unfortunately, this algorithm may make the drifts appear more often as it basically does exactly the same thing that introduces the drifts in the first place.

[adrianegraphene]

Just following this thread. I see it's closed, but I just got my trackpoint back from UHK repair and it is plauged with this issue.

From what I understand, UHK flashed some older firmware onto my trackpoint (8.X.0?, maybe 8.4.0) and it was working fine then. Since upgrading to version 11.0.0, my trackpoint is impossible to use reliably.

The "up and to the right" motion send my cursor into an uncontrollable left dive for 5-8 seconds. I have a lot of screen real estate, so moving up and to the right is done constantly.... I do have the resetTrackpoint command setup, but it doesn't stop the issue from happening again....

Has anyone gotten a feasible workaround? It's made my trackpoint unusable at this point.

[kareltucek]

@adrianegraphene please flash uhk-firmware-11.0.0-no_antidrift_v0.tar.gz and let us know whether it solves the issue. (Make sure it is flashed onto your trackpoint.)

[adrianegraphene]

Thanks @kareltucek. For the 1st minute after flashing, it was great. It felt "normal" again and I could be as forceful as I wanted, without the drift kicking in.

Then, as I started to write this, the drift started kicking in again. I'm not sure if this feels the same or slightly better. I'm going to reflash it with the same firmmware and see if being gentle with it from there on out, works better.

I do noticed that if I keep my base Speed and Speed above 1.0, that I don't run into the drift issue as much. It forces me to use the "mouse key + slow mouse speed" combination though, since going above speed 1.0 on trackpoint seems insanely fast...