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.

Just installed Karmic, latest proposed/updates/security installed via network. I have a DELL M4400 with the infamous DualPoint TouchPad.

I can reproduce this issue at any time by merely using the "Stick" and "TouchPad" at the same time. No button presses required. Just move the pointer using the "Stick" and brush the "TouchPad" with my hand. That's it. The pointer goes crazy, jumps all over the place and I get this in dmesg:

[ 510.877630] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
[ 510.878792] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 510.886324] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 510.887586] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 510.888545] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 510.888552] psmouse.c: issuing reconnect request

The "reconnect request" appears if I do that for like a second or more. If I only brush the TouchPad, I just get lost sync. However, after reconnect is issued, I loose all configuration for the Stick and TouchPad I used to have via HAL (.fdi preferences). Both devices are found "anew" and get the next input number in sequence, e.g. ../serio1/input/input16.

This is a major pain in the a$$. I haven't been using stand-alone mouse for 5 years. I had a ThinkPad with a similar TrackPoint. I touch type and cannot afford to remove my hands from the keyboard to hold the mouse. I'm unable to work with this new DELL. There is obviously a bug in the kernel driver. There is some aspect of the underlying protocol, which is not understood by the driver...

Please help us! I'll be using this for a long time and I'm willing to do any testing required, incl. custom kernel patching, compilation, whatever it takes.

Thank you, David

OH! A very important fact - after "reconnect", when I get the TouchPad and Stick back again as plain unconfigured mice, both work OK. I mean I can use the Stick & TouchPad simultaneously and everything is perfect. :) No jumping, no lost sync.

So I have these options:
1) avoid lost sync & reconnect and have my Stick with the ability to scroll (Wheel Emulation in combination with button 3) -- that's the custom config via HAL.
2) force reconnect, don't have any problems anymore, but also loose the Wheel Emulation -- cos I'm unable to apply HAL configuration on the reconnected devices. :(

I think this means the problem might not be just the driver. It's probably a combination of HW / driver issues.

Found out more!!

It works OK after reconnect, because the X input subsystem only sees the TouchPad (not the Stick) then. But both pointers work when used, so the TouchPad obviously sends also the Stick events (like a repeater):

This is xinput before reconnect:

"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
...
"AlpsPS/2 ALPS DualPoint TouchPad" id=8 [XExtensionPointer]
 Type is TOUCHPAD
 Num_buttons is 12
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
  Min_value is 0
  Max_value is 1023
  Resolution is 1
 Axis 1 :
  Min_value is 0
  Max_value is 767
  Resolution is 1
"DualPoint Stick" id=10 [XExtensionPointer]
 Type is MOUSE
 Num_buttons is 5
 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

See? Both devices are there, but when used simultaneously, they wreak havoc. So I force reconnect by using Stick and TouchPad at the same time for roughly 2 secs. I get this:

[ 3296.298172] psmouse.c: issuing reconnect request
[ 3297.452170] alps.c: Failed to enable absolute mode
[ 3298.512298] input: PS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input19

And now xinput looks like this:

"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
...
"PS/2 ALPS DualPoint TouchPad" id=8 [XExtensionPointer]
 Type is MOUSE
 Num_buttons is 5
 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

See? The Stick isn't there. Bot now both the TouchPad and the Stick work, there are no lost syncs any more and I can use them both simultaneously.

I think the problem is the TouchPad works also like a repeater for the Stick and when there is a Stick stand-alone + Stick repeated it causes troubles. If we could turn off TouchPad's repeater mode, I think the whole thing would be stable!

What do you think?

Judging from the message "Failed to enable absolute mode", after resyncing, the Alps driver has given up initializing the (now confused) hardware, and the hardware is being handed over to the Plain PS/2 driver. Which means, the hardware handles the merging of stick/pad events on its own, and it is seen as a plain PS/2 mouse. I.e. what you're seing is the compatiblity mode.

Your problem should be fixable by applying the kernel patch I posted earlier. I would be very interested to hear. Do you know how to compile your own kernel?

[The patch as posted is active for the Alps device built into the E6500 laptop. If your M4000's device reports differently, we may need to change the patch a little to activate the new codepath for it, too.]

Of course I am. Personally, I'm a Debian user - for about 10 yrs, but I wanted to try its younger brother on my new laptop. It was an opportunity. :) At the moment I've been hacking on the alps.c source and testing stuff by rmmod/insmod-ing a patched psmouse module. Same results so far.

I'll have a look at your patch and try it out. Right now I don't even know what it does, I didn't see it yet. When I'm done, I'll let you know.

BTW, you might be able to tell me how module versioning works "under the hood". Even though I've written a kernel module myself and contributed to v4l-dvb, I never looked into this deep enough. I know how to work with it the traditional way, but I'd like to be able to just compile the psmouse module and insmod it. I cannot do it unless I go through all that "CONCURRENCY_LEVEL=3 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic-pae" stuff, somehow making a compatible deb package of my flavour from the distribution release. Then, my .ko's from the build tree work with my current kernel.

Is there a way I could hack Module.symvers or something to compile the kernel the old-fashioned way (make menuconfig; make) and then be able to use the .ko? It would save me a lot of time waiting for the "Debian-way" recompilations...

I compiled "the Debian way", which generated a correct Module.symvers, and then just used manual make to re-compile only files I modified. This way I can compile and insert modules as I like -- right into the official unmodified linux-image kernel currently running. Might be useful for somebody. It might be possible to just copy Module.* files from linux-headers package into any source tree and just compile, but I doubt it.

Anyway, I really have to thank you -- your patch solved the problem! There's no more jumping, sync lost, reconnects, etc. Pure joy. :) The magical "new" 9th byte really wreaks havoc with the latest driver. I hope your fix gets into upstream ASAP, because it should have been there two years ago! I can't believe they've been ignoring it for so long.

Thank you, Sebastian.
~~~~~~~~~~~~~~~~~

PS: Mostly unrelated question. I use Stick's right button (3) for Stick-scrolling (wheel emulation). I have this disabled for the TouchPad. Here's an excerpt from my HAL config:

  <device>
    <match key="info.product" contains="AlpsPS/2 ALPS DualPoint TouchPad">
        <merge key="input.x11_options.SHMConfig" type="string">true</merge>
        <merge key="input.x11_options.Emulate3Buttons" type="string">false</merge>
        <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
        <merge key="input.x11_options.HorizEdgeScroll" type="string">true</merge>
        <merge key="input.x11_options.PalmDetect" type="string">true</merge>
    </match>
  </device>

  <device>
    <match key="info.product" contains="DualPoint Stick">
        <merge key="input.x11_options.Emulate3Buttons" type="string">false</merge>
        <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
        <merge key="input.x11_options.EmulateWheelButton" type="string">3</merge>
        <merge key="input.x11_options.EmulateWheelTimeout" type="string">100</merge>
        <merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge>
    </match>
  </device>

Scrolling using the Stick works, but it also works for the TouchPad! The same configuration works on my older ThinkPad. I use (Fluxbox) ALT+LeftBtn+Stick to move windows around and ALT+RightBtn+Stick to resize windows.

When I push ALT + TouchPad-right, it scrolls when I move the Stick (instead of resizing window). Without ALT pressed, it works normally: right click is registered. With ALT, however, right click isn't registered and moving the Stick scrolls (instead of resizing). Fluxbox configuration and version are the same as on my ThinkPad, where this works. I restored my $HOME here.

When I push ALT + TouchPad-right, resizing works iff I move the pointer using TouchPad. So it "works", but I want to use the *Stick* like I'm used to. Moving the Stick reverts to scrolling mode. Seems like the action is somehow associated with the pointer, not just the buttons of a pointer. How come it works on ThinkPad then? :)

Any ideas? HAL configuration is OK. Command lshal shows all properties set correctly - wheel emulation only for the Stick.

Can you send me a procedure to do this on my ubuntu 9.10?

Robert Hau
West Highland Support Services
917-657-0686 Cell
866-778-3484 x157 Office

----- Original Message -----
From: "Dave" <email address hidden>
To: "robert hau" <email address hidden>
Sent: Wednesday, November 11, 2009 7:46:02 PM GMT -05:00 US/Canada Eastern
Subject: [Bug 296610] Re: ALPS DualPoint Touchpad flaky performance

I compiled "the Debian way", which generated a correct Module.symvers,
and then just used manual make to re-compile only files I modified. This
way I can compile and insert modules as I like -- right into the
official unmodified linux-image kernel currently running. Might be
useful for somebody. It might be possible to just copy Module.* files
from linux-headers package into any source tree and just compile, but I
doubt it.

Anyway, I really have to thank you -- your patch solved the problem!
There's no more jumping, sync lost, reconnects, etc. Pure joy. :) The
magical "new" 9th byte really wreaks havoc with the latest driver. I
hope your fix gets into upstream ASAP, because it should have been there
two years ago! I can't believe they've been ignoring it for so long.

Thank you, Sebastian.
~~~~~~~~~~~~~~~~~

PS: Mostly unrelated question. I use Stick's right button (3) for Stick-
scrolling (wheel emulation). I have this disabled for the TouchPad.
Here's an excerpt from my HAL config:

  <device>
    <match key="info.product" contains="AlpsPS/2 ALPS DualPoint TouchPad">
        <merge key="input.x11_options.SHMConfig" type="string">true</merge>
        <merge key="input.x11_options.Emulate3Buttons" type="string">false</merge>
        <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
        <merge key="input.x11_options.HorizEdgeScroll" type="string">true</merge>
        <merge key="input.x11_options.PalmDetect" type="string">true</merge>
    </match>
  </device>

  <device>
    <match key="info.product" contains="DualPoint Stick">
        <merge key="input.x11_options.Emulate3Buttons" type="string">false</merge>
        <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
        <merge key="input.x11_options.EmulateWheelButton" type="string">3</merge>
        <merge key="input.x11_options.EmulateWheelTimeout" type="string">100</merge>
        <merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge>
    </match>
  </device>

Scrolling using the Stick works, but it also works for the TouchPad! The
same configuration works on my older ThinkPad. I use (Fluxbox)
ALT+LeftBtn+Stick to move windows around and ALT+RightBtn+Stick to
resize windows.

When I push ALT + TouchPad-right, it scrolls when I move the Stick
(instead of resizing window). Without ALT pressed, it works normally:
right click is registered. With ALT, however, right click isn't
registered and moving the Stick scrolls (instead of resizing). Fluxbox
configuration and version are the same as on my ThinkPad, where this
works. I restored my $HOME here.

When I push ALT + TouchPad-right, resizing works iff I move the pointer
using TouchPad. So it "works", but I want to use the *Stick* like I'm
used to. Moving the Stick reverts to scrolling mode...

Setting Importance as High -- issue seems to persist.

Increasing importance to High as this seems to affect a lot of people, making common Dell hardware difficult to use.

Sebastian,

Your patch gets us most of the way there. There's still a minor problem, apparently with the mouse buttons. They can occasionally get stuck in a "pressed" state.

To reproduce, in Ubuntu (Gnome):
1) Press and hold the touchpad's left mouse button while the pointer is on the desktop (or anywhere in Nautilus).
2) Drag with the trackpoint (the stick).
3) Stop dragging with the trackpoint.
4) Release the touchpad's left mouse button.
5) Notice that the computer still thinks that the left mouse button is down. This behavior continues until you initiate an event (movement or buttons) with the trackpoint.

