matttproud.com (blog)

Dealing with Stray Middle Click Events with Google Chrome in X11

Zürich, Schweiz

I am writing this mostly for posterity in case other people are running into this problem:

I’ve been using a Logitech Trackman Marble Mouse Trackball (p/n 810-000767) for many years in the X Window System1 — Linux and OpenBSD. It’s worked great — until about two years ago. I’ve not had the chance to bisect what has gone wrong — whether it is X11, an ecosystem library, or Google Chrome itself, but the problem is essentially this:

My Marble Mouse is configured to use the small button immediately on the right side to perform horizontal and vertical panning of content while moving the trackball (using the ScrollMethod and ScrollButton directives on the libinput driver). But recently as the trackball moves (and emphasis on this happening as the trackball moves), Google Chrome interprets this button press as a middle click for pasting from the primary selection copy buffer. So while panning, Chrome pans and the primary selection copy buffer’s content is spuriously inserted into whatever text pane is in focus! Moreover, the paste events can happen many times in rapid succession!

If you’re working with a rich text content box (presumably an EditContext), you can imagine how annoying this is: spontaneous text insertion of random-or-possibly-sensitive-text into a document!

This problem occurs with no other X11 clients: terminal emulators, graphical text editors, you-name-it. The thing is, I like the primary selection copy buffer concept, so I don’t want to disable this. And in all of these other applications, I can use this button to both pan and perform a middle click paste without a problem.

I’ve had to make my peace with a substandard solution: move primary selection pasting (through the middle click mnemonic) to another button, which is going to take my muscle memory a long time to learn.

I was able to fix this by adding a run-parts-style configuration fragment in /etc/X11/xorg.conf.d:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Section "InputClass"
    Identifier      "Logitech Trackball"
    MatchProduct    "Logitech USB Trackball"
    MatchIsPointer  "on"
    MatchDevicePath "/dev/input/event*"
    Driver          "libinput"

    # Map the left small button (physical 8) to the middle-click (logical
    # button 2).  The right small button (physical 9) is mapped to itself.
    Option "ButtonMapping" "1 9 3 4 5 6 7 2 9"

    # Enable scroll emulation.
    Option "ScrollMethod" "button"

    # Use the right small button (physical button 9) to enable scrolling
    Option "ScrollButton" "9"
EndSection

Note: You would want to corroborate your device’s name from the MatchProduct directive with what you see in xinput list.

I want to thank Jordi Castells for his writeup that includes a precise button mapping dissection: Logitech Trackman in Linux.

I verified what’s happening with xev, and I see the correct events:

Aside: Looking at xev was rather interesting, because I have never looked at precisely how the emulation mode works from an implementation standpoint:

Episodically in the pre-change configuration, I did see MotionNotify events interspersed into the log. Is that a red herring, or an actual lead? Perhaps there is a race with the processing of that event followed by these other clicks? Hard to say. I’m still left with the question of why this problem remains exclusively in Google Chrome and no other X11 client. I’m afraid I don’t have the time to deeply investigate this further.

  1. Funnily enough, this device is largely unusable in Wayland due to the inability to configure button mappings and other input parameters. I keep checking every couple of years, but no dice. ↩︎

Navigation:
Tags: