Mouse starts moving on its own

[laxu]

I have had this happen twice now with the 8.8.1 firmware. Suddenly mouse starts drifting diagonally towards upper right corner and using my actual mouse or trying to use the mouse commands on the UHK don't fix it. Only fix seems to be unplugging the UHK and plugging it back in.

Right before I wrote this the keyboard hard worked without issue the whole day then suddenly started moving on its own.

UHK is hooked directly to motherboard USB port, same I have always used.

[mondalaci]

1. How often can you reproduce this issue?
2. Have earlier firmware versions exhibited this issue? If so, which ones?

[laxu]

1. I just had it the third time right before writing this message. I had done nothing more than gone to the bathroom (before that it was working fine), returned to my computer, woke up my display and then the cursor started drifting.
2. No, never.

This happens randomly enough that I can't pinpoint it to anything more specific. UHK is connected to the same port as always and after reconnecting can work fine for days.

It always starts drifting towards the upper right corner so at least that is consistent.

[mondalaci]

Firmware 8.8.1 has been out for 2 months, it was bundled with Agent since its release, and nobody has reported such issues yet, so it's a this issue seems to be specific to your installation.

Can you reproduce this issue with another computer?

[mondalaci]

Also, please give a try to the recently released firmware 8.9.0. It contains a memory corruption fix that might be related.

[kareltucek]

The corruption is not related (at least not that one) - official firmware does not write the adaptive led at all.

trying to use the mouse commands on the UHK don't fix it

• Ok, but do the mouse commands affect the cursor somehow? (E.g., does pressing down temporarily make the cursor either stop or move down?)

• How fast does it move? Is it regular mouse speed or is it slower/faster?

• (Do accelerate/decelerate affect the speed?)

• (Is the horizontal speed exactly equal to the vertical speed?)

• Does the rest of UHK work? Can you press some shortcut (e.g., alt+tab)? If no, do layer switches at least light up the corresponding LEDs?

• (Anything nonstandard about your UHK? E.g., are you using some nonstandard bridge cable, or is the UHK one of the early batches?)

[kareltucek]

@mondalaci upper right corner sounds weird. It corresponds to (x,y)=(1,-1) directions if I am correct. Can you remember anything related to those two directions in the code you have written for modules during past months?

[mondalaci]

No, this shouldn't be an issue. I still believe it's an installation specific issue of some sort.

[laxu]

• Ok, but do the mouse commands affect the cursor somehow? (E.g., does pressing down temporarily make the cursor either stop or move down?)

Yes, I can use either mouse or the mouse keys on UHK to move the cursor, but it will still keep climbing towards the upper right corner.

• How fast does it move? Is it regular mouse speed or is it slower/faster?

It moves pretty slowly, definitely slower than my normal mouse key speed on UHK, or maybe at most at the initial speed before acceleration. If I have to guess it would move at something like a couple of pixels per second, slow and smooth.

• (Do accelerate/decelerate affect the speed?)

Have not tried this, will do if it happens again.

• (Is the horizontal speed exactly equal to the vertical speed?)

Yes.

• Does the rest of UHK work? Can you press some shortcut (e.g., alt+tab)? If no, do layer switches at least light up the corresponding LEDs?

Yes, works fine.

• (Anything nonstandard about your UHK? E.g., are you using some nonstandard bridge cable, or is the UHK one of the early batches?)

It's an early batch one, no mods done. Using the bundled cables.

I updated to 8.9.0 and latest Agent, will report back if this happens again.

[kareltucek]

Interesting. So usb interfaces are working properly and there is clearly nothing deadlocked in the firmware.

Indeed looks like an installation specific issue. I assume that your mouse bindings are on mouse (or other non-base) layer, which pretty much rules out hardware issues too.

Yet, this seems to be happening on 8.8.1 only (and maybe 8.9.0 too).

If 8.9.0 proves to be problematic, it would be a good idea to try 8.7.x firmware again - to rule out actual changes in the environment.

[mondalaci]

I'm closing this issue because nobody has reported it, and it must be installation specific. We will follow up regardless and keep us updated, @laxu.

[mondalaci]

