Bug 13135 - logitech mouse sometimes fails to move sideways at all
logitech mouse sometimes fails to move sideways at all
Product: xorg
Classification: Unclassified
Component: Input/evdev
Other All
: medium normal
Assigned To: Zephaniah E. Hull
Xorg Project Team
: 13959 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-11-07 14:47 UTC by Antoine Martin
Modified: 2008-08-13 06:16 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Martin 2007-11-07 14:47:28 UTC
Kernels tested: 2.6.22.x to
Xorg version 1.4.0
Device: Logitech Wireless Keyboard + Mouse
Bus 002 Device 009: ID 046d:c517 Logitech, Inc.
aka "Logitech Cordless Desktop Wave"
"Logitech Cordless Keyboard"
M/N: Y-RCP140
P/N: 820-000413 (137341-002 A)
PID: MC 7 30 S Z
C/N: 10827
CMII ID: 2007DJ1316

1) (critical) Sometimes - but not always, the X mouse driver will not detect the mouse correctly and the mouse will only move up and down the screen when it is moved left and right. It can only be moved right by holding a button and moving the Y axis, it can only be moved left by pressing certain keys on the keyboard. (some of these extra keys which are not normally mapped)
Reboot does not always fix it. Neither does poweroff... Seems quite random.
2) (less critical) The event driver for X does not work in its default configuration for this keyboard/mouse. Looks like the keyBits/evBits need tweaking, but I can't seem to find a tool that is going to help me detect which bits are useful and which ones aren't... (I've played with evtest.c and evread.c, etc...)
This is a shame as this is seems to be the only way to get all the extra keys to be picked up by X, and might resolve the first issue too.
Comment 1 Vlastimil Babka 2008-01-07 13:06:28 UTC
On my MX-3000 wireless combo mouse, the X axis does never work.

Relevant part of xorg.log indeed suggests some X axis problems:

(**) Option "CorePointer"
(**) MX600: always reports core events
(II) MX600: Found 1 absolute axes.
(II) MX600: Configuring as pointer.
(II) MX600: Found 5 relative axes.
(II) MX600: Configuring as pointer.
(EE) MX600: Unable to parse 'RelAxis 0' as a map specifier.
(**) MX600: Configuring 1 absolute axes.
(II) MX600: Checking button DIGI_STYLUS (74)
(II) MX600: Checking bit 330
(EE) MX600: AbsoluteTouch: 'DIGI_Touch' does not exist.
(II) MX600: Found 9 mouse buttons
(II) MX600: Configured 18 mouse buttons.

That's with xf86-input-evdev-1.2.0. It works fine with 1.1.5 and the log looks ok too:
(**) MX600-usb-0000:00:02.0-7/input1: always reports core events
(II) MX600-usb-0000:00:02.0-7/input1: Found 1 absolute axes.
(II) MX600-usb-0000:00:02.0-7/input1: Configuring as pointer.
(II) MX600-usb-0000:00:02.0-7/input1: Found 5 relative axes.
(II) MX600-usb-0000:00:02.0-7/input1: Configuring as pointer.
(**) MX600-usb-0000:00:02.0-7/input1: HWHEELRelativeAxisButtons: 6 7.
(**) MX600-usb-0000:00:02.0-7/input1: WHEELRelativeAxisButtons: 4 5.
(II) MX600-usb-0000:00:02.0-7/input1: Found 8 mouse buttons
(**) MX600-usb-0000:00:02.0-7/input1: Configuring 1 absolute axes.
(II) MX600-usb-0000:00:02.0-7/input1: Checking button DIGI_STYLUS (330)
(II) MX600-usb-0000:00:02.0-7/input1: Checking bit 330
(EE) MX600-usb-0000:00:02.0-7/input1: AbsoluteTouch: 'DIGI_Touch' does not exist.
(**) MX600-usb-0000:00:02.0-7/input1: Configuring in Absolute mode.
(**) MX600-usb-0000:00:02.0-7/input1: Configuring 5 relative axes.
(II) MX600-usb-0000:00:02.0-7/input1: Configured 12 mouse buttons

There's also a Gentoo bug about this: https://bugs.gentoo.org/show_bug.cgi?id=199317
Comment 2 Jose M. daLuz 2008-01-19 08:54:56 UTC
I have the same problem/messages as in comment 1. I have a Logitech MX-600 mouse.
Comment 3 Kjel Oslund 2008-02-08 11:44:34 UTC
I have the same problem with the evdev drive and no X-axis movement with from a Logitech Cordless Desktop S510 combo keyboard/mouse. The mouse works with the regular mouse diver, but not evdev.

I'm running Mandriva Cooker, x11-server-xorg-
Bus 002 Device 002: ID 046d:c513 Logitech, Inc.
Comment 4 Vlastimil Babka 2008-02-24 08:27:37 UTC
Looked a bit at the cause in evdev_axes.c. Looks like in EvdevAxisAbsNew(), it detects an absolute axis. In my case its position is 32 in the bits.abs, but the numbers to axes are assigned from 0 via variable 'j', so it ends up as "AbsAxis 0". Similarly in EvdevAxisRelNew(), relative axes are numbered from 0. And because EvdevParseMapToAbsAxis() is processed before EvdevParseMapToRelAxis(), the axis 0 is taken by the absolute axis, and the relative axis 0 is processed as already present and thus discarded.

While the mouse itself may be wrong about having an absolute axis, it at least reports it on different position than X axis, so it should work anyway. It worked before 1.2.0.
Comment 5 Kjel Oslund 2008-02-29 22:32:17 UTC
I've done some debugging of this problem and found the following for my Logitech Cordless Desktop S510 combo keyboard/mouse:

runing evtest on the devices shows that the second device interface for the mouse plus additional keys has the following events configured:

Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc513 version 0x111
Input device name: "Logitech USB Receiver"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 113 (Mute)
    Event code 114 (VolumeDown)
    Event code 115 (VolumeUp)
    Event code 116 (Power)
    Event code 119 (Pause)
    Event code 128 (Stop)
    Event code 130 (Props)
    Event code 131 (Undo)
[more type 1 events snipped ...]
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
    Event code 6 (HWheel)
    Event code 7 (Dial)
    Event code 8 (Wheel)
  Event type 3 (Absolute)
    Event code 32 (Volume)
      Value      0
      Min        1
      Max     4173
  Event type 4 (Misc)
    Event code 4 (ScanCode)

I added some additional messages to the evdev_axis.c code which shows this:
(**) Mouse2: always reports core events
(II) Mouse2: Found 1 absolute axes.
(II) Mouse2: Configuring as pointer.
(II) EvdevParseMapToAbsAxis: name=Abs32MapTo, option=0
(II) Mouse2: Found 5 relative axes.
(II) Mouse2: Configuring as pointer.
(II) EvdevParseMapToRelAxis: name=RelXMapTo, option=0
(II) EvdevParseMapToRelAxis: axes->v_flags=5
(EE) Mouse2: RelXMapTo: Axis 0 already claimed.
(EE) Mouse2: Unable to parse 'RelAxis 0' as a map specifier.
(II) EvdevParseMapToRelAxis: name=RelYMapTo, option=1
(II) EvdevParseMapToRelAxis: axes->v_flags=0
(II) EvdevParseMapToRelAxis: name=RelDIALMapTo, option=3
(II) EvdevParseMapToRelAxis: axes->v_flags=0
(**) Mouse2: Configuring 1 absolute axes.
(II) Mouse2: Checking button DIGI_STYLUS (74)
(II) Mouse2: Checking bit 330
(EE) Mouse2: AbsoluteTouch: 'DIGI_Touch' does not exist.
(II) Mouse2: Found 9 mouse buttons
(II) Mouse2: Configured 18 mouse buttons.
(II) evaluating device (Mouse2)
(II) XINPUT: Adding extended input device "Mouse2" (type: KEYBOARD)

Note that the Volume event Abs32MapTo has claimed Axis 0 ahead of RelXMapTo so mouse horizontal movement cannot be handled.

The keyboard does not have a volume wheel, just volume +/- buttons, so the reported event appears spurious. Possibly Logitech is using the same or similar controller code for several different keyboard models.
Comment 6 Kjel Oslund 2008-03-01 09:30:56 UTC
Re comment #5, I've also noted that the abs_axis_names[] table used in the drivers is out of sync with linux/input.h in kernel 2.6.24 (Mandriva kernel-headers-2.6.24-5mdv2008.1):

 * Absolute axes

#define ABS_X                   0x00
#define ABS_Y                   0x01
#define ABS_Z                   0x02
#define ABS_RX                  0x03
#define ABS_RY                  0x04
#define ABS_RZ                  0x05
#define ABS_THROTTLE            0x06
#define ABS_RUDDER              0x07
#define ABS_WHEEL               0x08
#define ABS_GAS                 0x09
#define ABS_BRAKE               0x0a
#define ABS_HAT0X               0x10
#define ABS_HAT0Y               0x11
#define ABS_HAT1X               0x12
#define ABS_HAT1Y               0x13
#define ABS_HAT2X               0x14
#define ABS_HAT2Y               0x15
#define ABS_HAT3X               0x16
#define ABS_HAT3Y               0x17
#define ABS_PRESSURE            0x18
#define ABS_DISTANCE            0x19
#define ABS_TILT_X              0x1a
#define ABS_TILT_Y              0x1b
#define ABS_TOOL_WIDTH          0x1c
#define ABS_VOLUME              0x20
#define ABS_MISC                0x28
#define ABS_MAX                 0x3f
#define ABS_CNT                 (ABS_MAX+1)

I'm using the 1.2.0 version of evdev driver, package x11-driver-input-evdev-1.2.0-5mdv2008.1 on Mandriva Cooker (2008.1)
Comment 7 Peter Hutterer 2008-03-01 19:29:11 UTC
*** Bug 13959 has been marked as a duplicate of this bug. ***
Comment 8 Vlastimil Babka 2008-06-07 16:15:32 UTC
Problem seems gone with xf86-input-evdev-1.99.2	here.
Comment 9 Peter Hutterer 2008-06-29 04:20:57 UTC
Calling it fixed then, please reopen if bug persists.
Comment 10 Jeremy Nickurak 2008-08-12 17:53:29 UTC
Is there a patch or workaround for people on distros still using 1.2.0?
Comment 11 zimous 2008-08-13 06:16:13 UTC
(In reply to comment #10)
> Is there a patch or workaround for people on distros still using 1.2.0?

I had used a workaround in mouse section of xorg.conf (maybe will work for you too):

Option "Abs32MapTo" "-1"

(see duplicate bug 13959 for details)