The inverse works, too (using the trackpoint's buttons and the touchpad for dragging.)

I believe this happens because the button state for each device is independent. Back when I was using someone else's patch, I fixed this by setting the button state for both devices any time the state for one of them changed. I don't think that's an unreasonable design, as I can't imagine a time when you'd really want to track them separately. Could you add this to your patch?

Incidentally, the Windows driver seems to handle the issue by disabling the touchpad and touchpad buttons any time it is processing events from the trackpoint. I'm not sure that's desirable, but it is likely the way that the manufacturer intended for the device to be used.

On Do, 2009-11-12 at 03:43 +0000, Erik wrote:
> Sebastian,
>
> Your patch gets us most of the way there. There's still a minor
> problem, apparently with the mouse buttons. They can occasionally get
> stuck in a "pressed" state.

Erik,

I'm sorry, but I can't reproduce this. Are you sure you're using my
patch and not the one by Chapman? It had exactly this issue. Also,
what kind of hardware do you have? Mine is in a Dell E6500.

> To reproduce, in Ubuntu (Gnome):
> 1) Press and hold the touchpad's left mouse button while the pointer is on the desktop (or anywhere in Nautilus).
> 2) Drag with the trackpoint (the stick).
> 3) Stop dragging with the trackpoint.
> 4) Release the touchpad's left mouse button.
> 5) Notice that the computer still thinks that the left mouse button is down. This behavior continues until you initiate an event (movement or buttons) with the trackpoint.

I tried many times now, but it doesn't happen here. Did the hardware
initialize properly, i.e. no error messages from alps.c and two devices
in /dev/input?

> I fixed this
> by setting the button state for both devices any time the state for one
> of them changed.

It may well be unavoidable, because at some times, the hardware does not
distinguish properly between touchpad buttons and trackpoint buttons.
However, I'm pretty sure that I catched those corner cases.

> Incidentally, the Windows driver seems to handle the issue by disabling
> the touchpad and touchpad buttons any time it is processing events from
> the trackpoint. I'm not sure that's desirable, but it is likely the way
> that the manufacturer intended for the device to be used.

LOL, I love it when commercial companies fix crappy hardware design in
the Windows driver. :-)

--
Best Regards, | Hi! I'm a .signature virus. Copy me into
 Sebastian | your ~/.signature to help me spread!

Dave,

thank you, it's nice to hear that it works (at least the basics).

> Scrolling using the Stick works, but it also works for the TouchPad! The
> same configuration works on my older ThinkPad. I use (Fluxbox)
> ALT+LeftBtn+Stick to move windows around and ALT+RightBtn+Stick to
> resize windows.

I'd need to look into this. Thinkpad is using different hardware as you
no doubt know, and Alps has the reputation of being a cheap clone.
Maybe this is one of the reasons? *g*

> When I push ALT + TouchPad-right, it scrolls when I move the Stick
> (instead of resizing window). Without ALT pressed, it works normally:
> right click is registered. With ALT, however, right click isn't
> registered and moving the Stick scrolls (instead of resizing). Fluxbox
> configuration and version are the same as on my ThinkPad, where this
> works. I restored my $HOME here.

What exactly is Alt supposed to do w.r.t. the Wheel Emulation? Does it
mean your windows manager handles Alt + ScrollEvent in a special way?

--
Best Regards, | Hi! I'm a .signature virus. Copy me into
 Sebastian | your ~/.signature to help me spread!

> I'd need to look into this. Thinkpad is using different hardware as you
> no doubt know, and Alps has the reputation of being a cheap clone.
> Maybe this is one of the reasons? *g*

I wouldn't be surprised. :) I'd like you to try it, perhaps you'd see more -- I haven't tried xev for example. It might tell us what's different w.r.t. X events from the ThinkPad.

> What exactly is Alt supposed to do w.r.t. the Wheel Emulation? Does it
> mean your windows manager handles Alt + ScrollEvent in a special way?

No, it has nothing to do with scrolling. It's hard to explain. :) Just try "xinit /usr/bin/fluxbox" and the default install has this windows move/resize feature. Moving even works in Metacity (not resizing). Blackbox clones have it.

Ordinally (now speaking about Pad, because Stick is in wheel emulation mode and this doesn't work for it):
1) push ALT, then LeftBtn (when pointer is over a window) and start moving mouse. This moves the window; window is following the mouse.
2) push ALT, then RightBtn (when pointer is over a window) and start moving mouse. This resizes the window; window's corner is following the mouse.

This action is incredibly useful - especially when you use many terminal windows. It is the fastest way to organize one's desktop. The 1) works. It works for both the Stick and Pad, becase button 1 isn't special (scroll) on either. I can ALT+StickLeft+Stick or ALT+StickLeft+Pad and windows are moving.

THE ISSUE -- right button. I push ALT+PadRight I get the mouse icon signalling window-resize mode, and I can use Pad pointer to resize. However: repeat ALT+PadRight, get resize icon, but try using the *Stick* pointer -- resize icon disappears and X reverts to scrolling - forgetting about pushed ALT and that I'm pushing PadRight, not StickRight! It's complicated, you'd have to try it yourself.

~~~~~~~~~~~~~~~~~~~~ ON TOPIC ~~~~~~~~~~~~~~~~~~~~~~~

