1

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.

10
  • 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 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 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 at 16:28
  • Have you tried a boot from an alternative Linux on a USB stick? Jul 10 at 17:49
  • @JeremyBoden Not yet. I can try in a little and report back.
    – protobyte
    Jul 10 at 19:33
0
  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.
1
  • So sorry I can't +1 this. My rep isn't high enough yet :(
    – protobyte
    Jul 16 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.