Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455606 - Middle mouse button doesn't work anymore
Summary: Middle mouse button doesn't work anymore
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-mouse
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-16 16:01 UTC by James Antill
Modified: 2018-04-11 18:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-17 00:30:25 UTC

Attachments (Terms of Use)

Description James Antill 2008-07-16 16:01:52 UTC
Description of problem:
 I have a logitech revolution, the last Xorg I could use (Fedora 7) one of the
buttons worked fine as the middle button. Now I can't get any of them to do it.

Version-Release number of selected component (if applicable):

Additional info:

 This is the mouse:,CRID=2135,CONTENTID=12134

 The Xorg.log has:

(II) config/hal: Adding input device Macintosh mouse button emulation
(II) LoadModule: "evdev"

(II) Loading /usr/lib64/xorg/modules/input//
(II) Module evdev: vendor="X.Org Foundation"
        compiled for 0.0.0, module version = 1.0.0
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 2.0
(**) Macintosh mouse button emulation: always reports core events
(**) Macintosh mouse button emulation: Device: "/dev/input/event0"
(II) Macintosh mouse button emulation: Found x and y relative axes
(II) Macintosh mouse button emulation: Found mouse buttons
(II) Macintosh mouse button emulation: Configuring as mouse
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation"
(type: MOUSE)
(II) config/hal: Adding input device Logitech USB Receiver
(**) Logitech USB Receiver: always reports core events
(**) Logitech USB Receiver: Device: "/dev/input/event3"
(II) Logitech USB Receiver: Found x and y relative axes
(II) Logitech USB Receiver: Found mouse buttons
(II) Logitech USB Receiver: Configuring as mouse
(II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: MOUSE) xorg.conf currently has:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Device" "/dev/input/mice"
        # Option            "Protocol" "IMPS/2"
        # Option            "Protocol" "USB"
        # Option            "Protocol" "Auto"
        Option      "Protocol" "Logitech"
        Option      "ZAxisMapping" "4 5"
        # Option "ButtonMapping" "1 8 3 6 9"

...I've tried the commented out options, and it used to work with IMPS/2 and no
ButtonMapping Option.

 The button I used to use as the middle button is reported as "button 8" in xev,
hence my trying the above buttonmapping.

Comment 1 Matěj Cepl 2008-07-16 22:28:24 UTC
Just to be sure, can we get whole /etc/X11/xorg.conf and /var/log/Xorg.*.log as
well please attached to this bug report as separate and uncompressed attachments?

Thank you very much.

Comment 2 Peter Hutterer 2008-07-17 00:30:25 UTC
The log excerpt indicates that evdev takes over your mouse.

In F9, input devices are hotplugged with the evdev driver. The list of devices
is provided by HAL, and any device using evdev will not send to /dev/input/mice.
If a InputDevice is configured for /dev/input/mice, it won't generate any event
if all mice are hotplugged through HAL. This usually looks like the
configuration is ignored or lost.

The two options to fix this is:
- Add Option "AutoAddDevices" "off" to the ServerLayout. This disables input
device hotplugging alltogether and prevents evdev from taking over.
- Change the InputDevice section to use evdev as driver and specify the device
file as /dev/input/by-id/... or /dev/input/by-path/... /dev/input/event0 is
valid too, but those numbers may change on reboot.
If you choose this option, you may have to specify multiple InputDevice sections
since evdev does not have an equivalent to /dev/input/mice.

Beware that some option that are supported in the mouse driver may not be
available in the evdev driver. If so, you can file a feature request with
upstream at

I'm closing this as NOTABUG, it's a configuration issue. Feel free to reopen if
I misinterpreted it.

Comment 3 James Antill 2008-07-17 04:25:00 UTC
 Ok, so I've reverted to my original config. + 'Option "AutoAddDevices" "off"'
in the server layout ... as that sounds like the easiest/best method? I'll
probably reboot X sometime tomorrow to see if that fixes it.

 But that then begs the question, why do we do the evdev stuff now? What is the
recommended configuration?

Comment 4 Peter Hutterer 2008-07-17 05:24:58 UTC
evdev separates the physical devices. with evdev, the server actually knows that
you have 2 keyboards and 4 mice connected. with /dev/input/mice, the server only
knows about one.

One of the benefits is hotplugging, you can hotplug and the server knows that a
new device is available. The other benefit is multi-device capabilities, which
won't come until X11R7.5 or later.

In the bright and sometimes distant future, evdev devices also announce their
capabilities, so you know that a device has 4 axes and 17 buttons, rather than
guesstimating it.

All that aside, the evdev driver is also easier to maintain than the mouse
driver. For now anyway.

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