I also believe there is still one issue left. I have the same problem - I do *something* (I'll have to find a reproducible way and describe it here) and my desktop goes crazy. X11 obviously *thinks* my ALT button is pressed and one/some of my Pad buttons are too. Why?

Because using Stick pointer, I cannot raise windows - it's like ghost clicks. I cannot select text and drag. My keyboard does nothing, even if I switch using ALT-Tab, writing doesn't get the presses registered. As if I was holding ALT or CTRL.

Fixing this is very easy - I just have to *click once* on the PadLeft button! Weird, but it really seems something gets stuck in pressed state. I cannot tell you how to reproduce, I managed it just once after aplying this PATCH and it was by using all Pad/Stick button/pointer ALT/CTRL combinations. :) A bit insane, yes, but it happened to me more than 4 times in two days, so it's definitely there.

I'll be back with more info!

I CAN REPRODUCE IT (with Sebastian's patch, of course)!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Push PadLeft (hold), then push StickLeft (hold), then touch Stick to move the pointer over some text (and let it be; still holding btns!)
   - your pointer should have moved and selected a piece of text -- normal "drag selection"
2) Now release PadLeft and then StickLeft (first StickLeft then PadLeft doesn't trigger this!)
   - now you're screwed :)

Voila! Your desktop is now officially crazy. :) Moving the pointer using external mouse, Stick or Pad keeps dragging the selection. You can push any buttons or keys you want, it won't stop untill you click PadLeft!

What happens to me - I usually pushed ALT-Tab in this state to check other windows (i.e. "what's going on?"). Try it. The situation get worse, because the selection stops, doesn't follow the mouse anymore, but all symptoms remain. Now you just see a desktop, where keyboard doesn't work, mouse clicks don't work, ALT+Tab order got reversed -- first I thought X went crazy. Until I found that it's the ALPS. Pushing PadLeft makes everything go away.

Dave I can confirm that also exists on a non alps touchpad. I have a second laptop a dell D620 that has the same behavior.

Robert Hau
West Highland Support Services
917-657-0686 Cell
866-778-3484 x157 Office

----- Original Message -----
From: "Dave" <email address hidden>
To: "robert hau" <email address hidden>
Sent: Thursday, November 12, 2009 7:09:00 AM GMT -05:00 US/Canada Eastern
Subject: [Bug 296610] Re: ALPS DualPoint Touchpad flaky performance

I CAN REPRODUCE IT (with Sebastian's patch, of course)!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Push PadLeft (hold), then push StickLeft (hold), then touch Stick to move the pointer over some text (and let it be; still holding btns!)
   - your pointer should have moved and selected a piece of text -- normal "drag selection"
2) Now release PadLeft and then StickLeft (first StickLeft then PadLeft doesn't trigger this!)
   - now you're screwed :)

Voila! Your desktop is now officially crazy. :) Moving the pointer using
external mouse, Stick or Pad keeps dragging the selection. You can push
any buttons or keys you want, it won't stop untill you click PadLeft!

What happens to me - I usually pushed ALT-Tab in this state to check
other windows (i.e. "what's going on?"). Try it. The situation get
worse, because the selection stops, doesn't follow the mouse anymore,
but all symptoms remain. Now you just see a desktop, where keyboard
doesn't work, mouse clicks don't work, ALT+Tab order got reversed --
first I thought X went crazy. Until I found that it's the ALPS. Pushing
PadLeft makes everything go away.

--
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 tr...

Robert, get and apply Sebastian's patch - it fixes this erratic, mildly destructive, behaviour.

I'm uploading the fixed module (psmouse) in case you don't know how to apply a patch to the kernel and make a package. You'd have to use the same Ubuntu kernel & version as I do, though! It's the latest i386 generic-pae (i.e. supporting >4GB RAM) for Karmic.

There's still one issue left, but I doubt you'll encounter it during normal use. See my post above about how it's triggered.

Robert, one more thing. If you want your settings permanent, to remain even after reset, mouse disconnect, etc you have to apply them via HAL. It is very easy, you've done the hard part already.

Just use gsynaptics or whatever and set your parameters. Then use "synclient -l" to list all properties & values and just put them in your *.fdi HAL file. Every time your TouchPad, mouse, etc is detected, these settings will be applied on the low HAL level. No need for GNOME or other SHM tools (which after all don't persist as you see).

You can use this to transform synclient output into HAL XML format -- paste the result into your *.fdi:

synclient -l | sed 's/ *\([^ ]\+\) *= *\([^ ]\+\)/\t<merge key="input.x11_options.\1" type="string">\2<\/merge>/'

In case the forum messes up white spaces or other characters: http://pastebin.com/f6ff8ce93

@Dave - Thanks for uploading the patched kernel module. Unfortunately, it's not working for me - I'm getting the following error on insmod:
insmod: error inserting 'psmouse.ko': -1 Invalid module format

And /var/log/messages reports
Nov 12 12:12:58 nightfall kernel: [ 4859.142421] psmouse: disagrees about version of symbol module_layout

I'm running the 2.6.31-15-generic kernel, but not the PAE extension. I'm guessing that's the problem, eh?

I'm sorry guys, I can't reproduce the buttons bug. Is there any syslog messages when this happens?

Which application are you seeing this behaviour in? I tried Firefox and Nautilus, both under Metacity. No luck.

That being said, even if this bug really is to blame on the Alps driver, the patch still is a major improvement I hope :-)

@Charles: Yes. PAE extension isn't harmful, you can use it just as well. It only allows more than 4GB RAM on a 32bit machine.

@Sebastian: I sort of debugged the problem, it's definitely the driver, not X or WM. Try following:

Exit X (so your /dev/input devices are not grabbed) and run (from package input-utils) as root:
# input-events -t 120 X & input-events -t 120 Y
(X = evdev number of TouchPad, Y = Stick; find these using lsinput)

This is how it should work:

1) push PadLeft -> EV_KEY BTN_LEFT pressed
2) push StickLeft -> EV_KEY BTN_LEFT pressed
5) release StickLeft -> EV_KEY BTN_LEFT released
4) release PadLeft -> EV_KEY BTN_LEFT released

Now ALPS has a definite bug:

1) push PadLeft -> EV_KEY BTN_LEFT pressed
2) push StickLeft -> EV_KEY BTN_LEFT pressed
4) release StickLeft -> NO event!
   - now you can click StickLeft like mad, no events!
5) release PadLeft -> EV_KEY BTN_LEFT released

At this point, PadLeft has correct state, but StickLeft is incorrectly "pressed" for the input subsystem. Until you click it or generate any other Stick event.

You can switch 4) and 5) to break PadLeft state instead.

@Dave Can you please try the attached patch on top of the original one and send me the output of dmesg|grep alps after it happened.

Cheers, Sebastian.

@Dave - Thanks, I got it. I'm running the pae kernel now, and have successfully installed the patch. I haven't had a lost-sync moment yet. I just need to do some configuration so my scroll is a bit more consistent, and I should be in good shape.

Thanks!

I think this might have something to do with my other (and last) issue - the ALT+left/right move/resize windows one. With some button events not getting delivered OR being delivered as coming from a different device than actually generated them...

Because that's exactly what happens to me:
A) hold PadRight, move Pad pointer = OK (all just Pad events)
B) BUT hold PadRight (Pad event), move Stick pointer (Stick event) and the action switches to purely Stick events, as if StickRight + Stick pointer were doing it all along.

First let's concentrate on events not getting lost, then I may assist you with detailed code paths within the driver causing my last issue. I'd insert some key printk's to see what's going on, it might be obvious for you then. It is, after all, possible that your HW revision behaves a bit differently. Our notebooks are basically the same, though; E6x00 and M4400 share the same platform.

Moving Stick/Pad pointer spews just this:

[112187.964927] alps.c: report ps2 pkt 0

This is the sequence of packets doing +PadLeft, +StickLeft, -StickLeft, -PadLeft:

[112192.799333] alps.c: report pad pkt 1
[112192.799337]
[112196.169118] alps.c: report ps2 pkt 1
[112196.169122]
[112201.379772] alps.c: report ps2 pkt 1
[112201.379776]
[112204.198994] alps.c: report pad pkt 0
[112204.198998]

Each action generates a packet. Only 3 events get translated by the driver into the input layer. It appears the third packet is ignored - the first release (-StickLeft) isn't propagated.

Packet dumps now? :)

Sebastian,

I've uploaded a Youtube video demonstrating the bug. I'm certain that I'm only using your patch, as I performed a clean installation before doing my testing. I'm using an m4400, which seems to have the same Dualpoint. You're right that the patch is a vast improvement, but the buttons will still probably be a showstopper for me. I'd be happy to provide any command input (lsusb, etc.) you want to see, or gather any other information you need. Just let me know.

