ALPS DualPoint Touchpad flaky performance

This seems like it may be the same bug as described in more detail here:

http://lkml.org/lkml/2008/11/1/2

I can reproduce at will following the actions described there.

I have a Dell E6400 and am seeing the same problems with the reset messages. It also sounds to me like the same issue as mentioned by slowrobot.

I'm running ubuntu 8.10. Myself and a coworker both have this same behavior with new Dell E6400 Latitude laptops.
For me it is pretty reliably triggered by typing anywhere near the touchpoint stick (the "n" key is particularly dangerous; holding it down is almost guaranteed to cause the pointer to "freak out". This makes it really hard to use the laptop at all :-(

After reading some of the comments on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/34501 I thought that the kernel version might be relevant. I tried both 2.6.27.9 and 2.6.27.11 - no difference, I have the same problem with either kernel.

I looked at the LKML post mentioned by slowrobot above; the trigger described in that thread does not seem to be the trigger for the bug here. All I have to do is type on keys *near* the touchstick, such as "n". But the "lost sync" messages in that thread look the same here.

Don't know if this helps, but I've noticed that xinput reports different devices before and after an episode of pointer-gone-mad behavior.
WHen I first start X, xinput -list gives me this output:

$ xinput -list
"Virtual core keyboard" id=0 [XKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
"Virtual core pointer" id=1 [XPointer]
 Num_buttons is 32
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
  Min_value is 0
  Max_value is -1
  Resolution is 0
 Axis 1 :
  Min_value is 0
  Max_value is -1
  Resolution is 0
"Macintosh mouse button emulation" id=2 [XExtensionPointer]
 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
"AlpsPS/2 ALPS DualPoint TouchPad" id=3 [XExtensionPointer]
 Num_buttons is 12
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
  Min_value is 0
  Max_value is -1
  Resolution is 1
 Axis 1 :
  Min_value is 0
  Max_value is -1
  Resolution is 1
"DualPoint Stick" id=4 [XExtensionPointer]
 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
"AT Translated Set 2 keyboard" id=5 [XExtensionKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
"Video Bus" id=6 [XExtensionKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255

Then, when the pointer starts acting crazy, I see this in /var/log/messages:

Dec 23 02:00:32 slinktopp kernel: [ 197.223741] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
Dec 23 02:00:32 slinktopp kernel: [ 197.224741] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 23 02:00:32 slinktopp kernel: [ 197.231699] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Dec 23 02:00:32 slinktopp kernel: [ 197.249580] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
Dec 23 02:00:32 slinktopp kernel: [ 197.262458] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
Dec 23 02:00:32 slinktopp kernel: [ 197.267989] psmouse.c: D...

Is this bug report a duplicat of this one -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330885 ?

No. Recognizing the touchpad at all is a separate issue from handling
its weird data stream correctly.

I don't know why the opener opened a new bug rather than reopening
270643.

On Sat, Feb 21, 2009 at 10:05:45PM -0000, emeriste wrote:
> Is this bug report a duplicat of this one --
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330885 ?
>

--

Paul Winkler
http://www.slinkp.com

I have the exact same problem on my Precision M4400 DualPoint. The problem is reliably repeated by moving the trackpoint stick and the touchpad at the same time. Any news on this?

Relevant entries in /proc/bus/input/devices:
I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="DualPoint Stick"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input19
U: Uniq=
H: Handlers=mouse1 event9
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0002 Product=0008 Version=6222
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input20
U: Uniq=
H: Handlers=mouse2 event10
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003

Sample dmesg output:
[ 1064.295828] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input17
[ 1064.344275] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input18
[ 1069.649639] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
[ 1069.650596] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 1069.658692] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1070.461368] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
[ 1070.462320] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 1070.469326] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1070.780301] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[ 1070.789547] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1070.806772] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[ 1070.815776] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1070.831797] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[ 1070.838772] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1070.893729] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[ 1070.900535] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1071.032366] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[ 1071.039123] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1073.387561] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[ 1073.394223] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1193.632760] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
[ 1193.633663] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 1193.641530] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
[ 1193.658689] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
[ 1193.659601] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 1193.666436] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 1193.667483] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sy...

I'm running 64 bit Intrepid on Dell Latitude E4300. For me the behaviour of touchpad/point stick improves significantly with:

http://lkml.org/lkml/2008/12/8/182

but I have got one "sync lost" report after applying the patch. Also seems that occasionally the touchpad does not get into the device tree during boot.

I found a reproducible way to cause sync errors even with the above patch applied. This may sound a bit weird, but whenever I use the RF switch at the side of the E4300 and at the same time e.g. keep tapping the touchpad, I get something like:

psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.

And the ALPS touchpad dissappears. Switching the RF on seems to register HID devices and that apparently interferes with the touchpad/pointing stick driver. For me this has the nasty side effect that the touchpad gets enabled even though I'm trying very hard to disable it as I keep touching it accidentally while I'm typing.

Hmm... probably the issue is not the RF switch. I get similar errors:

psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.

when I disable wireless networking from from NetworkManager. Interrupt masking/latency issue?

ALPS driver flakey or "crashing and falling back to standart PS2 mouse" on Dell E6400/E6500 is still an issue in Jaunty (Kubuntu Alpha 6)

I found an alleged fix here (.diff attachement of 4th reply)

http://www.gossamer-threads.com/lists/linux/kernel/991762

however it's for the 2.26.27 kernel, jaunty currently is 2.6.28-11.

Don't know where to go from here ... :-(

Above patch seems to be included in kernel 2.6.29 rc6

http://bugzilla.kernel.org/show_bug.cgi?id=12577

Anyway of getting it included in the current ubuntu kernel line?

I wrote a step by step how to make a patched psmouse.ko module from the descriptions of slinkp and kadawer in a forum thread.

http://ubuntuforums.org/showthread.php?p=6964479#post6964479

With the patch applied on jaunty 64 Kubuntu I am really happy. I no longer have erratic jumping of the curser, no more sync messages in the xorg logfile and the touchpad doesn't revert back to a generic ps2 mouse without scrolling and acceleration.

Hi slowrobot,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/karmic .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 296610

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Architecture: i386
Dependencies:

DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia wl
Package: linux None [modified: /var/lib/dpkg/info/linux.list]
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-15-server i686
UserGroups: adm admin cdrom dialout dip lpadmin plugdev sambashare sudo

I have been experiencing what sounds like the same problem running Ubuntu 9.04 Jaunty on a Dell Latitude 6500. apport-collect data added above. The biggest problem I have seems to be when I click-hold the left mouse button, touch-drag-release on the touchpad, then release the left mouse button. This is a common action for selecting a block of text.

This often works, but very regularly, it results in jumping the mouse (often downwards) and pasting a chuck of text as if I had clicked the middle mouse button.

Possibly relevant note: The upper mouse buttons on the Latitude 6500 are adjacent to the touch pad with no barrier in between. It is easy to accidentally touch the upper part of the touchpad with the same finger which is clicking a mouse button, especially using the thumb as I do in the above sequence. This may be involved in generating the bad behavior, though I cannot reproduce it reliably.

