Please revert: HAL configuration for Kingsis Peripherals Evoluent VerticalMouse 3

Bug #451729 reported by Daniel Hahler on 2009-10-14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xserver-xorg-input-evdev (Ubuntu)

Bug Description

Binary package hint: xserver-xorg-input-evdev

The attached patch configures the Kingsis Peripherals Evoluent VerticalMouse 3, using HAL.

I've posted it originally at

I'm not attaching it as a patch (but only as attachment), since I'm not sure where to put (and name) it in the package.

Daniel Hahler (blueyed) wrote :
Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Undecided → Wishlist
Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Fix Released
crwl (crwl) wrote :

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?

Daniel Hahler (blueyed) wrote :

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.

crwl (crwl) wrote :

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.

Ehren Kret (eakret) wrote :

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.

Marius (felijohn) wrote :

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.

Daniel Hahler (blueyed) wrote :

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.

Laszlo Pandy (laszlok) wrote :

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.

Daniel Hahler (blueyed) wrote :

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)?!

Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Wishlist → Medium
status: Fix Released → Triaged
summary: - HAL configuration for Kingsis Peripherals Evoluent VerticalMouse 3
+ Please revert: HAL configuration for Kingsis Peripherals Evoluent
+ VerticalMouse 3
Daniel Hahler (blueyed) wrote :

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?!

Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments