Bug 612140

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

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.

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

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.

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

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.

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.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[pcfe@karhu ~]$ uname -r
3.3.0-4.fc16.x86_64

retested by un- and then re-plugging mouse. Buttons still in wrong order.

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

# 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).

I still experience this issue with 3.6.2-4.fc17
adjusting version field

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

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

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

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).

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

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"

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

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

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.

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

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.

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.

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.

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

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.

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.

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.

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

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.

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?

already done, just waiting for an ack. http://patchwork.freedesktop.org/patch/26017/