Here're the sections from my xorg.conf that use this patch

Section "InputDevice"
        Identifier  "trackpoint"
        Driver      "mouse"
        Option      "CorePointer"
        Option      "Device" "/dev/input/mouse2"
        Option      "Protocol" "ImPS/2"
        Option      "Emulate3Buttons" "false"
        Option      "EmulateWheel" "true"
        Option      "EmulateWheelTimeOut" "0"
        Option      "EmulateWheelButton" "0"
        Option      "EmulateWheelInertia" "10"
        Option      "XAxisMapping" "6 7"
        Option      "ZAxisMapping" "4 5"
        Option      "YAxisMapping" "4 5"
EndSection

Section "InputDevice"
        Identifier  "Synaptics Touchpad"
        Driver      "synaptics"
        Option      "SendCoreEvents" "true"
        Option      "Protocol" "synaptics"
        Option      "HorizScrollDelta" "60"
        Option      "HorizEdgeScroll" "1"
        Option      "EmulateMidButtonTime" "0"
        Option      "VertTwoFingerScroll" "0"
        Option      "SHMConfig" "on"
        Option      "RTCornerButton" "4"
        Option      "RBCornerButton" "5"
        Option      "LTCornerButton" "0"
        Option      "LBCornerButton" "0"
        Option      "TapButton2" "0"
        Option      "TapButton3" "0"
        Option      "Emulate3Buttons" "0"
EndSection

sorry for the delay. looks good. why do you reset the respective other axis to zero though?

*** Bug 6113 has been marked as a duplicate of this bug. ***

Thanks for looking at this. I reset the other axis to zero to encourage straight motions. When using a single joystick-like device that controls both axes simulteneously (like the trackpoint) it can be difficult to make a motion in one axis without accidentally moving in another direction also. In other words, it's hard to press the trackpoint perfectly upwards; it's usually pressed a bit sideways also. So instead of generating 10 "up" events and 1 "right" event, for example, resetting the other axis would only generate the 10 "up" events.

Looking at this again, resetting the other axis does seem like a good idea, but it's not directly related to the issue of a buttonless MouseWheel. Maybe it should be controlled by a separate xorg.conf option?

Thanks

I think this feature has a narrow enough use-case that we can pick one 
default and live with it. Too many configuration options can backfire too
and options that are never used are just more code to maintain for no
reason.

I do wonder though (after testing this without the reset): only few GUIs
require horizontal scrolling and those that do often allow arbitrary
palacement of the viewport (e.g. PDF viewers). 
Those interfaces would be severely restricted if you could only scroll
up/down _or_ left/right at a time. Other interfaces that don't allow
horizontal scrolling anyway aren't affected by either setting.
So IMO this is a case against resetting the axes.

There are some apps that map horizontal and vertical scrolling to completely different actions. For example, mplayer uses horizontal scrolling for volume and vertical for seeking. So in this case running without the resets could cause unwelcome seeking when adjusting the volume.

I really do like being easily able to select which axis I'm controlling. In both web browsers and pdf viewers, I intend to scroll in only one direction most of the time. In my usage, the only time I wish for unrestricted scrolling is when panning inside a zoomed-in area of an image or a pdf (in that case, locked axes effectively reduce your speed by 50%, since parallel motion is disabled).

There are arguments for both sides, so perhaps a config option is justifiable here. I personally prefer the locked axes, but I can certainly patch my own copy of X if you decide that these are a bad idea by default.

fair enough, you convinced me. However, since these changes are two semantically different ones I'd like to commit them as two patches. One for the button 0 change, one for the "reset axis". this way it's clearer when reading the history. If you could resubmit as git-formatted patch, I'll be happy to apply to the drivers.

http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches

I'll attach the two evdev patches that implement the same feature here for reference. If you could review them as well, that'd be much appreciated. Feel free to copy the commit message :)

Created attachment 28683 [details] [review]
0001-Allow-0-as-wheel-emulation-button-for-unconditional-.patch

Allow button 0 as wheel emulation button.

Created attachment 28684 [details] [review]
0001-Restrict-wheel-emulation-to-a-single-axis-at-a-time.patch

reset inertia of one axis when scrolling on the other.


Oh, another thing: please check the man page for required changes as well so this behaviour is documented.

I'm attaching the two patches for the mouse driver. One minor code change I made since the patch I originally posted is to explicitly ignore the wheel-button timing if there is no wheel button. With the previous patch, we still checked for ms<=0, which just happened to be true, but this could conceivably change in a later revision of the driver. I looked at your evdev code, which looks fine to me (I just read the code, did not run it). In the evdev patch, I made a similar modification to ignore the button timing, and I am including that patch as well.

Created attachment 28690 [details] [review]
mouse-driver patch to allow buttonless EmulateWheel

Created attachment 28691 [details] [review]
mouse-driver patch to encourage scrolling in one direction at a time

Created attachment 28692 [details] [review]
evdev patch to allow buttonless EmulateWheel, with an extra timing check

mouse:
2d43329d778d7bfae5d9c99611ad49efa56716a6  Allow 0 as wheel emulation button for unconditional scrolling (#20529)
bf95ccf496d6674a83c44d559e3eef8729c69449  Restrict wheel emulation to a single axis at a time.

evdev:
2e5f68754fd5bc4e6b7fa5b95bdd30e2bb4e57fb  Restrict wheel emulation to a single axis at a time.
f4ba2bd785b25fd522967abd7775925d5fded70f  Allow 0 as wheel emulation button for unconditional scrolling (#20529)


Thanks for the patches, much appreciated.