I am using gsynaptics as described above. I am not using vmware. I don't always have to reload the psmouse module, though sometimes I do. Let me know if you need any additional information or tests.

This problem is extremely annoying as it results in incorrect mouse movements and clicks, generally pasting something I did not intend to paste in a location where I did not intend to have focus.

I can confirm that the problem persists in stock karmic as of 2009-09-11 with an E6400.

I also have an E6500 and see the same flaky behavior with my touchpad.

rhau@rhau-laptop:~$ xinput -list
"Virtual core pointer" id=0 [XPointer]
 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 0
 Axis 1 :
  Min_value is -1
  Max_value is -1
  Resolution is 0
"Virtual core keyboard" id=1 [XKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
"AT Translated Set 2 keyboard" id=2 [XExtensionKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
"HID 413c:8157" id=3 [XExtensionKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
"Video Bus" id=4 [XExtensionKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
"Macintosh mouse button emulation" id=5 [XExtensionPointer]
 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
"PS/2 ALPS DualPoint TouchPad" id=6 [XExtensionPointer]
 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

DMESG

[ 542.068494] psmouse.c: issuing reconnect request
[ 542.599497] synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume
[ 543.536733] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input11
[ 543.582886] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input12
[ 703.976093] CE: hpet increasing min_delta_ns to 15000 nsec
[ 765.972244] CE: hpet increasing min_delta_ns to 22500 nsec
[ 913.979397] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
[ 913.980420] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 913.985205] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 913.986402] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 913.987585] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 913.987591] psmouse.c: issuing reconnect request
[ 914.498336] synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume
[ 915.774945] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[ 916.585221] input: PS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input13

At this point I am confident that the behavior I am seeing is not correlated with multiple touches on the touchpad as I thought it might be in "Possibly relevant note" above.

I am also confident that it is extremely annoying to not have a reliable interaction with my computer. This one bug makes my use of Ubuntu extremely frustrating since I live on this laptop now.

I'm not sure how widespread this problem is, but I'm starting the importance at Medium since it has such a big impact. (I just had to re-edit this comment since the bug copied and pasted in part of the text.)

This bug is indeed quite frustrating. I can consistently reproduce it on my Latitude E6400 by using the pointing stick and touch pad simultaneously. One might wonder why anyone would want to use both at the same time, but when you use the pointing stick exclusively as I do, it is simply unavoidable because the palm of my hand will occasionally brush up against the touch pad. It's unfortunate that disabling the touch pad has no effect, even though the touch pad does not respond to input on its own when disabled. Something funky must be going on at the driver level.

I should mention that the patch that was posted by Matthew Chapman (http://www.gossamer-threads.com/lists/linux/kernel/991762) seems to remedy the problem although I haven't really had a chance to test it extensively. It's also inconvenient that it needs to be applied manually every time a new kernel is released.

I wonder if it's possible to disable the touch pad completely at the driver level for those of us how don't use it, and vice versa for the pointing stick. It's obviously not the solution to the problem but it might be useful as a temporary fix. I tried looking at the alps driver source, and although I have some experience as a programmer, I find it quite cryptic. If anyone can explain the changes that need to be made to accomplish this then I would be grateful.

Nothing new to add regarding the bug, just something I found easing the pain a little for me.

'm on Arch in the meanwhile but I think the issue is the same. At some point the psmouse driver crashes and loads a generic one. If this happens the Trackpoint scroll doesn't work anymore.

I usually fix the issue with the following commands to reload the psmouse driver.

#(after this you cannot use your mouse anymory temporarily)
sudo modprobe -rvf psmouse
#and reload the driver:
sudo modprobe -vf psmouse

If there was a way to disable the trackpoint, it might help. I also notice
that if you click both left mouse buttons that it locks.

Robert Hau
West Highland Support Services
Desk: (866)778-3484 x157
Cell: (917)657-0686
Email: <email address hidden>

----- Original Message -----
From: <email address hidden> <email address hidden>
To: <email address hidden> <email address hidden>
Sent: Tue Oct 06 12:19:30 2009
Subject: [Bug 296610] Re: ALPS DualPoint Touchpad flaky performance

Nothing new to add regarding the bug, just something I found easing the
pain a little for me.

'm on Arch in the meanwhile but I think the issue is the same. At some
point the psmouse driver crashes and loads a generic one. If this
happens the Trackpoint scroll doesn't work anymore.

I usually fix the issue with the following commands to reload the
psmouse driver.

#(after this you cannot use your mouse anymory temporarily)
sudo modprobe -rvf psmouse
#and reload the driver:
sudo modprobe -vf psmouse

--
ALPS DualPoint Touchpad flaky performance
https://bugs.launchpad.net/bugs/296610
You received this bug notification because you are a direct subscriber
of the bug.

Status in “linux” package in Ubuntu: Confirmed

Bug description:
On a Dell Latitude E6500. Ubuntu 8.10 32bit. Out of the box, the touchpad
was almost unusably slow, taking 4 or 5 trips across the touchpad to
traverse from one edge of the screen to the other. To remedy this, I create
a file:

/etc/hal/fdi/policy/shmconfig.fdi

With the following contents:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
  <match key="input.x11_driver" string="synaptics">
   <merge key="input.x11_options.SHMConfig" type="string">true</merge>
  </match>
 </device>
</deviceinfo>

Then, I installed gsynaptics, and used System->Preferences->Touchpad to fix
most of the usability issues.

The problem now is that occasionally, the mouse will 'flip out', make what
seem to be some very fast unexpected movements, clicks, etc. When that is
done, my settings as applied by gsynaptics will no longer be in effect - it
will be back to the out-of-the-box slowness. Going back to
System->Preferences->Touchpad will now result in a error about SHMConfig not
being enabled.

To get around this, I can do 'modprobe -r psmouse; modprobe psmouse'. After
this, gsynaptics will work again, and I can go back into it and reapply my
settings. This is all a fairly big PITA, obviously. This behavior
(touchpad going nuts, needing to restart psmouse) doesn't always happen, but
seems to happen most when something intensive or tricky is going on (e.g.,
it happens especially often when VMWare is running (note: Intrepid is the
host - the guest is Vista SP1). But it happens sometimes when not running
VMWare, as well. At the time when it flips out, lots of the following can
be seen in /var/log/messages:

Nov 7 22:23:02 peapod kernel: [46966.773325] psmouse.c: DualPoint TouchPad
at isa0060/serio1/input0 lost sync at byte 1
Nov 7 22:23:02 peapod kernel: [46966.781168] psmouse.c: DualPoint TouchPad
at isa0060/serio1/input0 - driver resynched.
Nov 7 22:23:03 peapod kernel: [46966.7...

The Dell Precision M4400 has the same bug. I'm intrigued by http://ubuntuforums.org/showpost.php?p=7808011#7808011 which indicates that replacing the hardware fixed the problem. Multiple hardware revisions going around?

The patch that's floating around is half of a workaround--you can still get into situations where the mouse buttons will seemingly stick, but at least the mouse doesn't jump or randomly send clicks anymore. I further modified it to try to deal with this, but it's a horrible kludge (and I haven't tested it against newer kernels.)

You may consider trying my Alps driver in
   http://www.medini.org/software/alps/alps.html
-- yotam

I have the same problem on 2 E4300, and 1 M4400. I see the problem with both 9.04 and 9.10.

On 9.04 I have reduced the problem by disabling the touchpad, but as this option has been removed in 9.10 I have instead forced the PS2 protocol to Internet Explorer mode by creating the following file:

/etc/modprobe.d/psmouse.modprobe

which contains:

options psmouse proto=exps

I dont have scrolling on the touchpad, but for me thats fine

Ooops meant IntelliMouse Explorer mode

I definitely can confirm this problem exists in 9.10

I found the fix for this on Karmic

If you have the latest updates

just added

Section "Module"
       Load "synaptics"
EndSection

Just an update. The problem seems to be less noticeable now, but it does still appear to have a problem in the logs

Nov 3 12:30:35 rhau-laptop kernel: [11320.890902] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.914873] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Nov 3 12:30:35 rhau-laptop kernel: [11320.916054] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.917250] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.929972] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.939733] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Nov 3 12:30:35 rhau-laptop kernel: [11320.940890] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.942050] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.953154] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.961480] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Nov 3 12:30:35 rhau-laptop kernel: [11320.962635] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.963861] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 12:30:35 rhau-laptop kernel: [11320.980872] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Nov 3 16:34:34 rhau-laptop kernel: [25959.968639] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 16:34:34 rhau-laptop kernel: [25959.980478] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Nov 3 16:34:34 rhau-laptop kernel: [25959.981625] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 16:34:34 rhau-laptop kernel: [25959.982836] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 16:34:34 rhau-laptop kernel: [25959.990967] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 16:34:34 rhau-laptop kernel: [25959.992140] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 16:34:34 rhau-laptop kernel: [25959.993357] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 3 16:34:34 rhau-laptop kernel: [25959.993364] psmouse.c: issuing reconnect request