http://www.youtube.com/watch?v=GqSZ-mftheM&fmt=18

There are no apparent errors in the dmesg output.

Interestingly enough, regardless of whether or not I'm currently experiencing the bug, I can reliably cause the driver to lose sync by pressing all three of the touchpad buttons at once. Pressing all three of the stick's buttons do not cause the driver to lose sync. I don't know if this bug is related--it's certainly probably an uncommon problem.

Erik

I should add that I'm using Compiz in the video, but the same behavior exists with Metacity.

Question regarding installing the psmouse.ko.

I read someone where you can put the file in /lib/modules/2.6.31-14-generic/kernel/drivers/input/mouse and replace the psmouse.ko Is that true. I tried with my install and i lost my mouse completely on reboot.

Does the psmouse.ko have to match the 2.6.31.15-generic-pae?

I looked at DMESG i saw

psmouse : disagrees about version of symbol module_layout.

RH

I watched the behavior on you-tube, and i can confirm the behavior as well.

It seams that the trackpoint mouse has a click to the trackpoint by itself.

It almost seams likes its doing a click-lock behavior.

If you gently move the trackpoint it doesn't lock for me. but i only use the touchpad anyway.

RH

I'm a bit on the opposite side as Robert - I only use the touchpad for scrolling, and use the pointy stick almost exclusively. But I commonly see the LH stick button lock on, and have to hit one of the other buttons (generally LH pad button) to free it up.

@Erik: WTF, you have three buttons on the Touchpad? I only have two on the touchpad and three on the trackpoint. I'm not really surprised that this breaks the driver as it is. We'll have to do further research on your model.

[Background: 9-byte packets on my model are marked by having all three touchpad buttons set (even if none is actually pressed). That's how the code currently detects a 9-byte packet coming in -- and of course, if there's no 9-byte packet actually there, we're desynced.]

@Dave: Input layer is not guilty here. A release event for the dev2 is not being sent, so the buttons sticks. This is a bug in the Alps driver.

So to be clear, you guys all seem to have M4400's with three buttons on the touchpad AND the trackpoint?

I'll prepare a new patch to dump debug info for the M4400 style dualpoint device.

Robert: If I remember correctly, these devices are represented by two input devs in the code, each with its own set of buttons. There was something weird about how the buttons were represented in the 9-byte packet, and what happened with the old patch was that the button state for dev would differ from the button state for dev2. As long as either device thinks that the button is down, the button is considered down. So while the 9-byte packet would change one of the devices button states to up, it wouldn't change the state for the second. And voila, you have the behavior demonstrated in the video. You never have the problem if you're dealing with 5-byte packets (only using one device or the other.)

Charles: Yeah, I often find it very convenient to use the pointy stick to move and the touchpad button to drag, though I've mostly trained myself to not do that due to the various problems with this particular hardware. More commonly, I'll be pressing a button on the stick with my palm resting slightly on the touchpad and I'll trigger the bugs. That's the main reason it annoys me.

Sebastian:
Correct, there are three buttons for each device on my Dualpoint. It's actually pretty convenient, once you get used to it!

Thanks for all of your work and patience.

> @Dave: Input layer is not guilty here. A release event for the dev2 is
> not being sent, so the buttons sticks. This is a bug in the Alps driver.

Exactly, that's how I meant it. The driver doesn't translate all packets into the input layer. Only 3 event are generated for those 4 packets.

BTW, my Stick also has THREE buttons. That's definitely the reason you have no issues and we do. Something's different in the packet. Let's concentrate on this issue and keep this thread as clean and ON TOPIC as possible. It's getting huge. :)

I could write hex+bin packet dumping code for alps.c and report the results here. I think that's the only way you'll be able to find out anything. Without the HW, you're kinda screwed. I code in C for living and have kernel dev. experience - no problem there. The driver is pretty simple too. Would you like to see dumped anything particular?

I might find time to hack on it myself, I'd just have to look on the packet structure "documented" in comments to get into the picture. Would you like to cooperate? My mail is >dave at awk dot cz<.

@Sebastian - No, I've got a Dell E6400 Latitude with the alps touchpad/trackpoint combination.

@Erik - Perhaps I miscommunicated - I almost NEVER use the touchpad buttons in any kind of normal operation, and have pretty well trained myself NOT to touch the touchpad unless I scroll. Scrolling would be about the only use my touchpad gets. My old Dell 620's touchpad (that this replaces) still had the original matte finish - hadn't worn smooth yet. So I'm pretty sure I'm not experiencing a dual-input problem here.

But I'm smart enough not to swear that up and down, either. :)

Please apply the attached patch on top of the other two. I'd like the complete output of "dmesg | grep alps" (since the init of the module, please reload between tests) for the following:

1. Press all three touchpad buttons at once.

2. Use touchpad and trackpoint movement at the same time (which caused desync in unpatched Linux)

@Dave If you want to spend a little time, the first thing to do is find out what sizes of packages are being sent. You can probably get this from the hexdump of the data stream. The other thing is -- if you get 9-byte packets from your touchpad, how are they flagged. Mine look like regular 6-byte packets at first, but are marked by three pressed touchpad buttons -- this obviously can't happen for my hardware, so it is a safe indicator. For your model, this is going to be different.

@Charles: Any problems so far? I'd guess that you have a two-button unit then, as I do?

@Sebastian: you forgot the patch. :)

Basically, there are TWO issues remaining:
A) Identify a definite 9p flag (not a priority)
B) Find out why some packets aren't processed, causing stuck buttons (priority)

I'm thinking aloud now, please comment, Sebastian (or *email* me - would be faster and not clutter this forum):

1) I'm studying the source now. As you say, you detect 9p by 1111 in place of Stick's 1MRL - this is OK for your model, but our model must flag differently... Or it better be! :) Pressing all 3 buttons would make the driver lose sync (think it's 9p when it isn't). Right?

2) Our model flags the same, so I think there must be another bit comprising the flag, we just haven't identified it yet. The HW cannot use only 1MRL as the flag, it would be a huge bug! Causing lost sync even on Windows...

3) Also, cloning TouchPad's buttons from 9p to both devices - as is now - is problematic. It could cause a drift between the driver state and real world anytime. It may pass without issues, but eventually, we'll drift until reset again. Have you tried *not* *updating* Stick buttons using this packet? If "(p[3] & 0xf) == 0xf" really is the 9p flag (or part of it), it means HW isn't in fact telling us about Stick's buttons - so why update them? If there *is* a button change, HW will probably send a separate packet. What do you think?

4) I'll dump all packet types, it might tell us some news. Then, I'll try to identify a complete 9p flag. However, 9p isn't causing the problem with stuck buttons. With DEBUG on, we could see 9p isn't triggered at all while the button gets stuck, so that's a different bug.

I must have got something wrong. "p[3] & 0xf" is 1MRL for the Stick, right? And TouchPad has 1MRL at "p[6] & 0xf". At least that's what the comments say!

