Update July 2024: This article applies only to Linux running the X11 window server. When using Wayland instead – the default since KDE Plasma 6 – none of the below will work. Fortunately Plasma 6’s System Settings let me configure everything I need except Drag Lock. I have used evsieve to implement this.

The Kensington Expert Mouse and Slimblade trackballs have four buttons and a scrollwheel, and I have my personal preference for their layout. There is a utility program available for Windows and macOS to customise the button mapping, but no equivalent program exists for Linux. Fortunately it doesn’t need to, because under Linux there are multiple ways to alter the button-click events sent by input devices; I tried the not-so-new-any-more hotness that is udev before settling on a simple X Windows xorg configuration file. Update Jan 2024: I have an additional requirement; since I use a KVM switch to move between multiple systems I need the configuration to be performed on the fly when the device is detected as having been plugged in. The Xorg approach refused to configure scrolling however, so I currently use a hybrid of mostly X11 xorg configuration plus udev and an xinput script to set scrolling, as explained below.

Xorg

X Windows includes the Xorg configuration file system, usually located at /etc/xorg.conf.d. Following the somewhat standard Linux approach, filenames in this directory should be prefixed with a number between 0 and 100, which denotes the order in which they are processed. Cutting to the chase, I created a file named 50-trackball.conf, with the following content:

Section “InputClass”
Identifier “libinput Kensington trackball”
MatchDevicePath “/dev/input/event*”
MatchVendor “047d”
MatchProduct “Kensington Slimblade Trackball”
Driver “libinput”
Option “ButtonMapping” “3 2 1”
Option “DragLockButtons” “2 3”
Options “Natural Scrolling Enabled” “1”
EndSection

It is necessary to restart X Windows to have it re-read the contents of /etc/xorg.conf.d. The simplest way to achieve this is to log out and back in. Here’s what each line does:

  • Identifier “libinput Kensington trackball”
    This is simply a label for the entry; can be anything.
  • MatchDevicePath “/dev/input/event*”
    Which /dev input event streams to monitor. I’ve configured this to ‘all of them’ to save me the grief of working out which one the trackball appears at. It might even change each time the trackball is reconnected, I don’t know.
  • MatchVendor “047d”
  • MatchProduct “Kensington Slimblade Trackball”
    These are used to decide whether the event data should be filtered. The vendor id can be determined using lsusb – it’s the first of the two hex IDs on the row for the Kensington trackball in that command’s output.
  • Driver “libinput”
    Which device driver I would like to have process events for this stream.
  • Option “ButtonMapping” “3 2 1”
    Okay, finally we’re getting to the meat of this. The syntax here is “which physical button should send left button events, which sends middle button events, and which sends right button events”. “3 2 1” flips the front-left (1) and front-right (3) buttons of the trackball to get left-handed behaviour, whilst assigning the back-left button (2) as middle button.
  • Option “DragLockButtons” “2 3”
    When using a trackball it is not comfortable to hold a button down whilst dragging, so this syntax means that a single click of the back-left button starts a drag at the current cursor position. Front-right terminates the drag at the new current cursor position.
  • Options “Natural Scrolling Enabled” “1”
    Being left-handed, for me anti-clockwise turning of the ball to descend feels “correct”; apparently that corresponds with Natural so far as the Slimblade xinput parameter name reporting is concerned.

The above configuration is fully set-and-forget; I use a KVM switch and yet the configuration is applied faithfully whenever the trackball is assigned to the Linux laptop.

Update Jan 2024

The above did not quite work by itself. I found that the Natural Scrolling Enabled parameter was not being applied when the trackball was connected. Following a comment to this post I learnt that positions 4 and 5 in the ButtonMapping string are “scroll down” and “scroll up”, so I used xev to determine that the Slimblade sends button 5 for an anti-clockwise twist of the ball, and 4 for clockwise, but setting ButtonMapping “3 2 1 5 4” did not work either.

I consequently turned to udev to detect the connection of the trackball and set a semaphore (a write to a named pipe), then wrote a login script that read from the named pipe in order to perform the actual trackball scrolling configuration using xinput. Read on..

Udev

Udev sends events when new devices are plugged in, and one can write rules to trigger actions based on those events. I therefore wrote a udev rule that detected the trackball being connected. Here is the rule (written to a file at /etc/udev/rules.d/80-trackball.rules):

ATTRS{idVendor}=="047d", ATTRS{idProduct}=="2041", OWNER="<your username>", ACTION=="bind", RUN+="/bin/sh -c '/bin/echo connected >> /tmp/TrackballPipe'"

idVendor and idProduct were determined using lsusb; owner is the user as which to perform actions. So far so good, but there is a catch. Udev rules run in a very limited environment, and the X11 environment is not set up. For this reason we cannot call our xinput configuration script directly from the rule’s RUN action, since xinput will complain ‘Unable to connect to X server’. Instead, as you can see, the RUN action simply writes the string ‘connected’ to /tmp/TrackballPipe. Separately, I set up this script to be run as a login script in my KDE environment. The script creates the named pipe and reads from it in a loop, waiting until it finds the string ‘connected’. A pipe is used rather than a file since reads from a pipe block until there is something in the pipe to read, so they are computationally cheap. When the semaphore text arrives, it runs the xinput code to configure the scroll direction, and all is finally right with the world.

 

Inspiration for the solution described was pieced together from these sources :

https://unix.stackexchange.com/questions/65891/how-to-execute-a-shellscript-when-i-plug-in-a-usb-device
https://unix.stackexchange.com/questions/439478/how-to-set-xinput-properties-triggered-by-udev-device-connection
http://www.reactivated.net/writing_udev_rules.html
https://unix.stackexchange.com/questions/58117/determine-xinput-device-manufacturer-and-model#answer-220082
https://wiki.archlinux.org/title/Libinput
https://bbs.archlinux.org/viewtopic.php?id=261138