Kernels tested: 2.6.22.x to 2.6.23.1 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 FCC ID: JNZYRCP140 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.
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
I have the same problem/messages as in comment 1. I have a Logitech MX-600 mouse.
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-1.4.0.90 Bus 002 Device 002: ID 046d:c513 Logitech, Inc.
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.
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.
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)
*** Bug 13959 has been marked as a duplicate of this bug. ***
Problem seems gone with xf86-input-evdev-1.99.2 here.
Calling it fixed then, please reopen if bug persists.
Is there a patch or workaround for people on distros still using 1.2.0?
(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)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.