Please revert: HAL configuration for Kingsis Peripherals Evoluent VerticalMouse 3

This bug was fixed in the package xserver-xorg-input-evdev - 1:2.2.5-1ubuntu4

---------------
xserver-xorg-input-evdev (1:2.2.5-1ubuntu4) karmic; urgency=low

  * local/evoluent-verticalmouse3.fdi, rules: Add support for Kingsis
    Evoluent VerticalMouse 3.
    (LP: #451729)

 -- Bryce Harrington <email address hidden> Wed, 14 Oct 2009 20:21:50 -0700

As a VerticalMouse 3 user, I think this change is a step backwards.

Now, in addition to moving the 2nd mouse button (which usually opens the context menu in applications) away from under the middle finger, where it usually is in every other mouse, I completely lost the Forward (in browsers) functionality that used to be in the thumb button in Jaunty and before.

How do I revert this change in my installation?

Oh, I'm sorry..

Isn't the middle mouse button normally the paste button and the the button for the ring finger opens the context menu?

Regarding the Forward button, I've thought about using the wheel button for this instead, but this causes havoc under KDE, see bug 448021.

To revert this change (or otherwise manipulate it locally), copy /usr/share/hal/fdi/policy/20thirdparty/evoluent-verticalmouse3.fdi to /etc/hal/fdi/policy and change the following line:
<merge key="input.x11_options.ButtonMapping" type="string">1 2 2 4 5 6 7 3 8</merge>

If you use
<merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 8 9</merge>
you'll have the default again (after unplugging and plugging in your mouse).

For me, the mouse wheel button is quite difficult to press, and since I use middle click a lot for pasting, I've remapped it.
I'm interested what other users of this mouse think, and it would be OK for me to revert this altogether, if it's a regression for others, too.

Middle (aka scroll wheel) is normally paste and the one right to the scroll wheel opens context menu. The rightmost button, under the ring finger, used to do the Back function (and the thumb button did Forward). This is also how it works in Windows, at least without installing any additional drivers. Paste button placement doesn't need to be considered on that OS, though...

I agree that this is largely a matter of preference - I don't find using the scrollwheel button difficult for pasting, but YMMV. I reverted the change using your instructions (thanks!) but can't really speak for others.

Anyone using mice with "extra" buttons probably agrees that the best option would be being able to configure mouse buttons easily using a GUI.

I experienced the same initial reaction as crwl upon receiving this update. Suddenly my right mouse button had seemingly stopped working. I definitely agree it's a matter of preference and probably also largely a matter of what configuration you're used to.

Thanks for the instructions to revert. They worked exactly as described.

For me the mouse behaves in a very strange way. The first time I log in (in either Gnome of Kde), the left-mouse click stops working after a few seconds. I have to log-out and log in and then the mouse functions great. I am using Karmic RC.

Marius, can you please check if the new fdi file triggers the bug you're experiencing?
Just remove /usr/share/hal/fdi/policy/20thirdparty/evoluent-verticalmouse3.fdi (move it e.g. to your home directory) and test if your problem disappears after rebooting.

Thanks so much for those instructions to revert the configuration. I agree with crwl and Ehren in that I like the old configuration much better. I use the middle button to paste a lot but have no problem pushing the scroll wheel unlike Daniel indicated. The fact that I could also use it for back and forward in Firefox made the initial experience that much better when I started using this mouse with Ubuntu.

I believe the old configuration should be the default since for most mice clicking the scroll wheel activates the button 2 paste, it is consistent with the Evoluent documentation which states that the context menu button is activated by the second flat button (not scroll wheel) and not the button closest to the desk. Since most Ubuntu users don't know or care to change the HAL mouse configuration, the old default is likely closer to their expectations.

Ok, I think this should get reverted, given the feedback. I still can use this config myself locally.

Be careful when just reverting this cahnge (r42), since a lot of other stuff apparently got changed / rolled back (by accident)?!

Hmm, maybe only
  <merge key="input.x11_options.ButtonMapping" type="string">1 2 2 4 5 6 7 3 8</merge>
should get changed to "1 2 3 4 5 6 7 8 9" or removed?!

This bug was fixed in the package xserver-xorg-input-evdev - 1:2.2.5-1ubuntu6

---------------
xserver-xorg-input-evdev (1:2.2.5-1ubuntu6) karmic; urgency=low

  * Revert addition evoluent-verticalmouse3.fdi.
    (LP: #451729)

 -- Bryce Harrington <email address hidden> Sun, 25 Oct 2009 12:23:17 -0700