You check for 9p flag in p[3]. Then how come when I pushed TouchPad 1+2+3 it triggered 9p check?? Of course, it lost sync and reconnected -- that's what we expected. Here's the log [ http://pastebin.com/m3cc6acf7 ]. BUT if those comments are correct, 9p check should be triggered by 1+2+3 on the Stick, not on the TouchPad, NO?

Can you explain this before I continue?

This is another test -- "+1 +2 +3 -3 -2 -1" on the Stick: http://pastebin.com/f5c8ff5
Works perfectly, no 9p trigger.

Note that button bits are different from TouchPad. This says "1 5 7 5 1 0", whereas TouchPad says "1 17" before it loses sync. Different.

WARNING: the TouchPad progression is:

+1
Nov 13 00:05:32 localhost kernel: [125574.612295] alps.c: report pad pkt 1
+2
Nov 13 00:05:34 localhost kernel: [125576.222749] alps.c: report pad pkt 17
+3
Nov 13 00:05:36 localhost kernel: [125578.214547] alps.c: looks like a 9p. contents so far: cf 0 0 5f 7f 0
Nov 13 00:05:36 localhost kernel: [125578.215806] alps.c: looks like a 9p. contents so far: cf 0 0 5f 7f 0
Nov 13 00:05:36 localhost kernel: [125578.216762] alps.c: looks like a 9p. contents so far: cf 0 0 5f 7f 0
-3
Nov 13 00:05:42 localhost kernel: [125584.043424] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost synchronization, throwing 6 bytes away.

Lost sync is AFTER I RELEASE the 3. button.

This is 9p detection while moving both pointers just a little:
http://pastebin.com/f3786c65d

Without other info, I have to conclude that p[3] is for TouchPad and p[6] is for Stick. That's how HW reports buttons according to logs. Alps.c comments say it's the other way - can you fix the description or explain?

@Sebastian - I've got three buttons on the pointy stick, two on the track pad. With Dave's uploaded module (with the first patch), my 'lost sync' problems (and the accompanying pointer 'skipping'/'jumping' seem to have disappeared.

I still think I'm seeing some occasional 'button locking' - where the LH button doesn't disengage, but I can't reproduce it reliably. I've tried Dave's and Erik's steps to reproduce, and I'm not seeing any problem.

My LH pointy-stick button lock seems to occur most when click on a scroll bar then release, and it doesn't let go of the scroll bar. It doesn't reproduce 100%, but I'll try to see if there's a contributing factor...

Bad news. The driver behaves correctly - it does exactly what HW says. Problem is HW says is "wrong". Look at my dumps:

1) Pad Left Push:
alps.c: [0] cf 11001111
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: [3] 59 01011001
alps.c: [4] 7f 01111111
alps.c: [5] 0 00000000
alps.c: ----------
alps.c: report pad pkt 1

2) Pad Left Release:
alps.c: [0] cf 11001111
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: [3] 58 01011000
alps.c: [4] 7f 01111111
alps.c: [5] 0 00000000
alps.c: ----------
alps.c: report pad pkt 0

3) Stick Left Push:
alps.c: [0] 9 00001001
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: ----------
alps.c: report ps2 pkt 1

4) Stick Left Release:
alps.c: [0] 8 00001000
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: ----------
alps.c: report ps2 pkt 0

5) Pad Left Push:
alps.c: [0] cf 11001111
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: [3] 59 01011001
alps.c: [4] 7f 01111111
alps.c: [5] 0 00000000
alps.c: ----------
alps.c: report pad pkt 1

6) Stick Left Push:
alps.c: [0] 9 00001001
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: ----------
alps.c: report ps2 pkt 1

7) Stick Left Release (!!! reports pushed !!!)
alps.c: [0] 9 00001001
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: ----------
alps.c: report ps2 pkt 1

8) Pad Left Release:
alps.c: [0] cf 11001111
alps.c: [1] 0 00000000
alps.c: [2] 0 00000000
alps.c: [3] 58 01011000
alps.c: [4] 7f 01111111
alps.c: [5] 0 00000000
alps.c: ----------
alps.c: report pad pkt 0

Number 7) is "wrong". It should say PS2 "release", but it's a PS2 "push" packet. Basically, it says "Left button on your *screen* is still pushed". Windows see only one pointer and a set of buttons - like X. This ALPS is designed accordingly, but also to save money surely. It provides only ONE set of *button states*.

Number 8) is a normal PAD "release" packet. No extra info about the Stick.

The only solution, unfortunately, is to update BOTH devices with all PS2/PAD button events. Yes, we merge two mouses into one with 2 pointers, but it will work. This ALPS just doesn't provide two independent mouse HWs. Only two pointers and one set of buttons. Bastards!!

This HW is also the reason why I can't resize with Stick while holding Pad button. Pad button is registered, but Stick movements contain Pad button states (!!!) as if they were Stick's. So X thinks "he pushed Stick button now" and it takes preference. I have just learned this from packet dumps.

It's true. Our ALPS has just one set of buttons. The fix should be easy now. Just be careful to apply this feature only to this model. You might miss one button, but I bet your ALPS also has only one set of button states like ours. Not many people use this model on Linux - it was unnoticed like crazy jumping or the whole 9p change.

PS: With my packet dumping, I think we can find the 9p flag easily if it's there. I believe it's there, it wouldn't work on Windows too if it was just 1MRL. This is almost certain. It's a basic protocol requirement.

Have to go to slee...

This is 9p flag dump. Two packets, one REAL 9p, other FAKE 9p.

[0] is the same in both, [1-3] differences shown below, [4-5] is not interesting - it's coordinates, they wouldn't put it there:

// [0] cf 11001111
// [1] 10 00010000 REAL
// [1] a 00001010 FAKE
// [2] 1a 00011010 REAL
// [2] 18 00011000 FAKE
// [3] 2f 00101111 REAL
// [3] 3f 00111111 FAKE
// [4] 0 00000000
// [5] ff 11111111
// [6] 38 00111000
// [7] 25 00100101
// [8] 2b 00101011

I think it's the FIN bit! It makes sense. I added "&& (packet[2] & 0x2) == 0x2" to your "(packet[3] & 0xf) == 0xf" conditions and will test tomorrow. I believe this fixes one of the issues! :)

Let me know what you think about those stuck buttons!! The dumps say it loud and clear. :((

Here's the dmesg|grep alp output.

New 9p detection is working perfectly so far. I tried all tricks, it's stable. :)

Managed to get lost sync! So we know it's not the FIN. :)

This is a list of all bits in a REAL 9p packet, which remain ON no matter what you do:

alps.c: [0] 11001111
alps.c: [1] 00000000
alps.c: [2] 00000000
alps.c: [3] 00001111
alps.c: [4] 00000000
alps.c: [5] 00000000
alps.c: [6] 00001000
alps.c: [7] 00000000
alps.c: [8] 00000000

This is a list of all bits in a REAL 9p packet which remain OFF no matter what you do:

alps.c: [0] 11001111
alps.c: [1] 01111111
alps.c: [2] 00111010
alps.c: [3] 00111111
alps.c: [4] 11111111
alps.c: [5] 11111111
alps.c: [6] 01111000
alps.c: [7] 01111111
alps.c: [8] 01111111

If 9p packet has something which identifies it, it might be possible to find it using these two masks (possibly superimposed). The other possibility is that your current test is correct and it is the "1+2+3 Pad click", which identifies itself as *NOT 9p*.

Considering the HW design, I wouldn't be surprised if they didn't expect 3 button Pads while making your model, and now that there *are* 3 buttons, they have to signal (backwards-compatible) that 1+2+3 packet *IS NOT a real 9p*. We'll talk tomorrow, for now read up what I prepared for you this evening! :))

While I'm hunting for the complete 9p flag, consider this. I think we might be able to emulate two independent mouses. When Stick button is pressed, we remember it and until released, do not report this button in the Pad events. When Pad button is pressed, we remember it, and until released, do not report this button in the Stick events.

HW does this:
Push Stick button, move Pad -> generates Pad events with Stick's buttons!
Push Pad button, move Stick -> generates Stick events with Pad's buttons!

We would just add one state machine, which would remember one set of buttons (array[3]). Like HW reports. Every time there is a button pushed (previously released), we remember which dev sent it. Until we receive a packet with this button released, we do not report this button as pushed to input layer of the *other* device. Once we receive a packet (from ANY device) with this button released, we zero its state in our array[3] and report a release for the *original* device.

The genius of this is that X also has ONLY ONE SET of 1-2-3 buttons. Sure, input layer has button state for *each* device, but using the state machine, we prevent stuck buttons on our ALPS, but do not break other, independent, APLS (if any exist), because X don't see independent buttons anyway.

Thinking about this, I'm beginning to believe it would be the best solution and possibly, a similar concept to what Windows do.

I'll implement it and test thoroughly. If it works and behaves in X exactly like my ThinkPad Pad (including X events level), which is truly "2 independent mouses", we can conclude that this algorithm is orthogonal and can be used on all devices.

If we find something is fishy on e.g. 2-button ALPS, we would have to add a module parameter to allow this solution only selectively. Did you find any HW ID which would differentiate between 2- and 3-button version?

This is the same, I thinkt:

alps.c: E6 report: 00 00 64
alps.c: E7 report: 62 02 14
alps.c: E6 report: 00 00 64
alps.c: E7 report: 62 02 14

Wow, that's a huge load of research :-) If we keep pushing like this, I think we can nail it.

About X11: X11 does support multiple independent mice. It does have a so-called 'core pointer' which most apps use, and which is all the mice merged together. But there should be a few apps around (games?) which can use them separately. Granted, this might not make much sense for a Multitouch device, so it would not be a big loss if we were forced to give up this goal and merge the two sets of buttons.

Why I send the buttons signals in a 9p packet to both devices is just for the reason documented in the code: My hardware doesn't differentiate. When I'm moving stick and touchpad at the same time, it sends 9p packets, and any trackpoint buttons pressed at the time are signalled in the 9p packet. So I just don't see how I could tell whether the button pressed is touchpad or trackpoint. (Which would be a requirement to implement a state machine as you suggested -- right?)

My Alps reports as

[254754.807079] alps.c: E6 report: 00 00 64
[254754.831702] alps.c: E7 report: 62 02 14

We won't be able to tell them apart automatically, unless we look at BIOS data or something, which gives us the laptop model :-(

(I'm just working through your messages, so please don't be offended if I'm stating something stupid *g*)

IMHO there must be a way to tell apart a 6-byte packet with all buttons set from a 9-byte packet; this of course must be in the first 6 bytes of the packet.

BTW, your post in message #79 suggests, that the hardware only has one set of bits for all the buttons. You don't get desync there, do you? This suggests that button events are incidentially reported via touchpad (3byte) / trackoint (6byte) packets sometimes, but there's no guarantee for that to happen.

I totally agree on your theory how they came up with the idea to signal 9p with LMR set by the way. That's also what I thought, and that's why I added the DUALPOINT9 flag, so we don't break plain touchpads with three buttons.

@Charles: Thanks for confirming that there's still a weird condition in the two-buttons model. It's not a top priority at the moment, but of course we'll need to find out why that happens, too. Can you provide a 'dmesg' log with the logging patch applied when it happens? I've been struggling to reproduce it, but failed.

@Dave: Honestly, I don't know what the FIN bit even does. Do you still think it tells apart 9p from 6p? I'll try and find out if it does that for my hw.

Guys,
      Is there anything I can do to help. I'm really interested in testing the psmouse.ko, but I don't have an understanding how to use it or implement it.

RH

@Robert: You shouldn't replace your mouse module in /lib just yet. You can load a modified .ko by unloading the unmodified one (rmmod psmouse) and loading the one in your homedir by insmod some/path/psmouse.ko.

@Dave: OK, im officially giving up. My hardware reports button one as pressed in a touchpoint packet when I hold the trackpoint button and move my finger on the touchpad. So theres no way of telling the two sets of buttons apart reliably. We'll have to merge them.

I figure it's not that bad since the most obvious reason to tell them apart is disabling the enormously unnerving touchpad completely, and you don't care about the buttons really :-)

That being said, we still need a way to recognize fake 9p's on M4400's.

@Bystanders: Sorry for the spam, I hope we'll arrive at a reasonable driver at least in exchange for all that nonsense mails being sent.

@Sebastian(#112): Unless the fake 9p is related to the button state issue, I don't think it's vital that we differentiate 9p and 3 actual button presses. Unless people a) Actually need to press all three at the same time or b) accidentally do this occasionally.

Has anyone tried to contact Alps to see if they will give out any specs?

Could any of the be caused by these mouses are supposed to be multi-touch devices.

RH

Sebastian,
    I tried what you suggested and i can to the rmmod no problem but the insmod errors when i try to use the psmouse.ko that submitted. Is it specific to the kernel he ran at the time.

insmod: error inserting '/home/rhau/Downloads/psmouse.ko': -1 Invalid module format

RH

@Sebastian - I'd be happy to test the button-locking problem I'm observing. I'd be most grateful if Dave can post the compiled psmouse.ko module with that patch - that simplifies things greatly for me.

@Robert: Not sure what you mean by multi-touch device. At least from data it currently sends (in the mode it's put in by the driver), you can't get more than one position.

W.r.t. your insmod question: Seems like you have to recompile your kernel with the patch applied. There's no way around it :-)

@Dave: I can de-sync my Alps by doing the following: Press and hold all three trackpoint buttons; then move pointer via touchpad. This is to be expected, of course: Both devices share button bits, and using the touchpad triggers 6-bytes. There has to be a flag somewhere else.

@Charles: W.r.t. the button locking, I have a patch for that ready, however I'm too tired now, and I will post it tomorrow.

I don't know if it's been mentioned yet, and I hope that I'm not misunderstanding you, but there's no reason to recompile the whole kernel just to apply a patch to a single module. Get the source for your kernel, copy the config file from the boot directory, copy the Modules.symvers from the headers directory, and then "make prepare", "make scripts", and "make oldconfig". Apply the patch, and then make only the module that you want to rebuild. That is, in the case of psmouse, "make modules SUBDIRS=drivers/input/mouse". Then simply copy psmouse.ko into your modules directory, and it should work. I know I'm skipping a lot of steps, but you can use the information here to look up exactly how to do it.

I can confirm that Sebastian's patch solves the lost sync issue on my Dell E6400. Great work! But I'm still having the same problem as Erik mentioned in comment #81. However, I don't get any lost sync events.

OK, from scratch. These three patches, applied in sequence should fix most of the problem, including the locked mouse buttons chaos.

--- They don't fix --- the three-button combo of death (e.g. press three buttons and move the touchpad). I've been thinking about it and there just seems no way to deal with this in a sane way (see below) without requiring lookahead on the seventh byte. This would mean the driver locks up when is receives a six-byte packet while alle the buttons are pressed and would only unfreeze after the seventh byte comes in and clears up the situation.

There is nothing in the first byte, it's 0xCF always.
The second byte is purely motion data, and required in full for that
The third byte has one unused bit -- which is always zero for me -- and the ges/fin bits, which occur in all combinations in 6-byte packets. I've not analyzed 9-bytes thoroughly because it's difficult to move touchpad and stick while tapping. Still, this is an unlikely spot.
The fourth byte is actually different for the two types of packet. The lower nibble contains the mouse buttons or 1111, leading to the now well-kown problem. The upper nibble contains either PS/2 passthrough bits or coordinates data.
Byte five is motion data again.
Byte six is the last resort. Maybe the hw doesn't use the whole dynamic range of Z for the pressure.

Hello Sebastian, I had to give it a rest for a day and a half. I hope to start coding tomorrow.

If you don't mind, I'll be working on the vanilla .31 kernel source + your first 9p extension. It seems the cleanest and I have nice packet dumping integrated. :)

One extra thing I found, which caused desync was an unfinished impl of 9p. There's a check for 0's at 0x80 bit from byte 2-6. You had a note there that it's different for 9p (4 and 5 don't have 0's), but the check was unchanged! When I was experimenting with the 9p flag, I got desync when using the FIN, but only becase this test reported BAD_DATA to psmouse. :) I didn't notice it at first, but now it's fixed (testing 0's for 6p and 9p only in proper places) and I'm going for the 9p flag like a hungry hound! :) You can see from the 0 & 1 masks I posted which 0x80 bits remain 0's.

When that's finished, I'm definitely going to implement the state machine. We agreed the ALPS has only one set of button states and merging is the obvious easy way to fix it, but I really need independent behaviour. I believe keeping an internal buttons state and masking button events from the input layer will provide orthogonal equivalent of TWO independent mice. As you said, this works only for the CORE pointer, but in reality, that's exactly how the ALPS is going to be used. You can see all modern distros removed not only Input configuration from xorg.conf - everything is dynamic via HAL.

You are right, games or a proper xorg.conf (as was usual 2 years ago) would discover that button events are masked and the behaviour wouldn't be orthogonal, but let's be honest here - merging buttons wouldn't be either in this situation. What's more, Stick & Pad aren't going to be used like this. Their HW just doesn't support it, so we can merge or we can mask - either way it'll fix stuck buttons. I just prefer masking, because it can emulate 2 mice perfectly (under common X configs).

Do you agree? What about your latest patches? Did you find something new? Did you deal with the 9p flag vs. 3-buttons?

On Sa, 2009-11-14 at 17:52 +0000, Dave wrote:
> Hello Sebastian, I had to give it a rest for a day and a half. I hope to
> start coding tomorrow.
>
> If you don't mind, I'll be working on the vanilla .31 kernel source +
> your first 9p extension. It seems the cleanest and I have nice packet
> dumping integrated. :)

I believe the latest patchset fixes the locked buttons, and I'd like to
see if that is, in fact, true. It does that by keeping both input layer
devices in sync, i.e. broadcasting each button bit from the hardware to
both devices. So I'm happy about any testing this patch gets :-)

> One extra thing I found, which caused desync was an unfinished impl of
> 9p. There's a check for 0's at 0x80 bit from byte 2-6. You had a note
> there that it's different for 9p (4 and 5 don't have 0's), but the check
> was unchanged!

Which check exactly? In function process_byte? Note that for 9p
packets, there's an extra return statement. If you change the
conditions which recognize 9p/6p, you'll have to change that code, too.

> When I was experimenting with the 9p flag, I got desync
> when using the FIN, but only becase this test reported BAD_DATA to
> psmouse. :) I didn't notice it at first, but now it's fixed (testing 0's
> for 6p and 9p only in proper places) and I'm going for the 9p flag like
> a hungry hound! :) You can see from the 0 & 1 masks I posted which 0x80
> bits remain 0's.

