Erratic input devices behaviour on Ubuntu kernels
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
| linux-source-2.6.22 (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: linux-image-
There is some major problem with the Ubuntu patches to the kernel input drivers.
I run a HP TC1100 Tablet PC in Ubuntu 7.10. I am experiencing erratic and irreproducible input device behaviour. This has to do with the way kernel handles the input devices, not the X.org configuration. Here is a detailed description:
The TC1100 has a detachable keyboard, with which it communicates via USB. There are also some buttons on the tablet, which are probably connected via the i8042 chip (standard PC keyboard interface). I have also hooked up a Logitech LX5 mouse and an USB keyboard that I use when the tablet is docked. The USB keyboard and the LX5 mouse are handled by the evdev X.org driver.
The problem is that with the generic Gutsy kernel, the input devices behave erraticaly. The buttons on the tablet seem to report random keycodes across reboots (sometimes the Q button gives XF86Launch2, sometimes XF86Dos, and sometimes 0x9F). The horizontal scrolling on LX5 is also broken. Sometimes the wheel tilting is reported as mouse buttons 11 and 12, sometimes as XF86Forward and XF86Back. Those seem to change randomly when I i.e. change the core X pointer from the Wacom digitizer to the evdev driver attached to /dev/input/mice. It may also depend on whether the LX5 mouse is connected or not when the system boots.
One irregularity I ahve noticed is that in /proc/bus/
Interestingly, none of the above happens with a kernel built from the linux-source-2.6.22 package. The keycodes are consistent and the horizontal scrolling is always reported as mouse buttons 7 and 6, which can be mapped to the horizontal axis.
While I don't expect this bug to be fixed, I'd like to get some clues as to what might be causing this.

I have traced the issue to the lmpcm_usb module, so this is a duplicate of bug #159824. This module detects the LX5 mouse as MX1000 (they apparently have the same product ID) and does something brain-dead after that. The keyboard-related problems seem to be X configuration issues.