Ubuntu
xserver-xorg-input-evdev package

[hardy] MX1000 mouse horizontal tilt is inverted

Bug #206963 reported by Jeremy Nickurak
2
Affects Status Importance Assigned to Milestone
xserver-xorg-input-evdev (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: xserver-xorg-input-evdev

Whether configured by hand, or with the standard hardy configuration, an MX1000 mouse's horizontal scroll doesn't work right. In particular, scrolling left produces a button-7 event, and scrolling right produces a button-6 event, the opposite of how applications associate them.

In the past I've been able to correct this behavior with ButtonMapping and HWHEELRelativeAxisButtons options in xorg.conf, however these no longer appear to be supported in the newer evdev drivers. (The mouse driver likewise doesn't support the mouse properly, and isn't used by default anymore anyways).

I'm not sure if this is a problem where something has changed at the X level or in the kernel, but I recall the buttons lining up correctly in the past.

xserver-xorg-input-evdev:
  Installed: 1:1.2.0-1

Linux kedri 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Same thing with Revolution MX.

Changed in xserver-xorg-input-evdev:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Sébastien Bertrand (damocles) wrote :

This tutoriel helps to resolve this problem :
http://wiki.ubuntuusers.de/evdev

It's in german, but you can still try to translate it :
http://translate.google.com/translate?u=http%3A%2F%2Fwiki.ubuntuusers.de%2Fevdev&langpair=de|en&hl=fr&ie=UTF-8

My InputDevice section looks like that :

Section "InputDevice"
 Identifier "Logitech MX1000"
 Driver "evdev"
 Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse"
 Option "RelHWHEELOptions" "invert"
EndSection

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

This seems to work if the mouse is plugged in when X starts up, but if it's removed and plugged in again it's inverted the wrong way again.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

The hotplug issue was a result of me using /etc/hal/fdi/policy/10-x11-input.fdi to allow access to all input devices (since this behavior is no longer supported in evdev directly).

I was able to work around this by:
- applying http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=47eb658e802775021e3efec109f95431cca188ca (which didn't patch cleanly, so I just upgraded config/hal.c entirely), to add support for arbitrary device options in a hal fdi
- editing 10-x11-input.fdi as follows:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
  <!-- FIXME: Support tablets too. -->
  <match key="info.capabilities" contains="input.mouse">
   <merge key="input.x11_driver" type="string">mouse</merge>
   <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
    <merge key="input.x11_driver" type="string">evdev</merge>

    <!-- Logitech tweaks -->
    <match key="@input.originating_device:usb.vendor_id" int="0x46d">
     <match key="@input.originating_device:usb.product_id" int_outof="0xc50e;0xc518">
      <merge key="input.x11_options.RelHWHEELOptions" type="string">invert</merge>
     </match>
    </match>
   </match>
  </match>

  <match key="info.capabilities" contains="input.keys">
  <!-- If we're using Linux, we use evdev by default (falling back to keyboard otherwise). -->
   <merge key="input.x11_driver" type="string">keyboard</merge>
   <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
    <merge key="input.x11_driver" type="string">evdev</merge>
    <merge key="input.xkb.layout" type="string">dvorak</merge>
   </match>
  </match>
 </device>
</deviceinfo>

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Fixed in Intrepid, works even after replugging it.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.