Bug 32882 - kensington pocket mouse model #72237 USB 0d62:1000 not working
Summary: kensington pocket mouse model #72237 USB 0d62:1000 not working
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 7.5 (2009.10)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL: https://bugs.launchpad.net/ubuntu/+so...
Depends on:
Reported: 2011-01-06 13:16 UTC by Bryce Harrington
Modified: 2011-02-24 19:36 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

XorgLog.txt (32.05 KB, text/plain)
2011-01-06 13:17 UTC, Bryce Harrington
no flags Details
Lsusb.txt (441 bytes, text/plain)
2011-01-06 13:17 UTC, Bryce Harrington
no flags Details
CurrentDmesg.txt (3.25 KB, text/plain)
2011-01-06 13:17 UTC, Bryce Harrington
no flags Details
BootDmesg.txt (44.92 KB, text/plain)
2011-01-06 13:18 UTC, Bryce Harrington
no flags Details
Workaround (885 bytes, patch)
2011-01-06 13:20 UTC, Bryce Harrington
no flags Details | Splinter Review
Output from evtest on benq m310 mouse (22.54 KB, text/plain)
2011-02-22 12:09 UTC, Jeff Norden
no flags Details

Description Bryce Harrington 2011-01-06 13:16:14 UTC
Forwarding this bug from Ubuntu reporter Douglas Henke:

kensington pocket mouse model #72237 USB 0d62:1000 getting interpreted as a keyboard and as having absolute axes when it has rel axes.  Do any real-world devices have both absolute and relative axes?

[Original Description]
Under Ubuntu, my Kensington pocket mouse, model #72237, does not move the cursor. (The buttons and wheel work, just not X or Y movement.) This is a wireless mouse with a USB dongle, USB ID 0d62:1000. The kernel recognizes the device, and udev creates the appropriate device files. I can stop gdm, cat the event file and see data when I move the mouse.

The same device works fine under Ubuntu 8.04 (tested on two computers), and WinXP (likewise). I have tried the mouse on three machines with Ubuntu 8.10, 9.04, and 10.04 (and radically different hardware), and it fails in the same way on all of them -- including one that dual-boots to 8.04 and then works fine. Also, other USB mice work fine on all the 8.10 and later hosts.  Others with the same mouse have reported seeing the same problem on MacOS and on recently released Ubuntu 10.10.

One problem is, it looks like the X server mistakes it for a keyboard. From my /var/log/Xor.0.log:

(II) config/hal: Adding input device HID 0d62:1000
(**) HID 0d62:1000: always reports core events
(**) HID 0d62:1000: Device: "/dev/input/event2"
(II) HID 0d62:1000: Found x and y relative axes
(II) HID 0d62:1000: Found x and y absolute axes
(II) HID 0d62:1000: Found absolute touchpad
(II) HID 0d62:1000: Found 32 mouse buttons
(II) HID 0d62:1000: Found keys
(II) HID 0d62:1000: Configuring as mouse
(II) HID 0d62:1000: Configuring as keyboard
(II) XINPUT: Adding extended input device "HID 0d62:1000" (type: KEYBOARD)

Here is what "xinput list" says about it:

"HID 0d62:1000"	id=5	[XExtensionKeyboard]
	Num_keys is 248
	Min_keycode is 8
	Max_keycode is 255
	Num_buttons is 32
	Num_axes is 2
	Mode is Relative
	Motion_buffer is 256
	Axis 0 :
		Min_value is -1
		Max_value is -1
		Resolution is 1
	Axis 1 :
		Min_value is -1
		Max_value is -1
		Resolution is 1

The reason evdev is confused is that, apparently, ioctl(fd, EVIOCGBIT, EV_KEY, ...) is returning capabilities that don't match the actual device in question. (Come to think of it, EV_ABS coming back with something for a mouse is odd, too.)

I'm not sure if the right solution is to add something to the quirks list in the kernel usbhid stuff, and/or if a workaround in evdev would be useful.

The attached patch makes my Kensington pocket mouse work again, and doesn't break any of the other input devices I have sitting around. (Caveat: I have no touchscreens.)

The basic ideas are:
   1) If a device says it has relative axes, then any claim that it also has absolute axes is a lie.

   2) A device can only be one of touchscreen, mouse or keyboard. If it looks like several, then
       take the first thing from that list it claims to be.

Bear in mind I haven't ever seen the usbhid, hald or evdev code before a couple days ago, so please apply vigorous quality control before pushing this into anything that'll be used by somebody's grandmother!