I'm not sure if that is a real fix. Even without the explicit module
load, X still loads the synaptics driver at least on the E6400.

(withOUT the mentioned stanza in the config file, I still get this):

peter@mildred:/var/log$ grep -i synaptics Xorg.0.log
(II) LoadModule: "synaptics"
(II) Loading /usr/lib/xorg/modules/input//synaptics_drv.so
(II) Module synaptics: vendor="X.Org Foundation"
(II) Synaptics touchpad driver version 1.1.2

On Tue, Nov 3, 2009 at 10:24 PM, Robert Hau <email address hidden> wrote:
> I found the fix for this on Karmic
>
> If you have the latest updates
>
> just added
>
> Section "Module"
>       Load "synaptics"
> EndSection
>
> --
> ALPS DualPoint Touchpad flaky performance
> https://bugs.launchpad.net/bugs/296610
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
/peter

This NOT a fix. The problem already lies at the PS/2 driver level, nothing to do with X11 which is two or three layers above that.

I confirm having the same bug since Linux 8 and 9.04

I can confirm the same bug on my new E6400 with kubuntu 9.10.

I'm attaching a patch that fixes the "lost sync" problem. The patch has also been sent to the upstream maintainer (of the Linux input subsystem).

Is there a chance to get this fix into a karmic update kernel?

I've been using this patch since I got the first version from Matt.

With middle mouse button configured for scrolling sometimes the cursor starts drifting into a direction. I guess this is triggered by accidentally touching the touch pad while using the track stick but I'm not completely sure how to trigger it.
It happens quite often tough.

So I have to confirm that the patch doesn't solve all problems.

@AlexHofbauer
If http://en.wikipedia.org/wiki/Pointing_stick#Problems is right, then this isn't a driver problem but a hardware problem.

@Kai Jauch -
The problems I'm seeing with my pointing stick & mouse buttons exhibit the same 'lost sync' as noted for the trackpad - it's not the drift problem noted by the wikipedia page.

Is there a chance of that patch getting into a development ppa for those of us w/o the time to recompile a kernel?

Sorry, I had missed Alex's note about drifting, pardon my previous comment.

Pardon the rookie question, but does that patch apply to a module component or the kernel? I.E., is it possible to just patch & compile a module to test the fix?

The patch changes code in the psmouse.ko kernel module, which is part of the stock kernel. I have no idea if there's a sane way to compile just a single module. You can, however, compile a patched kernel, 'rmmod' psmouse, and 'insmod' the patched module without rebooting.

.etc.asound.conf:

AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dave 3829 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf6fdc000 irq 21'
   Mixer name : 'IDT 92HD71B7X'
   Components : 'HDA:111d76b2,10280250,00100302'
   Controls : 28
   Simple ctrls : 18
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=85c40070-ba32-4322-99d8-053fa1491ad8
MachineType: Dell Inc. Precision M4400
NonfreeKernelModules: nvidia
Package: linux (not installed)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-15-generic-pae root=UUID=e7838b52-6756-46f7-9477-c17be3fd491c i8042.reset i8042.nomux elevator=noop ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic-pae
RelatedPackageVersions:
 linux-backports-modules-2.6.31-15-generic-pae N/A
 linux-firmware 1.25
Uname: Linux 2.6.31-15-generic-pae i686
UserGroups:

dmi.bios.date: 08/28/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A16
dmi.board.name: 0R906R
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA16:bd08/28/2009:svnDellInc.:pnPrecisionM4400:pvr:rvnDellInc.:rn0R906R:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Precision M4400
dmi.sys.vendor: Dell Inc.

@Sebastian: I would only want to disable the touchpad (movement and tapping). Leaving the buttons is OK. Actually even better than complete disable.

I've tried cardboard/plastic on top of the pad, I even opened up my laptop in a desperate attempt to find a wire/trace to cut but no - the touchpad seems to want to be alive :-/

I'm totally on your side -- I'll talk to Dmitry to see if he would include such a thing in the kernel, if not, I'll post a patch here once we have a final version.

Why do you want to disable the touchpad? Is it getting in your way of typing? Or is it due to the current problems that Sebastian's patch tries to resolve but it's not in Ubuntu's kernel yet? For the former, I recommend looking into "syndaemon" program. For the latter adding "option psmouse proto=exps" will force the touchpad into PS/2 compatibility mode, which is better than constantly losing sync (that assumes that psmouse is a module; for built-in ass psmouse.proto=exps to the kernel command line).

@Dmitry: Sort of both and more. The touchpad is getting in the way of typing but also in the way of using the trackpoint. With Sebastian's patch and when the touchpad is disabled with e.g. gsynaptics, things are almost OK. But the touchpad gets re-enabled seemingly at random. And even when it stays disabled, weird pointer activity can be triggered e.g. by moving two fingers into opposing directions on the touchpad. Similar pointer-jumping-things happen accidentally sometimes when I'm using the trackpoint. With Sebastian's patch I do not see "sync lost" errors. Is there a way to disable the touchpad with proto=exps?

@Antti: I have not tested this but Xorg should ignore devices for which HAL sets property xorg.ignore=true. See https://wiki.ubuntu.com/X/InputHotplug

So something like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
   <match key="info.product" string="AlpsPS/2 ALPS DualPoint TouchPad">
     <merge key="xorg.ignore" type="bool">true</merge>
   </match>
 </device>
</deviceinfo>

should do it? The setting is shown by lshal but it does not seem to cause persistent disable of the touchpad. For some reason the "Synaptics Off" property reverts back to zero i.e. the touchpad gets re-enabled. If I do:

xinput set-int-prop "AlpsPS/2 ALPS DualPoint TouchPad" "Synaptics Off" 8 1

and then repeatedly:

xinput list-props "AlpsPS/2 ALPS DualPoint TouchPad" |grep "Synaptics Off"

after a while the property is back to zero. However:

xinput set-int-prop "AlpsPS/2 ALPS DualPoint TouchPad" "Device Enabled" 8 0

does disable the touchpad and the setting stays. Is there a HAL property that would map to the "Device Enabled" xinput property?

The following in /etc/hal/fdi/preprobe seems to make the touchpad xinput device disappear completely:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
    <device>
        <match key="info.product" string="AlpsPS/2 ALPS DualPoint TouchPad">
            <merge key="info.ignore" type="bool">true</merge>
        </match>
    </device>
</deviceinfo>

I can still make the pointer jump around by using two fingers on the touchpad but accidental input activity does not seem very frequent.

OK, the patch is in mainline (2.6.33-rc1 as soon as it is released) now it is for Ubuntu kernel guys to backport it to whatever kernel they are using.

OK, the patch is in mainline (2.6.33-rc1 as soon as it is released) so now it's up to Ubuntu kernel guys to backport it to whatever kernel they are using.

Hi @all :-(
On the moment I'm on the lucid dev branch & a DELL 4300.
Problems described @#154 still occur.
Testing which will work in Lucid... Will report back.

GoofY,

the fix is not in Ubuntu yet.

Greets,
Sebastian

From: Sebastian Kapfer <email address hidden>
Date: Tue, 15 Dec 2009 08:39:50 -0800
Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)

commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream

Properly handle version of the protocol where standard PS/2 packets
from trackpoint are stuffed into middle (byte 3-6) of the standard
ALPS packets when both the touchpad and trackpoint are used together.

The patch is based on work done by Matthew Chapman and additional
research done by David Kubicek and Erik Osterholm:

 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610

Many thanks to David Kubicek for his efforts in researching fine points
of this new version of the protocol, especially interaction between pad
and stick in these models.

Signed-off-by: Sebastian Kapfer <email address hidden>
Signed-off-by: Dmitry Torokhov <email address hidden>
---

Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
Dell E4300.

 drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
 drivers/input/mouse/alps.h | 1 +
 2 files changed, 228 insertions(+), 25 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 5547e24..b172bef 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -5,6 +5,7 @@
  * Copyright (c) 2003-2005 Peter Osterlund <email address hidden>
  * Copyright (c) 2004 Dmitry Torokhov <email address hidden>
  * Copyright (c) 2005 Vojtech Pavlik <email address hidden>
+ * Copyright (c) 2009 Sebastian Kapfer <email address hidden>
  *
  * ALPS detection, tap switching and status querying info is taken from
  * tpconfig utility (by C. Scott Ananian and Bruce Kall).
@@ -35,6 +36,8 @@
 #define ALPS_OLDPROTO 0x10
 #define ALPS_PASS 0x20
 #define ALPS_FW_BK_2 0x40
+#define ALPS_PS2_INTERLEAVED 0x80 /* 3-byte PS/2 packet interleaved with
+ 6-byte ALPS packet */

 static const struct alps_model_info alps_model_data[] = {
  { { 0x32, 0x02, 0x14 }, 0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT }, /* Toshiba Salellite Pro M10 */
@@ -55,7 +58,9 @@ static const struct alps_model_info alps_model_data[] = {
  { { 0x20, 0x02, 0x0e }, 0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT }, /* XXX */
  { { 0x22, 0x02, 0x0a }, 0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT },
  { { 0x22, 0x02, 0x14 }, 0xff, 0xff, ALPS_PASS | ALPS_DUALPOINT }, /* Dell Latitude D600 */
- { { 0x62, 0x02, 0x14 }, 0xcf, 0xcf, ALPS_PASS | ALPS_DUALPOINT }, /* Dell Latitude E6500 */
+ /* Dell Latitude E5500, E6400, E6500, Precision M4400 */
+ { { 0x62, 0x02, 0x14 }, 0xcf, 0xcf,
+ ALPS_PASS | ALPS_DUALPOINT | ALPS_PS2_INTERLEAVED },
  { { 0x73, 0x02, 0x50 }, 0xcf, 0xcf, ALPS_FW_BK_1 }, /* Dell Vostro 1400 */
 };

@@ -66,20 +71,88 @@ static const struct alps_model_info alps_model_data[] = {
  */

 /*
- * ALPS abolute Mode - new format
+ * PS/2 packet format
+ *
+ * byte 0: 0 0 YSGN XSGN 1 M R L
+ * byte 1: X7 X6 X5 X4 X3 X2 X1 X0
+ * byte 2: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
+ *
+ * Note that the device never signals overflow condition.
+ *
+ * ALPS absolute Mode - new format
  *
  * byte 0: 1 ? ? ? 1 ? ? ?
  * byte 1: 0 x6 ...

I am a bit uncertain about this patch in stable from the view of regression
avoidance. Looking over the patch its hard to tell for certain whether the path
of execution is the same as before for the non-interleaved protocol.
Dmitry, how do you feel about it? Or maybe there has even be positive testing
with non-interleaved hardware with that patch.

-Stefan

Andy Isaacson wrote:
> From: Sebastian Kapfer <email address hidden>
> Date: Tue, 15 Dec 2009 08:39:50 -0800
> Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
>
> commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
>
> Properly handle version of the protocol where standard PS/2 packets
> from trackpoint are stuffed into middle (byte 3-6) of the standard
> ALPS packets when both the touchpad and trackpoint are used together.
>
> The patch is based on work done by Matthew Chapman and additional
> research done by David Kubicek and Erik Osterholm:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
>
> Many thanks to David Kubicek for his efforts in researching fine points
> of this new version of the protocol, especially interaction between pad
> and stick in these models.
>
> Signed-off-by: Sebastian Kapfer <email address hidden>
> Signed-off-by: Dmitry Torokhov <email address hidden>
> ---
>
> Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> Dell E4300.
>
> drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> drivers/input/mouse/alps.h | 1 +
> 2 files changed, 228 insertions(+), 25 deletions(-)
>

In principle, the patch was engineered in a way that nothing changes for old touchpads. Of course, you never know... I haven't heard of any regressions yet.

- Sebastian

On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
> I am a bit uncertain about this patch in stable from the view of regression
> avoidance. Looking over the patch its hard to tell for certain whether the path
> of execution is the same as before for the non-interleaved protocol.
> Dmitry, how do you feel about it? Or maybe there has even be positive testing
> with non-interleaved hardware with that patch.

Umm, it is a bit large for -stable to my taste. However without the
patch the affected laptops are pretty much unusable so I think we better
get it in. The non-interleaved devices should continue to work fine, at
least I don't see any adverse effects on my d630 (caveat - I am not
using _this_ version of the patch but rather what is currently in Linus's
tree).

Thanks.

>
> -Stefan
>
> Andy Isaacson wrote:
> > From: Sebastian Kapfer <email address hidden>
> > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> >
> > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> >
> > Properly handle version of the protocol where standard PS/2 packets
> > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > ALPS packets when both the touchpad and trackpoint are used together.
> >
> > The patch is based on work done by Matthew Chapman and additional
> > research done by David Kubicek and Erik Osterholm:
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> >
> > Many thanks to David Kubicek for his efforts in researching fine points
> > of this new version of the protocol, especially interaction between pad
> > and stick in these models.
> >
> > Signed-off-by: Sebastian Kapfer <email address hidden>
> > Signed-off-by: Dmitry Torokhov <email address hidden>
> > ---
> >
> > Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> > Dell E4300.
> >
> > drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> > drivers/input/mouse/alps.h | 1 +
> > 2 files changed, 228 insertions(+), 25 deletions(-)
> >
>

--
Dmitry

On Tue, Jan 19, 2010 at 12:36:14AM -0800, Dmitry Torokhov wrote:
> On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
> > I am a bit uncertain about this patch in stable from the view of
> > regression avoidance. Looking over the patch its hard to tell for
> > certain whether the path of execution is the same as before for the
> > non-interleaved protocol. Dmitry, how do you feel about it? Or
> > maybe there has even be positive testing with non-interleaved
> > hardware with that patch.
>
> Umm, it is a bit large for -stable to my taste. However without the
> patch the affected laptops are pretty much unusable so I think we better
> get it in. The non-interleaved devices should continue to work fine, at
> least I don't see any adverse effects on my d630 (caveat - I am not
> using _this_ version of the patch but rather what is currently in Linus's
> tree).

I agree, the interleaved protocol support is awfully high-impact for
-stable. However as you've observed, the affected machines are really
unusable without some fix.

Personally I'm fine maintaining the backport locally, but it'd be nice
to fix this for Karmic as well.

I'll do some testing on non-Dell hardware tomorrow.

-andy

On Tue, 2010-01-19 at 00:36 -0800, Dmitry Torokhov wrote:
> On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
> > I am a bit uncertain about this patch in stable from the view of regression
> > avoidance. Looking over the patch its hard to tell for certain whether the path
> > of execution is the same as before for the non-interleaved protocol.
> > Dmitry, how do you feel about it? Or maybe there has even be positive testing
> > with non-interleaved hardware with that patch.
>
> Umm, it is a bit large for -stable to my taste. However without the
> patch the affected laptops are pretty much unusable so I think we better
> get it in. The non-interleaved devices should continue to work fine, at
> least I don't see any adverse effects on my d630 (caveat - I am not
> using _this_ version of the patch but rather what is currently in Linus's
> tree).
[...]

For what it's worth, we already added this to Debian kernel packages and
I don't believe we've seen any bug reports related to it.

Ben.

--
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

I have been manually compiling the patch into my ubuntu karmic, and its been working great. I've been running it for the last few kernels.

RH

On Tue, Jan 19, 2010 at 02:44:14PM -0000, Ben Hutchings wrote:

> For what it's worth, we already added this to Debian kernel packages and
> I don't believe we've seen any bug reports related to it.

I see this also applies to Lucid. If this isn't going via -stable
anyhow (which it may well be) I think we could consider adding it to
Lucid and testing it there to get some confidence for Karmic.

-apw

I've been living with this horrible problem for a long time now. Is it possible to apply the patch on Jaunty? I'd be willing to test if somebody could walk me through the steps necessary.

Hardware: Dell Latitude E6500

$ uname -srmv
Linux 2.6.28-17-server #58-Ubuntu SMP Tue Dec 1 19:58:28 UTC 2009 i686

$ lsb_release -dc
Description: Ubuntu 9.04
Codename: jaunty

Download the patch file

mkdir ~/kernel
cd ~/kernel
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git (This take a while)
cd ubuntu-jaunty/
cp ~/alps-dave-2.6.31.patch .
patch -p1 < alps-dave-2.6.31.patch

make oldconfig (Sit back and wait)
make prepare (Wait some more)
make (Wait some more)

once that is done
cp /lib/modules/2.?????-generic/kernel/drivers/input/mouse/psmouse.ko /lib/modules/2.?????-generic/kernel/drivers/input/mouse/psmouse.ko.orig
cp /home/rhau/kernel/ubuntu-jaunty/drivers/input/mouse/psmouse.ko /lib/modules/2.?????-generic/kernel/drivers/input/mouse/psmouse.ko

Robert Hau

Thank you, Robert! Your instructions were very clear and helpful.

Some obvious touchpad bugs are clearly fixed on my E6500. I'll keep an eye out for the other odd ones which were more sporadic, but so far, so good.

For others attempting this on Jaunty, I'll point out:

- The referenced alps-dave-2.6.31.patch is available in the "Patches" section towards the top right of the launchpad bug page.

- The patch had a couple rejects with the Jaunty kernel. In the first one, it was pretty easy to see where to change the file drivers/input/mouse/alps.c so that this line:
       { { 0x62, 0x02, 0x14 }, 0xcf, 0xcf, ALPS_PASS | ALPS_DUALPOINT }, /* Dell Latitude E6500 */
  instead read like:
       { { 0x62, 0x02, 0x14 }, 0xcf, 0xcf, DELL_STYLE_DUALPOINT },
  The second patch reject was just comments.

- The final copying can be done a bit more easily using the commands:

  sudo cp /lib/modules/$(uname -r)/kernel/drivers/input/mouse/psmouse.ko \
   /lib/modules/$(uname -r)/kernel/drivers/input/mouse/psmouse.ko.orig

  sudo cp ~/kernel/ubuntu-jaunty/drivers/input/mouse/psmouse.ko \
   /lib/modules/$(uname -r)/kernel/drivers/input/mouse/psmouse.ko

- Install the new kernel module using:

  sudo rmmod psmouse
  sudo modprobe psmouse

If there's any way this can get into Jaunty it will make a lot of people happy, but I'll try to spread the word to the folks I know who have been hurting.

Ben Hutchings wrote:
> On Tue, 2010-01-19 at 00:36 -0800, Dmitry Torokhov wrote:
>> On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
>>> I am a bit uncertain about this patch in stable from the view of regression
>>> avoidance. Looking over the patch its hard to tell for certain whether the path
>>> of execution is the same as before for the non-interleaved protocol.
>>> Dmitry, how do you feel about it? Or maybe there has even be positive testing
>>> with non-interleaved hardware with that patch.
>> Umm, it is a bit large for -stable to my taste. However without the
>> patch the affected laptops are pretty much unusable so I think we better
>> get it in. The non-interleaved devices should continue to work fine, at
>> least I don't see any adverse effects on my d630 (caveat - I am not
>> using _this_ version of the patch but rather what is currently in Linus's
>> tree).
> [...]
>
> For what it's worth, we already added this to Debian kernel packages and
> I don't believe we've seen any bug reports related to it.
>
> Ben.
>
That sounds good. Thanks for that feedback Ben. For the Ubuntu part, I dicussed
this with Andy and we agreed to take it into Lucid first and then roll it back
to Karmic after a little delay.

-Stefan

On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> From: Sebastian Kapfer <email address hidden>
> Date: Tue, 15 Dec 2009 08:39:50 -0800
> Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
>
> commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
>
> Properly handle version of the protocol where standard PS/2 packets
> from trackpoint are stuffed into middle (byte 3-6) of the standard
> ALPS packets when both the touchpad and trackpoint are used together.
>
> The patch is based on work done by Matthew Chapman and additional
> research done by David Kubicek and Erik Osterholm:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
>
> Many thanks to David Kubicek for his efforts in researching fine points
> of this new version of the protocol, especially interaction between pad
> and stick in these models.
>
> Signed-off-by: Sebastian Kapfer <email address hidden>
> Signed-off-by: Dmitry Torokhov <email address hidden>
> ---
>
> Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> Dell E4300.

What -stable tree is this for? .31 is no longer being maintained. Is
this the proper patch for .32? .27?

>
> drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> drivers/input/mouse/alps.h | 1 +
> 2 files changed, 228 insertions(+), 25 deletions(-)

Ick, that's a big patch, and kind of violates the -stable rules, right?
It's a "add new functionality" type thing that you are doing here from
what I can tell. This doesn't fix a regression, does it?

confused,

greg k-h

On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > From: Sebastian Kapfer <email address hidden>
> > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> >
> > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> >
> > Properly handle version of the protocol where standard PS/2 packets
> > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > ALPS packets when both the touchpad and trackpoint are used together.
> >
> > The patch is based on work done by Matthew Chapman and additional
> > research done by David Kubicek and Erik Osterholm:
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> >
> > Many thanks to David Kubicek for his efforts in researching fine points
> > of this new version of the protocol, especially interaction between pad
> > and stick in these models.
> >
> > Signed-off-by: Sebastian Kapfer <email address hidden>
> > Signed-off-by: Dmitry Torokhov <email address hidden>
> > ---
> >
> > Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> > Dell E4300.
>
> What -stable tree is this for? .31 is no longer being maintained. Is
> this the proper patch for .32? .27?
>
> >
> > drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> > drivers/input/mouse/alps.h | 1 +
> > 2 files changed, 228 insertions(+), 25 deletions(-)
>
> Ick, that's a big patch, and kind of violates the -stable rules, right?
> It's a "add new functionality" type thing that you are doing here from
> what I can tell. This doesn't fix a regression, does it?
>

Well, yes and no. As shipped .32 (and earlier) has the signature for
ALPS that is installed in those newer Latitudes so we try to activate
ALPS protocol for their touchpads. Unfortunately without the patch the
protocol desyncs all the time, making trackpoint/touchpad unuseable.

IOW if you are an owner of said Latitude you want this patch _very
much_. But yes, the patch is sizeable.

--
Dmitry

On Wed, Jan 20, 2010 at 11:54:38PM -0800, Dmitry Torokhov wrote:
> On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> > On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > > From: Sebastian Kapfer <email address hidden>
> > > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > >
> > > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > >
> > > Properly handle version of the protocol where standard PS/2 packets
> > > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > > ALPS packets when both the touchpad and trackpoint are used together.
> > >
> > > The patch is based on work done by Matthew Chapman and additional
> > > research done by David Kubicek and Erik Osterholm:
> > >
> > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > >
> > > Many thanks to David Kubicek for his efforts in researching fine points
> > > of this new version of the protocol, especially interaction between pad
> > > and stick in these models.
> > >
> > > Signed-off-by: Sebastian Kapfer <email address hidden>
> > > Signed-off-by: Dmitry Torokhov <email address hidden>
> > > ---
> > >
> > > Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> > > Dell E4300.
> >
> > What -stable tree is this for? .31 is no longer being maintained. Is
> > this the proper patch for .32? .27?
> >
> > >
> > > drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> > > drivers/input/mouse/alps.h | 1 +
> > > 2 files changed, 228 insertions(+), 25 deletions(-)
> >
> > Ick, that's a big patch, and kind of violates the -stable rules, right?
> > It's a "add new functionality" type thing that you are doing here from
> > what I can tell. This doesn't fix a regression, does it?
> >
>
> Well, yes and no. As shipped .32 (and earlier) has the signature for
> ALPS that is installed in those newer Latitudes so we try to activate
> ALPS protocol for their touchpads. Unfortunately without the patch the
> protocol desyncs all the time, making trackpoint/touchpad unuseable.
>
> IOW if you are an owner of said Latitude you want this patch _very
> much_. But yes, the patch is sizeable.

So is this something that you, as the maintainer of the subsystem, would
recommend that I consider for the -stable tree because of this
situation?

thanks,

greg k-h

On Thu, Jan 21, 2010 at 08:23:28AM -0800, Greg KH wrote:
> On Wed, Jan 20, 2010 at 11:54:38PM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> > > On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > > > From: Sebastian Kapfer <email address hidden>
> > > > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > > > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > > >
> > > > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > > >
> > > > Properly handle version of the protocol where standard PS/2 packets
> > > > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > > > ALPS packets when both the touchpad and trackpoint are used together.
> > > >
> > > > The patch is based on work done by Matthew Chapman and additional
> > > > research done by David Kubicek and Erik Osterholm:
> > > >
> > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > > >
> > > > Many thanks to David Kubicek for his efforts in researching fine points
> > > > of this new version of the protocol, especially interaction between pad
> > > > and stick in these models.
> > > >
> > > > Signed-off-by: Sebastian Kapfer <email address hidden>
> > > > Signed-off-by: Dmitry Torokhov <email address hidden>
> > > > ---
> > > >
> > > > Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> > > > Dell E4300.
> > >
> > > What -stable tree is this for? .31 is no longer being maintained. Is
> > > this the proper patch for .32? .27?
> > >
> > > >
> > > > drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> > > > drivers/input/mouse/alps.h | 1 +
> > > > 2 files changed, 228 insertions(+), 25 deletions(-)
> > >
> > > Ick, that's a big patch, and kind of violates the -stable rules, right?
> > > It's a "add new functionality" type thing that you are doing here from
> > > what I can tell. This doesn't fix a regression, does it?
> > >
> >
> > Well, yes and no. As shipped .32 (and earlier) has the signature for
> > ALPS that is installed in those newer Latitudes so we try to activate
> > ALPS protocol for their touchpads. Unfortunately without the patch the
> > protocol desyncs all the time, making trackpoint/touchpad unuseable.
> >
> > IOW if you are an owner of said Latitude you want this patch _very
> > much_. But yes, the patch is sizeable.
>
> So is this something that you, as the maintainer of the subsystem, would
> recommend that I consider for the -stable tree because of this
> situation?
>

Yes, I am recommending it. The new behavior should be mostly contained
by ALPS_INTERLEAVED flag that is only set for one particular signature;
the rest of devices should not be affected.

The patch could be made smaller (there are some comments and a bit of
restructuring that could be cut out) but given that it is in Debian for
some time I question whether introducing 3rd, less tested variant to
reduce patch line count makes sense.

Thanks.

--
Dmitry

On Thu, Jan 21, 2010 at 09:30:48AM -0800, Dmitry Torokhov wrote:
> On Thu, Jan 21, 2010 at 08:23:28AM -0800, Greg KH wrote:
> > On Wed, Jan 20, 2010 at 11:54:38PM -0800, Dmitry Torokhov wrote:
> > > On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> > > > On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > > > > From: Sebastian Kapfer <email address hidden>
> > > > > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > > > > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > > > >
> > > > > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > > > >
> > > > > Properly handle version of the protocol where standard PS/2 packets
> > > > > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > > > > ALPS packets when both the touchpad and trackpoint are used together.
> > > > >
> > > > > The patch is based on work done by Matthew Chapman and additional
> > > > > research done by David Kubicek and Erik Osterholm:
> > > > >
> > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > > > >
> > > > > Many thanks to David Kubicek for his efforts in researching fine points
> > > > > of this new version of the protocol, especially interaction between pad
> > > > > and stick in these models.
> > > > >
> > > > > Signed-off-by: Sebastian Kapfer <email address hidden>
> > > > > Signed-off-by: Dmitry Torokhov <email address hidden>
> > > > > ---
> > > > >
> > > > > Cherrypick to 2.6.31 by Andy Isaacson <email address hidden>. Tested on
> > > > > Dell E4300.
> > > >
> > > > What -stable tree is this for? .31 is no longer being maintained. Is
> > > > this the proper patch for .32? .27?
> > > >
> > > > >
> > > > > drivers/input/mouse/alps.c | 252 +++++++++++++++++++++++++++++++++++++++-----
> > > > > drivers/input/mouse/alps.h | 1 +
> > > > > 2 files changed, 228 insertions(+), 25 deletions(-)
> > > >
> > > > Ick, that's a big patch, and kind of violates the -stable rules, right?
> > > > It's a "add new functionality" type thing that you are doing here from
> > > > what I can tell. This doesn't fix a regression, does it?
> > > >
> > >
> > > Well, yes and no. As shipped .32 (and earlier) has the signature for
> > > ALPS that is installed in those newer Latitudes so we try to activate
> > > ALPS protocol for their touchpads. Unfortunately without the patch the
> > > protocol desyncs all the time, making trackpoint/touchpad unuseable.
> > >
> > > IOW if you are an owner of said Latitude you want this patch _very
> > > much_. But yes, the patch is sizeable.
> >
> > So is this something that you, as the maintainer of the subsystem, would
> > recommend that I consider for the -stable tree because of this
> > situation?
> >
>
> Yes, I am recommending it. The new behavior should be mostly contained
> by ALPS_INTERLEAVED flag that is only set for one particular signature;
> the rest of devices should not be affected.
>
> The patch could be made smaller (there are some comments and a bit of
> restructuring that could be cut out) but given that it is in Debian for
> some time I question whether introducing 3rd, less tested variant to
> reduce patch line count ...

This bug was fixed in the package linux - 2.6.32-12.16

---------------
linux (2.6.32-12.16) lucid; urgency=low

  [ Andy Whitcroft ]

  * Revert "SAUCE: acpi battery -- delay first lookup of the battery until
    first use"
  * SAUCE: acpi battery -- move first lookup asynchronous
    - LP: #507211
  * [Config] update configs to cleanup generic configs
  * [Config] disable CONFIG_X86_CPU_DEBUG for amd64
  * [Config] enable USER_NS
    - LP: #480739, #509808

  [ Heiko Carstens ]

  * (pre-stable) driver-core: fix devtmpfs crash on s390
    - LP: #512370

  [ John Johansen ]

  * [Config] for server and virtual flavours make CONFIG_SCSI_SYM53C8XX_2=y
    - LP: #494565
  * [Config] VIRTIO=y for server/virtual flavours
    - LP: #494565

  [ Kay Sievers ]

  * (pre-stable) Driver-Core: devtmpfs - set root directory mode to 0755
    - LP: #512370

  [ Kees Cook ]

  * SAUCE: x86: brk away from exec rand area
    - LP: #452175

  [ Leann Ogasawara ]

  * [Upstream] e1000: enhance frame fragment detection
    - CVE-2009-4536
  * [Upstream] e1000e: enhance frame fragment detection
    - CVE-2009-4538

  [ Sebastian Kapfer ]

  * (pre-stable) Input: ALPS - add interleaved protocol support (Dell E6x00
    series)
    - LP: #296610

  [ Upstream Kernel Changes ]

  * inotify: do not reuse watch descriptors
    - LP: #485556
  * inotify: only warn once for inotify problems
  * revert "drivers/video/s3c-fb.c: fix clock setting for Samsung SoC
    Framebuffer"
  * memcg: ensure list is empty at rmdir
  * drm/i915: remove loop in Ironlake interrupt handler
  * block: Fix incorrect reporting of partition alignment
  * x86, mce: Thermal monitoring depends on APIC being enabled
  * futexes: Remove rw parameter from get_futex_key()
  * page allocator: update NR_FREE_PAGES only when necessary
  * x86, apic: use physical mode for IBM summit platforms
  * edac: i5000_edac critical fix panic out of bounds
  * x86: SGI UV: Fix mapping of MMIO registers
  * mfd: WM835x GPIO direction register is not locked
  * mfd: Correct WM835x ISINK ramp time defines
  * ALSA: hda - Fix missing capture mixer for ALC861/660 codecs
  * V4L/DVB (13868): gspca - sn9c20x: Fix test of unsigned.
  * reiserfs: truncate blocks not used by a write
  * HID: add device IDs for new model of Apple Wireless Keyboard
  * PCI/cardbus: Add a fixup hook and fix powerpc
  * Input: pmouse - move Sentelic probe down the list
  * asus-laptop: add Lenovo SL hotkey support
  * sched: Fix cpu_clock() in NMIs, on !CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
  * sparc64: Fix NMI programming when perf events are active.
  * sparc64: Fix Niagara2 perf event handling.
  * i2c: Do not use device name after device_unregister
  * i2c/pca: Don't use *_interruptible
  * serial/8250_pnp: add a new Fujitsu Wacom Tablet PC device
  * sched: Fix task priority bug
  * vfs: Fix vmtruncate() regression
  * Linux 2.6.32.5
  * x86, msr/cpuid: Register enough minors for the MSR and CPUID drivers
  * V4L/DVB (13900): gspca - sunplus: Fix bridge exchanges.
  * Staging: asus_oled: fix oops in 2.6.32.2
  * Staging: hv: fix smp problems in the hyperv core code
  * tty: fix race in tty_fasync
  * ecryptfs: use after free
  * ecryptfs: initi...

I declined the Lucid nomination because the fix is already released there.

DELL LATITUDE D600
UBUNTU 9.10 with proposed-updates
LINUX 2.6.31-20-generic
NAUTILUS 1:2.28.1-0ubuntu3
GNOME 2.28.1
FireFox 3.5.8
FireGestures 1.5.6

When using UBUNTU_JAUNTY, I get the same problems as described above (log below) -- but with UBUNTU_KARMIC the problem has evolved somewhat:

- previously it was common when the left-mouse button froze, for the FireGestures plugin to activate its mouse-trail like an etch-a-sketch; almost always had to reboot to get mouse back. this is rarely happening now.

- when the mouse buttons lock up, i can now normally mouse up from my app (browser) onto the Nautilus command bar (APPLICATIONS : PLACES : SYSTEM) and repeatedly right-click until I get a drop-down menu; then I can repeatedly left-click until I get a drop-down menu -- restoring mouse button control. [normally in this process, i can not use the mouse pad vertical scroll feature until left-click is restored]

- the mouse randomly jumping around the screen seems a bit more frequent than UNBUNTU_JAUNTY installs.

*NEW* Right-click for a drop-down menu leaving the mouse perfectly still, the left-click (double-tap) will not be recognized until you atleast slightly move the mouse.

*NEW* Right-click for a drop-down menu and slight/slow movement of mouse activates first menu item as if you just left-clicked it. This happens MOST of the time and often winds up launching the item, or creating a new document/action. [a trashbin full of new empty folders i've had to delete daily based on this]

*FYI* I have not tried any of the patches mentioned.

Mar 11 14:59:13 TOBY kernel: [ 0.900131] input: Macintosh mouse button emulation as /devices/virtual/input/input3
Mar 11 14:59:13 TOBY kernel: [ 0.926729] mice: PS/2 mouse device common for all mice
Mar 11 15:20:43 TOBY kernel: [ 1314.335444] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Mar 11 15:20:43 TOBY kernel: [ 1314.336324] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Mar 11 15:20:43 TOBY kernel: [ 1314.339657] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Mar 11 15:20:44 TOBY kernel: [ 1314.707995] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 2
Mar 11 15:20:44 TOBY kernel: [ 1314.709051] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Mar 11 15:20:44 TOBY kernel: [ 1314.712164] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Mar 11 15:20:44 TOBY kernel: [ 1314.713141] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Mar 11 15:20:44 TOBY kernel: [ 1314.825724] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Mar 11 15:24:01 TOBY kernel: [ 1511.489477] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Mar 11 15:24:01 TOBY kernel: [ 1511.492702] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.
Mar 11 15:24:01 TOBY kernel: [ 1511.493780] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Mar 11 15:24:01 TOBY kernel: [ 1511.511965] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byt...

sirald66,
      Please test this in Lucid as this is the current development branch. Per the kernel Engineer(stefan) the fix should be in lucid. Please respond here if you still encounter it.

Thanks!

~JFo

I noticed the "DualPoint TouchPad...lost sync" messages in the output of dmesg. I removed "irqpoll" from my kernel command line and rebooted, and mouse movement (via either pointing stick or touchpad) is back to normal. I'm using 32-bit Ubuntu 9.10 (Karmic) on a Dell Latitude D630.

Details:
* removed irqpoll from GRUB_CMDLINE_LINUX in /etc/default/grub
* ran "sudo update-grub"
* rebooted

However, I had originally *added* irqpoll because it appeared to fix very slow performance after resuming from sleep ( http://ubuntuforums.org/showthread.php?t=1417770 ), so I'm not sure if that will now be broken again.

Accepted linux into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I've had karmic-proposed enabled since my system install and get them regularly, but the ALPS DualPoint patch never appeared. Still have the same problem.

I haven't had any problems with my mouse since the proposed update.

i'm running 2.6.31-21-generic

The patch is working perfectly.

2.6.31-21-generic fixed my E6400's erratic mouse. I've been using it for almost two weeks now.

This bug was fixed in the package linux - 2.6.31-21.59

---------------
linux (2.6.31-21.59) karmic-proposed; urgency=low

  [ Andy Whitcroft ]

  * [Config] generic-pae switch to M586TSC
    - LP: #519448

  [ Chris Wilson ]

  * (pre-stable) drm/i915: Increase fb alignment to 64k
    - LP: #404064

  [ Colin Ian King ]

  * Input: i8042 - bypass AUX IRQ delivery test on laptops
    - LP: #534448

  [ Jerone Young ]

  * SAUCE: Fix volume hotkeys for Dell Studio 1557
    - LP: #465250

  [ Mirsal Ennaime ]

  * SAUCE: aufs: Fix header files inclusion in debug.h
    - LP: #517151

  [ Stefan Bader ]

  * [Config] Enable all CGROUP configuration options
    - LP: #480739

  [ Surbhi Palande ]

  * Revert "[Upstream] acerhdf: Limit modalias matching to supported
    boards"
    - LP: #509730
  * [Config] ext3 defaults to ordered mode
    - LP: #510067

  [ Tim Gardner ]

  * [Config] Fix sub-flavours package conflicts
    - LP: #454827

  [ Upstream Kernel Changes ]

  * PCI/cardbus: Add a fixup hook and fix powerpc
    - LP: #455723
  * fnctl: f_modown should call write_lock_irqsave/restore
    - LP: #519436
  * ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C
    - LP: #516325
  * tg3: Add 57788, remove 57720
    - LP: #515390
  * HID: ignore all recent SoundGraph iMON devices
    - LP: #488443
  * Input: ALPS - add interleaved protocol support (Dell E6x00 series)
    - LP: #296610
  * acerhdf: limit modalias matching to supported
    - LP: #509730
  * ASoC: Do not write to invalid registers on the wm9712.
    - LP: #509730
  * cifs: NULL out tcon, pSesInfo, and srvTcp pointers when chasing DFS
    referrals
    - LP: #509730
  * clockevents: Prevent clockevent_devices list corruption on cpu hotplug
    - LP: #509730
  * dma: at_hdmac: correct incompatible type for argument 1 of
    'spin_lock_bh'
    - LP: #509730
  * drivers/net/usb: Correct code taking the size of a pointer
    - LP: #509730
  * Libertas: fix buffer overflow in lbs_get_essid()
    - LP: #509730
  * md: Fix unfortunate interaction with evms
    - LP: #509730
  * pata_cmd64x: fix overclocking of UDMA0-2 modes
    - LP: #509730
  * pata_hpt3x2n: fix clock turnaround
    - LP: #509730
  * SCSI: fc class: fix fc_transport_init error handling
    - LP: #509730
  * sound: sgio2audio/pdaudiocf/usb-audio: initialize PCM buffer
    - LP: #509730
  * USB: emi62: fix crash when trying to load EMI 6|2 firmware
    - LP: #509730
  * USB: Fix a bug on appledisplay.c regarding signedness
    - LP: #509730
  * USB: musb: gadget_ep0: avoid SetupEnd interrupt
    - LP: #509730
  * USB: option: support hi speed for modem Haier CE100
    - LP: #490068, #509730
  * x86, cpuid: Add "volatile" to asm in native_cpuid()
    - LP: #509730
  * e100: Use pci pool to work around GFP_ATOMIC order 5 memory allocation
    failure
    - LP: #509730
  * e100: Fix broken cbs accounting due to missing memset.
    - LP: #509730
  * hostap: Revert a toxic part of the conversion to net_device_ops
    - LP: #509730
  * hwmon: (fschmd) Fix check on unsigned in watchdog_write()
    - LP: #509730
  * hwmon: (sht15) Off-by-one error in array index + incorrect constants
    - LP: #509730
  * i2c/tsl2550: Fix...

FYI - The fix has worked for some still under Karmic, but not for me. I will wait until Lucid is released.

DELL LATITUDE D600
UBUNTU 9.10 karmic-proposed
LINUX 2.6.31-21-generic