Knowledge Base

The solution

In my ~/.fluxbox/startup:

xinput set-button-map "$( xinput | awk -F'[=]' '/ouse/{print $2}' | awk '{print $1}' | head -n1 )" 1 2 3 4 5 6 7 0 0 &

The story

I installed Devuan ceres on a desktop workstation as part of my research into lightweight window managers. I installed my self-rolled dpkg of Palemoon (source on gitlab) because I have been actively reducing my use of upstream Firefox. When I scrolled up with the mouse wheel, the browser jumped back and forth in history. If the current tab in the browser has no previous pages, then the scrolling operates just fine. Apparently I'm a unicorn. Nobody has had this exact problem in this environment before (Windows users of Firefox changing the about:config don't count). Relevant xkcds include a tiny bit of xkcd#979 and a healthy dose of xkcd#1495. I investigated many different methods to try to solve my problem. I tried changing the about:config settings in the browser (specifically mousewheel.default.action and similar) which did not solve my problem. My next attempt involved file ~/.fluxbox/keys to assign commands to mouse button actions to reduce the effect they have in the window, which failed to suppress the undesirable actions. I investigated using xbindkeys to control what is sent to the X server when it receives certain inputs. I even tried complicated guile logic, which actually seems quite nifty, but it just didn't accomplish what I wanted in this case. I found an interesting example (secondary reference 3) where some toggling logic was shared, and I spent a lot of time trying to tinker with that. I finally found what I was looking for on the Arch Wiki (primary reference 1), go figure. Those Arch folks know how to help a guy no matter the distro! You can use xinput to change what signals are sent to X from the device by remapping the buttons. You can suppress a button with 0. The wiki helpfully explains how to find which device to modify. And then the series of numbers after that are the button mappings. So the first button, is mapped to the first number, and so on. If a button is mapped to 0, it is effectively ignored.

xinput set-button-map "$( xinput | awk -F'[=]' '/ouse/{print $2}' | awk '{print $1}' | head -n1 )" 1 2 3 4 5 6 7 0 0 &

In my example, I mask buttons 8 and 9. Using xev and xbindkeys -mk I learned that my mouse (a generic HP mouse since I've never cared about fancy peripherals) sends button 4 on scrolling up, and then button 8 and button 9 when stopping the scrolling up action. It was the button 8 (and 9) that were causing weird issues with the browser. When I mask the input with xinput as seen here, the scrolling operates completely normally and as expected.

The probable causes

I have been using this mouse with Xfce on Fedora for years, and the scrolling has never been a problem. I suspect my choice of installing all the packages myself on a Devuan netinst contributed to the problem. I had an issue with fonts on xscreensaver which was probably due to my minimal install. Perhaps Fluxbox does not perform some perfunctory task that desktop environments (DEs) do with sanitizing input. I don't care, because Fluxbox has been quite satisfactory. And as a side node, I haven't found a debian-family "minimal" disc that can be used independently of a network, like the CentOS minimal disc image, only a netinst.

References

Primary

1. Mouse buttons - ArchWiki [wiki.archlinux.org]

Secondary

1. XBindKeys [nongnu.org]
2. xbindkeysrc.scm [nongnu.org]
3. [SOLVED] [xbindkeys] Advanced mouse binds? [linuxquestions.org]
4. fluxbox-keys(5) Manual Page [fluxbox.org]

Commands/programs

xev - uesful to display info about keys are being pressed xbindkeys -mk - same xinput - manipulate mouse button mapping

Files

~/.fluxbox/keys ~/.xbindkeysrc ~/.xbindkeysrc.scm