I'd be happy to provide any additional data that would help, or make any suggested edits to my xorg.conf.
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0:  henke      1535 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
 Card hw:0 'Intel'/'HDA Intel at 0x58540000 irq 16'
   Mixer name	: 'Realtek ALC268'
   Components	: 'HDA:10ec0268,1025015b,00100101'
   Controls      : 8
   Simple ctrls  : 5
CheckboxSubmission: c003c793cae090991827803bc76423b6
CheckboxSystem: c69722ecac764861be52925fa50b4dcc
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
HibernationDevice: RESUME=UUID=4c8ee15c-d4e4-45ba-a036-4cd81df6ccb0
MachineType: Acer AOA150
Package: xserver-xorg-input-evdev 1:2.3.2-5ubuntu1
PackageArchitecture: i386
ProcCmdLine: root=UUID=e87d53ec-2f11-42fe-a591-8a858aea7353 ro quiet splash
 PATH=(custom, user)
 LANG=en_US.utf8ProcVersionSignature: Ubuntu 2.6.32-21.32-generic
Regression: Yes
Reproducible: Yes
 0: phy0: Wireless LAN
 	Soft blocked: no
 	Hard blocked: no
Tags: lucid  regression-release needs-upstream-testing lucid lucid
Uname: Linux 2.6.32-21-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 10/06/2008
dmi.bios.vendor: Acer
dmi.bios.version: v0.3310
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.vendor: Acer
dmi.board.version: Base Board Version
dmi.chassis.type: 1
dmi.chassis.vendor: Chassis Manufacturer
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAcer:bvrv0.3310:bd10/06/2008:svnAcer:pnAOA150:pvr1:rvnAcer:rn:rvrBaseBoardVersion:cvnChassisManufacturer:ct1:cvrChassisVersion:
dmi.product.name: AOA150
dmi.product.version: 1
dmi.sys.vendor: Acer
system: codename:           lucid
 architecture:       i686
 kernel:             2.6.32-21-generic
Comment 1 Bryce Harrington 2011-01-06 13:17:20 UTC
Created attachment 41722 [details]
Comment 2 Bryce Harrington 2011-01-06 13:17:39 UTC
Created attachment 41723 [details]
Comment 3 Bryce Harrington 2011-01-06 13:17:59 UTC
Created attachment 41724 [details]
Comment 4 Bryce Harrington 2011-01-06 13:18:25 UTC
Created attachment 41725 [details]
Comment 5 Bryce Harrington 2011-01-06 13:20:01 UTC
Created attachment 41727 [details] [review]

The user (and several other reporters with the same issue) finds that this patch adequately works around the problem for him.  It's unclear if this is a generally acceptable patch or would cause regressions on other devices so is just presented for your diagnostic edification.
Comment 6 Peter Hutterer 2011-01-06 13:31:43 UTC
Please run evtest against the device file of your input device. The device file is usually /dev/input/eventX, where X is a number. You can get this number by looking at the Handlers for your device in

More information on evtest is here: http://people.freedesktop.org/~whot/evtest/
Comment 7 Douglas Henke 2011-01-07 07:56:24 UTC
Re Comment #6: I'm the original reporter. I'd like to help, but I regret that I no longer have the device in question thus cannot comply with your request for evtest results.

I'm posting this mainly so that if anyone else *does* have this mouse and is reading this bug, they'll please consider running evtest and posting the result, and won't just wait and assume I'll do it.

I'd like to, but can't.
Comment 8 Jeff Norden 2011-02-22 12:08:25 UTC
I've still got a Benq m310 mouse that is affected by this bug.  I'm attaching a file with the output of evtest run on the device, as well as the lines from /var/log/messages that appear when the mouse is plugged in.  Hope this helps!

-Jeff Norden
Comment 9 Jeff Norden 2011-02-22 12:09:59 UTC
Created attachment 43677 [details]
Output from evtest on benq m310 mouse
Comment 10 Peter Hutterer 2011-02-24 19:36:36 UTC
yeah, this mouse is detected as tablet thanks to it reporting a pen, a stylus button and absolute axes amongst other things. The following snippet should fix it but really, the best fix for this is to tell the manufacturers to stop randomly setting fields in the HID descriptors.

This is broken hardware, we can't fix this in the driver, sorry.

Section "InputClass"
   Identifier "oh Benq m310, how I hate thee"
   MatchProduct "HID 0d62:1000"
   Driver "evdev"
   Option "IgnoreAbsoluteAxes" "true"

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.