AFAIK, steps of the wheel up or down are treated as clicks of a 4th or 5th mouse button. That is because the capabilities of core X pointer devices were defined rather early, before mice with scroll wheels and long before 3D mice or data gloves: max 5 buttons (but maybe can get away with a bit more), and only two dimensions of motion. If the scroll wheel were just another dimension of motion, perhaps adjusting the speed of it would be easier, but the protocol doesn't allow it. Extension devices can theoretically have more buttons and dimensions of motion, but not a lot of drivers exist, applications would have to be written specially to talk to extension devices, and I think there's a limitation that a device cannot be a core device and an extension device at the same time (although a tricky driver could perhaps treat a single physical device as two logical devices, one core and one extension, so as to report core events to any app, and extension events to extension-device-aware apps; but again, there's very little code for that sort of thing out there).
Each toolkit that applications are built with has different ways of using button 4 or 5 clicks as scroll bar accelerators. With Motif for instance, the capability may not be built in, but if it isn't it can be added with appropriate X resources, although realistically they might need to be set on a per-Motif-application basis. GNOME and KDE apps typically have native support, but I don't use them enough to know if they have some way of setting it for all apps that use one of those toolkits at once. I suspect they may not, or not all apps take advantage of this, because I can find others asking the same sort of question (for Linux, but the principle is the same) and only getting per-application answers. I think it boils down to this: at _best_, you can only set scroll rate once for everything if all your apps use the same toolkit, and if the toolkit supports that. AFAIK, Firefox is GNOME based, so if it provides its own rate control, I'm guessing that there is no single rate control for all GNOME apps. The X server could fake all that out by generating one, or more than one buttonpress/buttonrelease event for each mouse wheel step. So if there's a way, maybe that's it and was how Xsun could do it. No idea if Xorg can, although some very quick googling didn't find it. And that could only speed it up, not slow it down if the app is already assuming more than one line (or whatever its increment is) of scroll per click. If there's some magic I haven't heard of, Alan would probably know if anyone would. But I wouldn't recommend getting your hopes up for hearing what you want to hear. This message posted from opensolaris.org
