Hello, it started as a bug report: it have a 5-button mouse with a wheel, even though I don't use much the buttons 4 and 5 (I think only for previous and next in firefox history). I recently switched to OpenBSD, and I was surprised to find these buttons cause scrolling, like the wheel. If this behavior is intended, the rest of this e-mail is moot.
Assuming this is indeed a bug, I went looking for a cause that I could fix, and found a philosophical or engineering question instead (hence my posting to misc@ instead of bugs@). As far as I can tell, on my setup (which I assume is common), the input is handled by wscons(4) and send to X through xf86-input-ws. I think the root cause of my problem lies in a conceptual mismatch, so I will try to use a maybe-overly precise vocabulary. The physical fidget-toy on my desk which I call "mouse" has clicky parts which I could describe as "physical buttons", and a spinning part which could be called a "physical wheel". I have no idea how this works, but wscons(4) reacts to physical buttons with WSCONS_EVENT_MOUSE_UP and WSCONS_EVENT_MOUSE_DOWN events, and the physical buttons are numbered from 1 to 5, while the physical wheel triggers WSCONS_EVENT_MOUSE_DELTA_Z with an amount of -1 or +1. So a wscons(4) button maps exactly to a physical button, and wscons(4) Z axis maps to the physical wheel. On the other side, as far as I can tell X can't handle the concept of wheel, so the wheel gets inserted as two buttons, as described by ZAxisMapping option. So by default, turning the wheel up is translated as pressing the X button 4, and turning the wheel down is pressing the X button 5. However, from my reading of the function wsSendButtons() in https://github.com/openbsd/xenocara/blob/master/driver/xf86-input-ws/src/ws.c the wscons(4) buttons are sent untranslated to X, so wscons(4) button 4 and 5, which are physical buttons, cannot be distinguished by X from turning the wheel. Meanwhile, with default configuration on Linux and FreeBSD, the physical buttons 4 and above are mysteriously translated into X buttons 8 and above, which allows Firefox to map the extra buttons to previous and next in history while the wheel is still mapped to vertical scrolling. So at this point, one could add a simple if (button >= 4) button += 4; in wsSendButtons() before the call to xf86PostButotnEvent(), and OpenBSD default behavior would match Linux and FreeBSD default behavior. But is this the right thing to do? Or are the 4 hardcoded there a little bit too magic? Maybe we want something more sound, by considering that the virtual button numbers are provided by ZAxisMapping and WAxisMapping, and populating the wscons(4) buttons in the remaining available numbers? Or maybe we/wscons(4) are more right than everybody else, and we want to keep the button numbers between wscons(4) and X, letting the user update ZAxisMapping (and WAxisMapping if they have a really fancy mouse), to available numbers, and maybe reconfiguring all their application for the new numbers. Or maybe leveraging ButtonMapping to return to the standard default numbers. Or whatever floats the user's boat without their pestering the upstream with overly long e-mails in misc@. Not sure how to conclude from there, this button issue has no impact on me outside of my firefox usage, but it keeps declining, w3m makes the web so much more readable and faster, and surf is enough for most javascript-requiring websites still worth my attention, so I let the issue go and wouldn't have posted this if it wasn't commissioned. So the above is really a brain dump of my research for people who care about the issue more than I do (though some of you might not care directly about the issue but care about the new user experiencing out-of-the-box OpenBSD). Natasha
