The trackball I bought has two little buttons that replace the typical (and useful!) wheel. One (button 3) is used to scroll down and the other (button 4) to scroll up. These are the events that a wheel generally generates every time you move it in either direction.

Unfortunately, if you press and hold one of these special buttons, the trackball only sends a single press event. So, if you want to scroll a document up or down, you have to repeatedly click buttons 4 and 3 respectively, which is highly annoying: you end up going to the scroll bar and using it rather than the two buttons.

The Windows and Mac OS X drivers solve this by generating press and release events periodically for those buttons while they are pressed. This way, the application sees as if you had clicked them multiple times. Very comfortable.

I didn't mention NetBSD in the previous paragraph because it doesn't support this feature. That is, it handles those buttons as two extra regular buttons (in fact, they are from the hardware's point of view). And no, neither Linux, XFree86 nor X.Org provide options to simulate the expected behavior as far as I can tell.

So, what did I do? Add support to NetBSD's mouse driver (wsmouse) to simulate automatic button repeating. This way, I can use the trackball to its full power — hey, I got that model precisely because those two buttons!

This new feature is customizable through a set of nodes exposed by wsconsctl(8), as seen below:
# wsconsctl -m -a | grep repeat
repeat.buttons=3 4
repeat.buttons indicates which buttons are subject to automatic event repeating. The other three variables indicate the delays used to control how often events are sent. Three are needed because they the feature supports acceleration. That is, the first time you click a button, it will take 200ms until the first repeated event is sent. The second event will be sent after 175ms; the third after 150ms and so on until the events are separated 50ms each other (the minimum). Useful to scroll large documents.