I can confirm that this is an actual issue. I was able to reproduce it, although very sporadically and randomly, and just got an email report about it. We'll do our best to fix it.

@kareltucek I assume that the calculation of mouse speed is slightly messed up. It must be a small error that adds up over time. Can you look into it?

[kareltucek]

Sure!

[kareltucek]

Just to be sure, can you confirm the above observations? (I.e., that it is a slow smooth movement towards upper right corner.)

[mondalaci]

Yes, exactly the behavior I experienced.

[kareltucek]

If I am not mistaken, then:

• Kinetic calculations are taking place only when some mouse state(s) is(are) active.
• All sources of mouse movement are consumed properly (i.e., zeroed after they have been used).

If I am correct, then we might be dealing either with a memory corruption, or a garbled I2C communication. One hypothesis is that moduleState->pointerCount might be getting garbled under some circumstances.

---

I would appreciate some help with testing uhk-fw-8.10.1-mouse_crashunt.tar.gz (It might make sense even to just leave a few keyboards running nonstop):

• If your keyboard led display shows BPC or MC<X> (i.e., any nonstandard text it shows while not holding tilde*) under any circumstances, please report back.

• If you encounter the mouse move problem:

  1. Hold tilde* to show debug info on led display and write down the content (numbers/letters).
  2. Repeat once more. (This will refresh the content - both - old and new - values are of interest).
  3. Try to reconnect left keyboard half, and see if it changes anything.

  (The code shown by tilde encodes some info about the cause of last registered mouse movement. Namely, first digit is number of keys which are registered as active, second digit shows the type of active mouse state and third digit identifies origin of the movement.)

*When saying "tilde", I mean the top left key of your left keyboard half, whatever it actually is.

[IzK666]

:( I'm sorry. I can't help you now. I'll be away a few days for holidays.
But if you still need help on september, I'll install it and try it.

[laxu]

Just got this once again, first time in several months. I tried reconnecting left keyboard half but that definitely does not change the situation.

I use the mouse functionality on the keyboard pretty rarely so I would not tie it directly to that either. It always seems to climb towards the upper right corner.

[kareltucek]

Thanks for report!

It would be great if you could also flash the above firmware and gather the mentioned codes from led display next time it happens, since you seem to be the one most capable of reproducing the problem. (The firmware is vanilla 8.10.1 with addition of just a few debugging conditions. It will not restrict your use of uhk in any way, apart from showing stuff on the LED display time to time.)

---

As far as my testing goes - I have had no luck reproducing the problem so far.

[laxu]

I flashed the debug firmware and will report back if I can get this issue again. It seems most likely to happen coming out of sleep.

[laxu]

Ok I got the bug again, after waking computer from sleep. WIndows 10 v2004. Ryzen 3700X, X570, keyboard connected to a USB hub. Bug has happened connected directly too.

Holding tilde shows "204" or "Z04" in the LCD. Otherwise it has just shown the current key layout name. Debug shows 200 after keyboard USB cable has been reconnected.

If I disconnect the left keyboard half, the cursor starts moving faster towards the upper right corner. When the left keyboard half is connected again, the cursor movement slows back down. This happens whether it is connected with the cable or via the pins.

[kareltucek]

Thanks!

That means that the values actually come from TouchpadUsbMouseReport. Of course, it is still a bit of a mystery why or how.

[mondalaci]

@laxu Can you still reproduce this with the newest firmware version? I can recall a fix or two that might have fixed it.

[mondalaci]

We haven't got any reports about this for a year. Closing this issue and will reopen if needed.

[milianw]

Hey there,

I regularly run into this issue with the UHK trackpoint. After using it the mouse sometimes continues to move in a certain direction. The easiest to get "out of it" is by using a real mouse and shaking it around, which often helps...

Still, can this issue be solved on the UHK side? Is there some debug output you'd like to have from me when this happens, such as xev or udev/libinput logs - if so, can you tell me what commands I should run?

Thanks

[kareltucek]

@milianw this has nothing to do with this ticket. The ticket you are interested in is #382. See my reply there.

Also, you can search the github or forums for "trackpoint drifts".