2

I woke up this morning to this strangeness. It was not doing this when I left my computer yesterday.

I first noticed it when my tmux key bindings did not work. My prefix is Ctrl+Space. Then I noticed when my mouse went over my browser tabs they continuously scrolled to the right. Then I noticed terminal always scrolled to the bottom. But not inside my vim sessions, and only inside tmux when using urxvt, but not when inside tmux using kitty. Then I also noticed that any browser frame which contains text wider than the frame and has a horizontal scroll bar, it will scroll to the right. Also holding my Ctrl key inside my browser continuously zooms it out.

What I have done to troubleshoot:

  • updated all my packages
  • rebooted multiple times
  • killed all tmux sessions
  • different mouse and keyboards
  • cleaned my mouse thoroughly including the sensor on the bottom making sure it wasn't a hair
  • this happens when my keyboard is completely unplugged
  • I'm able to navigate my mouse from my keyboard, so I turned off my mouse and tested with my keyboard only

If it happens without my mouse on, and without my keyboard plugged in, it has to be outside the devices I would think.

  • Computer: Dell 13 XPS
  • OS: Arch Linux
  • Desktop Environment: None
  • Window Manager: AwesomeWM
  • Keyboard: Ergodox EZ
  • Mouse: J-Tech Digital

My question is, how can I troubleshoot this? Is there a way to see some unknown key strokes happening? Or a stuck mouse wheel command?

Update:

Thanks to @duthils suggestion in the comments. I ran xev and aside from the expected mouse move events, I found this output.

ButtonPress event, serial 32, synthetic NO, window 0x3600001,
    root 0x1a6, subw 0x0, time 87726801, (433,445), root:(4274,482),
    state 0x0, button 7, same_screen YES

ButtonRelease event, serial 32, synthetic NO, window 0x3600001,
    root 0x1a6, subw 0x0, time 87726801, (433,445), root:(4274,482),
    state 0x0, button 7, same_screen YES

Which according to docs it does look like horizontal scrolling events somehow being sent from the trackpad. So I have what I thought is disabled it. But it still seems to be occurring. Maybe I need to restart some service or something? Here is how I disabled it.

$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ ELAN25B5:00 04F3:25B5                     id=12   [slave  pointer  (2)]
⎜   ↳ DELL07E6:00 06CB:76AF Mouse               id=13   [slave  pointer  (2)]
⎜   ↳ DELL07E6:00 06CB:76AF Touchpad            id=14   [slave  pointer  (2)]
...
$ xinput disable "DELL07E6:00 06CB:76AF Touchpad"

But it continued happening. So I also

$ xinput disable "DELL07E6:00 06CB:76AF Mouse"

just to be sure. But it still happens. Am I disabling it the correct way? Or am I misreading the event outputs produced by xev? I also tested this after disabling both my touchpad and mouse, then turning off my actual mouse in case it was sending these horizontal scroll events. And it still happens with the mouse turned off. What else could it be coming from is my mouse is turned off and my trackpad and mouse is disabled?

I'm also very curious as to why this is happening? Why would my computer just all of the sudden overnight decide to just start sending these horizontal trackpad scrolling events?

Update 2:

Here is the results from xinput --test-xi2 thanks to @duthils suggestion.

EVENT type 17 (RawMotion)
    device: 2 (16)
    detail: 0
    flags: 
    valuators:
          2: 15.00 (15.00)

EVENT type 15 (RawButtonPress)
    device: 2 (16)
    detail: 7
    flags: emulated
    valuators:

EVENT type 16 (RawButtonRelease)
    device: 2 (16)
    detail: 7
    flags: emulated
    valuators:

EVENT type 13 (RawKeyPress)
    device: 3 (19)
    detail: 37
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 3 (19)
    detail: 37
    valuators:

EVENT type 13 (RawKeyPress)
    device: 3 (19)
    detail: 37
    valuators:

EVENT type 17 (RawMotion)
    device: 2 (16)
    detail: 0
    flags: 
    valuators:
          2: 15.00 (15.00)

EVENT type 15 (RawButtonPress)
    device: 2 (16)
    detail: 7
    flags: emulated
    valuators:

EVENT type 16 (RawButtonRelease)
    device: 2 (16)
    detail: 7
    flags: emulated
    valuators:

EVENT type 17 (RawMotion)
    device: 2 (16)
    detail: 0
    flags: 
    valuators:
          0: -0.89 (-1.00)
          1: 0.00 (0.00)

Best of my understanding it told me that I was receiving a button press and release from device with id of 16 (my mouse) and a key press and release from device with id of 19 (my keyboard).

I did a number of other tests like disable each device and run test, then re-enabled them, and run tests again. Compare the differences, etc. The key press/release coming from my keyboard didn't seem to make a difference. But the mouse press/release did. I found it odd that it still occurs when the mouse is turned off (power off, no battery). But my best guess is it is coming from the usb dongle. So I removed it and plugged it back in, and viola. Issue gone.

protobyte
  • 33
  • 4
  • Have you tried killing the tmux session and starting a new one? Or even just rebooting? The same happened to me once and I vaguely remember that one of those approaches fixed it (sorry I don't have a real answer about the cause) – mattb Jul 10 '21 at 16:13
  • @mattb Yes. I just killed all tmux sessions and it still continued. Then I rebooted again and no tmux sessions are running and opened back up my browser and it still is happening. – protobyte Jul 10 '21 at 16:22
  • hmm, I would consider adding that to the question since it's qualitatively different from the situation I (and I guess others) had. I hope you get some help on it. – mattb Jul 10 '21 at 16:28
  • Have you tried a boot from an alternative Linux on a USB stick? – Jeremy Boden Jul 10 '21 at 17:49
  • @JeremyBoden Not yet. I can try in a little and report back. – protobyte Jul 10 '21 at 19:33
  • Did you try [disabling your touchpad](https://unix.stackexchange.com/questions/388963/how-can-i-enable-disable-the-synaptics-touchpad-in-debian-9-with-libinput)? Also, what do you see when running [`xev`](https://www.x.org/wiki/guide/debugging/#index1h2) in a terminal and moving your mouse in the `xev` window? – duthils Jul 11 '21 at 03:41
  • @duthils I have not tried disabling my touchpad. Great thought. I will try after this if my findings from your second suggestion isn't the culprit. So `xev` produced plenty of `MotionNotify`'s. But it also produced some `ButtonPress` and `ButtonRelease` events. I'm investigating this further and will update my question with more details. – protobyte Jul 11 '21 at 14:48
  • @duthils I updated my question with more details. But you were on the right track. It appears a horizontal scrolling event is being sent to my system somehow. Disabling my mouse and trackpad and turning off my external mouse does not seem to have any impact. – protobyte Jul 11 '21 at 17:04
  • To disable a device, you can also use its id like `xinput disable 14`. What does `xinput --test-xi2` show? It's similar to `xev`, but will print the device of each event like this `device: 3 (16)`. The device id is the one in parenthesis (`16` in this example). – duthils Jul 11 '21 at 21:01
  • @duthils Your question ultimately led to my resolution. (see updated question). I would like to accept your comment if you don't mind leaving it in an answer. Can't thank you enough for your suggestions. This was so frustrating to me. I still have many questions like how this happened and why; Should I worry about my key press/release for other things, etc. But I won't worry about that for my original question. Thanks again. – protobyte Jul 11 '21 at 22:29
  • 1
    "So I removed it and plugged it back in, and viola. Issue gone." I had the exact same problem and, thanks to this post, I was able to solve it in the same way. Unplugging and reinserting the USB dongle of the mouse did the trick. Remarkably, rebooting the computer did not suffice. Strange. – RHertel Aug 31 '22 at 06:13
  • Unplugging my USB dongles for wireless keyboard and mouse fixed it. I had exactly the same problem, except I was getting phantom scroll down or up events. I would never have thought the RF receivers could fail in this way. Thanks!! – Will Pierce Jul 04 '23 at 15:42

1 Answers1

2

  1. Confirm that events are being received with xev

  2. Find the device ID emitting those events with the following command:

xinput --test-xi2

It will output events of this kind:

EVENT type 15 (RawButtonPress)
    device: 2 (16)
    detail: 7
    flags: emulated
    valuators:
  1. Find the device name: the device ID (e.g. (16)) maps to the device list of xinput --list.
duthils
  • 386
  • 2
  • 4