Bug 612140 - please make Evoluent VerticalMouse 3 work out of the box
please make Evoluent VerticalMouse 3 work out of the box
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
20
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-07 08:13 EDT by Patrick C. F. Ernzer
Modified: 2014-05-19 07:09 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-13 20:29:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrick C. F. Ernzer 2010-07-07 08:13:14 EDT
Description of problem:
out of the box, the buttons of an Kingsis Peripherals Evoluent VerticalMouse 3 are mapped differently from a normal mouse.

Version-Release number of selected component (if applicable):
xorg-x11-drv-mouse-1.5.0-4.fc13.x86_64

How reproducible:
always

Steps to Reproduce:
1. plug in Kingsis Peripherals Evoluent VerticalMouse 3
2. use buttons
  
Actual results:
button mapping different from standard mouse (e.g. middle button is what right-button is on normal mouse)

Expected results:
all buttons mapped like any other mouse

Additional info:
/usr/bin/xinput set-button-map "Kingsis Peripherals  Evoluent VerticalMouse 3 " 1 2 2 4 5 6 7 3 8

works for me. (note the additional space at the end of the device's name)
Comment 1 Bug Zapper 2010-07-30 08:28:02 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Peter Hutterer 2011-11-10 22:35:37 EST
is this still an issue? if so, are you actually using the mouse driver (If you don't know or you're not sure, you're using evdev).

The drivers just set up a default mapping, so if the mapping is still broken this would need to be fixed in the kernel. Please provide your Xorg.log and the evtest output for this device when you press the buttons.
Comment 3 Patrick C. F. Ernzer 2011-11-11 08:55:01 EST
(In reply to comment #2)
> is this still an issue?

Do you mean under F15, probably still an issue, but I still have this in place;
$ cat /etc/X11/xinit/xinitrc.d/99-Evoluent-VerticalMouse-3.sh 
#!/bin/bash
/usr/bin/xinput set-button-map "Kingsis Peripherals  Evoluent VerticalMouse 3 " 1 2 2 4 5 6 7 3 8

If you mean under F16, I'll be able to tell once this box has been upgraded.

> if so, are you actually using the mouse driver (If you
> don't know or you're not sure, you're using evdev).

I'd be using evdev then.

> The drivers just set up a default mapping, so if the mapping is still broken
> this would need to be fixed in the kernel. Please provide your Xorg.log and the
> evtest output for this device when you press the buttons.

Do I presume correctly that no matter of you want F15 or F16 results, I'll have to disable the xinitrc.d script and re-launch xorg? Or would you be happy with evtest results after a 
/usr/bin/xinput set-button-map "Kingsis Peripherals  Evoluent VerticalMouse 3 " 1 2 3 4 5 6 7 8 9
?
Comment 4 Patrick C. F. Ernzer 2011-11-28 07:48:18 EST
Just installed (fresh install,  not update) the box which has the Evoluent VerticalMouse 3 connected. Problem remains that buttons are mapped wrong. installing xorg-x11-apps and running the script by hand resolved the problem for now. Adjusting release.
Comment 5 Peter Hutterer 2011-11-28 23:02:21 EST
evtest logs the data directly from the kernel, xinput settings have no effect on it. that output would be useful to figure out what the device actually does
Comment 6 Patrick C. F. Ernzer 2011-11-29 08:14:02 EST
evtest gives, (these are all from a single press / scroll)

left mouse button
Event: time 1322571962.743771, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1322571962.743772, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1322571962.743786, -------------- SYN_REPORT ------------
Event: time 1322571962.851773, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1322571962.851774, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1322571962.851789, -------------- SYN_REPORT ------------

middle mouse button
Event: time 1322571991.945402, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002
Event: time 1322571991.945403, type 1 (EV_KEY), code 273 (BTN_RIGHT), value 1
Event: time 1322571991.945416, -------------- SYN_REPORT ------------
button 1Event: time 1322571992.097352, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002
Event: time 1322571992.097353, type 1 (EV_KEY), code 273 (BTN_RIGHT), value 0
Event: time 1322571992.097366, -------------- SYN_REPORT ------------

right mouse button
Event: time 1322572014.021111, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90004
Event: time 1322572014.021113, type 1 (EV_KEY), code 275 (BTN_SIDE), value 1
Event: time 1322572014.021122, -------------- SYN_REPORT ------------
Event: time 1322572014.351108, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90004
Event: time 1322572014.351110, type 1 (EV_KEY), code 275 (BTN_SIDE), value 0
Event: time 1322572014.351119, -------------- SYN_REPORT ------------

click mouse wheel
Event: time 1322572059.636491, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1322572059.636492, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1322572059.636503, -------------- SYN_REPORT ------------
Event: time 1322572014.021111, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90004
Event: time 1322572014.021113, type 1 (EV_KEY), code 275 (BTN_SIDE), value 1
Event: time 1322572014.021122, -------------- SYN_REPORT ------------
Event: time 1322572014.351108, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90004
Event: time 1322572014.351110, type 1 (EV_KEY), code 275 (BTN_SIDE), value 0
Event: time 1322572014.351119, -------------- SYN_REPORT ------------
Event: time 1322572059.854501, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1322572059.854502, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1322572059.854513, -------------- SYN_REPORT ------------

thumb button on mouse
Event: time 1322572123.387663, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90005
Event: time 1322572123.387664, type 1 (EV_KEY), code 276 (BTN_EXTRA), value 1
Event: time 1322572123.387672, -------------- SYN_REPORT ------------
Event: time 1322572123.539659, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90005
Event: time 1322572123.539660, type 1 (EV_KEY), code 276 (BTN_EXTRA), value 0
Event: time 1322572123.539667, -------------- SYN_REPORT ------------

wheel towards front of mouse
Event: time 1322572160.335222, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1322572160.335223, -------------- SYN_REPORT ------------

wheel towards back of mouse
Event: time 1322572190.016747, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1322572190.016749, -------------- SYN_REPORT ------------


So, to summarise; this mouse needs a work around because it reports it's buttons wrong. Apologies, I thought that was clear from description. Nothing wrong with xorg-x11-drv-mouse but it would be nice if it knew that, when the mouse tells it's wrong button tales, it really needs to interpret them for this particular model.
Comment 7 Peter Hutterer 2011-11-29 16:36:25 EST
reassigning to kernel, this needs a quirk to work out of the box.

Required button reassignments as follows:
Button currently reported → Button should be reported

BTN_LEFT → BTN_LEFT  (no change necessary)
BTN_RIGHT → BTN_MIDDLE
BTN_SIDE → BTN_RIGHT
BTN_MIDDLE → BTN_SIDE


This may still cause issues with the wheel click that currently reports two button events, but should at least fix the other issues that require button remapping.
Comment 8 Dave Jones 2012-03-22 12:51:19 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 9 Dave Jones 2012-03-22 12:55:36 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 10 Dave Jones 2012-03-22 13:06:18 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 11 Patrick C. F. Ernzer 2012-03-26 11:36:15 EDT
[pcfe@karhu ~]$ uname -r
3.3.0-4.fc16.x86_64

retested by un- and then re-plugging mouse. Buttons still in wrong order.
Comment 12 Josh Boyer 2012-09-07 12:03:49 EDT
(In reply to comment #7)
> reassigning to kernel, this needs a quirk to work out of the box.
> 
> Required button reassignments as follows:
> Button currently reported → Button should be reported
> 
> BTN_LEFT → BTN_LEFT  (no change necessary)
> BTN_RIGHT → BTN_MIDDLE
> BTN_SIDE → BTN_RIGHT
> BTN_MIDDLE → BTN_SIDE
> 
> 
> This may still cause issues with the wheel click that currently reports two
> button events, but should at least fix the other issues that require button
> remapping.

I'm not really sure how or where (which driver) to code that up in.  I can't find any other quirks like this at a cursory glance.  Any tips?
Comment 13 Dave Jones 2012-10-23 11:37:41 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 14 Patrick C. F. Ernzer 2012-10-29 11:19:10 EDT
I still experience this issue with 3.6.2-4.fc17
adjusting version field
Comment 15 Patrick C. F. Ernzer 2013-01-23 07:00:24 EST
I still experience this issue on F18 x86_64 with 3.7.2-204.fc18.x86_64
adjusting version field (and lowering severity, it's just a mouse and the work around shown in comment #3 is straightforward. Still it would be nice if we could offer an out of the box experience for this ergonomic mouse

Peter: do you have quirk tips for Josh (comment #12)?
Comment 16 Fedora Update System 2013-01-25 01:55:16 EST
xorg-x11-server-1.13.1-5.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.13.1-5.fc18
Comment 17 Peter Hutterer 2013-01-25 01:56:20 EST
I've added the snippet below to the xorg-x11-server quirk files. It gives you some button mapping, but given that this changes the existing one, I may have to revert it though if some people complain (and they liked the default one better).

Section "InputClass"
        Identifier "Evoluent VerticalMouse 3"
        MatchProduct "Evoluent VerticalMouse 3"
        Option "ButtonMapping" "1 2 2 0 0 0 0 3 8"
EndSection
Comment 18 Fedora Update System 2013-01-26 11:05:28 EST
Package xorg-x11-server-1.13.1-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.13.1-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1549/xorg-x11-server-1.13.1-5.fc18
then log in and leave karma (feedback).
Comment 19 Fedora Update System 2013-01-31 01:27:44 EST
xorg-x11-server-1.12.4-5.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.12.4-5.fc17
Comment 20 Benjamin Gilbert 2013-02-13 18:42:17 EST
The change in comment 17 disables the scroll wheel on this mouse.  Changing the ButtonMapping to the following fixed it for me:

	Option "ButtonMapping" "1 2 2 4 5 0 0 3 8"
Comment 21 Fedora Update System 2013-02-14 06:17:23 EST
xorg-x11-server-1.13.2-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.13.2-4.fc18
Comment 22 Fedora Update System 2013-02-14 16:16:59 EST
xorg-x11-server-1.12.4-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.12.4-6.fc17
Comment 23 Fedora Update System 2013-02-24 04:08:35 EST
xorg-x11-server-1.13.2-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Fedora Update System 2013-04-17 01:02:50 EDT
xorg-x11-server-1.12.4-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.12.4-7.fc17
Comment 25 Fedora Update System 2013-06-07 19:30:00 EDT
xorg-x11-server-1.12.4-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 whereami 2014-05-07 17:35:49 EDT
Please revert these changes. The manufacturer intended the original button placement:

http://www.evoluent.com/vm3.html
"""
When the driver is not installed, the default functions in Windows are:
Top button - left click.
Wheel button - .middle click (e.g., for pan and rotate in CAD programs).
Middle button - right click.
Bottom button - back.
Thumb button - forward.
"""

As a user of this mouse for >6 years, I think the manufacturer is correct. The "Middle button" falls naturally under the middle finger, while the "Bottom button" falls naturally under the ring and pinky. The "Middle button" therefore is on the same finger as the right button on a standard mouse. The ring/pinky button is an extra button. It is under the finger that on a standard mouse would be on the right side.

I do think the manufacturer should have swapped the forward/back buttons, but I got used to that.
Comment 27 whereami 2014-05-12 16:44:30 EDT
Hi Peter, Please consider this a complaint of the variety described in Comment 17.

The modification hit the latest Ubuntu LTS (14.04 Trusty) released last month.
Comment 28 Peter Hutterer 2014-05-13 00:46:08 EDT
Was this filed in a ubuntu bug somewhere? how many people are complaining about this already? I'm surprised this hasn't come up earlier, this bug is over a year old already
Comment 29 whereami 2014-05-13 14:21:57 EDT
I could only find these complaints wrt Ubuntu 14.04:
http://ubuntuforums.org/showthread.php?t=2221058
http://askubuntu.com/questions/458830/where-are-the-mouse-button-settings-in-ubuntu-14-04

I also found this bug from 2009 where a similar change was made and then reverted with support from 3 people:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/451729
And the bug that led me there:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/455822

I note that afaict only one person complained for you to change the default here.

Just to re-summarize, my complaint is two-fold:
1) Right-click is not under the middle finger, while middle-click is duplicated.
2) The Forward button is missing.
And my main arguments are:
1) The manufacturer's default is not unreasonable.
2) You changed the default >6 years after this mouse was first produced.
Comment 30 Peter Hutterer 2014-05-13 20:26:55 EDT
This is a notification for users of the Evoluent Vertical Mouse 3. This mouse had a custom button mapping that differs from the mapping most people are used to. The manufacturer documents this here: http://www.evoluent.com/vm3.html

<quote>
Top button - left click.
Wheel button - .middle click (e.g., for pan and rotate in CAD programs).
Middle button - right click.
Bottom button - back.
Thumb button - forward.
</quote>

A change in F18 shipped the following quirk to make the mouse send left/middle/right for the three mouse buttons. This change was in error, we should follow the manufacturer's defaults. If you prefer the changed behaviour, pop the following snippet into /etc/X11/xorg.conf.d/99-vertical-mouse.conf

Section "InputClass"
       Identifier "Evoluent VerticalMouse 3"
        MatchProduct "Evoluent VerticalMouse 3"
        # Sets following configuration:
        # top button:    left
        # middle button: middle
        # bottom button: right
        # wheel click:   middle
        # thumb button:  8 (back)
       Option "ButtonMapping" "1 2 2 4 5 6 7 3 8"
EndSection


The behaviour will be reverted to the defaults in Fedora 19 and above.
Comment 31 Peter Hutterer 2014-05-13 20:29:58 EDT
Closing this as WONTFIX, because the original request of the bug is to change the mapping. We're reverting to the defaults again, see Comment 30 for a workaround to address the original request for this bug.
Comment 32 Fedora Update System 2014-05-13 20:56:47 EDT
xorg-x11-server-1.14.4-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.4-9.fc20
Comment 33 Fedora Update System 2014-05-16 06:10:32 EDT
xorg-x11-server-1.14.4-9.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 34 whereami 2014-05-16 14:21:25 EDT
Thanks Peter. I realized this is also upstream, which I think is how it made its way to Ubuntu. Could you remove the quirk from the X.org repositories too?
Comment 35 Peter Hutterer 2014-05-19 07:09:46 EDT
already done, just waiting for an ack. http://patchwork.freedesktop.org/patch/26017/

Note You need to log in before you can comment on or make changes to this bug.