The code that determines whether it's 9p or 6p is scattered in two
places. That's mainly an artefact of the previous driver implementation
which I didn't want to change drastically. I'm a little confused now,
in what way do you use FIN to distinguish between packets?

> When that's finished, I'm definitely going to implement the state
> machine. We agreed the ALPS has only one set of button states and
> merging is the obvious easy way to fix it, but I really need independent
> behaviour.

What do you mean by 'independent behaviour'? I don't see how you want
to achieve this. The hardware just doesn't give you the data from what
I can tell. Our first priority should be to fix the desyncs associated
with the three-button-pressing IMHO.

> I believe keeping an internal buttons state and masking
> button events from the input layer will provide orthogonal equivalent of
> TWO independent mice.

>From my experience I now beleive the hardware doesn't give us the actual
state of the buttons, but LOGICALOR(touchpad_button,trackpoint_button).
In this constellation, we only can lose, because there will always be
some corner cases where stuff breaks. YMMV.

> As you said, this works only for the CORE pointer,
> but in reality, that's exactly how the ALPS is going to be used. You can
> see all modern distros removed not only Input configuration from
> xorg.conf - everything is dynamic via HAL.

I don't see where the core pointer comes in here -- I think all the core
pointer does is, again, LOGICALOR(dev,dev2). So if one of your devices
has invalid button data, the core pointer's data may be invalid too.

Is your goal to be able to disable e.g. the touchpad buttons? I'm a
little confused about your intentions.

> You are right, games or a proper xorg.conf (as was u...

@Sebastian -
WOW. I applied your patches & installed the modified module about an hour or so ago, and have NOT seen the button lock problem yet (although I haven't been using my machine too extensively in that time).

So far, it also appears that my touchpad is registering scroll commands (along side of touchpad) much more reliably as well. I'm not sure if you did anything that should have affected that, but it's working nicely nonetheless.

I'll keep you informed if I observe other issues...

@Sebastian: I guess I didn't make myself clear. Typical usage is Stick+Pad are OR'd by the X in the "core" pointer. As you say. The point of the state machine (it's a s.m. only theoretically, it's very simple actually and there won't be any corner cases) is to *emulate* two independent mice when Stick & Pad are joined within "core" pointer. Emulate by simple button-event masking.

Stuck buttons issue is of course solved more easily by mere merging, as you did, but that way we really get just two pointers with one set of buttons. It's perfectly OK, because the ALPS behaves like this. It is our *obvious* way out. BUT - I don't like this behaviour. :) Most usage patterns wouldn't see any difference, but there are some patterns, which won't work with merged buttons. I'll describe it later, this is just a short reply to keep you updated and to *celebrate* another, the best so far, version based on our recent work and research. Yay! :)

Merging (cloning buttons into both Inputs) doesn't allow actions like: wheel emulation using btn3 on Stick AND no wheel emulation using btn3 on Pad (or some action on Pad *different* from Stick). Independent mice would have no trouble in such setup. If we mask ALPS buttons, this will work. Even the most border-line/special usage patterns would work as if two independent mice were used. For me, it's enough pain having to use Pad that I'd rather fix it myself.

I suggest you forget about it, I'll ask you to stress-test it when finished; check if it breaks something on your model, etc. OK? More important, as you say, is the 9p flag. I'll continue tomorrow - I spent all day today working on a new fence *outside*. Yep, one of _those_ experiences. :)

@Sebastian: The patches work for me! Fantastic!

After two full days of using the patch, most of my problems are all gone - it's been great. BUT:
Has anyone else noticed a 'double-click' issue? I've been having a tough time hitting a single click on the RH button - I end up grabbing/resizing window when I try to bring it to the front, popping up a separate view for my mail when I click on the header in kmail to read it.

Anyone else, or is this just me on my lonesome?

Guys,
       I finally got my e6500 back from dell repair. My laptop had 3 buttons on the trackpoint and 2 for the touchpad.

i remember when i was playing with this before, after upgrading to 9.10 i saw some errors in the background, but never had a chance to capture them. I checked all of the logs but it doesn't reflect this error.

usb_id[818]: unable to access "/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/event6"
usb_id[819]: unable to access "/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/mouse1"

is this related to the mouse on this machine.

RH

Ok, so Thanks to Charles, I managed to re-compile the git and get my psmouse.ko file. The mouse seems much better. I still see during reboot the errors above.

usb_id[818]: unable to access "/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/event6"
usb_id[819]: unable to access "/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/mouse1"

Any Ideas?

"AlpsPS/2 ALPS DualPoint TouchPad" id=10 [XExtensionPointer]
 Type is TOUCHPAD
 Num_buttons is 12
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
  Min_value is 0
  Max_value is 1023
  Resolution is 1
 Axis 1 :
  Min_value is 0
  Max_value is 767
  Resolution is 1
"DualPoint Stick" id=11 [XExtensionPointer]
 Type is MOUSE
 Num_buttons is 5
 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

Also Assuming this looks good in the logs now
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.282097] alps.c: weirderbit: 2
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.293329] alps.c: x = 775 y = 466
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.308898] alps.c: weirderbit: 2
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.320482] alps.c: x = 783 y = 466
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.331475] alps.c: weirderbit: 0
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.340910] alps.c: x = 786 y = 466
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.373790] alps.c: weirderbit: 0
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.384946] alps.c: x = 786 y = 466
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.508128] alps.c: weirderbit: 0
Nov 17 12:49:59 rhau-laptop kernel: [ 1742.519437] alps.c: x = 786 y = 466

RH

On Di, 2009-11-17 at 13:08 +0000, Robert Hau wrote:
> Guys,
> I finally got my e6500 back from dell repair. My laptop had 3 buttons on the trackpoint and 2 for the touchpad.
>
> i remember when i was playing with this before, after upgrading to 9.10
> i saw some errors in the background, but never had a chance to capture
> them. I checked all of the logs but it doesn't reflect this error.
>
> usb_id[818]: unable to access "/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/event6"
> usb_id[819]: unable to access "/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/mouse1"

Robert,

I guess not since the Alps unit is connected to an internal PS/2 port,
not via USB. I don't have that message in my syslog from what I can
see. It may be the RF killswitch?

--
Best Regards, | Hi! I'm a .signature virus. Copy me into
 Sebastian | your ~/.signature to help me spread!

My system is affected by this, but for some reason, right now, I woke up my laptop, and the flakiness is gone.

I have a feeling if I re-boot, things will go back to normal (normal means, it will do all the things already described here...)

My touchpad cursor is moving slower than usual, all buttons work, and I can move the thumb stick while hitting the touchpad, and nothing strange happens.

If there's anything I can provide, let me know.. But for now, I'm never rebooting!

@James: That happens after a lot of desync issues. The kernel module reverts to proto=bare. You can replicate this behavior on a running system by issuing the following commands as root:

# modprobe -r psmouse
# modprobe psmouse proto=bare

You can also modify your Grub config to get this at boot.

Ug. So nobody's seeing the double-clicking problem? I've had a hard time getting some usable output from /var/log/messages, but it looks like it's registering a second click when I use the lh pad or lh stick button:

Nov 18 13:08:38 nightfall kernel: [54580.133189] alps.c: weirderbit: 0
Nov 18 13:08:38 nightfall kernel: [54580.143690] alps.c: x = 106 y = 85
Nov 18 13:08:38 nightfall kernel: [54580.167968] alps.c: weirderbit: 0
Nov 18 13:08:38 nightfall kernel: [54580.180136] alps.c: x = 106 y = 85

I'm not seeing this on the stock module. It's not 100% repeatable, but it's common enough that it's moderately unusable - I'm reverting to the original psmouse.ko module until this problem goes away.

I wrote this mini HOWTO for people without kernel compilation know how. It's very easy, just apply those steps, I took care for everything else (I hope). :) I'm attaching the latest version of our patch - it was written by Sebastian and me. There is still one hidden hiccup, HW-based, which we can't seem to be able to solve to our satisfaction, but nobody will notice it during normal use. The keyword is "don't push all 3 TouchPad buttons at once!". :) See the descriptions above.

On the other hand, Sebastian's 9b packet handler makes lost syncs history and my button handling/masking brings you basically the full power of TWO independent mice! Yes, even on this joke of a touchpad. :) All the tricks I used on ThinkPad work now and those are some crazy combinations, I can tell you, requiring two distinct mice with their *own* buttons.

Change to root (su). Execute each "#" line as root separately and watch for errors. I tried to make it idiot-proof, but who knows. This HOWTO tries to get source and headers for your *currently running* kernel, patch psmouse, compile and replace your current driver with the newly patched one. On the fly! This is no win$hit, my friends. :)

Get all packages required for our compilation:

# apt-get install libncurses5 libncurses5-dev build-essential

Now download the source and headers for your running kernel:

# cd /usr/src
# KVER=$(dpkg -l | grep linux-image-`uname -r` | awk '{print $3}')
# HPKG=linux-headers-`uname -r`
# KPKG=linux-image-`uname -r`
# apt-get install $HPKG=$KVER
# apt-get source $KPKG=$KVER

Might take some time depending on your connection. Now module patching:

# KDIR=linux-`uname -r | sed 's/-.*//'`
# cd $KDIR
# cp /boot/config-`uname -r` .config
# cp /usr/src/linux-headers-`uname -r`/Module.symvers ./
# make oldconfig
# make prepare
# make scripts
# patch -p1 -b < /usr/src/alps-dave-2.6.31.patch

The last command should print just a bunch of "patching..." lines. No questions asked. If it fails, your kernel is too different from 2.6.31 for the patch utility to recognize where to insert the patch. Shouldn't happen though. Now let's compile as little as possible - just a couple of mouse modules:

# make SUBDIRS=drivers/input/mouse modules

You should now have your own "psmouse.ko" module -- fresh, patched and compatible with your running kernel. Let's backup & overwrite the currently installed driver with this new one:

# MDIR=/lib/modules/`uname -r`/kernel/drivers/input/mouse
# mv $MDIR/psmouse.ko $MDIR/psmouse.ko.bak
# cp drivers/input/mouse/psmouse.ko $MDIR/
# depmod -a

Now even if you reboot, the system will use your *new* psmouse module. OK, last step; let's replace the driver right now, without rebooting:

# rmmod psmouse
# modprobe psmouse

Wait for it... HAL should have detected it again and... there you go! Enjoy. :)

@charles: Hello Charles, the latest patch I just submitted fixes this behaviour. I noticed it too, in a different way, but I think I know what you mean. The patch is still being worked on; the button merging algorithm which is responsible for the double clicking was the most straightforward way to go at the time. I even agreed with Sebastian. Personally, I needed some time for other stuff before I could implement the button masking I promised. It should solve all button issues AND make the HW-merged devices perform in almost every respect like two *independent* devices.

Try the latest patch I uploaded just now. I've been using it for over a day and haven't had a single issue. And like I mentioned, all TP+Stick tricks I learned on my old ThinkPad work now. They require independent mice, so they wouldn't work with previous versions at all.

The more testing the better.

PS: uploading binary for Ubuntu "linux-image-2.6.31-15-generic-pae" version 2.6.31-15.50.

HOWTO update1: The patching line:

# patch -p1 -b < /usr/src/alps-dave-2.6.31.patch

refers to the patch uploaded as part of the HOWTO post and saved earlier by you into /usr/src/. I forgot to mention this implicit step, but I guess it's obvious.

On Mi, 2009-11-18 at 22:06 +0000, Dave wrote:
> I wrote this mini HOWTO for people without kernel compilation know how.
> It's very easy, just apply those steps, I took care for everything else
> (I hope). :) I'm attaching the latest version of our patch - it was
> written by Sebastian and me. There is still one hidden hiccup, HW-based,
> which we can't seem to be able to solve to our satisfaction, but nobody
> will notice it during normal use. The keyword is "don't push all 3
> TouchPad buttons at once!". :) See the descriptions above.
>
> On the other hand, Sebastian's 9b packet handler makes lost syncs
> history and my button handling/masking brings you basically the full
> power of TWO independent mice! Yes, even on this joke of a touchpad. :)

Great work! I'll check it out tomorrow :-)

--
Best Regards, | Hi! I'm a .signature virus. Copy me into
 Sebastian | your ~/.signature to help me spread!

Dave's patch seems to have solved my double-click problem (after testing for a few hours). I'm guardedly optimistic!

Sorry, I haven't been very responsive this week.

I have been in touch with Dmitry Torokhov who maintains the Input layer for Linux. He suggested a few changes, and I wrote a new version of the patch based on his suggestions. It also has a variant of Dave's 'button router'. This is now on the linux-input mailing list, and I hope for inclusion in Linux.

Nevertheless, I'd appreciate it if you guys gave the new version a spin and verify that all your favorite bugs are gone. Maybe someone could compile a readymade .ko for everyone to test with the stock ubuntu kernel?

Thank you guys for helping me on this!

A few minor details:

* The weirderbit is used as a button bit in some models.
* Waiting for a seventh byte after six have been received is not an option. The PS/2 driver will force desync in this case. I.e. detecting the packet lengh will need a redesign at a deeper layer. Nevertheless, if you don't press all three buttons, the driver should work :-)
* Dave says that the seventh byte is not even necessarily helpful.

I'm unable to apply your latest patch, Sebastian.

@Mark: Oh, I'm sorry. I forgot to mention that this patch is against upstream Linux. Please find attached a patch against karmic's kernel source.

@Sebastian:

I applied your patch to vanilla 2.6.32-rc8 and since then have been playing around a little bit. On an E5500 I tried using pad and stick at the same time, mixed button usage like mad and used the pad to scroll but did not encounter any issues at all.

Thanks so much for providing this great example of open source engineering.

Hey i haven't updated my patch to the newest one, but has anyone tried this with vmware. I'm having issues clicking now with the new patch.

I'm confused. Which version of the patch do you run?

Sebastian,
      Here is whats going on. I have run my VMware Windows VM lately. I ran it after installed karmic, and all worked fine. I recently turn it back on and the mouse won't click anywhere, and the mouse doesn't seem to track like it used to. The messages for the VM seam to think when I move the mouse that i click in and out of the vm.

Robert Hau
West Highland Support Services
917-657-0686 Cell
866-778-3484 x157 Office

----- Original Message -----
From: "Sebastian Kapfer" <email address hidden>
To: "robert hau" <email address hidden>
Sent: Monday, November 23, 2009 1:32:31 PM GMT -05:00 US/Canada Eastern
Subject: [Bug 296610] Re: ALPS DualPoint Touchpad flaky performance

I'm confused. Which version of the patch do you run?

--
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.797747] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5
Nov 7 22:23:03 peapod kernel: [46966.798897] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Nov 7 22:23:03 peapod kernel: [46966.805873] psmouse.c: DualPoint TouchPad...

On Mo, 2009-11-23 at 19:02 +0000, Robert Hau wrote:
> Sebastian,
> Here is whats going on. I have run my VMware Windows VM lately.
> I ran it after installed karmic, and all worked fine. I recently turn
> it back on and the mouse won't click anywhere, and the mouse doesn't
> seem to track like it used to. The messages for the VM seam to think
> when I move the mouse that i click in and out of the vm.

Maybe Vmware is configured to handle only the first mouse in the system?
I have no idea if such a thing is possible, never having used Vmware.

Do other apps show problems?

--
Best Regards, | Hi! I'm a .signature virus. Copy me into
 Sebastian | your ~/.signature to help me spread!

Correction this seems to be related to a java problem that caused stranger behavior, rebooting solved it.

First a "thank you" for the patch to all involved. The karmic stock kernel is really unbearable on Dell latitude E4300.

Has anyone found an easy reliable way to disable the touchpad completely? I've tried gpointing-device-settings and gsynaptics but the touchpad gets continuously re-enabled. Would it be difficult to add touchpad disable to the kernel driver as a module option?

@Antti: From what I can tell, this is not possible completely, as the hardware itself merges the two datastreams to some degree. It would be reasonably simple to disable the touchpad part and hardware tapping, the buttons on the touchpad are a different issue. So if you can live with the touchpad buttons and just want the touchpad to stop moving your pointer, yes, that is possible (though the option is not implemented yet).

@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.